NHN(대표 김상헌)이 운영하는 국내 최대 포털 네이버를 대상으로 beistlab이 아주 짧은 시간에 만들어진 점검툴로 테스트한 결과 대량의 버그들이 발견되었다. 특히 발견된 버그들은 어려운 유형의 XSS가 아니라 비교적 쉬운 유형의 XSS였다. 왜 이런 결과가 나온 것일까. beistlab 이승진씨는 자신의 블로그에 자세히 포스팅하고 있다. 다음은 beistlab 이승진씨의 허락을 받아 데일리시큐에 전문을 게재한다. [편집자 주]
 
우리나라에서 가장 유명한 포털 사이트인 네이버에서 무려 22개의 XSS 취약점이 발견되었다. 최근 매체에서 네이버의 XSS 취약점들이 기사화된 것을 보았고 “네이버의 보안 수준”이 궁금해 본 프로젝트를 진행하게 되었다. 과거 네이버의 취약점들을 네이버 보안팀에 알려준 경험이 몇번 있으나, 사이트의 보안 수준에 대해서 객관적으로 평가를 해본 적은 없었기 때문에 이런 호기심이 생겼다.
 
시작하기 전에 몇가지 언급하겠다. 기존에 공개되어있는 웹 보안 점검 툴들은 대체로 효과적이지 않기 때문에 사용하는 사람들도 좋은 결과를 기대하는 경우는 별로 없다.
 
또한 네이버는 굉장히 많은 서버, 도메인, 그리고 페이지가 있다. 보안팀 인력이 많다고 해도 모든 페이지에 대해서 일일이 수작업으로 검증하는 것은 쉽지 않다.
 
마지막으로, 아직까지 국내 개발자들은 시큐어 코딩(Secure Coding)에 익숙하지 않다. 즉, 네이버 같은 대형 사이트에서는 버그 없는 사이트를 유지하기란 매우 어렵다고 볼 수 있다.
 
위와 같은 이유 때문에 프로젝트를 시작하기 전에 몇가지 룰을 정해놓았다. 이 프로젝트의 특징은 다음과 같다.
 
[프로젝트 특징]
1. XSS 발견에만 초점:
서버 프로그램의 취약점을 찾는 행위는 법적으로 문제가 될 수 있기 때문에, 주로 클라이언트에 영향을 주는 버그인 XSS 발견에만 초점을 맞추었다. (물론, CSRF로 확장되어 악용될 가능성도 있다.)
 
2. XSS 발견 자동화 프로그램 제작:
대형 사이트의 보안 수준을 체크해야 하기 때문에 프로그램을 제작한 후, 취약점을 자동으로 발견하는 방향으로 진행되었다.
 
3. 수작업을 통한 해킹은 제외:
보안 전문가에 의해 진행되는 수작업을 통한 세밀한 해킹은 네이버뿐만 아니라 해외의 유명 사이트들에서도 마찬가지로 취약점이 발견될 수 있기 때문에 보안 수준을 객관적으로 측정하기 위해 수작업 해킹은 제외했다.
 
4. 단시간내의 프로젝트 진행:
이 프로젝트는 한명의 해커가 짧은 시간 내에 얼마나 많은 버그를 찾아낼 수 있는지 알아보기 위함이다. 만약 짧은 시간에 많은 버그가 발견되었다면 그만큼 보안 수준이 낮다고 볼 수 있기 때문에 이러한 규칙을 세웠다.
 
이 프로젝트를 통해 다음과 같은 결과를 얻었다.
[프로젝트 결과]
1. 프로젝트 진행 시간
– 총 진행시간: 8시간
– 자동 취약점 점검 프로그램 제작: 1시간
– 프로그램 실행 시간: 6시간
– 검증 시간: 1시간
 
2. 발견한 XSS 버그
 – 총 버그 갯수: 22개
 – 버그가 발생한 페이지수: 14
(하나의 페이지에 여러 XSS 취약점이 존재하는 경우도 있음.)
 
