시스템이야기2012. 1. 11. 18:37
Hash table 충돌을 이용한 DoS 공격(일명 HashDoS)을 해결한 PHP 5.3.9버전이 나왔습니다.
  • php 5.3.8 포함하여 이전 버전 사용중 : 필히 업그레이드 할 것
  • php 5.3.9 RC 또는 5.4.0 RC4~RC5 사용중 : 임시 업그레이드하셨던 분은 필요하면 정식 버전을 적용해도 되겠네요.

php


참고로 php.ini의 max_input_vars default값은 1000입니다.

http://www.php.net/index.php#id2012-01-11-1

The PHP development team would like to announce the immediate availability of PHP 5.3.9. This release focuses on improving the stability of the PHP 5.3.x branch with over 90 bug fixes, some of which are security related.

Security Enhancements and Fixes in PHP 5.3.9:

* Added max_input_vars directive to prevent attacks based on hash collisions. (CVE-2011-4885)
* Fixed bug #60150 (Integer overflow during the parsing of invalid exif header). (CVE-2011-4566)


※ 2012.2.2에 php 5.3.10버전이 나왔습니다. HashDoS를 패치한 5.3.9버전에 원격에서 코드를 실행할 수 있는 취약점이 있습니다. 자세한 것은 'php 5.3.10으로 업그레이드하세요."를 읽어보세요.

* HashDoS 관련 글

- 2012/01/04 - [시스템이야기] - php에서 hash table DoS(HashDoS) 공격 방어
- 2012/01/02 - [시스템이야기] - 웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)


Posted by 좋은진호
시스템이야기2012. 1. 4. 09:36
HashDoS 공격에 대해서는 '웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)'  을 읽어보기 바란다.

웹서버에서는 Request POST, GET 변수를 hash 구조로 관리한다. 그런데 POST 요청 파라미터수가 상당히 많을 경우(GET 요청은 길이 제한이 있으므로 문제가 되지 않음)에 hash 충돌이 많이 발생하게 되어 CPU load가 상당히 올라가게 된다. 이런 문제는 PHP5, Asp.Net, Java, V8 자바스크립트 엔진 등에서 발생한다.

취약점을 해결하거나 공격을 약화시키는 방법이다.

1. php 5.4.0 RC버전과 앞으로 나올 PHP 5.3.9 버전 (취약점 해결)

max_input_vars 설정으로 파라미터 개수를 제한한다.

2. 기존 php버전에서 (완벽한 해결이 아닌 공격을 약화시키는 방법)

php.ini 설정값 (default)
max_input_time = 60     ; Maximum amount of time each script may spend parsing request data
post_max_size = 8M

max_input_time은 요청 데이터를 파싱하는데 걸리는 최대 시간이다.
max_input_time으로 파싱 시간 제한, post_max_size으로 POST 사이즈를 제한함으로써 파라미터수를 어느정도(?) 제한하는 효과를 갖는다. 완벽한 해결이 아닌 공격을 약화시키는 방법이다.

기존에 쌓아둔 웹로그를 분석해서
  1. 스크립트의 실행 시간이 얼마나 걸리는지 (max_input_time 설정위해. 웹로그 시간은 정확히는 전송시간 + max_input_time + max_execution_time과 관련)
  2. POST 요청의 사이즈를 분석한다. (post_max_size 설정위해)
수치를 적절히 파악한 후 서비스에 지장없는 정도로 조절한다.
(예 : max_input_time = 10, post_max_size = 100K)
단, 파일이 업로드되는 서비스는 POST사이즈가 크므로 post_max_size는 적용하기 어렵고, max_input_time만 설정해볼 수 있다.

3. 수호신(suhosin) php 보안 모듈 사용 (취약점 해결)

suhosin.post.max_value_length = 1000000
suhosin.post.max_vars = 500
suhosin.request.max_vars = 500

