IBM 해킹에 비춰본 웹서비스 보안

5.18일 researcher.ibm.com 메인 페이지 변조, SQL Injection에 의한 권한 획득

웹서비스 보안에 대해서 문제점과 대응방식의 변화에 대해 이야기를 한지는 아주 오래되었고 지금도 계속 하고 있다. 그러나 변화는 멀었고 아직 인식도 멀리 있는 상태이다.

문제 해결을 위해 security service를 기획하고 제안 했지만 결국에는 아무도 나서지 않아 직접 할 수 밖에 없었던 지금과 관련된 이야기다. 오늘자 기사로 researcher.ibm.com과 같은 중요 서비스에 대한 직접 해킹과 전 세계에서 가장 점유율이 높은 웹 취약성 진단 도구인 Appscan의 주인이 IBM 이라는 점은 심각한 시사점을 던져 주고 있다. 또한 필자 본인이 본 관점이 정확했음을 입증하고 있다.

< zone-h 의 researcher.ibm.com 미러 페이지>

* SQL Injection을 이용했다는 것은 시스템의 권한 획득은 물론 취약성 자체가 DB의 권한을 통해 웹서버를 통제함으로써 DB의 내용도 모두 통제 하고 있다는 것과 동일하다. 페이지 변조에만 관심을 두어서는 안된다. 지금 이런 유형의 일들은 항상 그리고 거대 규모로 일상적으로 일어나고 있는 위험들이다. 만약 변조가 없었다면 내부 침입으로 이어 졌을 것임은 당연한 일이 아닐까? 이것이 모든 기업과 기관, 국가들이 직면한 딜레마이다.

스캔 서비스의 현재 최대 덕목은  정확하고 가급적 많은 취약성의 진단으로 판정을 하고 있다. 그러나 과연 이것이 적합한 것인가? 질문에 대한 답을 볼 수 있는 사건이다. 언제나 발생 할 수 밖에 없는 그런 일들이지만 말이다.

IBM은 현재 가장 정확하고 방대한 Application scanner인 Appscan을 보유중이고 전 세계적으로 점유율도 높으며 판매도 강화하고 있는 Application Security의 주력 제품이다.

Appscan을 이용해 미국방부 및 기업들의 보안성을 강화 시켜 주는데 정작 아이러니컬 한것은 researcher.ibm.com 리서처 사이트는 Application 취약성에 의해 권한 획득을 당했다는 점이다.

< 미 국방부의 3단계 어플리케이션 보안 강화를 위한 SDLC 모델>

* 2006년 부터 진단과 수정, 보완이 시작된 것으로 알고 있지만 현재까지도 진척률은 미미하다. 그리고 진단이 완료된 서비스들은 한번도 변화하지 않았을까?. ^^; 딜레마이며 이 문제로 인해 2011년 미공군은 빠른 속도가 장점인 별도의 진단 스캐너를 공식적으로 도입한다. 완벽한 프로세스의 정착이 그만큼 어려우며 또한 현재의 SDLC 모델은 최소한 Web application에 대해서는 맞는 모델이 아니라는 입증된 결과를 보여주고 있을 뿐이다.

단 하나의 웹 서비스라면 문제는 다르다. 완벽하게 관리를 하고 체계적으로 또 실험적으로 적용 할 수 있을 것이다. 그러나 수십, 수백여개의 웹서비스를 관리해야 하는 회사나 담당 부서라면 과연 무엇을 해야 하는가? 또 무엇이 가장 필요한가?.

웹서비스의 절대과제는 널리 사용자들에게 서비스를 알리고 접점의 역할을 하는 것이지만 지금은 다른 용도로도 널리 쓰이고 있다. ( 공격자에 의해 악성코드 전파의 수단으로 이용됨.)  이미 악성코드 유포에 이용이 된다는 점은 웹서비스의 소스코드 변경을 전제로 한다. 소스코드의 변경은 권한을 가지고 있을때에만 가능하다. 매주 마다 수백여개 이상의 웹서비스들에서 무시하지 못할 수치의 악성코드들이 뿌려지고 있는 상황에서 과연 그 서비스를 운영하는 기업들은 자신의 서비스에서 악성코드를 뿌리고 있다는 것을 알기나 할까?

웹서비스의 현재 보안수준을 직접 확인 할 수 있는가?

웹서비스 진단은 언제 끝났으며 그 사이 변화나 갱신은 한번도 없었는가?  ( CEO나 회장님 지시로 한시간 만에 급조한 페이지나 이벤트들은 없었을까? .. 의문이다. 의문)

