IT이야기2010. 6. 16. 18:43
최근 월스트리트 저널(online.wsj.com)등을 포함한 MS IIS 서버와 ASP.net환경의 서버에 대량 SQL Injection(Mass SQL Injection) 공격이 이뤄지고 있으니 주의가 필요하다.

해킹된 사이트에는 _script src=http://ww.robint.us/u.js_ 스크립트가 삽입이 되었다. 그 이후에 2677.in/yahoo.js, 4589.in/yahoo.js 등의 도메인으로 스크립트를 삽입하고 있다. 최근 Adobe Flash 0-day 취약점(CVE-2010-1297)이 발생했다. 이 취약점을 패치하지 않은 유저가 해킹된 사이트를 방문하면 악성코드에 감염이 된다. Armorize Blog(상세한 분석 자료 있음)에 따르면 이 악성코드는 다음 3개 게임 사이트의 게임 계정을 가로채는 것으로 알려졌다.
 
aion.plaync.co.kr
aion.plaync.jp
df.nexon.com

구글에서 2677.in/yahoo.js 또는 4589.in/yahoo.js를 검색하면, 프레시안(현재는 정상 복구된 것으로 보임), 한국표준협회, 아산시 평생학습센터 등 다수의 국내 사이트들이 감염된 것을 확인할 수 있다.

[ 구글에서 '2677.in/yahoo.js' 검색 결과 ]


