어플리케이션(7) 계층 취약점 공격

• HTTP Get Flooding 공격
• Hulk DoS 공격
• Hash DoS 공격
• slow HTTP Header DoS(slowloris) 공격
• slow HTTP POST DoS(RUDY) 공격
• slow HTTP Read DoS 공격
• CC attack 공격

HTTP Get Flooding 공격

"7계층" DDoS 공격의 한 유형

공격자가 동일한 동적 콘텐츠에 대한 HTTP GET 요청을 다량으로 발생
⇉ 웹 서버(공격대상)가 해당 요청을 처리하기 위해서 서버 자원을 과도하게 사용
⇉ 정상적인 요청을 처리하지 못 하도록 서비스 부하 일으킴

참고: https://www.cloudflare.com/ko-kr/learning/ddos/http-flood-ddos-attack/

이러한 형태의 공격에서는 여러 컴퓨터 또는 기타 장치를 조정하여 대상 서버로부터 이미지, 파일, 기타 자산에 대한 여러 요청을 보냅니다. 공격 대상이 들어오는 요청과 응답으로 넘쳐나면 합법적인 트래픽 소스의 추가 요청에 대해 서비스 거부가 발생합니다.

실습

⑴ 실행가능한 httpflooder.pl 파일 준비

⑵ HTTP Get Flooding 공격을 시작

perl ./httpflooder.pl -a GF -t 100 -n 1000 -u /index.php -h 10.0.0.50
※ 서버에 부하가 많은 동적(jsp, asp, php 등) 콘텐츠 자료를 GET Request

⑶ 공격 당하는 홈페이지가 정상적으로 서비스가 되는지 확인

HTTP Get Flooding 패킷 분석

• XP에서 확인해 보니 GET /index.php 요청하는 패킷이 반복해서 유입
• XP에서 CPU와 세션 상태 확인

Hulk DoS 공격

공격 대상 웹서버 URL 주소를 지속적으로 변경하면서, 다량으로 GET 요청을 발생시키는 서비스 거부 공격
⇒ 특정 URL로 과다 요청하는 것에 대한 임계치 기반의 공격을 탐지하는 DDoS 대응 장비 우회 의도

실습

⑴ hulk.py 파일을 이용해 Hulk DoS 공격 시작

⑵ 공격 당하는 홈페이지가 정상적으로 서비스가 되는지 확인

URL 정보에서 파라미터 값 계속 변경 ⇒ 임의의값 만들어서 요청

Hash DoS 공격

❗웹서버에서는 HTTP Request 요청 시 GET , POST 방식으로 전송되는 변수를 hash 구조로 관리

※ Hash Table :
클라이언트에서 HTTP 요청을 통해 전달되는 각종 파라미터 값을 관리하는 공간

이런 특성을 악용하여 조작된 수 많은 파라미터 값을 POST 방식으로 웹서버로 전달
⇉ 웹 서버는 다수의 해시 충돌(Hash Collision)이 발생
⇉ 해시테이블에 접근하는 시간이 급속도로 증가
⇉ 정상적인 파라미터 조회가 느려짐 (조회 시 많은 CPU 자원을 소모)
⇉ 서비스 거부 공격

실습

⑴ hashdostester.jar 툴을 이용한 실습

java -jar "hashdostester.jar"
실행 후 공격대상 입력, 요청 사이즈 200 조정하고 Start 클릭

URL : 공격대상

⑵ 요청 패킷 확인

요청 파라미터 정보는 “파라미터명=파라미터값”&“파라미터명=파라미터값” 반복

slow HTTP Header DoS(slowloris) 공격

HTTP Dos 툴로 TCP 세션을 정상적으로 연결 후,
HTTP 패킷 요청(GET 메소드)시에 불완전한 헤더값을 보내어 커넥션을 유지하게 둔 채 새로운 HTTP 연결을 반복해서 시도하는 방법

공격방식⭐

HTTP 헤더

각 필드는 \r\n (개행문자)로 마무리되고,
헤더의 가장 끝은 \r\n\r\n로 구성되어 있음

[HTTP Response Format] https://hazel-developer.tistory.com/145

• 서버 입장에서는 TCP 3-Way Handshake가 맺어진 이후
  HTTP 헤더의 끝을 인식하기 위해 \r\n를 두 번 받아야 한다.
  ❓만약, 두 번째 \r\n이 오지 않을 경우, 헤더 정보가 아직 전송 중이라고 인식하고 연결을 유지

  Slowloris는 이러한 점을 악용
  => \r\n을 한번만 보낸 상태에서 마지막 개행문자를 보내지 않고 지속적으로 의미없는 변수를 전송
  => 세션 고갈
  => HTTP 세션을 계속 잡아두게 하는 공격

