Null HYD VRTDOS

DOS ATTACKSUSING

SLOWLORIS

V RAMAN TEJA

DOS ATTACKSUSING

SLOWLORIS

V RAMAN TEJA

About me!

Security Enthusiast Graphic & Web Designer Entrepreneur Engineering in the making CISE v 2.0

Security Enthusiast Graphic & Web Designer Entrepreneur Engineering in the making CISE v 2.0

Topics

Dos Attacks – A general description

Slowloris – Denial of Service – Stops Apache Webservers

Other Dos Attacks

Dos Attacks – A general description

Slowloris – Denial of Service – Stops Apache Webservers

Other Dos Attacks

Denial Of Service Attacks

Types of Dos Attacks

There is a variety of forms aiming at a variety of services:

Traffic consuming attacks or Network Layer Attacks(DNS,firewall, router, load balancer, OS, etc.)

Application Layer attacks (web server, media server,mail server)

There is a variety of forms aiming at a variety of services:

Traffic consuming attacks or Network Layer Attacks(DNS,firewall, router, load balancer, OS, etc.)

Application Layer attacks (web server, media server,mail server)

Network Layer attacks

HTTP GET

Application Layer attacks

Application Layer DoS attacks

Slow HTTP headers attack (a.k.a. Slowloris)Slow HTTP message body attack (a.k.a Slow Post)Slow read HTTP attack (a.k.a. TCP Persist Timer exploit)

Slow HTTP headers attack (a.k.a. Slowloris)Slow HTTP message body attack (a.k.a Slow Post)Slow read HTTP attack (a.k.a. TCP Persist Timer exploit)

What is low-bandwidth attack?M

bps/

sec

Mbp

s/se

c

Seconds

What is common?

All mentioned attacks aim at draining the poolof concurrent connections (usually relativelysmall)

HyperText Transfer Protocol (HTTP)Message syntax

Per RFC 2616

generic-message = start-line

*(message-header CRLF) CRLF

[ message-body ] start-line = Request-Line | Status-Line

Per RFC 2616

generic-message = start-line

*(message-header CRLF) CRLF

[ message-body ] start-line = Request-Line | Status-Line

HyperText Transfer Protocol (HTTP)Message example

GET /page.htm HTTP/1.1CRLF Host: www.example.com:8080CRLF Content-Length: 25CRLF CRLF Optional Message Body

GET /page.htm HTTP/1.1CRLF Host: www.example.com:8080CRLF Content-Length: 25CRLF CRLF Optional Message Body

SEND INCOMPLETE HTTP REQUESTS

Apache has a queue of approx. 256 requests Each one waits approx. 400 seconds by default for

the request to complete So less than one packet per second is enough to

occupy them all Which means Low-bandwidth DoS and no collateral

damage!

Apache has a queue of approx. 256 requests Each one waits approx. 400 seconds by default for

the request to complete So less than one packet per second is enough to

occupy them all Which means Low-bandwidth DoS and no collateral

damage!

Slowloris

Slowloris

Low bandwidth attack that sends HTTP requests withincomplete headers. It continues to send headers atregular intervals to keep the sockets active

First mentioned by Adrian Ilarion Ciobanu in 2007and implemeted by Robert Hansen in 2009

Low bandwidth attack that sends HTTP requests withincomplete headers. It continues to send headers atregular intervals to keep the sockets active

First mentioned by Adrian Ilarion Ciobanu in 2007and implemeted by Robert Hansen in 2009

How slowloris works

GET / HTTP/1.1\r\nHost: vulnerable-server.com:80\r\nX-sadwqeq: dfg4t3\r\n

X-4rete: fdsgvry\r\n

59 seconds later



X-egyr7j: 8ih\r\n

59 seconds later

59 seconds later

Client Server

Demonstration

Slow POST

Attack that sends HTTP requests with completeheaders but incomplete message body. There willbe no delay in HTTP header. Continues to senddata at regular intervals to keep the socketsactive

Nullifies IIS internal defence. Discovered by Wong Onn Chee and popularized

by Tom Brennan in 2009

Attack that sends HTTP requests with completeheaders but incomplete message body. There willbe no delay in HTTP header. Continues to senddata at regular intervals to keep the socketsactive

Nullifies IIS internal defence. Discovered by Wong Onn Chee and popularized

by Tom Brennan in 2009

How Slow POST works