유저들은 KrCERT의 권고문을 살펴보고, 반드시 Adobe Flash Player(http://get.adobe.com/flashplayer/)를 업데이트해야 한다.

마지막으로 위 도메인의 등록정보를 살펴보자. 3개 모두 중국(CN)에서 등록을 했다. 등록일이 얼마되지 않았다. 스크립를 호스팅하기 위해 생성한 도메인이라는 것을 뜻한다. 그리고, 도메인이 차단될 경우에 유사 도메인으로 계속 등록을 시도할 가능성이 커보인다.

1. robint.us
   Domain Registration Date:                    Sun Mar 14 05:28:08 GMT 2010
   Domain Last Updated Date:                    Tue Jun 08 05:10:09 GMT 2010

2. 2677.in
   Created On:10-Jun-2010 10:33:51 UTC
   Last Updated On:12-Jun-2010 15:59:46 UTC

3. 4589.in
   Created On:13-Jun-2010 08:13:07 UTC
   Last Updated On:13-Jun-2010 08:13:08 UTC


* 관련 정보

  - Mass infection of IIS/ASP sites - robint.us
  - Mass infection of IIS/ASP sites - 2677.in/yahoo.js
  - 대량 SQL Injection 공격 주의 (2009.12월)
Posted by 좋은진호
시스템이야기2010. 5. 31. 19:14
MySQL의 SELECT LOAD_FILE() 함수, LOAD DATA는 서버내에 있는 파일을 읽어들이는 명령이다. MySQL 데몬이 파일을 읽을 권한이 있다면, 서버내의 경로와 상관없이 어떠한 파일이라도 읽을 수 있다. 만약 웹페이지가 SQL Injection 공격의 취약점이 있다고 할 때 다음과 같은 형식으로 쉽게 웹에서 서버 내의 파일을 확인할 수 있는 위험성이 존재한다.

select ...생략... from ...생략...  UNION SELECT LOAD_FILE("/etc/passwd");

이 함수가 편리성, 활용성 측면에서는 좋을 수 있지만, 보안에는 취약한 통로를 제공하는 셈이다.

2009월 말, 루마니아의 Unu 해커는 세계 주요 사이트와 국내 보안 업체 사이트를 SQL Injection공격으로 해킹을 했다. 그리고, MySQL의 load_file() 함수로 서버의 /etc/ 파일까지 캡쳐하여 블로그에 공개한 적이 있다.

mysql


MySQL 5.1.17부터는 LOAD_FILE() 함수, LOAD DATA, SELECT ... OUTFILE을 특정 디렉토리내의 파일만 허용하도록 설정할 수 있다. --secure-file-priv 옵션은 동적으로는 설정값을 변경할 수가 없다. my.conf 의 '[mysqld]' 섹션에 다음과 같은 설정을 한다. (경로는 운영 환경에 맞게 할 것)

[mysqld]

secure-file-priv=/var/tmp

위처럼 설정하고 MySQL 데몬을 실행하면 load_file()을 사용할 수 있는 경로가 /var/tmp으로 제한이 된다.

자세한 글은 커피닉스의 'MySQL에서 보안위해 load_file() 경로 제한하기' ( 2010.5 )를 읽어보기 바란다.


* 관련글

- 2009/11/30 - [IT이야기] - nProtect 웹사이트, SQL Injection공격 당해
- 2008/12/11 - [시스템이야기] - MySQL 인젝션 공격 방어하는 GreenSQL
- 12.22~23 커피닉스 이야기 (Intel사이트 SQL Injection등) (2009.12.24)
- 대량 SQL Injection 공격 주의 (2009.12.11)


Posted by 좋은진호
IT이야기2010. 4. 15. 01:32
최근 KISA의 '입찰공고' 중에 '2010년 웹사이트 개인정보 모니터링 사업자 선정' 제안요청서를 봤다. 개인정보 모니터링 시스템의 환경 정보가 있다.

- 10대 검색서버(OS : Redhat Ent5.0 이상)
-  3대 검증/제어/현황/확인 서버
-  1대 DB 서버 (DBMS 알티베이스)

검색서버, 즉 검색봇 용도로 10대가 마련되어 있다. 10대라면 떠오르는게 있다.

2009년 12월에 'KISA, 개인정보 노출 검사 위해 웹페이지 마구잡이로 긁어가'라는 제목으로 썼던 'KISA 개인정보 노출 대응시스템'이 있다. 그 때 검색봇인 pirs 봇의 IP가 210.97.192.140~149이거나 211.254.252.50~59등 IP개 10개다. 그리고, 당시 언론에서 '검증,확인,분석,대응'을 수행하는 시스템이라는 말을 썼는데, 제안요청서에 적혀있는 3대의 서버용도명과도 비슷하다. 이 제안서에 있는 시스템과 'KISA 개인정보 노출 대응시스템'은 같은 시스템일 것으로 추측해본다. 다른 시스템이라 하더라도, 모니터링 대상만 조금 다를 뿐 목적은 같을 것 같다.

작년말에는 대상이 6500여개 웹사이트였는데, 제안요청서에는 '약 45,000개 웹사이트 개인정보 모니터링'이라고 적혀있으니 그 대상이 확대된 모양이다.

  o 약 45,000개 웹사이트 개인정보 모니터링
   - 점검 대상 : 중앙부처, 지자체, 공사/공단, 대학교, 준용사업자, 교육기관 및 초중고 학교 웹사이트
     ※ 점검 대상은 '09년 점검대상과 KISA가 추가로 지정하는 웹사이트
   - 점검 주기 : 2주

2. 고려사항
  o 주요 준용사업자(병원,호텔,백화점 등) 및 초중고 학교로 노출점검 대상 확대
    - 약 22,000개 도메인 목록 수작업 확보 필요


다른 제안서도 봐보자.

  • 휴대전화 실시간 스팸차단리스트(M-RBL) 구축
스팸메일 차단할 때, RBL(Real-time Blackhole List)을 이용하는 경우가 많다.
제안요청서를 보니, 모바일도 스팸전화 차단을 위해 스팸메일과 비슷한 방법을 이용한다. KISA에 M-RBL 시스템(모바일 RBL시스템)을 구축해두고, 이통사에서는 rsync를 이용해서 주기적으로 M-RBL파일을 받아가는 형태이다.
  •  이해관계자별 IPv6 적용 안내서 제작 사업자 선정
2011년경 IPv4주소 할당 중지 예상에 따라 IPv6 인프라 준비를 위해서 안내서를 제작한다는 것이다.
IPv4 중지 예측에 대해서는 'IPv4, 2011년 9월 할당 중지 예측'를 읽어보길.


위 3개의 정보만으로도, KISA의 '입찰공고'를 자주 봐야할 이유가 생겼다.
1) '시스템 구성'정보를 얻을 수 있고,
2) 정책방향(그 정책이 좋은지, 나쁜지와는 상관없이)도 미리 알 수 있는 흥미로운 공간이다.


혹시 이글을 KISA등 IT 정책세우시는 분들이 한분이라도 읽을지도 모르니, 한가지 덧붙인다.

'IT이용도'에 따라 '한 사람'의 생활이 달라지지만,
'IT정책'은 '한 국가'의 IT생태계를 좌우한다는 것.