위 결과를 통해 알 수 있듯이, 짧은 시간에 대량의 버그가 나왔다. 프로그램을 실행한 시간동안 필자는 수면을 취하고 있었으므로, 실제로 본 프로젝트에 투자한 시간은 2시간이다.
 
프로그램의 원리는 단순하다. 필자는 프로그램을 파이썬으로 작성했고 해당 프로그램이 수행하는 기능을 요약하면 다음과 같다.
 
1. naver.com 사이트 크롤링 (하위 도메인 및 페이지 포함)
2. 인자가 들어가는 페이지들을 식별한 후 파싱
3. 사용자로부터 문자열을 입력받는 페이지들에 특정 crafted 스트링을 삽입
(속도 문제로 인하여 정수형 인자만 받는 페이지들은 테스트에서 제외)
4. Response 받은 페이지를 다시 파싱하여, crafted 스트링이 어떻게 해석되었는지 확인
5. 해석된 결과에 따라 XSS 가능성 여부를 판단하여 기록
6. 마지막으로 “검증 시간” 과정에서 프로그램이 발견한 버그들이 실제 버그가 맞는지 검증
 
이 프로그램은 제한된 시간 내에서 작성된 것이다. 만약 시간을 더 투자해 프로그램을 업그레이드할 경우 더 많은 버그를 네이버 사이트에서 발견할 수 있을 것으로 생각한다. 이 프로젝트는 즉흥 아이디어를 구현한 것이기 때문에 naive하며, 위에서 설명한 작동 원리 역시 기본적인 내용이다.
 
[프로젝트 시사점]
이 프로젝트의 결과를 통해 어떠한 점들을 시사할 수 있는지 알아보겠다.
1. 국내 대형 포탈 사이트들의 보안 수준
본 프로젝트는 네이버를 대상으로 진행했으나, 네이버뿐만 아니라 기타 다른 국내 포탈 사이트도 네이버와 비슷한 보안 수준을 갖고 있을 것이라 생각하고 있다. 따라서 여기서 언급하는 부분은 네이버에 국한된 내용이 아니라 다른 국내 사이트에도 적용된다고 볼 수 있다.
 
결과를 다시 정리해보자면 다음과 같다.  
– 아주 짧은 시간에 대량의 버그들이 발견되었으며
– 발견된 버그들은 어려운 유형의 XSS가 아니라 비교적 쉬운 유형의 XSS다.
 
따라서 우리나라 포털 사이트들의 보안 수준은 낮다고 볼 수 있다.
 
적어도 XSS에 대비한 코딩은 매우 미흡하다고 증명된 것이다. XSS 버그를 완벽히 예방하는 것은 어려운 일이지만, 발견한 버그들은 비교적 쉽게 찾을 수 있는 유형의 버그였다. 따라서 XSS가 아닌 다른 해킹 기법에 대비한 코딩도 잘되어있지 않을 것이라 예상할 수 있다.
 
실제 시도를 해보지 못했기 때문에 정확한 의견을 내기는 어렵지만, 다른 유형의 버그들도 비슷한 난이도의 수준에서 발견할 수 있을 것으로 예측한다.
 
다시 한번 언급하지만, 본 프로젝트에서는 XSS 유형의 버그를 발견하는 것에만 초점을 맞추었다. 서버단에서 발생할 수 있는 취약점들에 대한 스캔은 법적으로 문제의 소지가 있기 때문이다.
 
2. 해외 포털 업체와 비교한 국내 포털 업체의 보안 수준 향상을 위한 노력
먼저, 해외 포털이나 국내 포털 회사에서 일해본 경험이 없기 때문에 저자가 알고 있는 지식이 사실이 아닐 수도 있음을 밝힌다. 여기서 서술하는 정보는 각 회사들에 근무하는 주변의 지인들로부터 들은 이야기이고, 필자 나름의 기준으로 평가를 내린 것이다.
 