수호신 모듈을 사용하면 위 설정만으로도 문제가 해결된다. 최대 파라미터 개수를 500개로 제한한 경우이다. default는 1000이다. 다음과 같이 차단되었음을 확인할 수 있다.

suhosin[95705]: ALERT - configured POST variable limit exceeded - dropped variable '..생략..' (attacker 'xxx.xxx.xxx.xxx', file '/..생략../index.html')

4. apache와 nginx에서 POST사이즈 제한 (100K로 제한하는 예)

POST사이즈 제한을 php설정 외에 웹서버 자체 설정도 적용하고 싶다면 다음과 같이 한다. 위 2번에서 설명한대로 기존 웹로그를 분석해서 적절한 POST사이즈를 파악해서 적용한다.

1) apache
   LimitRequestBody 100000

2) nginx (defaul는 1MB)
   client_max_body_size 100k;


※ 다음은 php.ini의 max_input_time 설정을 착각하는 분들이 있어 정리했다. (1.4(수) 19시)

위에서 말한대로, php.ini 설정 중 max_input_time은 HTTP '요청 데이터(POST, GET)를 파싱하는데 걸리는 시간'이다. 'input' 이라는 단어가 들어가기 때문에, 전송되는 시간으로 착각하는 경우가 있다. 하지만 모든데이터를 다 받은 순간부터 실행 시작하기까지의 시간이다. 아래에서 3번에 해당하는 구간이다.

1) POST 요청 -> 2) POST 데이터 전송 -> 3) 전송후 파싱 -> 4) 실행

정상적인 요청이라면 파싱하는데 걸리는 시간은 짧다. 그래서 이 수치를 줄임으로써 어느정도의 효과가 있다.


Posted by 좋은진호
시스템이야기2012. 1. 2. 19:20
먼저 공격 동영상 한편을 보자.

Denial of Service using Hash tables collisions in PHP


hash table collisions버그를 이용해서 PHP로 DoS공격을 하는 예이다. 동영상에서는 약 190초 동안이나 CPU load가 15%정도 올라갔다. H/W사양이나 요청하는 POST값은 다양하니 수치의 의미보다는 load 상승의 심각성을 중요포인트로 생각해야 한다. 이런 비정상 요청 몇개만으로 서비스는 제대로 이뤄지지 않을 수 있다. '단 몇개만'으로.

웹서버에서는 Request POST, GET 변수를 hash 구조로 관리한다. 그런데 POST 요청 파라미터수가 상당히 많을 경우(GET 요청은 길이 제한이 있으므로 문제가 되지 않음)에 hash 충돌이 많이 발생하게 되어 CPU load가 상당히 올라가게 된다. 이런 문제는 PHP5, Asp.Net, Java, V8 자바스크립트 엔진 등에서 발생한다.

PHP의 경우 5.4.0 RC버전과 앞으로 나올 PHP 5.3.9 버전에서 max_input_vars 설정으로 파라미터 개수를 제한할 수 있다.