POST / HTTP/1.1\r\nHost: vulnerable-server.com:80\r\nContent-Length: 4096\r\nContent-Type: application/x-www-form-urlencoded\r\n

59 seconds later

\r\n

foo=bar\r\n

&Owkuvj5=POaLLI\r\n

&uWat9wGqrP4SxV=SN3q\r\n

59 seconds later

59 seconds later

59 seconds later

...

Client Server

Slow Read

Attack that keeps server sockets busy by maliciouslythrottling down the receipt of large HTTP responses

Uses known Network Layer flaws to aim Application Layer

First mentioned by Outpost24 in sockstress. Implementedas part of nkiller2 by Fotis Hantzis, a.k.a. ithilgore in2009

Attack that keeps server sockets busy by maliciouslythrottling down the receipt of large HTTP responses

Uses known Network Layer flaws to aim Application Layer

First mentioned by Outpost24 in sockstress. Implementedas part of nkiller2 by Fotis Hantzis, a.k.a. ithilgore in2009

Related TCP details

“Window size (16 bits) – the size of the receivewindow, which specifies the number of bytes (beyondthe sequence number in the acknowledgment field)that the sender of this segment is currently willing toreceive” – Wikipedia

“Window size (16 bits) – the size of the receivewindow, which specifies the number of bytes (beyondthe sequence number in the acknowledgment field)that the sender of this segment is currently willing toreceive” – Wikipedia

How Slow Read works

bigp

age.

htm

l

Client ServerGET bigpage.html HTTP/1.1\r\nHost: vulnerable-server.com:80\r\n\r\nBTW, my recv window is only 32 bytes

HTTP/1.1 200 OK\r\nContent-Length: 131072\r\nContent-type: text/html\r\n\r\n message

Recv

buf

fer

Send

buf

fer

bigp

age.

htm

lHTTP/1.1 200 OK\r\nContent-Length: 131072\r\nContent-type: text/html\r\n\r\n messageKernel to app: I can send only 32 bytes now

Got it, wait for now (ACK window 0)

9090

Are you ready to receive more bytes?

OK, give me another 32 bytes

Prerequisites for successful SlowRead attack

The larger server response is - increasing the chances ofprolonging the connection