외부에서 접속이 가능한 웹 서비스들은 대체 얼마나 있으며 그 모든 것들에 대해 안전한 상태를 유지 하고 있는가?

웹서비스의 보안성 유지는 절대적인 미션이다. 그 미션의 유지에 기본이 되는 것은 100%에 가까운 보안성을 유지하는 것이 아니다. 분명히 말하지만 항상 보안성을 100% 가까이 유지 하는 것은 불가능에 가깝다.  보안 전문업체를 활용해도 마찬가지 이다. 그 원인의 첫번째는 보안도구들의 한계와 웹의 잦은 변화를 따라 갈 수 없는 현실에서 기인한다.

잦은 변화를 따라가면서 현재 전체 서비스에 대한 수준을 일정 수준 이상 유지해야 하는 절대적인 생존 법칙이 있다.  

 * 여기서의 일정 수준은 자동화된 공격 도구들에 의해서는 손쉽게 당해서는 안되는 것이며, 또한 알려진 취약성에 대해서도 기본적인 대책이 되어야 함을 의미한다. 

수준의 유지와 전체 외부 노출 서비스에 대한 관리를 위해 우리는 보안 진단 스캐너와 수많은 보안 컨설팅, 관제 등의 서비스들을 활용하고 진단 인력을 동원한다. 그중에서 진단 스캐너의 목적은 100%에 가까운 진단이 가능한 것도 있어야 하지만 모든 것에 대한 일정수준 유지에는 극명한 한계를 가지고 있어서 불가능한 면이 많다. 그렇다면 일정수준 유지를 위해서는 무엇이 필요한가?

수준유지를 위해 필요한 포인트는 정확하고 많은 취약성의 진단이 아니라 가장 빠르고 손쉽게 점검이 가능한가?..접근성은 좋은가?, 결과는 명쾌한가? 웹 서비스 개발속도에 전혀 영향을 주지 않을만큼 빠르고 심플한가가..핵심이 되어야 가능해 진다.

긴 점검 시간과 복잡한 결과, 사전만한 사이즈의 결과 리포트 ( 어떨때 보면 전문가들도 가르치려 하는 그런 뉘앙스를 느낄 때도 있다. )로는 현재의 문제를 극복하지 못한다. 문제의 핵심을 직시해야 한다.

현황:  

- 웹 서비스는 변화가 많다. ( 잦은 변경)

- 보안 취약성을 제대로 이해하는 개발자도 부족하고 진단 보고서를 이해하는 개발자는 더욱 적다.

위의 현황은 현실에서는 부정 할 수 없는 내용이다. 전문가들 조차도 제대로 이해를 못하는 상황에서 개발자들까지 이해를 한다는 것은 뜬구름일 뿐이다.  특히 한국의 경우 웹 개발은 개발 프로젝트로 제대로 인정 하지 않으며 모든 업무에서 기한의 압박과 하찮은 일이라는 시선 같은 이중고에 시달리고 있다. 이 상황에서 보안을 하라는 것은 불가능에 가깝다. 특히 사전과 같은 두께의 보고서와 처음보는 낯선 용어들의 나열은 좌절감을 극대화 시킬 뿐이다.

현실:

- 고객사들은 100%에 가까운 모든 취약성을 진단하고 제거 하기를 희망한다. 

- 스캐너들은 점점 더 무거워지고 어쩌면 공격도구에 가까운 기법들을 사용한다.

- 점점 더 진단 보고서들은 난해해지고 두꺼워 진다. 그래야 전문성 있게 보이나 보다.

- 모든 웹서비스들을 진단 하는데에는 엄청난 시간과 인력, 비용이 소요된다. 그래서  샘플링으로 진단을 할 수 밖에 없다.

- 즉 일년에 한번 진단 하기도 힘든 웹서비스들은 늘어만 간다.

- 진단을 받아도 외부 노출된 웹 서비스들중 방문자가 많은 사이트, 중요하다고 생각되는 사이트만을 선정하여 진단을 한다.

현실에서의 문제와 요구사항들은 문제해결과는 다른 길로 인도하고 있다. 만약 충분한 전문인력을 보유하고 있고 비용에 대해 부담이 없는 기업이라면 얼마든지 전체에 대해 100% 가까운 진단과 수준을 유지하는 것에 기꺼이 박수친다. 그러나 문제를 직시해 보자.  보안진단 비용이 웹서비스 개발과 운영 비용 보다도 휠씬 더 많이 소요 된다면 과연 그 웹서비스를 계속 유지 하는 것이 합당 할까? .. 이 질문에 대해 답을 할 수 있어야 한다. 모든 문제를 풀때 정답에 가까운 것은 비용 대비 효과가 충분한가 하는점이다.  

