[별도]SQL Injection Filtering 우회 기법

요즘 프로젝트에 참여해 보면 많은 고객사(사이트)에서 웹 방화벽 등을 이용하여 웹 애플리케이션을 보호하고 있다. 그 중에 일부 보안 담당자들은 웹 방화벽이 설치되어 있어 우리 사이트는 SQL Injection등의 공격으로 부터 매우 안전하다고 철통 같이 믿고 있는 고객을 만나곤 한다. 근본적으로 소스코드 취약점을 수정하여한다고 권고하지만 일부 관리자 들은 웹 방화벽이 있다며 비용 또는 과도한 업무 등등 여러가지 이유를 들어 수정을 거부하거나 방화벽만 믿고 취약점을 방치하는 경우가 종종있다.

이 문서에는 근본적으로 소스코드에서 왜 보안 취약점을 제거해야 하는지에 대해서 한가지 예로 SQL Injection을 통해서 설명하고자 한다.

그림1. 구성도

그림1의 구성도는 일반적인 기업에서의 구성 환경이다. 보통 IIS WEB 서버와 DB 서버가 별도의 Zone으로 분리되어 있을 경우 방화벽을 별도로 두는 경우가 더 많다.

이러한 환경에서 공격자와 일반 사용자는 WAF(Web Application Firewall)을 통해서 서비스를 이용하게 된다.

보통 IIS WEB서버에 MSSQL 조합을 많이 사용하나 ORACLE, MySQL 등등의 DB서버를 다양하게 연결해서 사용하게 된다. 여기에서 IIS WEB서버에서 특수한 현상이 발생하게 된다.

■ 사용자가 요청한 질의어

1. SELECT * FROM SYSOBJECTS
2. SEL%ECT * FRO%M SY%SOB%JECTS

사용자가 요청한 질의어 중에 위의 두 구문 중 2번째는 DB에서 명백하게 에러를 발생시켜야 정상이나 IIS WEB 서버의 경우 WebToB, Apache, Weblogic etc.. 등의 웹서버와 다르게 동일한 질의 결과가 반환된다. 즉 "%"문자열이 자동으로 제거 된다고 이해해도 좋을거 같다.

위와 같은 현상은 IIS와 MSSQL의 조합에서만 발생하는게 아니며 IIS와 ORACLE, MySQL 등등의 DB와 연동하면 동일한 현상이 발생한다.

해당 현상은 Windows Server 2000의 SP1부터 발생하며 SP0의 경우 발생하지 않는다.

그럼 예시를 통해서 더 자세하게 알아 보자.

(select+@@version)

(se%lect+@@versi%on)

위와 같은 현상이 발생하는 것이다. 그러므로 Keyword Filtering 형태의 WAF는 모두 우회가 가능하게 된다. 대표적으로  무료 소프트웨어 웹방화벽인 WebKnight와 현제 솔루션 업체에서 공급하고 있는 대부분의 방화벽은 위의 기법을 이용하면 SQL Injection이 가능하게 된다.

이 기법은 웹 애플리케이션 모의해킹에서 다양하게 응용이 가능하다. 근본적인 원인을 차단하지 않고 보안장비 및 솔루션에 100% 의존하는 것에 대해서 다시한번 재고해 볼 필요성이 있다.

보안장비와 솔루션은 외부의 불법적인 공격을 지연시켜주는 효과를 가져다 준다고 인식하는 것이 가장 바람직할 것 같다.

만약에 아직도 보안 장비에 100% 의존하여 소소코드 차원의 원천적인 취약점을 제거하지 않고 방치하고 있다면 신중하게 다시 생각해볼 필요성이 있다.

모든 일에는 요령이나 지름 길은 없다 지름 길이 있다면 그것은 바른 길 정도의 길을 가는 것이다.

이런 부분으로 마찰이 있었거나. 고민이 되는 컨설턴트 보안업체에 일하시는 분들과 각 회사의 보안 담당자에게 도움이 되었길 바랍니다.

자신이 알고 있는 보안 지식은 자신의 한계성에서 나온 것이며 아무도 생각지 못한 기술들이 얼마나 더 많이 존재하는지 알 수 없습니다. 더 노력하는 N3015M이 되겠습니다.


* p.s
위의 자료는 Pangolin의 SELECT 필터링 기법에 대해서 연구하다 추가적으로 발견된 부분입니다. IIS에 연동된 DB서버에서 발생하는 현상으로 URL디코딩 로직에서 발생되지 않나 유추되지만 이 부분은 리버스엔지니어링 전문가님들에거 맡기는게 바람질 할거 같습니다.

※ 참고자료

%는 문자를 16진수로 나타냄을 의미한다. 예를 들면, %20은 스페이스이고 %3D는 "="로 치환된다.

IIS/ASP에서는 %에 계속되는 문자가 16진수로 표기 할 수 없는 문자열이 계속 되었을 경우, %를 제거하고 Web 어플리케이션에 SQL 문장을 전송한다.

이러한 경우 「DEC%LARE」나 「E%XEC」는 각각 「DECLARE」와 「EXEC」로 Web 어플리케이션에 전달된다. 취약할 경우 SQL 구문이 실행된다. 

많은 IDS/IPS에서는 리퀘스트에 포함되는 특정 키워드와 패턴 매치에 의해서 SQL 익젝션을 시도를 감지한다. 이 때문에 감지 키워드안에 무효인%를 포함시켜서 회피가 가능하게 된다.

첨고URL :
http://j2k.naver.com/j2k_frame.php/korean/www.lac.co.jp/info/rrics_report/csl20081002.html

도움주신 조철(?)님과 김동(?)님에게 감사드립니다.