Posted by 좋은진호
IT이야기2009. 11. 30. 19:18

'보안뉴스'에 '[단독] 엔프로텍트, 해킹당해 100만 고객 DB와 ID/PW 유출!' 이라는 기사가 올라왔다. 며칠전 Symantec Japan 사이트를 해킹했던 루마니아 해커 우누(Unu)가 SQL Injection 공격을 사용해서 http://www.nprotect.com/ 웹페이지를 해킹했다. ID, 메일주소, 비밀번호가 유출됐을 가능성이 있다.

공격한 해커의 블로그를 보면 다음과 같은 사항을 알 수 있다.
  • MySQL 5.0.x 버전 사용
  • DB데이터는 별도 내부망이 아닌 공인 IP를 통해서 통신 (211.200.28.x)
  • MySQL load_file() 함수를 사용할 수 있도록 되어 있어 시스템의 파일들도 쉽게 볼 수 있었다.
  • 비밀번호는 암호화 되어 있지 것으로 보인다. (추측)
  • 유저 DB건수는 약 108만여건

[+] Gathering MySQL Server Configuration …
Database: ??????
User: ????????@211.200.28.???
Version: 5.0.41-log
... 생략 ...
[+] Number of Rows: 1079630

nProtect는 홈페이지에 비밀번호 변경 공지가 띄워진 상태이고, '엔프로텍트 보안강화 조치를 위한 개인정보 변경 안내'라는 메일을 고객들에게 발송했다. 해킹에 대한 이야기는 없고, '고객님의 정보보호 강화를 위하여 패스워드(비밀번호)를 변경해 주세요'라는 내용으로 변경을 권고하고 있다. 개인정보가 유출되지 않았기를 바라지만, 가입된 사용자라면 빨리 변경하시길...

nProtect 비밀번호 변경 공지

[ nProtect웹사이트에 올라온 비밀번호 변경 공지 ]


이 번 nProtect 웹사이트 해킹을 보니 다음과 같은 생각이 든다.

  • 유저들의 보안강화를 위해 노력은 했지만, 정작 본인의 웹사이트 보안에는 구멍이 생겼다.
  • 중이 제 머리 못 깍는다 격이다.
  • 비교적 빨리 조치를 취해서 다행일지도 모르겠다.
  • 그럴지라도, nProtect 관계자분들은 이번 사건을 심각하게 생각해야 하고, 후속조치(망분리, 비밀번호 암호화 등)가 필요하다.

Posted by 좋은진호
IT이야기2009. 11. 23. 19:19
11월 초에 Ikee worm이름의 아이폰 웜(iPhone Worm)이 최초로 발견되었다. 그리고, F-Secure의 'Malicious iPhone worm' 글에 따르면 또 다른 아이폰 웜이 발견되었다.

아이폰 보호 기능을 해제하고, default 비밀번호를 변경하지 않은 경우에 감염이 된다.

이 웜은 리투아니아에 있는 웹기반 C&C(command & control center) 서버에 접속한다. 그리고, 이 때 아이폰의 시스템 정보(uname)와 SQLite 정보(SQLITE 환경변수), IP정보(ifconfig) 등을 저 서버에 넘겨주게 되어 있다. F-Secure에 따르면 아직 웜이 확산되지는 않았지만 위와 같은 정보들을 빼내가기 때문에 Ikee worm보다는 더 심각한 웜으로 보고 있다.

저 리투아니아에 있는 C&C 서버에 /xml/a.php?name= 값으로 접속하면, 404 not found 페이지를 보여준다. a.php 페이지가 이제 지워졌으니 문제없겠구나 생각할 것 수 있을 것 같다. 그러나 실제 지워지지 않았다. 마치 파일이 없는 것처럼 눈속임 화면을 뿌려준 것이다. 실제로는 200 OK.

iphone worm C&C서버

[ 404 페이지인 것처럼 속이고 있다. ]


HTTP/1.1 200 OK
Date: Mon, 23 Nov 2009 09:47:26 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch15
X-Powered-By: PHP/5.2.0-8+etch15
Content-Length: 228
Connection: close
Content-Type: text/html; charset=UTF-8

<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /xml/a.php?name=.... was not found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.34 Server at 92.61.38.16 Port 80</ADDRESS>
</BODY></HTML>Connection closed by foreign host.