문제의 직시:

- 웹 서비스는 수시로 변경 되고 갱신된다. 작은 변경에도 DB까지 직접 공격 당하는 취약성은 언제든지 발생 될 수 있다.

- 많은 웹서비스들이 있는 회사라면 전체의 상황을 일정 수준 유지 할 수 있어야 한다. 외부 노출된 모든 서비스들이 대상이 되어야만 한다.

- 진단보고서들을 이해하고 적용 할 수 있는 사람이 없다. 그냥 보고서만 받고 묵혀둔다. 일단은 면피용이다.

- 취약성 스캐너의 사용과 결과를 이해 할 수 있는 사람이 내부에 없다.  ( 즉 보고서가 나와도 해독불가의 상황)

- 중요한 서비스의 기준은 방문자가 많은 서비스가 아니라 외부 노출된 모든 서비스가 중요하다. ( 모든 서비스는 내부망으로 이어져 있다. )

결론적으로는 이렇다.

문제의 핵심은 웹 서비스의 잦은 변화에도 손쉽게 사용 할 수 있고 결과도 직관적이며 접근성도 매우 높은 심플한 보안서비스가 절대적으로 필요하다는 것.  100%를 추구하는 것은 1~2년에 한번씩 진행해도 된다. 그와는 별개의 수준 유지를 위한 도구나 서비스가 필요하다는 점이다. 

정말 중요한 것은 10개의 서비스중 4개는 100%이고 나머지 6개는 50% 미만이라면 그 기업의 안전도는 50% 미만인 것이다. 평균은 가장 보안 수준이 낮은 서비스가 평균이 된다. 우린 이 평균을 끌어 올려야 손쉽게 당하지 않으며 일정 수준의 관리가 가능해 지는 것이다. 모든 것은 연결 되어 있다. DMZ Zone에 포함된 서버들, DB에 접근이 가능한 모든 웹서비스들은 치명적이다. 방문자가 많고 중요도에 따라 우선 순위를 정하는 것은 아무런 의미가 없다는 점이다. 가장 관리가 안되는 서비스의 해킹은 상대적으로 쉬울 것이다. 또 그 서비스와 연결된 내부망은 어떻게 보호 할 수 있을까? 

IBM의 해킹을 보면서 ( 역설적이게도 가장 잘 진단한다고 하는 취약성에 의해 당했다.) 처음 서비스 모델의 진단서비스를 기획할 수 밖에 없었던 5~6년전의 경험들이 눈앞에 떠올라 길게 써본다. 

강력한 보안 진단 제품을 가지고 있는 IBM 조차도 전체의 일정수준 유지에는 어려움을 겪고 있다. 이 상황에서 일반 기업들이 유지 할 수 있을 것이라는 점은 상식을 벗어난다. 필자가 개발한 서비스에 대한 언급도, 설명도 할 필요가 없다. 그 필요성과 존재 이유를 가장 잘 설명해 주는 예가 눈 앞에 있는데 무엇을 더 설명 해야 할까?

입 아프게 말을 할 필요가 없다. 앞으로도 계속 될 문제들이며, 우린 아직 정리도 못한 상황이다. 즉 계속 될 문제라는 점은 확실하다. 

* 한국내에서도 일정 규모 이상의 공공 사업에는 Secure coding을 적용 한다고 한다. 그 Secure coding 이라는 것은 진단 스캐너 보다도 호흡이 긴 작업이다. C/S 베이스의 코딩에 대해서는 강력하게 추천하나 이 Secure coding이 웹 베이스까지 확장 되는 것에 대해서는 우려를 표시 할 수밖에 없다. 어플리케이션 진단 스캐너 조차도 수준 유지와 꾸준한 관리가 어려운 판국에 더 긴 주기를 가진 것으로 보호를 하겠다는 것은 넌센스감도 되지 않는다. 현실을 모르면 배는 산에 올라가도 산이 산인줄을 모른다. 지금이 그 상황이다. 

Secure coding은 권고로 하되 전체의 외부 노출 서비스를 일정수준 유지하고 체크 할 수 있는 지수의 운용, 효율적 점검 방안의 수립이 휠씬 더 필요한 상황이다.

-바다란