대응방안 : 연결 타임아웃 시간을 적절히 짧게 두어 의심되는 연결이 종료되도록 한다

실습

⑴ slowloris.pl을 이용해 HTTP DOS 공격을 시작

perl ./slowloris.pl -dns 10.0.0.50

⑵ 공격 당하는 홈페이지가 정상적으로 서비스가 되는지 확인

⑶ Wireshark로 패킷 확인

Header와 Body를 구분하는 0d0a0d0a가 아닌, 0d0a(=\r\n)에서 끝냈다는 것은 아직 전송할 헤더가 남았음을 의미

slow HTTP POST DoS(RUDY) 공격

HTTP POST Method를 사용하여 헤더의 Content-Length 필드에 임의의 큰 값을 설정하여 전송한 후, 소량의 데이터(1byte)를 느린속도로 전송하여 세션연결을 유지하며 공격하는 방식

공격방식

클라이언트와 서버가 정상적인 3-Way Handshaking을 거친 다음
⇉ 클라이언트가 POST 데이터를 보낼 때, Content-Length 필드를 20000으로 지정 한 후, 서버로 전송
⇉ 서버는 클라이언트에서 20000 Byte의 데이터가 들어올때 까지 해당 세션을 열어둠
⇉ 하지만 클라이언트는 1초에 1Byte씩 전송
⇉ 20000초(5시간 30분)동안 세션이 유지됨

RUDY : Are You Dead Yet! (너 아직도 안 죽었니?)

실습

⑴ Slow HTTP POST DOS(RUDY)공격 시작

slowhttptest -X -c 1000 -r 500 -w 10 -y 20 -n 5 -z 32 -p 3 -u http://10.0.0.50

⑵ 공격 당하는 홈페이지가 정상적으로 서비스가 되는지 확인

slow HTTP Read DoS 공격

TCP의 흐름 제어 = 연결된 상호간에 수신 가능한 양만큼만 데이터를 전송하는 제어방식

TCP 헤더의 Window 필드 ⇒ 수신측에서 수신 가능한 여유 공간의 크기를 담아서 송신측에게 전달하는 헤더 필드
if, 수신측에서 여유 공간이 없다면, Zero Window Packet으로 응답

공격자는 이런 TCP 흐름 제어 특성을 이용하여 HTTP 요청을 보낸 후 Window 사이즈 크기를 0으로 조작하여 지속적으로 서버에 전달하여 서버가 요청에 대한 응답 메세질를 전송하지 못하고 연결을 지속으로 유지하도록 한다
웹서버의 연결 자원이 모두 소진되어 정상적인 요청을 받을 수 없는 상태로 만드는 공격

공격방식

대응책

동시 연결(concurrent connection)에 대한 임계치 설정을 통한 차단

• 동일한 출발지 IP에서 동시에 연결할 수 있는 연결 개수에 대한 임계치(Threshold) 설정
• iptable 이용한 30개 이상초과 동시 연결에 대한 차단 조치
  iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 30 -j DROP

연결 타임아웃(Connection Timeout) 설정을 통한 차단

• 웹서버 연결 후 아무런 데이터 송수신이 없이 세션을 유지하는 시간에 대한 Timeout 설정
• httpd.conf 파일에 timooutd 이 default 로 120초 값으로 설정되어 있는데 이것을 5초 설정 권장

읽기 타임아웃(Read timeout) 설정을 통한 차단

• 요청 header 와 body 각각에 대하여 타임아웃을 지정하여 지정한 시간 내에 read를 못하면 클라이언트에게 오류코드를 반환한다.

CC attack 공격

웹 캐시?

• 웹 문서(HTML, 이미지 등)를 캐쉬 서버에 미리 저장하여, 원본 서버 대신 전송해 주는 기술
• 사용자 응답 속도 향상, 원본 서버의 부하 감소 -> 서비스 안정성 증대
  

HTTP CC Attack 은 HTTP 1.1 RFC 2616 에 규정되어 있는 ‘Cache-Control’이라는 헤더 옵션값을 사용하여 웹 서버에 더 많은 부하를 유발시키는 지능화된 DDoS 공격 기법.

HTTP 요청 시 Cache-Control 설정을 User-Agent 헤더 필드에 첨부하여 서버의 부하를 발생

• no-store(캐쉬 저장 금지)=> 요구에 대한 어떠한 응답도 캐시하지 않음
• must-revalidate(캐쉬의 재검증) => 캐쉬 서버가 웹서버에 캐쉬 엔트리 검증을 요구