그리고,  http://www.malwaredomainlist.com/mdl.php 에서 목록을 보면 /xml/p.php 페이지도 아이폰 웜이 호출하는 페이지로 되어 있다. 마찬가지로 404 페이지인 것 처럼 눈속임을 하고 있다.

먹을 것이 많아지니 벌레가 들끓는다.


최초 웜에 대한 것은 다음 글을 참고하기 바란다.

Posted by 좋은진호
IT이야기2009. 8. 31. 19:07
지난 금요일(8.28일)에 Apache Software Foundation의 웹사이트가 해킹을 당해 서비스를 일시 중지한 적이 있다. F-Secure의 'Apache.org hack'을 읽은 금요일 밤에 접속했을 때는 웹서비스는 정상적으로 복구된 상태였다.

apache


다행인 것은 공격자는 Apache 웹서버 자체의 S/W적인 취약점이나 SSH의 취약점이 아닌 SSH key 인증을 이용해서 접근했다. minotaur.apache.org(people.apache.org로 알려진 서버) 서버에 파일을 업로드 한 것이다. 이 minotaur 서버는 Apache 커미터들에게 쉘 계정을 제공하는 서버이다.

ASF측에서는 예방차원에서 서버를 모두 shutdown했다. 그리고 초기 조사 이후에 apache.org 서비스를 eris.apache.org(이 서버는 공격 당하지 않은 안전한 서버)로 DNS를 변경했고, 이 서버를 통해 공지페이지를 제공했다. 그 이후 유럽의 장애 대처 및 백업 서버인 aurora.apache.org 서버(이 서버 또한 안전한 서버)로 서비스를 변경했다. 현재 aurora.apache.org IP와 www.apache.org IP가 같은 것을 보면 아직 유럽의 임시 서버를 통해서 서비스가 되고 있는 것으로 보인다.

공격자는 www.apache.org 내의 CGI 스크립트를 포함하여 몇몇 파일을 생성까지 했다. 그런데, ASF의 서버들은 rsync의 자동화처리(cron에 등록되어 있을 것 같음)를 통해서 파일을 각 서버로 자동 배포하는 구조로 되어 있다. 공격자가 생성한 몇몇 파일들이 자동적으로 sync가 되었는데, 복구는 ZFS 스냅샷으로 이전 상태로 복원했다고 한다. ZFS 파일시스템의 우수성을 다시 한번 느끼게 한다.

참고로 ZFS파일시스템은 주기적으로 snapshot을 실행(zfs snapshot -r ... 형식) 한다면, 적은 공간으로 파일시스템을 원하는 시점으로 되돌릴 수 있다(zfs rollback). ZFS에 대해서는 'FreeBSD 7에서 ZFS 사용 (유연성은 좋으나, 성능은 불만족)' (2009.2월)을 읽어보기 바란다.

apache.org 얘기로 돌아가서, 공격자가 서버 접속해서 상위 권한을 획득하지는 않았다. 하지만 다운로드 받는 분들은 디지털 signature 체크(MD5 등)를 하길 바란다. 자세한 글은 아파치 인프라팀의 'apache.org downtime - initial report' 글에 있다.

서버 운영자들 중 PW없이 접속하도록 SSH 인증키를 만들어 놓곤 한다. 그러나 이 키들이 노출됐을 때 얼마나 위험한 것인지 잘 아셔야 한다. 그리고, 왜 이런 오픈소스 진영의 서버들을 해킹하려고 시도하는지, 안타깝다. 그런 노력(?)을 하려거든, 오픈소스 진영에 기부나 할 것이지...

