제품의 안정성 증명과 해킹

제품의 안정성을 증명하기 위해 해커를 동원하는 것은 좋은 생각이 아니다.

사례1: Pitbull 시스템의 해킹 대회 사건(http://www.securityfocus.com/news/1717, http://www.wired.com/science/discoveries/news/2001/04/43234)
핏불 시스템이 자사 제품의 안정성을 증명하기 위해 해킹대회를 열었다가 LSD라는 팀에게 해킹당해 망신당한 사건. 이 대회의 정말 재미있는 면은 대회 후에 핏불 시스템이 LSD팀에 상금을 전혀 지급하지 않았다는 것이다. 이 이야기는 후에 해커들이 술자리에나 컨퍼런스에 모일 때마다 입에서 입으로 회자되며 안주로 씹히게 된다. 수년 간이나... 한마디로 회사 망신 제대로 시킨 것이다. 결국 작년인가 LSD팀이 컨퍼런스 참석하러 왔다가 아주 짤막하게 핏불에서 약속했던 상금보다는 한참 적지만 돈을 주기로 했다는 이야기가 뉴스로 나온적 있는데, 정말 지불했는지는 확인해보지 않아 모르겠다.

사례2: XX사 시큐어OS 해킹 사건
00사에서 마침 제품 도입 검토 중인 XX사 시큐어OS 제품의 안정성을 증명해달라고 했다가 취약점이 드러난 사건. 개발사 사장님도 동의하신 거니까 괜찮다면서, 프로젝트 중에 별도의 추가 비용도 지불하지 않고 덤으로 하게된 일. 작업 시작한지 얼마되지 않아 팀원 중 모모씨가 telnet localhost 하고 나자 시큐어OS의 모든 제한 정책에 적용을 받지 않게 되는 것을 발견함. 해당 제품은 원격 접속에 대해선 정책을 적용하고 로컬 접속에 대해선 신뢰할만한 내부자의 작업이므로 정책을 적용하지 않겠다는 단순한 생각을 갖고 있었던 것. 후에 이 취약점은 수정된 것으로 안다.

Professional Penetration Tester로 일하게 되면 '우리 사이트의 안정성을 "증명"하기 위해 모의해킹을 받고 싶다.', '우리 제품의 안정성을 "증명"하기 위해 모의해킹을 받겠다.'라는 무리한 요구를 자주 듣게 된다. 이들의 목표는 말그대로 "검토"가 아니라 "증명"이다. 이런 이야기를 들으면 해커들은 누구나 속으로 '피식~'하고 웃어버린다.

이런 요구는 얼핏 생각하기엔 상식적으로 맞는 것 같아 문제가 없는 것 같지만, 사실은 깊이 생각해보지 않아 착각을 한 것이다. 모의해킹은 '취약점이 존재한다는 것을 증명하는 작업'이다. '취약점이 존재하지 않는 것을 증명'하기 위해 '취약점이 존재하는 것을 증명'하는 방법을 적용하는 것은 잘못된 접근법이다. 위의 몇가지 사례만 봐도 쉽게 알 수 있는 일 아닌가?

이해가 어렵다면, 쉽게 개발자 논리로 이야기해보자. 디버깅은 '버그를 발견하고 고치기 위한 작업'이다. '버그가 존재하지 않는다는 것을 증명하기 위해 디버깅'을 하는 바보는 세상에 없다. 계속 디버깅하면 할수록 결국 미처 생각못했던 버그만 늘어날 뿐이다. 만일 추가적인 버그가 발견되지 않는다면 디버깅에 충분한 시간을 들이지 않은 것이다.

마찬가지로 '자사 제품/서비스의 안정성을 증명하기 위한 모의해킹'의 결론은 결국 '취약하다'로 끝날 수 밖에 없다.

내 얘기가 변방의 약소국가에 있는 허접한 해커가 한 소리라 못믿겠다면, 전세계 최고의 해커로 인정받는 Mudge의 이야기를 들어보자. 케빈 미트닉이 저술한 'The Art of Intrustion (한국어 번역서: 해킹 침입의 드라마)'를 보면 Mudge가 똑같은 상황에서 뭐라고 했는지 언급되고 있다.

'자신들의 보안은 완벽하다고 자부하면서 그걸 확인하기 위해 모의침입테스트 전문가를 고용한 회사들은 대부분 (결과가 너무 뜻밖이라서) 충격을 받기 십상이다. 보안 점검을 수행하는 전문가들은 늘 되풀이되는 비슷한 보안 실수들을 쉽게 찾아낸다.'
... 중략 ...
'따라서 기밀 정보를 훌륭하게 보호하고 있다는 사실을 확인받기 위해 모의침투 테스트를 의뢰하는 것은 어리석은 행동이다. 왜냐하면 전혀 반대의 결과를 얻는 것이 다반사이기 때문이다.'

이제 보안회사 모의해킹팀에게 '우리 사이트/제품의 안정성을 증명하기 위해 모의해킹이 꼭 필요하다.'는 무리한 부탁은 하지 말자. 솔직히 듣는 사람도 부담스럽다. 결과가 어떻게 나올지 뻔히 알기 때문이다. 

우리로선 왜 안좋은 생각인지 다양한 방법으로 설득하는 수 밖에 없는데, '그런 건 내가 알아서 책임질테니까 무조건 해달라'라고 고집을 부려 어쩔수없이 작업을 시작했다가, 원치 않는 결과를 들고 돌아가는 사람의 힘없는 뒷모습을 볼 때면 '회사에 가서 어떻게 하실려고 하는 걸까...' 하는 걱정과 함께, '아~ 왜 내가 뚫었을까?'하는 자괴감까지 들게 된다.

서로 곤란한 이런 상황은 이왕이면 피하는게 제일 좋지 않겠는가?

기억해둬야 할 큰 원칙
1. 버그가 있다는 것은 증명할 수 있어도 없다는 것은 증명할 수 없다.
2. 취약점이 있다는 것은 증명할 수 있어도 없다는 것은 증명할 수 없다.

참고로 마이클 하워드의 공격자/방어자의 딜레마도 기억해두면 좋다.
원칙 #1: 방어자는 모든 위치를 방어해야 한다; 공격자는 가장 약한 위치를 선택할 수 있다.
원칙 #2: 방어자는 이미 알려진 취약성에 대해서만 방어할 수 있다; 공격자는 알려지지 않은 취약성을 나중에 찾을 수 있다.
원칙 #3: 방어자는 항상 경계해야한다; 공격자는 아무 때나 공격할 수 있다.
원칙 #4: 방어자는 규칙에 따라 경기를 한다; 공격자는 반칙을 할 수 있다.
(Writing Secure Code, 2nd Ed.)
이글루스 가든 - professional secur...