자체 보안팀을 갖고 있는 것은 해외, 국내 모두 동일하다. 보안팀 내부 상황이나 현실적인 문제에 대해서는 필자가 알 수 있는 방법이 없으므로, 외부인의 관점에서 봤을 때의 차이점을 표로 나타내봤다.

 
 위 비교표에 대해서 추가적으로 설명하겠다. 우선 구글이나 페이스북의 경우엔 해커가 취약점을 발견할 경우 이에 대해서 공식적으로 접수받는 창구를 마련하고 있다. 심지어 리포트를 할 경우 보상금까지 지급한다. 명예와 함께 일석이조를 취할 수 있다.
 
여기서 주목해야 할 부분은 보상금이 아니다. 공식적인 접수 창고를 만들었다는 것 자체에 의미를 부여해야 한다. 이것이 보안을 위한 최선의 방법은 아닐지라도, 최대한 많은 정보를 입수해 사용자를 보호하려는 노력을 한다는 것을 알 수 있다.
 
외부 전문가 활용면에서도 차이가 난다. 구글의 경우 자체 보안팀에 월드 클래스 해커들을 다수 보유하고 있음에도 불구하고 또 외부 보안 컨설턴트를 고용해 자사 제품의 보안을 강화하고 있다. 자체 보안팀이 보지 못하는 부분을 외부 인력을 활용해서 해결하려는 노력이라고 할 수 있다.
 
반면에 국내 회사들은 자체 보안팀이 있다는 명목하에 외부 보안 전문가들의 도움을 받으려는 의지가 강하지 않다. 이러한 부분은 보안팀의 잘못이 아니라 임원들의 잘못된 결정 때문에 일어나는 경우가 많다. 의사 결정권자들은 보안을 위해 어떤 투자를 해야 하는지 이해가 부족한데, 우리나라는 엔지니어들의 의견이 강하지 않기 때문에 임원들을 설득하기가 어렵다.
 
3. 침해사고 발생 시 법정에서의 불리함
과거 본 블로그를 통해 “침해사고 재판 시 해킹에 사용된 기술의 난이도가 미치는 영향“에 대해 알아본 적이 있다. 간단히 요약하면 “쉬운 난이도의 취약점을 보유했다고 판단될 경우 배상 금액이 커질 가능성”에 이야기하고 있는 글이다.  
-관련 글: beistlab.com/2012/03/08/lg_elec_breach/ 
 
국내에서는 침해사고의 유형에 따라, 법정 소송이 진행될 수 있다. 본 프로젝트의 결과로 비추어봤을 때, 네이버의 보안 수준은 높지 않다고 할 수 있다.
 
즉, 이러한 결과들이 미래의 법정소송에서도 영향을 줄 수도 있다. 물론 XSS는 CSRF 등으로 활용되지 않는 이상 서버단의 취약점으로 발전될 수 있는 확률이 높진 않지만, 기존에 공개된 버그들을 평가해 재판에 적용할 수 있다는 가능성을 배제할 순 없다.
 
본 프로젝트를 통해 알아낸 22개의 버그는 이미 5월 달에 네이버 개발팀에(보안팀에 알리려 했으나, 네이버는 보안팀이 취약점 접수 업무를 공식 담당하지 않아서 개발팀에 리포트했다.) 통보되었으며, 악용의 소지를 막기 위해 버그에 관한 상세 정보는 공개하지 않는다.  
 
마지막으로, 비록 네이버의 보안 수준이 낮다고 평가되었음에도 불구하고 이를 전적으로 보안팀의 잘못으로 보기에는 어렵다.
 
대형 기업들은 한가지 이유 때문에 보안 수준이 낮아지지 않는다. 시큐어 코딩에 대한 이해가 부족한 개발자, 예산 결정권자들의 보안에 대한 이해 부족, 바쁜 업무에 시달려서 정작 본인들의 업무를 못하게 되는 보안팀 등의 복합적인 문제가 섞여 있다고 볼 수 있다.
[글= beistlab 운영자 이승진]