현재 @hashDoS 트위터( http://twitter.com/hashDoS )에서 이번 취약점에 대한 논의가 있으니 참고하기 바란다.

* php에서 hash table DoS(HashDoS) 공격 방어 (정리해서 올렸습니다. 1.4(수) 오전)
* hashDoS 취약점 관련 글


Posted by 좋은진호
시스템이야기2011. 8. 31. 17:15
지난주 '아파치 웹서버를 한방에 다운시키는 Range요청 취약점'이 발표되었다.

apache 웹서버


국내에서는 이 DoS 취약점에 대해 너무나 조용하지만, 한방에 서버를 다운시킬 수 있는 심각한 문제이다. 아파치 웹서버(Apache)에 정상적이지 않은 형태로 Range 헤더를 요청하면, 웹서버의 load는 단 몇초만에 급상승하여 서버는 응답을 처리할 수가 없다.

아파치 1.3, 2.0, 2.2버전대 모두 DoS 취약점이 존재한다. 오늘 DoS 취약점을 패치한 2.2.20 버전을 발표했다.

SECURITY: CVE-2011-3192 (cve.mitre.org) core: Fix handling of byte-range requests to use less memory, to avoid denial of service. If the sum of all ranges in a request is larger than the original file, ignore the ranges and send the complete file. PR 51714.

예전 1.3.x버전 운영중인 분들은 더 이상 지원하지 않는 버전대를 버리고 2.2.x대로 갈아타시기 권장한다. 2.0.x버전대는 조만간 발표될 것이다.
2.2.20 테스트 결과, 해당 취약점이 패치된 것을 확인했다.


Posted by 좋은진호
시스템이야기2011. 8. 30. 13:22


apache


jjun님이 글을 쓰셨으니 간단하게만 몇가지 언급하겠다.

'아파치 웹서버 무력화시킬 심각한 DoS 결함 발견' 기사에는 mod_deflate또는 mod_gzip 모듈과 관련이 있는 것으로 쓰여있지만, 이 모듈과는 무관하게 취약점이 존재한다. 해당 모듈을 주석처리해도 악의적인 Range 헤더 요청에 대해 똑같은 문제가 있으며, 아파치 메일링 리스트에서도 이 모듈을 언급한 것은 잘못된 판단이었다고 한다.

* Bug 51714 - Byte Range Filter might consume huge amounts of memory combined with compressed streams
As discussed on the Apache Dev Mailing list it looks like this issue has nothing to do with mod_deflate or mod_gzip, wrong assumption by me.

웹페이지 size에 따라서, Range 헤더의 문제가 발생할 수도 있고 없을 수도 없다.

1) mod_php5모듈이 없다면 웹페이지 size에 상관없이 문제가 있다.
2) mod_php5모듈과 함께 아파치를 동작중이라면 8000bytes 이하의 웹페이지를 요청할 때만 문제가 발생한다. mod_php5 모듈이 있더라도 php로 인식하지 않는 확장자(예를 들어 .css, js, .txt 등)는 사이즈에 상관없이 문제가 있다.

따라서 index페이지만 체크하고 '우리는 문제가 없네'라고 판단해서는 안된다. php로 된 index가 8000bytes를 넘는다면, 취약점이 없는 것으로 보일 수 있기 때문이다.

Request 헤더에 Range: bytes=0-,1-2,2-3,4-5 같은 형태로 요청했다고 가정하자.

0-은 해당 웹페이지의 시작부터 끝까지를, 1-2는 웹페이지의 2번째~3번째 문자(0부터 시작하니깐 1-2는 2~3번째)를, 나머지도 같은 의미이다. 일반적으로 콤마(,)로 구분해서 여러 필드를 요청하는 경우는 없다라고 생각하면 된다.

[ 아파치 설정에서 Range헤더에 콤마를 제한하는 예 ]
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

따라서 위처럼 5개 필드 이상(콤마가 5개 이상)인 경우만 제한해도 좋고, 간단하게 콤마(,)가 포함된 경우를 차단해도 무방할 것으로 보인다.
곧 패치버전이 나올 것이다. 하지만 그 때까지는 L7장비 또는 웹서버에서 Range 헤더 조건 강화하는 방법으로 차단해야 할 것이다.


* 관련글 :
  - Mitigation of Apache Range Header DoS Attack
  - DoS with mod_deflate & range requests

* 내용 추가 (2011.8.31(수) 점심)

이 DoS 취약점을 패치한 2.2.20 버전이 발표되었다.

- Release 정보 : http://www.apache.org/dist/httpd/Announcement2.2.html
- 다운받기 : http://ftp.daum.net/apache/httpd/




Posted by 좋은진호
IT이야기2011. 1. 20. 22:48
DDoS공격은 꾸준했지만, 최근 12월과 1월에 DDoS 공격량이 증가하고, 공격도 심해졌다는 얘기를 한다.

