SQL Injection 취약점 사례 분석 #1 > security

작성자 : 이종량
편집자 : 홍순성

최근 해킹의 유형이 크게 변화되고 있다. 과거의 해킹은 주로 범용의 OS나 특정 데몬 또는 서비스 관련 프로그램들이었으나 이에 해당하는 업체들이 몇 년간 크게 신경 쓴 이후로 이는 급격하게 줄어들기 시작했다.
최근의 유형은 이런 범용적인 차원이 아닌 각각의 어플리케이션의 문제를 잡아내기 시작했다. 이에 따라 보안패치는 더 어려워지고 있으며, 심각한 경우에는 보안 패치를 진행할 수 없는 상황에 빠지고 있다.

대표적인 공격 대상으로 웹서비스를 통한 공격의 증가가 주를 이루고 있다. 웹서비스의 취약점이라고 하면 2001년의 Nimda가 대표적이라 할 수 있을 것이다. 이 공격은 전적으로 IIS의 취약점을 이용한 공격이었다. 2002년의 슬래머 웜은 패치 안된 MSSQL 시스템이나 허술한 SA의 암호로 인하여 발생되었다. 슬래머 웜 이후 해킹은 허술한 관리자 계정(SA)의 비밀번호가 대부분을 차지하고 있다. 이 슬래머 웜 이후의 해킹은 한가지 커다란 변화를 갖게 된다. 바로 SQL이 해킹을 하는데 상당히 적합하다는 사실을 발견하게 된다. 윈도우 취약점과는 달리 SQL의 취약점은 알고 있는 관리자 이외에는 쉽게 패치가 있다는 사실조차 잘 모르며, 여러 대의 시스템이 동시에 접근하여 사용하는 만큼 덜 끄고 쉽게 눈에 보이지 않는다는 특징이 있는 것이다. 더구나 접근하는 시스템은 모두 기록을 남길 수도 있기에 SQL을 장악했다는 것은 연관되어 있는 시스템 모두를 장악한 것과 같다는 사실을 알게 된다. 또 한가지 장악 시 좋은 점은 1회 해킹으로 수없이 많은 데이터를 너무나 손쉽게 얻을 수 있다는데 있다.

대표적인 웹서비스의 취약점으로 CRFL나 Code execution과 같은 부분이 있다. 이러한 공격의 부분은 UrlScan이나 이와 유사한 필터를 통해 막을 수 있다. (IIS 6.0은 UrlScan의 기능이 대부분 내장되어 있다) 하지만 Input validation과 같은 문제는 UrlScan으로는 처리가 되지 않는다. UrlScan의 비 공식적인 버그 중 하나가 바로 QueryString을 정상적으로 필터링 하지 못한다는 사실이다. 이로 인하여 많은 문제점이 발생되고 있다. 이 부분을 사용한 공격이 바로 SQL Injection이다. SQL Injection에 대해 조금 더 자세히 설명하자면, 예를 들어 만약에 악의적인 목적은 아니지만, 개발상 필요하니까 다음과 같은 부분을 써서 개발했다고 하자

[그림1] test.asp

만약 위의 쿼리가 test.asp 라는 문서에 있고 해당 웹 페이지에서 누군가가 test.asp?table_name=sysxlogins&arg1..... 라고 호출했다면 결과는 어떻게 될까? 그리고 이 결과값을 외부의 사용자가 볼 수 있다면? 외부의 사용자가 시스템을 정말로 해킹하고자 한다면 위의 쿼리에 신경을 쓸 필요조차 없다. 대부분의 데이터베이스 시스템은 원활한 동작을 위해 Administrator 권한이나 Local System으로 실행해야만 한다. MSSQL에는 xp_cmdshell이라는 명령어가 있다. 이 명령어는 SQL서버를 실행하는 계정을 통해 명령프롬프트를 실행할 수 있도록 해준다. 따라서 SQL을 해킹 당하는 것은 바로 Administrator를 해킹 당하는 것과 같은 위치에 있게 된다.

SQL Injection 공격이 무서운 이유는 바로 대부분의 공지사항이나 쉽게 노출될 수 밖에 없는 페이지로 인하여 발생된다. 많은 사이트에서 띄우는 공지사항은 팝업 창을 이용하여 DB의 내용을 그대로 읽어와서 화면에 뿌리는 형식을 따른다. 따라서 대부분의 공지사항은 다음과 같은 형식을 따르게 된다.

기본 형식> URL/notice.asp?pid=1234

