Q 최근 보안 이슈가 발생하는 근본적인 이유는 무엇이라고 생각하시나요?
A 보안사고는 모든 영역에서 발생할 가능성이 있다. 어떤 경로가 1차적인 원인이 될지 판단하기 힘들다. 웹 서비스를 통한 침투, 개인PC 감염을 통한 침투, 외장 메모리 감염을 통한 침투, 무선 네트워크를 통한 침투, 버려진 쓰레기를 뒤져서 획득한 개인정보, 물리적인 접근 통제를 우회한 침투 등 매우 다양하다.
2013년에 보안 분야에서 화두가 된 것은 사이버테러다. 2013년에 3월과 6월에 발생한 공격을 모두 보면 근본 원인들을 파악할 수 있다. DDoS 공격만 부각하고 있지만 그전에 공격자들이 서버 및 개인PC를 좀비로 만드는 과정이 더 중요하다.
이 책에서는 기술적인 부분에 한해 중요한 몇 가지에 대해서만 살펴보겠다.
첫째, 웹 서비스의 소스코드 차원의 보안 문제다. 인터넷이 성장하면서 우리는 10년 넘게 웹 서비스 보안 진단을 하고 있다. OWASP[^1]에서 배포되는 가이드, 행안부-한국인터넷진흥원에서 배포되는 가이드를 보면 항목이 추가/수정됐을 뿐 원인과 대응은 동일하다. 그만큼 계속 가이드를 제공함에도 웹 서비스 침투를 통해 공격이 이뤄지는 원인은 뭘까?
[^1]: OWASP(https://www.owasp.org): The Open Web Application Security Project의 약자로 보안 영역에서 다양한 프로젝트를 진행하고 있다. 웹 애플리케이션, 보안 프레임워크, 모바일 보안, 시큐어 코딩 등 학습할 때 꼭 참고해야 하는 사이트다. 한국에서도 챕터가 있으며 현재 활발히 활동 중이다. (https://www.facebook.com/groups/owaspk/)
많은 서비스를 하고 있는 업체에 가서 보안 관리를 하면 이 원인을 바로 알 수 있다. 개발 단계에서부터 보안 검토가 이뤄져야 하는데, 이 프로세스가 정립된 곳이 많지 않다. 개발이 진행되기 전에 개발자 및 시스템 운영자, 프로젝트 담당자를 대상으로 보안 교육이 이뤄지고, 요구사항 분석, 설계, 개발, 배포까지 모든 단계에서 보안을 고려해야 나중에 서비스를 오픈했을 때 위협을 최소화할 수 있다. 그렇지만 서비스를 빨리 오픈해서 사업을 해야 하기 때문에 프로세스가 있더라도 제대로 따르지 않는 경우가 많다.
그 많은 서비스는 제각각 플랫폼도 다르고 사용되는 프로그래밍 언어도 다르다. 구축되는 서버의 환경설정도 모두 다르다. 이에 대한 가이드가 계속 업데이트되고 오픈하기 전까지 보안 검토가 모두 이뤄져야 한다. 컨설팅 업무를 할 때도 제일 어려운 부분이 환경에 맞는 가이드를 수립하고 교육하는 것이다. 웹 프레임워크 버전이 조금만 달라져도 가이드는 완전히 달라지고 그에 맞는 소스코드도 달라진다.
이런 프로세스를 완벽하게 구축해서 화이트박스 방식의 소스코드 차원의 진단까지 완벽하게 하려면 보안관리자 한두 명으로는 부족하다. 그렇기 때문에 소스코드 차원에서 보안을 강조하고 있지만, 현실적으로 어려움이 있는 것이고 이 안에서 조금이나마 허점이 발생할 경우 1차적인 공격 대상이 된다.
이 같은 상황에 대응하려면 적어도 아래와 같은 절차가 필요하다.
- 서비스와 관련된 보안 공통 모듈를 중앙에서 관리
- 개발자가 인수인계를 할 때 각 페이지에 보안 모듈 반영 여부에 대한 이력을 관리
- 각 단계별 보안성 검토(개발 전 교육, 개발 과정의 잠재적 취약성 분석, 소스코드 취약점 진단, 모의해킹 진단, 이행 점검 등)
둘째, 오픈된 서비스 관리다.
나는 군대와 비교해서 포털 서비스는 최전방이라고 부르고, 게임 서비스는 고지전이라고 부른다. 그만큼 두 서비스는 수많은 경로를 통해 공격받을 가능성이 많아서 공격에 대응하기가 어려운 서비스다. 반면 공격자 입장에서는 매우 흥미로운 곳이고 얻을 게 많은 곳이라서 매일 새로운 이벤트가 발생한다.
이런 곳은 보안관리자가 봐야 할 대응 지점이 많다. 서버 대수만 보면 몇 천 대가 되고 IP 대역으로 보면 몇 만 개의 IP 대역을 관리해야 할 가능성이 높다. 그토록 많은 곳에서 어떤 경로를 통해 공격이 침투할지 판단하기란 쉽지 않은 일이다. 관제 모니터링 업무를 하더라도 이벤트가 발생하거나, 침투가 발생한 뒤에 문제를 파악하는 경우가 대부분이다.
침해사고가 발생한 뒤에 해당 서비스를 파악하면 “이 서비스가 우리가 관리하는 게 맞아?”, “이 서비스 담당자가 누구야?”라는 문의가 많다. 서버접근통제 솔루션과 각 부서에서 서비스되는 운영 서버, 개발 서버를 관리하고 있다고 하더라도 모든 개발자가 하는 행동을 완벽하게 파악하기란 힘들다. 침투된 서버를 보면 대외 서비스가 아니라, 어떤 기능도 하지 않는 단순 서버거나 백업 서버인 경우가 많다. 이는 개발 테스트를 하거나 백업 용도로 마련해둔 서버는 물론이고, 그것을 관리하는 인원조차도 제대로 신경 쓰지 않기 때문이다. 방화벽에서는 대부분 80/TCP, 443/TCP 등 웹서버와 관련된 것은 열려 있는 경우가 많기 때문에 공격자는 이런 허점을 많이 이용한다.
방치된 웹서버는 많은 공격에 노출된다. 최신 취약점을 패치하지 않아 생기는 공격의 경우 단숨에 시스템까지 침투할 수 있는 공격 기법들이 공개돼 있기 때문에 이 서버가 1차적으로 침투당하면 데이터베이스 및 개인PC 및 근접 네트워크 대역에 모두 침투할 수 있다. 이런 공격 하나에 모든 서비스가 다 중지되는 경우도 있다. 공격하는 데는 1분도 안 걸린다. 관제업무도 주요 서비스의 이벤트에 초점을 두고 있기 때문에 수많은 이벤트에서 특정 공격이 연속적으로 발생하지 않는다면 이런 공격을 찾기란 쉽지 않다.
따라서 정기적으로 자사가 관리하는 IP 대역을 모두 스캔해서 불필요하게 열려 있는 서비스 및 포트에 대응해야 한다. 참고로 내가 일하는 금융권의 경우 ‘전자금융감독규정’을 예로 살펴보면 아래와 같은 조항에 불필요한 서비스/개발 서버 외부 접근 제한에 대해 언급돼 있다.
제17조(홈페이지 등 공개용 웹서버 관리대책) ① 금융기관 또는 전자금융업자는 공개용 웹서버의 안전한 관리를 위하여 다음 각 호를 포함한 적절한 대책을 수립·운용하여야 한다.
1. 공개용 웹서버를 내부통신망과 분리하여 내부통신망과 외부통신망사이의 독립된 통신망(이하 “DMZ 구간”이라 한다)에 설치하고 네트워크 및 웹 접근제어 수단으로 보호할 것
2. 공개용 웹서버에 접근할 수 있는 사용자계정을 업무관련자만 접속할 수 있도록 제한하고 불필요한 계정 또는 서비스번호(port)는 삭제할 것(다만, 사용자계정은 아이디 및 비밀번호 이외에 제37조에 따른 공인인증서 등을 추가 인증수단으로 반드시 적용하여야 한다)
3. 공개용 웹서버에서 제공하는 서비스를 제외한 다른 서비스 및 시험·개발 도구 등의 사용을 제한할 것
열려 있는 서비스의 포트를 진단하기 위해 오픈소스 도구인 Nmap이나 Superscan 등의 도구를 사용한다. 또한 유료 포트 진단 도구를 활용할 수도 있다. 열린 포트를 확인하는 데는 어려움이 없다. 그렇지만 포트가 열려 있다는 결과가 나왔을 때 해당 포트가 어떤 서비스를 운영하고 있는지, 실제 취약한 서버가 맞는지 하나하나 확인해야 한다. 수천 대의 서비스가 운영되고 있는 경우에는 이 많은 IP와 포트를 확인하는 데도 많은 시간이 소요된다.
이런 점을 고민하다가 NSE(Nmap Scripting Engine)을 업무에 활용하는 방안을 생각해냈다. NSE는 Nmap의 기능과 취약점 자동화 진단을 조합해서 사용할 수 있는 스크립트이며, 그림 1-7에 나온 예제는 wkhtmlimage[^2] 바이너리를 활용해 열려 있는 서비스의 화면을 자동으로 저장해서 결과를 출력한다.
[^2]: wkhtmlimage 다운로드: http://code.google.com/p/wkhtmltopdf/

열려 있는 포트를 점검할 때 자주 나오는 취약점들이 꼭 있다. 솔루션이 설치되면 관리자 페이지는 대부분 웹서비스로 구성돼 있다. 이 경우 특정 포트를 사용하며, 이 포트는 관심을 두지 않으면 금방 신경도 안 쓰게 된다. 위에서 소개한 톰캣 관리자 페이지도 이 중 하나다(물론 버전 6부터는 기본적인 관리자 페이지 및 계정을 사용하지 못하게 설정돼 있다. 하지만 항상 최신 버전을 유지한다는 생각은 버리자). 내부 시스템에서 사용하고 있을지라도 8080, 8888 같은 포트를 사용해 다른 시스템 영역과 동일한 방화벽 정책이 적용되면 외부에도 공유될 수 있다. 솔루션이라는 범위는 매우 넓다. 소스코드를 관리하는 서비스라고 한다면 내부 자산이 심각하게 노출될 수 있다. 인증서 승인이나 문서 승인 시스템이라고 한다면 개인정보나 내부 기밀정보가 노출될 수 있다.
건물에 설치돼 있는 무선 네트워크를 진단할 때 가끔씩 비밀번호가 설정돼 있지 않은 무선 AP가 연결되곤 한다. 연결된 AP를 중심으로 IP 대역을 모두 스캔해 보면 이 대역에 연결된 수많은 CCTV 관리자 페이지가 보이기도 한다. CCTV는 주차장을 포함해 각 층의 로비에 설치된 것이었으며 중앙에서 통제하는 시스템이었다. 이런 정보는 공격자에게 매우 좋은 먹잇감이다. 외부인뿐만 아니라 건물 내부에서 상주해서 일하는 업체 직원들도 이런 스캔 공격 기법을 조금만 알면 손쉽게 정보를 획득할 수 있다. 이런 정보를 가져가거나 이슈를 발생시킬 수 있는 경로는 아주 많다.
셋째, 개인PC 보안 관리다.
아무리 강조해도 지나치지 않는 것은 바로 개인 사용자의 보안 의식이다. 어떤 기술적인 부분을 강화하더라도 임직원들이 보안에 관심이 없다면 무용지물이 될 수 있다. 개인PC에서 감시/통제해야 할 부분은 너무 많다.
개인PC 보안을 위해 ‘저장매체 접근 통제’, ‘안티 바이러스’, ‘유해 사이트 차단’ 등 악성코드와 관련된 솔루션을 많이 설치하고 있다. 그렇지만 보안을 강화할수록 임직원들의 불만은 커지는 편이며, 각 팀에서는 업무상의 이유로 보안 솔루션 통제에서 일부 기능을 제외하고 있다. 뜨거운 감자인 ‘망분리’ 이슈도 개인PC를 통한 사고가 많이 발생했기 때문이라고 할 수 있다.

유해 사이트를 차단하더라도 평소에 방문하던 사이트가 감염되면 사용자들은 자신도 모르게 악성코드가 설치되는 공격(Drive by Download)에 노출되고, 알려지지 않은 취약점(제로데이)에 의해 컴퓨터가 장악된다.
웹 서비스를 통해 침투하는 경우보다 개인PC를 경유지로 내부 시스템을 침투하는 편이 훨씬 수월하기 때문에 공격자는 어떻게든 개인PC를 장악하기 위한 방법을 생각한다.
언젠가는 원천적인 대응 방안이 나올 것이라 믿으면서(진짜 나올지는 의문이다) 그때까지는 임직원이 어떻게 하면 보안 인식을 강화할 수 있는지 장기적인 교육과 프로그램을 도입해야 한다.
여기서는 모의해킹 및 악성코드 감염 관점에서 세 가지 대표적인 예를 들었지만 이 밖에도 보안을 적용해야 할 영역은 많다. 매년 각 영역에서 강화해야 할 부분에 대한 계획을 수립하고 이를 추진해야 한다.