최근 몇몇 업체가 DDos공격을 받았다. 이들 업체도 DDoS 공격 피해자인데, 고객들에게 그것도 못 막냐~라는 얘기를 듣게 되고, 고객에게 미안한 마음까지 생긴다. 하지만 이들 업체가 노력하지 않아서 못 막는게 아니다. 차단위한 인프라 구축에도 한계가 있다. 만약 50G, 아니 100G가 들어온다면 일반적인 국내 환경에서 이 트래픽을 감당할 인프라를 갖춘 곳이 얼마나 되겠는가.

1. 폭우가 쏟아져 상류댐에서 대량의 물을 방류하게 되면 하류에서는 대비를 하더라도 피해를 입을 수밖에 없다.

이런 경우 해결할 방법은 상류댐(IDC나 연동망 등)에서 물길을 막아주는 것 밖에 없다.(이를 IP null routing이라고 한다. 공격받는 IP로 들어오는 트래픽을 상단에서 버리는 것이다.) 그러나 이 댐은 특이해서 물을 한방울도 흘러보내지 않거나 대량의 물을 그대로 방류하거나 둘중 하나만 선택할 수 있다. 어쩔 수 없이 물을 한방울도 흘러보내지 않는 것을 선택하게 된다. 대량의 물은 막았지만 식수난을 겪게 된다. (IP null routing을 하게 되면 공격 트래픽은 막아지지만 해당 IP로는 서비스를 할 수 없다. 인프라는 보호했지만 서비스는 못하는 현실)

DDoS

[ 이미지 출처 : 구글 이미지 검색 -> make.to ]


※ DDoS공격 유형은 여러가지가 있는데, 위는 UDP유형으로 대역폭을 초과하는 공격을 예로 든 것이다.
※ DDoS공격은 유형에 따라 차단할 수 있다. 그리고, 인프라를 초과하더라도 상단과의 협조와 내부 DDos방어장비를 이용해 단계별 처리로 피해를 줄일 수 있다. 먼저 DDoS방어장비 구축과 인프라 개선은 해야하는 것은 당연하다.


2. 최근 공격량이 증가했다는 것은 좀비 PC가 늘었다는 이야기가 된다. '선' 좀비 PC 구축 -> '후' DDoS공격의 형태이기 때문이다.