Posted by 좋은진호
IT이야기2009. 7. 8. 10:24
어제 네이버 메일과 쪽지기능, 옥션(auction.co.kr), 조선닷컴(chosun.com), 청와대(www.president.go.kr), 국방부(www.mnd.go.kr), 은행사이트, 그리고 백악관 등 다수 사이트가 DDoS공격을 받았다. 지금도 청와대, 국방부, 조선닷컴, 옥션 등이 원할게 접속되지 않는다. 네이버 블로그도 일부 개인 페이지들이 제대로 보이지 않는 경우가 있다. 그 원인은 악성코드 때문이었다. 쿨캣님의 블로그( http://xcoolcat7.tistory.com/520 )에서 악성코드가 공격을 하는 대상 사이트의 목록을 볼 수 있다. 악성코드의 공격대상 목록과 실제 공격당한 사이트가 일치한다.

악성코드 msiexec2.exe의 공격 대상 사이트 목록

[ 출처 : 쿨캣님 블로그 ]


msiexec1.exe 등을 포함한 Win-Trojan/Downloader.374651 악성코드는 안철수연구소 바이러스 정보에서 정보를 얻을 수 있다. 그러나 공격대상 사이트 목록이 있는 msiexec2.exe에 대한 분석자료는 안랩 사이트 등 다른 곳에는 아직 공개되어 있지 않은 상태이다.

KRCERT에 '신종 분산서비스거부공격(DDoS)에 따른 "주의" 경보발령'  공지가 올라와 있다. '신종 DDoS 악성코드로 인하여 국내 주요 공공기관 및 이용자 방문이 많은 포털, 금융 사이트에 대한 접속 장애 발생'했다는 내용이다.

이 악성코드가 부팅 후 자동 실행이 된다. 그리고, 제어 서버(C&C) 접속 없이 공격 대상 목록 파일정보를 기반으로 자동 공격한다.  만약 악성코드내에 공격을 중단하는 명령이 없다고 한다면, 대상사이트는 공격을 계속 받을 수 밖에 없다. C&C(Command & Control) 접속없이 이뤄지므로, 공격을 멈출 방법이 없기 때문이다. PC만 켜져있는 동안은 계속 공격이 이뤄진다는 얘기.

개인 PC에 악성코드가 심어져 있는지 검사가 필요하다.


* 관련정보 (18:15 추가)
  - 안철수연구소, DDoS 공격용 악성코드 전용백신 무료 제공 (그리고, 이번에 공격한 악성코드명)
  - Urgent-Massive DDOS Attack!
  - 하우리의 분석자료 (Trojan.Win32.DDoS-Agent.33841) (공격대상 목록 포함)
  - 네이버, 옥션, 청와대 공격 악성코드 분석 (글 쿨캣님, 16:36)
  • 악성코드 초기 버전(7.5일)이 만든 uregvs.nls 파일에는 한국 사이트는 없었고, 미국 정부 사이트만 있었다고.
  • 한국 사이트는 7월 7일에 포함

Posted by 좋은진호
IT이야기2009. 4. 28. 23:27
국내 몇몇 주요 사이트의 도메인 정보가 25일(토)에 변조된 사건이 발생했다. 상태(Status) 정보, 관리책임자(Administrative Contact)정보, 기술책임자(Technical Contact)정보 등이 변경되었다. 다행인 것은 네임서버 정보는 변경되지 않았다는 것. 만약 이 정보까지 변경됐다라면 큰 난리가 생겼을 것이다. 랭키닷컴 기준으로 1위~100위 사이트 중 .com, .net 도메인과 그외 추가로 몇개를 whois 검색했다. 총 7개 도메인에서 특이한 점이 보였다.

  • daum.net
  • hanmail.net
  • n------.com
  • c------.com
  • c------.com
  • d------.com
  • i------.com (도메인 길이에 상관없이 '-' 갯수를 임의로 통일해서 표기함)

daum.net 도메인을 살펴보자. daum.net의 whois는 DomainTools whois  또는 godadday whois  등을 포함하여 여러 whois 사이트와 whois 명령으로 살펴보았다.

daum.net whois

[ 2009.4.28현재 daum.net whois 결과 ]


daum.net whois

[ 2009.4.28현재 daum.net whois 결과 ]



1. 최종 갱신일(Updated Date)을 보면 4.25(토)이다. 변조는 토요일에 발생났다. 위 도메인 모두 그렇다.

   Updated Date: 25-apr-2009

2. Status정보가 특이하다.

   Status: clientDeleteProhibited
   Status: clientRenewProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Status: serverDeleteProhibited
   Status: serverRenewProhibited
   Status: serverTransferProhibited
   Status: serverUpdateProhibited

   일반적으로 ok로 표시되거나 clientTransferProhibited 이나 clientDeleteProhibited, clientUpdateProhibited 정도의 상태 정보만 표시가 되는데, client... 로 시작하는 것 4개와, server... 로 시작하는 상태 정보까지 보인다. 이는 1) 도메인 정보를 악의적으로 변경한 자가 더이상 도메인 정보를 변경할 수 없도록 금지(Prohibited)시켰거나,  2) 도메인업체에서 관리기관에서 더이상 누군가 변경을 못하도록 임시로 보호조치를 취했을 것 같다. daum.net의 3.5일 갱신 정보에는 clientDeleteProhibited, clientTransferProhibited, clientUpdateProhibited 이렇게 3개 상태 정보만 갖고 있었다.