위의 소스는 분명히 pid라는 인수를 받아 이를 넘기는 역할을 할 것이고, 이 인수는 SQL 서버상으로 넘어가게 될 것이다. 따라서 SQL 서버에 어떻게 해서든 자신이 원하는 쿼리를 넣을 수만 있다면 상당히 좋은 공격 대상이 될 수 있다. 대부분의 SQL 서버상의 데이터는 ;와 ’와 ”를 섞어서 쓰기 때문에 이 몇 개의 문자만 잘 섞어서 사용한다면 원하는 쿼리를 브라우저에 한 줄로 만들어 보내는 것은 간단한 일이다.

아주 간단하게 자신의 사이트에 이런 부분이 문제가 되는지를 확인해보고 싶다면 아무 페이지나 열고 ;’를 추가해서 오류 페이지가 뜨지 않으면 된다. (;’는 SQL Injection의 기본 패턴 중 하나이다)

예시> URL/notice.asp?pid=1234;’

대부분의 취약성 분석 도구는 운영체제나 특정 프로그램, 또는 시스템에 따른 보안 부분만 확인을 한다. 이러한 부분은 이미 대부분의 개발사 홈페이지나 별도의 기술지원을 통해 비교적 간단하게 처리할 수 있다. 반면 웹 서비스는 각 회사마다 만들어진 구조가 다르고 인터페이스도 다르기 때문에 보안 취약점을 분석하기란 아주 어렵다. 웹 서비스의 경우 acunetix사의 Acunetix Web Vulnerability Scanner라는 프로그램을 통해 비교적 간단하게 체크할 수 있다. 정품이 아니어도 데모 버전으로도 충분히 확인이 가능하기에 한번쯤은 돌려보는 것이 좋다. 이 프로그램을 돌리는 경우 가끔 DB에 이상한 내용이 마구 적힐 수 있으므로 주의하기 바란다.

[그림2] Acunetix Web Vulnerabilty Scanner 의 화면

참고로 그림1은 어떤 사이트에서 해킹 작업 직 후 기록된 DB의 내용이다. IP정보를 알기 위해 SQL에 xp_cmdshell이라는 명령어를 통해 ipconfig /all을 실행하고 이 값을 X_9400이라는 테이블에 집어넣은 것이다.

[그림3] X_9400 이라는 이름의 테이블 내용

위의 내용을 보면 현재의 공격대상은 단순한 웹서비스가 아니다. 외부에서의 접근이 용이하지 않기에 안전하다고 생각되는 시스템, 즉 데이터베이스를 통한 간접 공격이 이루어지고 있다. 이러한 URL을 통한 공격은 웹 어플리케이션의 소스상에서 문자열을 정확하게 필터링 하는 방법이 최고의 방법이겠지만, 이것이 용의하지 않는 경우 이러한 부분을 필터링 할 수 있는 부분을 마련해야 한다. 이러한 대표적인 장비로 IPS나 IDS같은 고급 네트워크 장비가 있지만, 이러한 장비가 없는 경우에는 어쩔 수 없이 서버에서 필터링을 할 수 있는 프로그램을 마련하는 방법 밖에는 없을 것이다. URL의 내용을 그나마 잘 필터링 하는 프로그램으로 WebKnight 라는 ISAPI 필터가 있다. 이 프로그램은 GNU라이센스를 따르므로 별도의 비용은 지불하지 않아도 되며, 설치 역시 비교적 간단하다. 다음은 WebKnight 에서 남긴 로그의 일부분이다.

[그림4] WebKnight의 로그

WebKnight와 같은 필터가 좋은 해결책이기는 하나 소스의 수정이 가장 확실한 방법이며, 이러한 필터의 추가는 사이트의 장애나 오류를 낼 수 있는 부분이 많기 때문에 사전에 철저한 준비와 테스트만이 정상적인 웹서버의 동작을 보장할 수 있다.

최근의 이러한 해킹의 유형이 허술한 SA의 암호 때문도 아니고 패치가 안된 윈도우 시스템 때문도 아니다. 허술하게 개발된 웹 어플리케이션에 의해 발생되고 있다. 이러한 취약점은 꼭 IIS(ASP)+MSSQL의 문제점이 아니며, 웹 상에서 실행되는 페이지가 PHP건 JSP이건 종류를 가릴 것 없이 거의 모든 웹 어플리케이션에서 발생되고 있다. 단지 QueryString이 있는 URL이 있는 어떠한 게시판이라도 좋으며, DB가 어떤 종류의 것인지 판단할 수만 있으면 된다. 이런 응용 프로그램 상의 문제로 인한 부분은 이 부분을 커버하기 위해 보다 완전한 시스템을 갖추는 것 이외에는 대책이 없다고 봐도 무방할 것이다.

참고 자료
- UrlScan : http://www.microsoft.com/technet/security/tools/urlscan.mspx
- acunetix 사 홈페이지 : http://www.acunetix.com/wvs/
- 취약점 해결 필터 WebKnight : http://www.aqtronix.com/?PageID=99