'하우리의 맞춤전용백신 목록'에서도 Trojan/DDoSAgent 전용백신이 작년 11월부터 증가했다. 좀비 PC도 늘어 났다는 것이다.
인터넷침해대응센터(KRCERT)의 보안공지( http://www.krcert.or.kr/ )를 보면 12월말부터 국내 주요 오픈소스 게시판의 취약점이 줄줄이 발표되었다. (당시 대량의 서버에 설치된 제로보드를 자동 패치하느라 고생한 커피닉스 분이 생각난다. ^^) 이들 3개 게시판이면 국내 공개 게시판의 대부분을 커버한다고 보면 된다.
취약점을 이용해 악성코드만 심으면, 공장에서 찍어내듯 좀비 PC를 만들 수 있는 대량 양산 체제를 구축한 것이다. 밤낮이 필요없는 24시간 양산 체제. 게시판 사용하는 사이트는 널려있으니, 악의적인 사람 입장에서는 원감절감(노력절감) 체제. 우리 나라 좀비 PC들은 네트웍도 빵빵하고, 성능은 날아다닌다. 그만큼 막강한 공격력을 자랑(?)하게 된다.

[ 인터넷침해대응센터(KRCERT)의 보안공지 ]


* 국내 공개 웹 게시판(제로보드) 취약점 주의 (2010/12/21)

  o 국내 PHP 기반의 공개 웹 게시판 제로보드에서 XSS, CSRF 및 RFI 취약점이 발견됨[1, 2]
  o 해당 취약점을 이용한 홈페이지 변조 및 원격 실행 위협이 발생함에 따라, 취약한 버전 사용자의 주의 및 조속한 패치가 요구됨

* 국내 공개 웹 게시판(테크노트) 취약점 주의 (2011/01/06)

  o 국내 PHP기반의 공개 웹 게시판인 테크노트에서 SQL인젝션 취약점이 발견됨 [1]
  o 취약한 버전을 사용하고 있을 경우, 홈페이지 해킹에 의한 내부정보(개인정보 등)유출 등의 피해를 입을 수 있으므로 웹 관리자의 적극적인 조치 필요

* 국내 공개 웹 게시판(그누보드) 취약점 주의 (2011/01/07)

  o 국내 PHP기반의 공개 웹 게시판인 그누보드에서 XSS, CSRF 취약점이 발견됨[1]
  o 취약한 버전을 사용하고 있을 경우, 홈페이지 해킹에 의한 관리자 계정 탈취 및 악성코드 유포지로 악용되는 등의 피해를 입을 수 있으므로 웹 관리자의 적극적인 조치 필요

게시판 취약점 이용한 악성코드 심기, 유명사이트 해킹으로 악성코드 심기, 웹브라우저의 zeroday취약점 등으로 좀비 PC 양산체제 구축은 꾸준할 것이다. DDoS공격 증가와 좀비 PC 양산체제 여건 마련은 무관하지 않다.

PC점검 철저히 하시라. 그리고 IE에만 의존하지 말고, 파이어폭스나 크롬 등도 이용하시라.
내가 이용자이면서 그들에게 공격자일 수도 있다. 누구를 욕할 처지가 아닐 수 있다.
Posted by 좋은진호
IT이야기2007. 2. 8. 11:52
DDoS공격이 1월말부터 증가했고, J 모 채팅 사이트가 며칠째 서비스를 못한다는 얘기를 들었습니다.
작년부터 DDoS공격이 있었지만 최근에 공격이 보다 증가하고, 강도도 높아진걸로 보입니다.
이는 언론에서도 얘기하듯이
1) 기존의 돈요구 목적 외에
2) 31일에 중국에서 있었던 동계아시안게임때 우리팀 선수의 백두산 세리머니로 인해 중국해커들의 공격이 있는 걸로도 추측해볼 수 있을 것 같습니다.

최근 DDoS 공격에 대한 얘기들이 많이 나오고는 있지만 중국발 웹해킹(특히 윈도)에 대한 것도 빼놓을 수가 없겠죠. 커피닉스에 몇몇 웹해킹 관련 정보를 적어둔게 있으니 검 색해보시면 될겁니다. 이전에 적어둔 웹해킹 사례외에도 몇몇 사이트를 알고 있지만 친분상 알게된 정보라 따로 얘기하지 않겠습니다.

블로그, 신문기사와 호스팅사이트를 토대로 DDoS 공격을 당한 경우를 정리했습니다. 이외에 누구나 아는 대형 사이트 몇개가 있지만, 해당 업체관계자에게 직접 들은 정보가 아니어서 말씀드리지 않겠습니다. (몇 단계를 거치다 보면 정확하지 않은 정보가 전달되는 경우가 있으니깐요. ^^*)

1. 티스토리 서비스 장애관련 (2007.1.29 오전~)

http://notice.tistory.com/736

1월 29일 오전 10시경 부터 약 한시간여 동안 티스토리 서비스의 접속이 원할하지 못하였습니다. 외부의 서비스 방해 공격에 의해 네트웍에 과부하가 걸린 상태에서 일부 네트웍 장비가 장애를 일으켜 결과적으로 티스토리에 접속이 어려운 상태가 되었습니다. 티스토리 서버들은 정상적으로 운영되고 있었으며, 문제가 된 네트웍 장비에 대해 원인을 파악하여 해결하고 보안성을 강화하였습니다.

한시간여 동안이라고 쓰여있지만 실제로는 그 이상이였죠. 티스토리 장애건 워낙 많은 블로거들이 써서 따로 적지 않겠습니다.

2. 닷네임코리아 (2007.1.29)

http://www.dotname.co.kr/server_error2.html

