왜 웹이 뚫리는가?
(Why software fails in Security?)
배상우 선임 컨설턴트
STG 시큐리티 SSR팀
swbae@stgsecurity.com
연/재/목/차
1회 : 웹 애플리케이션 해킹 기법
- 국내외 보안 동향(이번호)
2회 : 안전한 웹 애플리케이션 개발 방법론(6월호)
버그 없는 프로그램은 없다. 비단 '버그가 있다는 것은 증명할 수 있어도 버그가 없다는 것은 증명할 수 없다'는 유명한 말을 거론하지 않더라도 이에 공감하지 않는 사람은 없을 것이다. 푸른색 화면에 알 수 없는 메시지를 뿌리고 죽어나가는 윈도우즈, 하루라도 멈춰서지 않으면 돌아가지 않는 컴퓨터 때문에 얼마나 많은 밤을 날려버린 작업을 복구하느라 죄없는 머리카락만 쥐어뜯었는가?
깨지기 쉬운 소프트웨어(Fragile software)
날려 버린 작업은 아까운 일이지만 워드 문서 한두 개쯤 날아갔다고 해서 보안에 큰 영향을 미치는 것은 아니다. 하룻밤 밤샘 노가다로 복구할 수 있는 문서 자료로 인해 거대 운석이 지구에 부딪쳐 종말을 맞게 된다거나, 회사가 도산할 일은 없기 때문이다. 그러나 삭제된 자료가 워드 문서가 아니라면 이야기가 조금 달라진다. 몇 년간의 회계 자료가 담겨있는 DBMS를 통째로 삭제해버렸다던가, ERP 시스템이 멈춰버려 회사 전체 업무가 마비된다던가 하는 경우 작게는 수천에서 크게는 수조원의 피해가 발생한다.
우리에게 다행스러운 점은 모든 버그가 파괴적인 영향을 일으키는 것이 아니라는 점이다. 버그 중 극히 일부에 해당하는 버그만이 시스템에 파괴적인 영향이나, 보안상의 문제를 일으킨다. 그렇기 때문에 우리는 오늘도 마음 놓고 전철을 타고, 불을 켜고, 커피를 마시면서 작업에 몰두할 수 있는 것이다.
최근 미국에서는 이와는 반대되는 사건이 일어났는데 여러분도 잘 알듯이 '대규모 정전 사태(Blackout)'로 인해 추위와 암흑을 벗삼아야 했던 일이다. 이 사건은 전기 공급 시스템을 관리하는데 사용되는 GE 사의 XA/21 시스템의 소프트웨어 설계 결함에 원인이 있는 것으로 밝혀지고 있다.
애플리케이션에 존재하는 버그 중 일반적으로 몇 %가 보안 문제를 일으키는지에 대해서는 그간 실험적 연구가 있어왔으나, 아직 체계적이고 만족할 만한 수준에는 미치지 못하는 것으로 알고 있다. 다만 외국의 한 보안 회사가 수행한 연구 결과에 따르면 조사 대상이 된 약 300여 웹 사이트의 약 75% 정도가 심각한 보안 취약점을 안고 있는 것으로 밝혀졌다. 필자도 버그로 인해 멈춰선 ERP를 본 일이 있는데 해당 회사는 복구하기까지 반나절 만에 약 12~20억원의 피해를 보았다. 이런 피해가 아주 작은 패킷 하나로 인해 발생했다는 게 믿어지는가? 해당 회사는 ERP에 대한 의존도가 높아 만일의 사태에 대비하기 위해 HA 시스템을 구축했으나, 오히려 HA 시스템의 버그로 인해 ERP 시스템이 멈췄고 결과적으로 큰 손실을 입었다.
위의 통계나 사례들이 우리에게 무엇을 말해주는가? 네트웍 특히 인터넷은 이미 우리 생활의 기본적인 인프라스트럭처의 일부가 되었다. 이 인프라스트럭처는 소프트웨어라는 상대적으로 연약한 요소에 기반해 운영되고 있기 때문에 살얼음판을 걷는 듯한 조심스러운 태도 없이는 자칫 큰 사고로 이어질 수 있다는 것을 깨달아야 한다. 소프트웨어가 비스킷이나 크래커처럼 손쉽게 부서질 수 있다는 사실은 일반인들이 받아들이기에는 생소하게 느껴지겠지만 엄연한 현실이다. 사용자들이 프로그램 사용법에 대해 장기간 교육 받고 프로그래머가 설계하고 작성한 의도에서 벗어나지 않고 얌전히 사용해준다면 아무 문제가 없겠지만, 이런 이상적인 상황은 존재하지 않기 때문에 프로그램은 부서지고 멈추고 오작동하는 것이다. 때가 되면 어김없이 나오는 윈도우즈 패치는 마이크로소프트사 프로그래머와 버그의 전쟁의 흔적이다.
왜 소프트웨어는 보안 버그를 갖게 되는가?
그러면 이런 버그가 왜 발생하는지 알아보도록 하자. 소프트웨어 품질 관리(Software Quality Management)분야의 대가인 Gary McGraw는 최근에 출간된 'Exploiting Software : How to break code'에서 소프트웨어의 보안 버그는 소프트웨어가 가진 내재적 특성에 의해서 유발되는 것이라고 말하고 있다. 그는 소프트웨어의 특성을 Complexity(복잡성), Extensibility(확장성), Connectivity(상호연결성)으로 요약하면서 이런 특성이 소프트웨어의 보안을 위협하고 있다고 주장한다.
Complexity 오늘날의 소프트웨어는 나날이 복잡해져 가고 있다. 복잡한 기능을 갖춘 프로그램의 QA 테스트는 어려운 작업일 뿐 아니라 신뢰도가 떨어지게 된다. 또한 QA는 단순히 방법론이나 도구를 통해 해결 가능한 단순한 문제가 아니며, 일정 수준 이상의 복잡도를 가진 프로그램은 버그가 없다는 것을 증명할 수 없다.
Extensibility 일정 수준 이상의 프로그램은 확장성이라는 편리한 특징을 제공한다. 컴포넌트 기반의 프로그램 개발도 이런 확장성을 토대로 가능한 것이다. 그러나 확장성이 뛰어난 프로그램이나 컴포넌트 일수록 본래 의도하지 않던 다른 용도로 사용하기 쉬우며, 다양한 버그를 갖고 있게 마련이다. 바이러스나 웜도 과거에는 OS 자체의 문제를 공략했다면 요새는 마이크로소프트 오피스 제품군의 네트웍이나 메일 기능, 매크로 기능 등을 이용해 손쉽게 퍼지고 있다.
Connectivity 과거의 스탠드 얼론 환경은 사용자와 하드웨어만을 고려하면 되는 행복한 세상이었으나, 네트웍과 연결되면서 프로그램은 다른 컴퓨터, 다른 프로그램과의 상호작용 또한 고려해야 하는 상황에 부딪혔다. DBMS, 미들웨어, 서버, 사용자 브라우저 등 프로그램의 수행에 영향을 미치는 요소가 증가하였고, 프로그램의 작동 방식을 효과적으로 통제하기 어려운 상황, 프로그램의 성능 측정이 어려운 상황이 되어 버렸다.
Gary McGraw의 설명은 소프트웨어의 버그에 대해 다분히 이론적인 측면에서 접근하고 있다. 앞서 언급한 소프트웨어의 내재적 특성이 아니라고 해도 소프트웨어의 보안 버그가 발생하는 다양한 현실적인 이유가 있다. 필자가 근 2년간 웹 애플리케이션에 대한 소스 및 디자인 분석 프로젝트를 진행한 경험에 따르면, 대부분의 보안 버그는 상식적으로 생각하는 바와 같이 실제 구현 단계에서 코딩 상의 실수로 발생하는 것이 아니라, 설계 단계에서 보안에 대한 고려가 부재해서 벌어지는 것으로 파악되었다. 대부분의 개발자들이 학교나 학원에서 보안에 대한 별도의 교육을 받은 바가 없어 보안에 무지한데다, 무리한 납기일정을 맞추려고 노력하다보니 개발 과정 전체에 걸쳐 보안을 찾아보기 어렵다.
결국 개발 프로젝트에서 설계 단계에 적절한 보안을 고려하는 경우를 찾아보기 어려우며, 고객의 보안 요구 사항에 대한 세심한 분석이 없이 그저 '웹 보안은 SSL, PKI, 방화벽을 납품하면 된다.'는 단답형의 전형적 대안만을 제공하고, '우리 사이트는 다양한 보안 솔루션을 통해 보안하고 있으니 100% 안전하다'고 착각하는 경우가 많다.
해커들의 웹 해킹 기법
개발 과정상에서의 위와 같은 문제는 웹 해킹이 발생할 수 있는 좋은 토대를 제공해 왔다. 공격자들 사이에서 웹은 방화벽이나 침입탐지시스템(IDS)와 같은 보안 솔루션의 방해를 받지 않고 손쉽게 내부 서버로 들어갈 수 있는 관문으로 인식되고 있는 실정이다. 웹 공격자들은 웹 사이트의 작동 방식을 분석할 수 있는 분석 도구들과 웹 애플리케이션 프로그래밍에 대한 전문 지식으로 중무장하고, 다른 사이트에는 전혀 존재하지 않는 특정 사이트의 애플리케이션이 가진 문제점을 공격해 들어온다. 이들이 자주 사용하는 공격 기법은 보안에 무지한 프로그래머들이 프로그래밍 시 손쉽게 저지르는 보안상의 실수를 공격하는 방법으로 대표적으로 다음과 같은 공격 기법들이 있다.
1. SQL injection(SQL 구문 삽입 공격 기법)
모 결혼 정보 업체의 해킹에 사용된 기법으로 국내에서 유명해진 기법. 웹 애플리케이션에 강제로 SQL 구문을 삽입하여 내부 DB 서버의 데이터를 유출, 변조 가능하며, 관리자 인증을 우회할 수도 있다.
2. Cross-Site-Scripting(크로스 사이트 스크립팅 취약점 공격 기법)
다른 사용자나 관리자가 가진 쿠키나 세션을 알아채지 못한 사이에 강제로 가로챌 수 있는 무서운 공격 기법. 보안 전문가 사이에서도 위험도가 저평가되어 왔으나 최근에 자동화된 실시간 공격 도구의 등장으로, 가장 심각한 위협으로 대두되고 있다.
3. Directory Traversal(디렉토리 변조 및 접근 공격 기법)
웹 애플리케이션의 특정 인자로 프로그래머가 예상치 못한 디렉토리나 파일을 지정하여, 해당 파일이나 디렉토리의 내용을 살펴볼 수 있는 공격 기법. 관리자의 ID와 패스워드, DBMS 서버 접속에 사용되는 정보, 소스 파일 등 서버의 주요 정보를 노출할 수 있다.
4. File Upload(공격용 툴 업로드)
공격자가 공격에 사용되는 도구를 업로드 하는 것을 적절히 막지 못하는 문제점이 있는 경우 공격자는 PHP나 ASP, JSP 등으로 작성된 공격 도구를 서버에 업로드 하여, 웹 서버를 장악할 수 있다.
5. Malicious Source Injection(외부 파일 실행 공격 기법)
PHP에 특화된 문제로, PHP의 독특한 특징으로 인해 공격자의 웹 서버에 존재하는 공격용 프로그램을 피공격자의 서버에서 실행하게 되어 웹 서버를 장악당하는 공격 기법. 공격자는 피공격자의 서버에 접속할 필요조차 없다는 점에서 무서운 공격 기법이라 할 수 있다.
6. URL manipulation & Parameter manipulation(URL 변조 및 인자 변조 공격 기법)
웹 애플리케이션의 URL이나 인자를 프로그래머가 원하지 않던 다른 값으로 변조하여 공격하는 기법. 웹 애플리케이션이 사용자의 입력값을 적절히 검증하지 않는 경우 예기치 못한 오동작(일반 사용자 게시판에서 관리자 게시판 게시물을 지울 수 있는 등)을 유발하거나, 웹 애플리케이션의 보안 메커니즘을 우회할 수 있다.
7. Mis-configuration Attack(취약한 설정 공격 기법)
웹 서버나 웹 애플리케이션의 잘못된 설정을 이용하여 서버 내의 중요한 데이터를 열람한다거나, 서버 자체를 장악하는 공격 기법. 국내에는 아파치, IIS 등 웹 서버나 WebLogic, WebSphere, Tomcat 등의 웹 애플리케이션 서버에 대해 적절한 설정이 이루어지지 않고 있어 상황이 매우 심각하다.
8. Cookie & Session spoofing(쿠키 및 세션 변조 공격 기법)
다른 사용자나 관리자의 쿠키/세션을 도용하여 관리자로 접속하는 공격 기법. 대부분의 웹 애플리케이션이 쿠키 및 세션 데이터를 무조건적으로 신뢰하여 이 공격 기법에 노출되어 있다.
9. 관리자 페이지 강제 접속 공격 기법
관리자 페이지 등 중요한 페이지에 인증이 설정되어 있는 경우, 관리자 게시물 쓰기 URL 이나 관리자 게시물 지우기 URL 등 관리자 페이지의 다른 메뉴로 강제 접속하여 인증을 우회하고 관리자 권한을 획득하는 공격 기법. 인증을 취약하게 구현하여 발생하는 문제이다.
대부분의 공격 기법이 생소하게 들릴 것이다. 웹 공격자들이 사용하는 공격 기법이 위와 같이 다양함에도 불구하고 기존의 대부분의 보안 대책은 공격 기법에 대한 고려 없이 무조건적으로 '웹 보안은 SSL, PKI, 방화벽을 설치하면 된다'는 모범답안 형태로 이루어져왔다. 때문에 값비싼 솔루션은 구축해놨지만 여전히 웹을 통해 내부 주요 정보가 노출되는 사고가 빈번하게 발생하고 있는 것이다.
애플리케이션 보안에 희망은 없는가?
애플리케이션의 보안을 강화하기 위해서는 다음과 같은 두 가지 측면에 대한 고려가 반드시 필요하다. 첫째는 데이터 흐름(data flow) 측면에서의 보안에 대한 고려이며, 둘째는 사용자의 활용 사례를 고려한 보안 방안이다. 이에 대해서는 다음호에서 좀더 자세히 설명하겠다.