참고로 google.com이나 yahoo.com은 clientRenewProhibited 과 serverRenewProhibited를 제외한 6개의 Status를 갖고 있다.

3. Administrative Contact 정보와 Technical Contact 정보가 모두 아래와 같이 변경되어 있다. 도메인 소유 업체의 정보가 나와야할 것인데, 엉뚱한 정보뿐이다. 그리고, 얼핏보면 메일주소가 미국 업체Godaddy인 것처럼 보인다.

      Tigran, Arutunyan  domain.godaddy@yahoo.com
      Domain
      537 Seabright Ave.
      Santa Cruz, California 95062
      United States
      +1.4965784      Fax --


위의 3가지 도메인 정보때문에 변조되었을 것으로 추정한 것이다. 7개 도메인이 모두 같은 '국내 도메인 등록업체'(의심가는 서비스 업체가 있으나 얘기하지는 않겠음)일 가능성이 있다. 그리고, 그 등록업체의 문제로 인해 변조되었을 것이다. whois의 history정보를 볼 수 있다면 좀 더 명확해질텐데, 비용이 발생해서 볼 수가 없다. ^^ whois 정보로만으로 제3자 입장에서 파악하는게 쉽지가 않다. 한가지는 확실하다. 국내 대표 사이트의 도메인 정보가 이렇게 나온 경우는 본 적이 없다.



* 도메인 변조 관련

----------------------------------------------------
2009.6.4(목) 추가 사항

* 도메인 상태 코드(Status Code)에 대한 자세한 것은 '도메인 정보의 숨겨진 비밀, 상태 코드'를 보시길 (2009.5.28, 글 좋은진호)
Posted by 좋은진호
IT이야기2009. 3. 9. 23:53
웹프로그래밍을 할 때, 웹브라우저명(Agent)이나 레퍼러(Referer) 정보를 화면에 출력할 경우가 있다. Request header의 웹브라우저명, 레퍼러를 누구나 쉽게 변경(위조)가 가능하다는 것을 알면서도 특별한 조치없이 바로 echo하는 경우가 많다. 일반적인 브라우저명이라면 다음과 같은 형식이다. 그대로 echo한다고 해도 문제가 되지 않을 것이다. 