http://blog.naver.com/anlichol?Redirect=Log&logNo=150014189101 (2007.2.5, 양선생님)
http://s2day.tistory.com/293 (2007.2.5, S2day님)

withpartner.co.kr 이라는 사이트가 공격을 당했다고 하는데, 이 사이트가 닷네임코리아에 할당된 IP입니다.
그래서 닷네임코리아의 일부 IP대역이 서비스가 안되었을 걸로 추측합니다. 아래는 with... IP를 whois한 결과입니다.

IPv4 주소          : 211.39.253.0-211.39.254.255
네트워크 이름      : DOTNAMEKOREA
연결 ISP명         : DREAMX
할당내역 등록일    : 20060315
할당정보공개여부   : Y

참고 : 중국발 해킹(DDoS) 최종 종착역은? (2007.2.5. withpartner.tistory.com )

3. 기타 사이트의 공지사항

http://www.mireene.com/bb.php?mode=read&no=150&page=1&bid=notice (2007.1)
http://ipix.esocom.com/dboard/main.php?url=./board_view&bseq=1&subseq=4&no=210 (2006.12)
http://www.happyjung.com/gnuboard/bbs/board.php?bo_table=notice&wr_id=236 (2006.12)

위의 내용은 IDC내의 다른 사이트가 공격을 당해 호스팅업체까지 영향을 받은것인지는 공지사항을 읽어보시고 판단을 하세요.

4. 언론 보도

- "해킹 안당하려면 돈내" 중국 해커 공격 급증 ( 한계레, 2007.2.6 17:48 )
http://news.naver.com/news/read.php?mode=LSS2D&office_id=028&article_id=0000187055

- '중국발 해킹피해' 속수무책 (YTN, 2007.2.6 18:51, 사흘간 서비스 중단. 심하다. ^^* )
http://search.ytn.co.kr/ytn/view.php?s_mcd=0103&key=200702061851014569

- IP중국발 DDOS 해킹 사례 급증! ( 한국경제21,  2007.2.6 11:16 )
http://www.keconomy21.co.kr/board_view_info.php?idx=435&seq=3

- 국내 수천여 개 사이트, '인해전술' 해킹 당했다 ( SBS TV, 2007.2.7 )
http://news.naver.com/news/read.php?mode=LSS2D&office_id=055&article_id=0000090903

6일에 root DNS서버 공격을 당했다는 건 아시는 분들이 있을건데요,
root DNS서버의 response time을 확인해보고 어떤 root DNS서버인지 직접 찾아 볼겁니다.
데이터로 파악이 안되고, 보안업체에 문의해서 정보가 없다면 추가로 글은 안쓰겠습니다. ^^*

---------------------------------------------------------
5. 호스팅 업체들 (2007.2.14 추가 작성)

- 아이비호스팅 (2007.2.7(수) 00:30~??:??)
http://ivyro.net/ivyro/board/list.php?mode=read&number=157&board_name=iwebboard_notice

- 아이비호스팅 (2007.2.5(월) 11:??~12:30)
http://ivyro.net/ivyro/board/list.php?mode=read&number=153&board_name=iwebboard_notice

- 마루호스팅 (2007.2.5(월) 17:40~, 20:00~21:??, UDP, ICMP)
http://www.maru.net/bbs/view.php?id=notice&no=203
http://www.maru.net/bbs/data/notice/attacked_mrtg.jpg
http://sir.co.kr/bbs/board.php?bo_table=cm_free&wr_id=166879

- 마루호스팅 (2007.2.8(목) 18:34~20:32, 최대 840M)
http://www.maru.net/bbs/view.php?id=notice&no=203

- 이미지호스팅 - 링크파일 (2006.12.26(화) 20:00~20:12)
http://www.linkfile.co.kr/board.htm?w=v&bm_id=1&si_id=282

- 모임즈 커뮤니케이션 (2006.2.13(화))
http://networks.moimz.com/moimz/board/board.php?bid=host_notice&no=138
Posted by 좋은진호