Slow Read

Slow Read

1. 설명

해커는 2가지 방법을쓴다

1) HTTP 파이프라이닝 (HTTP 1.1 스펙에서 동작)

설명

HTTP 파이프라이닝 : 네트워크 효율을 높이기 위해 하나의 세션에서 다수의 HTTP를 요청하고 응답받는 기술. 웹 서버의 송신버퍼 크기를 초과하는 HTTP 응답 데이터를 생성하기 위해 활용.   관련 기술1) : 커널 영역의 송신 버퍼보다 큰 데이터를 요청하면 프로세스는 전체 데이터를 커널에게 맡기고 그 사실을 잊어먹는다.    관련 기술2) 커널의 데이터는 ACK를 회신받아야 커널에서 반환한다. 즉 ACK를 받지못하면 커널에서 전송대기상태로 남는다. 결국 HTTP 파이프라이닝을 이용해 송신 버퍼보다 큰 데이터를 요청하면 프로세스는 전체 데이터를 커널에게 맡길 것이다. 그리고 공격자는 데이터를 수신할 때마다 윈도우 사이즈를 줄여서 결국 0으로 만들어버린다. 이러면 그 데이터는 커널 영역에 계속 남게 된다. 공격자는 계속 ACK를 0으로 응답하여 세션을 유지한다. 소수의 공격을 통해 소규모 트래픽만으로 웹서버를 다운시킬 수 있다. 이는 HTTP의 정당한 기술을 이용한 방법이다.

2) tcp flow control 약점을 이용 (이것이 더 크다)

설명

TCP는 흐름제어와 혼잡제어를 이용하여 신뢰성있는 전송을 보장한다.  흐름제어 : 송신자는 윈도우 크기만큼 수신자의 응답을 기다리지 않고 세그먼트를 전송할 수 있다. 이 윈도우크기는 수신자가 정하며 TCP는 패킷들의 전달이 확인될 때마다 윈도우를 옆으로 옮겨가며 그 다음 패킷을 전송한다.(슬라이딩 윈도우) 이는 보내고 응답이 올때까지 기다리는 방법보다 효과적이다.(stop and wait) 송신자는 수신자와 TCP 3 way handshaking을 통해 수신컴퓨터와 윈도우 크기를 동일하게 맞춘다.   - 취약점(송신프로세스) : 송신자가 매우 천천히 1바이트씩 전송하면 TCP/IP 헤더크기로 인해 41바이트의 세그먼트를 전송한다. 해결책으로 처음엔 1바이트를 보내지만 이후 점차 기다린 다음에 세그먼트를 전송한다.  - 취약점(수신프로세스) : 수신자는 윈도우 크기를 0으로 통보하면 송신자는 전달을 중단한다. 이후 1바이트를 입력버퍼로 가져가면 송신자는 1바이트 데이터를 전송한다. 해결책으로 수신자가 최대 크기의 세그먼트를 받을 수 없거나 버퍼의 절반이 비어있지 않으면 윈도우 크기를 0으로 통보한다. 또는 버퍼에 충분한 공간이 있을 때가지 응답을 하지 않는다. 다만 500ms 이내에는 응답을 해야한다.  혼잡제어 : 네트워크 데이터 처리 속도가 느린 경우 송신자의 속도를 제어한다. 흐름제어는 수신자와 송신자의 전송속도를 다루지만 혼잡제어는 호스트, 라우터를 포함하여 넓은 관점에서 전송 문제를 다룬다. 처음에 패킷을 하나 보내고 이것이 문제 없이 도착하면 시간 당 보내는 패킷을 증가시킨다. 실패할 경우 패킷 전송량을 반으로 줄인다.

2. 공격방법

1) 핸드쉐이킹을 통해 윈도우 사이즈를 알려준다.

2) HTTP 파이프라이닝을 통해 다수의 페이지를 요청한다.

3) 서버가 데이터를 보내줄 때마다 ACK 보내게 되는데 이 때 윈도우 사이즈를 점차 줄여나간다.

4) 이후 윈도우 사이즈가 0인 ACK를 계속 보낸다.

3. 쉬운 설명

HTTP 파이프라이닝같은 경우 하나씩이 아니라 초과해서 5개씩 떙겨서 보내라고한다.

사실 이것은 하나의 세션에서 다수의 HTTP를 요청하고 응답 받는 HTTP/1.1의 기술인데

Slow HTTP read dos에서는 웹 서버의 송신버퍼 크기를 초과하는 HTTP 응답 데이터를 생성하기 위해 활용되고 있다.

이게 OS에 구현되어있으면 서버는 클라이언트에게 말한다.

"나 10개 받을 준비가 되어있어"

또는 클라이언트가 서버에게 묻는다.

"너 이만큼받을 수 있어?"

다시 설명하면 난 이만큼만 받을 수 있으니까 넌 그만큼만 보내 라고 대화하면서 전송속도를 조절하는 것이다.

이때 송신자가 10기가보낸다고 하면 수신자는 믿어버린다. 그런데 너무 크니까 커널핸들에게 의탁한다.

그리고 프로세스는 그 사실을 잊어버리고 커널이 다 끝나고 말해야 기억난다.

만약 받는쪽이 못받겠다고 윈도우사이즈를 0으로 보내면 서버는 계속 그것을 기다려야만 한다.

커널에서 설정한 시간만큼 기다리는데...근데 타임아웃나기전에 1바이트씩 윈도우사이즈를 잡아서 보내면..여기서 문제가 생긴다.

근데 엄청난 리소스를 그만큼써야한다는의미 근데 조금씩 보내면 버퍼를 1기가 만큼잡아놨는데..그만큼 채울려니까 서버가 미치려고 한다.

4. 해결책

1) 커널 단

 - Persistence 타이머를 특정 수준의 윈도우 사이즈 통보가 수신되지 않으면 RST 또는 FIN 패킷을 전송하도록 한다.

2) 보안장비

 - 일정시간 동안 데이터가 수신 되지 않으면 RST 또는 FIN 패킷을 전송한다.

 - 비정상적인 Window Size를 가진 SYN 패킷을 차단한다.

 - 서비스 운영에 큰 지장이 없는 경우 HTTP 파이프라이닝을 제한한다.