Mozilla/5.0 (X11; U; Linux i686; ko; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

그러나 다음과 같이, 브라우저명에 자바스크립트 등의 코드를 넣은다면 상황은 달라질 것이다. 피해는 XSS나 XSRF에 비해 미비할 수도 있겠지만 악의적인 임의의 자바스크립트를 실행할 수 있다.

<script>alert('hello')</script>

브라우저명에 실행가능한 형태의 코드나 자바스크립트를 넣는 것을 XAS(Cross Agent Scripting)라고 하며,
레퍼러에 넣는 것을 XRS(Cross Referer Scripting)이라고 부른다.

레퍼러를 변경해서 테스트해보자. FireFox에는 레퍼러를 변경할 수 있는 'RefControl' Addon( http://addons.mozilla.org/ko/firefox/addon/953 )이 있다. 설치 후 도구 -> RefControl Options -> Add Site 를 클릭한다.

RefControl

( Firefox RefControl Addon에서 Referer를 사용자가 설정하는 화면 )



단순히 <? echo $_SERVER['HTTP_REFERER']; ?>만 되어 있는 페이지의 경우 다음과 같이 자바스크립트가 실행되는 것을 확인할 수 있다.
XRS 임시 테스트 화면

( XRS 테스트 결과. 이 페이지는 테스트를 위해 임시로 만듬. 실제 존재하지 않음 )



XAS, XRS를 막기위해서 php의 경우 htmlspecialchars() 함수 등으로 특수문자(<, > 등)를 변환해야 한다.

[ 좋지 않은 php 코드 ]
<?
echo $_SERVER['HTTP_USER_AGENT'];
echo $_SERVER['HTTP_REFERER'];
?>

[ 안전한 형태의 php 코드 ]
<?
echo htmlspecialchars($_SERVER['HTTP_USER_AGENT']);
echo htmlspecialchars($_SERVER['HTTP_REFERER']);
?>

※ XSS(Cross Site Scripting), CSRF/XSRF(Cross Site Request Forgery)에 대한 한글 문서는 많으나 XAS, XRS에 대한 글은 거의 없어 정리했다.

Posted by 좋은진호
시스템이야기2008. 12. 11. 00:34
GreenSQL( http://www.greensql.net/ )은 MySQL에 대한 SQL 인젝션(Injection) 공격을 방어하는 프락시 개념의 어플리케이션이다. 웹페이지를 호출하면 DB쿼리는 먼저 GreenSQL 로 넘어겨지고, 검사한 후 정상적이면 MySQL 서버로 요청하는 과정을 거친다.
GreenSQL을 설치하고 실행과정은 이렇다. MySQL 서버는 기존 그대로 실행(디폴트 3306 포트)하고, GreenSQL을 3305포트로 실행(127.0.0.1:3305)한다. 이 때 GreenSQL은 MySQL 서버로 커넥션이 이뤄진다. 웹페이지는 DB커넥션을 GreenSQL의 3305포트로 커넥션하도록 변경해주면 된다. (MySQL을 3305로, GreenSQL을 3306으로 실행할 수도 있을 것이다.)

[ 이미지 출처 : GreenSQL 홈페이지 ]

DB 쿼리의 정상, 비정상은 어떻게 판단하는가?

1) '관리자가 실행할 SQL 유형'이나 '민간한 형태의 SQL 유형'(flush privileges, show 명령, 불법적 형태 등)을 패턴 매칭 방식으로 찾아서 불법 요청으로 간주한다. 예를들면 DB관리 명령어, DB 스키마를 변경시도하는 경우, 시스템 파일을 액세스하려는 경우 등을 불법으로 간주한다. 이 패턴에 대해서는 설정 파일을 통해서 변경이 가능하다.

2) 그후 각 쿼리 유형에는 점수가 할당되어 있는데, 이 점수를 합산한다. 지정된 값 이상이 될 경우, 경고 메시지를 뿌려주거나 차단할 수 있다. 유형은 다음과 같다.

* Access to sensitive tables increases risk query (users, accounts, credit information)
* Comments inside SQL commands increases query risk
* Usage of an empty password string
* Found ‘or’ token inside query
* Found SQL expression that always return true (SQL tautology)
* Comparison of constant values (SQL tautology)
* ... 등 ...

점수는 설정 파일을 통해서 변경이 가능하다. 다음은 샘플 설정 파일의 일부이다.
# If query risk is bigger then specified value, query will be blocked
block_level = 30
# Level of risk used to generate warnings. It is recomended to run application
# in low warning level and then to acknowledge all valid queries and
# then to lower the block_level
warn_level=20
# Risk factor associated with SQL comments
risk_sql_comments=30

차단된 샘플 로그이다. (sCag님 제공. 감사합니다.)

2008-12-09 16:54:18 mysql SELECT * FROM user WHERE name = 'x' or 1=1; --' AND pwd=SHA('')  blocked

GreenSQL에 대한 결론이다.

  • 멋진 생각이다. ^^
  • 패턴 설정과 차단수준을 유동적으로 변경 가능하다.
  • 대부분의 리눅스 배포판을 지원하며, FreeBSD도 지원한다.
  • 성능 테스트 결과 약간의 성능 저하가 발생한다. (2~12%정도)
  • 대용량 서비스에서 사용하기는 무리가 있을 것 같다.
  • 소규모 사이트나 웹호스팅에서는 고려해볼만 하다.
  • SQL Relay(DB 풀링과 로드발런싱 등)에서 제공하는 기능 등이 하나로 합쳐진다면 멋질 것 같다.
※ 개인적으로 GreenSQL을 운영하지 않습니다. 소규모 사이트, 웹호스팅에서 유용할 것 같아 소개해드리는 것이며, 운영상 궁금한 점을 저에게 질문하셔도 답해드릴 수 없습니다. ^^
※ 글쓰고 나니깐 sCag님도 GreenSQL 글을 쓰셨네. 안쓰실 것 처럼 말씀하시더니. ㅋㅋ

Posted by 좋은진호