Quick'n'sloppy Slow-Loris implementation

(random-man) #1

Hello! So the other night I tried to learn some more about the Slow-Loris style of DOS attack. I couldn’t tell you much about EXACTLY how the original slow-loris.pl worked, but here’s what I found to be effective against an Apache2. I figured I’d go through the process of what I did to share some of the knowledge I gained through it. Plus, I thought it would be a nice and simpler first post.

So first of all, for those who aren’t a little bit familiar with the Slow-Loris type of DOS attack, the main point is that it is low-bandwidth, and only takes one computer running multiple threads. Alot of DOS/DDOS attacks revolve around sending an unmanageable amount of information to the server. This works, but also at the expense of the attacking resources. What is great about this kind of attack, and the Slow-Loris concept is that it does not use a ridiculous amount of bandwidth. Instead, it takes up all of the web servers possible connections. So let’s take a look at the server-status page of our Apache2 server while its running normally.

As we can see, the server is currently only handling one request. One important thing to know is that HTTP is considered a “connectionless” protocol. What this means is that a client will establish a TCP connection to an HTTP server, send its request, then the server will send its reply and close the connection. This makes sense, especially considering that a website may serve many people at once, and many concurrent socket connections can bog down a less capable box. Now suppose our goal is to halt this server from serving anyone. We might first think to send a bunch of UDP packets at random ports and try to take up as much resources from the server as possible, but the Slow-Loris type attack targets the server’s web-server software itself instead. Our goal, for the attack, is to take up all the allowed connections for the webserver, and keep those sockets connected for as long as possible. So let’s open up a connection with this server and see how long it takes before it closes our connection because we sent it no request. This can be done quickly and simple with netcat. Just open up a connection, send part of a request, and see how long it takes before the server disconnects us. We get the following html response.

408 Request Time-out

Request Time-out

Server timeout waiting for the HTTP request from the client.

Apache/2.2.22 (Debian) Server at Port 80

For this particular Apache, it took about 20 seconds before the server sent us a “you took too long” html response. So, we know we can open a socket and connect, then waste about 20 seconds of the servers time before we get disconnected. So far so good, but we can do a little more to be more effective. We can send, as a header in the HTTP request, a “Keep-Alive” request. Keep in mind that it is up the server whether or not it wants to listen and follow our wish, but this is basically asking the server not to close our connection for a little while. I’m not exactly sure why this is implemented in HTTP protocol, but I believe it is for the better performance of some clients. You may want to read more on that if you’re interested. Also, if you want to learn more about HTTP in general, I suggest you check out the RFC documents, they proved useful to me. So let’s send a request with a keep alive header in there and see how it responds. Let’s fire up python and check it out. Here is the first part of the response we get.

HTTP/1.1 200 OK
Date: Tue, 24 May 2016 06:00:09 GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Fri, 15 Apr 2016 21:00:37 GMT
ETag: "1ff92-329-5308c4d87d9fc"
Accept-Ranges: bytes
Content-Length: 809
Vary: Accept-Encoding
Keep-Alive: timeout=5, max=100 <------------Important!
Connection: Keep-Alive <---------- Important!
Content-Type: text/html

We now know that this web server does indeed listen to Keep-Alive requests, and it will give us 5 more seconds until it closes our connection. Let’s implement that into our attack too. Here is a pastebin link to the python script I tossed together for this. Keep in mind, it is by no means refined, and I have made no improvements from the time it was written around 5-am :stuck_out_tongue: Basically, it takes advantage of the keep-alive and how long it takes before the server closes client sockets to keep attacking sockets connected for a while. Also, for fun, it will send various user agents to the server. At least for this particular Apache, it took it over almost immediately. I hope you enjoyed reading this, and hopefully the script might give you a bit more knowledge about HTTP. Thanks! Of course, as you all already know, don’t go using it against some vulnerable public web server. (Note: I tried this also on an XMPP server running on Windows, and it disrupted it, but was not as effective since XAMPP doesn’t listen to keep-alive header requests)

PasteBin link : http://pastebin.com/ABdrzZtW

(Command-Line Ninja) #2

Man! This is sweet! I used to use a tool called sockstress which was very similar to this in design, but with tcp, sending a syn, and never responding to the server with an ack.

This is a really good share! Nice work :wink:


Ye that one is kinda deprecated nowadays, you can spoof the IP by the way.
SlowLoris is specific for the HTTP protocol though/

(random-man) #4

Thanks man! Yeah I’ll have to check that out!

(random-man) #5

Yeah. I tested it on XAMPP and it was somewhat effective in the fact that it was a pain to get on the site, but it definitely did not completely kill it like Apache 2. I’m trying to tweak the attack a bit so it can work on XAMPP better. Spoof the IP over a TCP connection? By packet forging? I didn’t know that was possible.


Well it becomes problematic when it’s connection based indeed.
I meant as a comment to pry0cc, the synflooder.
You can spoof the IP then.

(random-man) #7

Ah I see. Yeah. I’d say, if someone in the evil mindset, spoofing the ip and using proxies would basically move it impossible to find the source. At least, I couldn’t think of any way someone could.

(pico) #8

I believe that if a machine gets a wrong packet it will respond with a RST, terminating the connection. I’m not fully sure, it has been a while since I do not have to go that down in the TCP/IP stack.

In that case, you have to be sure that you are spoofing an off-line machine so it will not send the RST packet back to the server… which will actually free the connection

(pico) #9

In general, you cannot spoof your ip and use a standard proxy. Normal proxies requires the client to establish a full connection and that is not possible when you spoof your IP, unless you are in a local network (where you can sniff the traffic) or the proxy is running a 15 years old operating system. The first case is useless, the second one is quite unlikely

(random-man) #10

Yeah. But maybe if you were doing some thing UDP, spoofing the IP from a proxy? I don’t think any normal socks proxy would allow that kind of control though.

(pico) #11

I think you need SOCKS4a or SOCK5 to support UDP:

However, there is a negotiation going on between the client and the server. Apparently that is done over a normal TCP connection (not fully sure), but in any case, in order to bind an UDP port you need to interchange information with the server and therefore, that will be logged (in general).

I quickly went through the RFC but looks like it need some serious reading.


(random-man) #12

yeah definitely worthy of some attention. you gotta love the RFCs.

(pico) #13

The love stage went away many years ago… :wink:

(system) #14

This topic was automatically closed after 30 days. New replies are no longer allowed.