make server generate a data stream that doesn't fully fitinto socket's send buffer (65536 bytes is default on mostLinux systems /proc/sys/net/ipv4/tcp_wmem, if serverdoesn't set its own value)

Request large resource by naturally finding it and/oramplifying the response size by using HTTP pipelining.

The larger server response is - increasing the chances ofprolonging the connection

make server generate a data stream that doesn't fully fitinto socket's send buffer (65536 bytes is default on mostLinux systems /proc/sys/net/ipv4/tcp_wmem, if serverdoesn't set its own value)

Request large resource by naturally finding it and/oramplifying the response size by using HTTP pipelining.

time

Why is Slow Read different?Traditional (slowloris/slowpost) DoS

Customer stuck decidingwhat he wants

Makes an order Pays Takes the order Next!

It is possible to identify and isolateslow client in his request state

Customer stuck decidingwhat he wants

Makes an order Pays Takes the order Next!

It is possible to identify and isolateslow client in his request state

Why Slow Read is different?Slow Read DoS

Makes an order forparty of 50

Pays Cannot take the

entire order with him,makes several tripsto the car.

Next!

it is quite late to do anything, asthe request was already acceptedand processed



entire order with him,makes several tripsto the car.

Next!

Why is Slow Read different?



entire order with him,makes several trips tothe car

Next!

Customer stuck decidingwhat he wants Makes anorder & Pays Takes theorder Next!



entire order with him,makes several trips tothe car

Next!

Why is Slow Read different? (contd..)

Defense mechanisms expect the crushing fist of malice toappear in the request

Instead, the entire transaction should be monitored

Defense mechanisms expect the crushing fist of malice toappear in the request

Instead, the entire transaction should be monitored

There is a good chance that you are. Defaultconfigurations of nginx, lighttpd, IIS, Apache, Varnishcache proxy, Shoutcast streaming server - are vulnerableto at least one of the mentioned attacks

Am I vulnerable?

There is a good chance that you are. Defaultconfigurations of nginx, lighttpd, IIS, Apache, Varnishcache proxy, Shoutcast streaming server - are vulnerableto at least one of the mentioned attacks

Use available tools to simulate attacks. SlowHTTPTestcovers all mentioned attacks and some more athttp://slowhttptest.googlecode.com

Check out http://slowhammer.me to get access to yourown whitehat botnet in the cloud

Use Qualys WAF or other firewalls that are supposed toprotect, but test before you pay!

What should I do?

Use available tools to simulate attacks. SlowHTTPTestcovers all mentioned attacks and some more athttp://slowhttptest.googlecode.com

Check out http://slowhammer.me to get access to yourown whitehat botnet in the cloud

Use Qualys WAF or other firewalls that are supposed toprotect, but test before you pay!

Detection and Mitigation

Drop connections with abnormally small TCP advertisedwindow(s) (i.e. <<16bits)

Set an absolute connection timeout, if possible Limit length, number of headers to accept Limit max size of message body to accept Drop connections with HTTP methods (verbs) not supported

by the URL Limit accepted header and message body to a minimal

reasonable length Define the minimum data rate, and drop connections that

are slower than that rate

Drop connections with abnormally small TCP advertisedwindow(s) (i.e. <<16bits)

Set an absolute connection timeout, if possible Limit length, number of headers to accept Limit max size of message body to accept Drop connections with HTTP methods (verbs) not supported

by the URL Limit accepted header and message body to a minimal

reasonable length Define the minimum data rate, and drop connections that

are slower than that rate

Detection and Mitigation

Qualys Web Application Scanner passively detects theslow attack vulnerabilities

ModSecurity v2.6 introduced a directive calledSecWriteStateLimit that places a time limit on theconcurrent number of threads (per IP address)

Snort is working on detecting connections with small TCPadvertised window(s)

Christian Folini introduced Flying Frog script athttps://www.netnea.com

Qualys Web Application Scanner passively detects theslow attack vulnerabilities

ModSecurity v2.6 introduced a directive calledSecWriteStateLimit that places a time limit on theconcurrent number of threads (per IP address)

Snort is working on detecting connections with small TCPadvertised window(s)

Christian Folini introduced Flying Frog script athttps://www.netnea.com

Example of misconfiguration

OSI Model- a new approach

OSI Model DoS Attack

7 Application Slowloris – Incomplete HTTP Requests

6 Presentation

5 Session5 Session

4 Transport SYN Flood – Incomplete TCP Handshakes

3 Network HTTP GET/POST Flood

2 Data Link

1 Physical Cut a cable

A few more Attacks!A few more Attacks!

“the sky is falling.... but we cannot tell you why”

The new TCP DoS attacks

Source: news.softpedia.com

The “new” TCP DoS attacks

During 2008, the discovery of some (supposedly)new vulnerabilities received their share of press.

They were “announced” by Outpost24, but nodetails were provided – thus resulting in speculationby the community.

No counter-measures were proposed to vendors,either.

While not publicly credited for our work, weprovided advice to vendors on these issues.

During 2008, the discovery of some (supposedly)new vulnerabilities received their share of press.

They were “announced” by Outpost24, but nodetails were provided – thus resulting in speculationby the community.

No counter-measures were proposed to vendors,either.

While not publicly credited for our work, weprovided advice to vendors on these issues.

The “new” TCP DoS attacks

For the most part, the vulnerabilities are: Connection-flooding attacks (Naphta and FIN-WAIT-2

flooding attacks) Socket send buffer attacks (Netkill and closed windows) TCP reassembly buffer attacks

For the most part, the vulnerabilities are: Connection-flooding attacks (Naphta and FIN-WAIT-2

flooding attacks) Socket send buffer attacks (Netkill and closed windows) TCP reassembly buffer attacks

Some insights on the recent TCP DoSvulnerabilities

Some insights on the recent TCP DoSvulnerabilities

Connection-flooding attacks(Naphta and FIN-WAIT-2)

Connection-flooding attacks(Naphta and FIN-WAIT-2)

Naphta (connection-floodingattack)

TCP connections require end-points to keep state (insystem memory) for the connections.

Memory is a limited resource, and thus can betargeted for exhaustion: simply establish lots ofconnections with the target system.

This attack vector was known as “Naphta” -- seeCERT Advisory CA-2000-21.

To avoid exhausting his own resources simply craftsthe required packets to establish TCP connectionswith the target system, thus bypassing its kernelimplementation of TCP.

TCP connections require end-points to keep state (insystem memory) for the connections.

Memory is a limited resource, and thus can betargeted for exhaustion: simply establish lots ofconnections with the target system.

This attack vector was known as “Naphta” -- seeCERT Advisory CA-2000-21.

To avoid exhausting his own resources simply craftsthe required packets to establish TCP connectionswith the target system, thus bypassing its kernelimplementation of TCP.

Naptha attack (example)

Countermeasures for Naphta

Key problem: an actual attack does not necessarilydiffer from a high-load scenario

Possible counter-measures: Enforce per-user and pre-process limits Enforce limits on the number of ongoing connections

from a single system/prefix at the application-layer Enforce limits on the number of ongoing connections

from a single system/prefix at a firewall

Key problem: an actual attack does not necessarilydiffer from a high-load scenario

Possible counter-measures: Enforce per-user and pre-process limits Enforce limits on the number of ongoing connections



A typical connection-termination scenario:

FIN-WAIT-2 flooding attack

A typical connection-termination scenario:

FIN-WAIT-2 flooding attack

Problems that may arise due to the FIN-WAIT-2state There’s no limit on the amount of time a connection can

stay in the FIN-WAIT-2 state – connections could stayforever in FIN-WAIT-2.

When TCP gets into the FIN-WAIT-2 state there’s nouser-space controlling process (i.e., it’s hard to enforceapplication-layer limits)

Problems that may arise due to the FIN-WAIT-2state There’s no limit on the amount of time a connection can

stay in the FIN-WAIT-2 state – connections could stayforever in FIN-WAIT-2.

When TCP gets into the FIN-WAIT-2 state there’s nouser-space controlling process (i.e., it’s hard to enforceapplication-layer limits)

FIN-WAIT-2 attack (example)

Counter-measures for FIN-WAIT-2flooding

Enforce a limit on the duration of the FIN-WAIT-2state. E.g., Linux 2.4 enforces a limit of 60 seconds.Once that limit is reached, the connection isaborted.

Enforce on the number of ongoing connections withno controlling process.

The counter-measures for the Naptha attack stillapply. However, it is difficult for applications toenforce limits (remember: no controlling process forthe connections).

Enforce a limit on the duration of the FIN-WAIT-2state. E.g., Linux 2.4 enforces a limit of 60 seconds.Once that limit is reached, the connection isaborted.

Enforce on the number of ongoing connections withno controlling process.

The counter-measures for the Naptha attack stillapply. However, it is difficult for applications toenforce limits (remember: no controlling process forthe connections).

Counter-measures for FIN-WAIT-2flooding

Applications should be modified so that they retaincontrol of the connection for most states. This can beachieved with a conbination of the shutdown(),setsockopt(), and close().

Applications should be modified so that they retaincontrol of the connection for most states. This can beachieved with a conbination of the shutdown(),setsockopt(), and close().

Socket send buffer vulnerabilities

The socket send buffer keeps a copy of those datathat have been accepted by TCP for delivery to theremote TCP end-point.

It is possible to exploit the Socket send buffer for amemory exhaustion attack: Send an application request to the target system, but

never acknowledge the response (Netkill). Send an application request, but immediately close the

receive window, so that the target TCP refrains fromactually sending the response.

The socket send buffer keeps a copy of those datathat have been accepted by TCP for delivery to theremote TCP end-point.

It is possible to exploit the Socket send buffer for amemory exhaustion attack: Send an application request to the target system, but

never acknowledge the response (Netkill). Send an application request, but immediately close the

receive window, so that the target TCP refrains fromactually sending the response.

Netkill

Data that have been sent but not yet acknowledgedare kept in the socket send buffer for their possibleretransmission.

TCP will retransmit those data until they either getacknowledged or the connection times out. In themean time, system memory is tied to those data.

Easy to exploit for memory exhaustion: establish lotsof TCP connections, send an applicattion-request oneach of them, and never acknowledge the receiveddata.

Data that have been sent but not yet acknowledgedare kept in the socket send buffer for their possibleretransmission.

TCP will retransmit those data until they either getacknowledged or the connection times out. In themean time, system memory is tied to those data.

Easy to exploit for memory exhaustion: establish lotsof TCP connections, send an applicattion-request oneach of them, and never acknowledge the receiveddata.

Netkill (example)

Netkill (countermeasures)

Problem: it’s very hard to infer attack from thebehavior of a single connection.

Possible counter-measures:Measure connection progress at the application-

layer Do not use an unnecessarily large socket send

buffer Enforce per-user and pre-process limits Enforce limits on the number of ongoing connections

from a single system/prefix at the application-layer


Possible counter-measures:Measure connection progress at the application-

layer Do not use an unnecessarily large socket send

buffer Enforce per-user and pre-process limits Enforce limits on the number of ongoing connections

from a single system/prefix at the application-layer

Netkill(countermeasures)

Enforce limits on the number of on-going connectionsfrom a single system/prefix at a firewall

When dropping connection, these are possible parametersthat may provide hints for selecting the target connection:

Large amount of data queued in the TCP retransmissionbuffer

Small amount of data successfully transferred to theremote endpoint

Enforce limits on the number of on-going connectionsfrom a single system/prefix at a firewall

When dropping connection, these are possible parametersthat may provide hints for selecting the target connection:

Large amount of data queued in the TCP retransmissionbuffer

Small amount of data successfully transferred to theremote endpoint

Closed windows

The TCP sliding-window mechanism prevents a fastsender from overwhelming a slow consumerapplication.

When the advertised window is zero, the window issaid to be closed.

The TCP sender polls the receiver from time to timeto find out if the window has opened (persist timer).However, there’s no limit on the amount of time thatthe window can be closed.

The TCP sliding-window mechanism prevents a fastsender from overwhelming a slow consumerapplication.

When the advertised window is zero, the window issaid to be closed.

The TCP sender polls the receiver from time to timeto find out if the window has opened (persist timer).However, there’s no limit on the amount of time thatthe window can be closed.

Closed windows

Easy to exploit for memory exhaustion: just send anapplicattion-request to the remote end-point, andclose the receive window.

Easy to exploit for memory exhaustion: just send anapplicattion-request to the remote end-point, andclose the receive window.

Closed windows (example)

Closed windows (countermeasures)


It has been proposed that TCP should impose a limiton the amount of time that the window can beclosed. However, this counter-measure is trivial tocircumvent: just open the window a bit from time totime.


It has been proposed that TCP should impose a limiton the amount of time that the window can beclosed. However, this counter-measure is trivial tocircumvent: just open the window a bit from time totime.

Closed windows (countermeasures)

Measure connection progress at the application-layer Do not use an unnecessarily large socket send buffer Enforce per-user and pre-process limits Enforce limits on the number of ongoing connections



Measure connection progress at the application-layer Do not use an unnecessarily large socket send buffer Enforce per-user and pre-process limits Enforce limits on the number of ongoing connections



Summary

Even though the simplest distributed DoSattacks are enough to knock down most websites today, the nature of the attack will besure to improve, and it’s better to be readyor, at least be aware of upcoming problems.

Even though the simplest distributed DoSattacks are enough to knock down most websites today, the nature of the attack will besure to improve, and it’s better to be readyor, at least be aware of upcoming problems.

References

ModSecurity Advanced Topic of the Week: Mitigation of 'Slow Read" Denial ofService Attack

http://blog.spiderlabs.com/2012/01/modsecurity-advanced-topic-of-the-week-mitigation-of-slow-read-denial-of-service-attack.html

DDoS attacks in H2 2011http://www.securelist.com/en/analysis/204792221/DDoS_attacks_in_H2_2011

The State of the Internet

http://www.akamai.com/stateoftheinternet/

Evaluation of slowhttptest against servers protected by CloudFlare

http://samsclass.info/123/proj10/slow-read.html

Blog posts on hardening web servers

https://community.qualys.com/blogs/securitylabs/

ModSecurity Advanced Topic of the Week: Mitigation of 'Slow Read" Denial ofService Attack

http://blog.spiderlabs.com/2012/01/modsecurity-advanced-topic-of-the-week-mitigation-of-slow-read-denial-of-service-attack.html

DDoS attacks in H2 2011http://www.securelist.com/en/analysis/204792221/DDoS_attacks_in_H2_2011

The State of the Internet

http://www.akamai.com/stateoftheinternet/

Evaluation of slowhttptest against servers protected by CloudFlare

http://samsclass.info/123/proj10/slow-read.html

Blog posts on hardening web servers

https://community.qualys.com/blogs/securitylabs/

Contact

V Raman teja Network Security , Web Technologies, Graphic

Designing & Coding Email: [email protected] Ph: 9032195562

V Raman teja Network Security , Web Technologies, Graphic

Designing & Coding Email: [email protected] Ph: 9032195562

Null HYD VRTDOS

Education

Transcript of Null HYD VRTDOS