This is not really relevant to the video, actually, but this is a slow loris. I just wanted to show it because it was cute, that's all... Don't keep them as pets though. Now, the slow loris is I guess my favorite Denial of Service (DoS) attack -- now that says a lot about me, doesn't it, that I have a favorite denial of service attack... Before we demonstrate anything, of course, let's get straight out in the open, you shouldn't be using slow loris on anyone, or any other DoS attack on anyone else, alright, because you'll get in a lot of trouble. Most DoS have this idea that you try and defeat some web server, [or] some computer on the other side of the web, by giving it as much bandwitdh as you can, such that it breaks, right, they have a certain amount of bandwidth [that] they are allowed to use. and if you give them more than that, or try to request too many web pages, their server goes down. That's the general idea of a DoS. Distributed DoS is just the next level, where you have multiple computers all attempting to do the same thing, and then, more modern DoS will use amplification and things like this, to try and improve this even more. But, the whole point is as much bandwidth as you can all at the same time, alright, and if you get enough, you can take them down. If you don't, then they just laugh, right? So, you know, Microsoft and Google, you're going to have difficulty bringing them down. But, smaller websites, it can have a massive impact on the amount of money they are making, if no one can visit their shop, or something like that, so it's a real problem. What I like about the slow loris is it comes at it from a completely different way. It's a protocol attack, so a layer-7 application attack, which doesn't need a lot of bandwidth, so I can do a slow loris on someone and then browse the web as normal, play computer games... So let's think back to how me talking to a web server works. I send off a "get" request to a website, and I say "get me index.html", then the web server sends back index.html, and that's the end of that conversation, right, then I start up another conversation that says: "I've read this index.html, I now need, you know, header.jpeg", so I send off another get request, and so on, and we have these short conversations back and forth. Now, usually, an HTTP request is just text, right, so it litterally says "HTTP get 1.1", or something, index.html, where I'm sending it, a bit about me, so I'm using, you know, Firefox or something, and then some other data, and then it always ends with two caret return line feeds, so two new lines, right, so, normally in text we have a caret return character, and then a line feed character, two of those signals the end of an HTTP request. What the inventor of the slow loris, some hacker named Rsnake, I think, (indeed!) decided was "what if I never send those caret return line feeds, can I just keep the website waiting for me, can I go so slowly, by asking for website so slowly, that I just break them", right? And yeah, he can! And -- and so they have things like timeouts and stuff so maybe let's say I'm in the middle of browsing a website, and then -- on my phone, right -- and just as I'm in the middle of sending off a request, I lose phone signal, right? That's pretty common, you know, these days, so that would timeout on the server's end as well, and they would let the connection go, and then they conserve someone else's website. The problem comes if I don't send no data, I send some data, but just painfully slowly. What's great about the slow loris is, there's hardly any code, it talks to a web server, and it basically says "get me index.html", or something like that, and then sends a space, or a 0, or a random number, or something like that, and then it waits for about, you know, 10, 20, 30 seconds, just when the website is about to assume it's gone, and sends another single byte, and says "I'm still here! I'm just really slow", and then it does this again, and it does this again, and keeps that connection going as long as it can, and then it does it with 200 other connections, or as many connections as it can. So, my computer sending out this attack, it's sending 200 byte packets every minute or so, it's not a lot at all, and it's very difficult for a firewall or something to notice this, because these are valid HTTP requests, they're just super slow, right, and you know maybe I've just got a really bad internet connection, maybe. Now, this doesn't affect every web server, it mostly affects Apache, because of the way Apache works. Unfortunately, Apache is very prevalent, there's about 40, 50% Apache these days, it's hard to know for sure, but I had a quick check, and that seems to be about the right estimate. Apache when they designed it, they decided it would be a good idea to start up a new thread to serve every concurrent connection, so when a connection comes in with an HTTP request, they set up a new thread that handles that request, and then the thread goes away when it's finished. Now, that wasn't entirely stupid, you know, if the connections appear, and then they go away, that's not a problem. But if the connection starts to stay longer than we anticipate, then our connection limit gets reached, so Apache will have a connection limit of, let's say, 200 concurrent connections, because beyond that you've just got so many threads [that] the whole thing starts to grind to a halt. So, what slow loris does, is begin to open connections, and as a new one gets freed up, from someone else using the website, they'll open that one, and this one, and that one, until they got all the connections. So, let's see how it works, right, so I've come up with another of my glorious websites, just for this, "Mike's website"! So, that's actually this computer here, which is running Windows and Apache. Now, so this is my website, with my company profile, and lorem ipsum. What this website is, is not very important. Let's have a quick look at the code, this is not the original implementation of slow loris, this is a Python implementation I found, but essentially, it's not very long, right, 67 lines, which another reason in our kit, because it's so elegant. Really, what it does -- it has some code here, to start up a socket, which is a TCP connection, and make it get requests, here's our get request text, and then, for all existing sockets, down here, can we send a little bit more data every 15 seconds. And if a socket dies, we recreate it, and we just keep that going, and we'll do this for 200 concurrent sockets, which is more than my Apache installation is configured to handle. So let's run this -- there we are, python, slow loris, to the IP address that we just looked up. Alright, it's creating all the sockets, and now, it's just going to sit there, every now and then, sending a byte of data to the Apache web server. So, the web server thinks that it's got 200 people looking at the website, when in fact it's got one person looking at the website really, really slowly 200 times. If I press refresh on this, because it has been cached, we can see we're now waiting. Waiting. (Sean:) So if you clear the cache now, in your browser, would that -- that not be able to get the website? (Mike:) No, it wouldn't be able to see the website, so let's go to website now, that we're under slow loris. So... Alright, we're waiting for it. I mean, we might get lucky, maybe one of these sockets drops out and then the server can respond, alright, but we might not. But... (Sean:) You've clicked to go back to that same website, and of course it can't load it and so we're just sitting... (Mike:) Yeah and [at] some point we might see a timeout on this client-side, saying "no, we didn't get any response from the server". This server is basically -- won't serve this website to me, because it's too busy serving 200 other websites, or more specifically, busy waiting for us to finish the request 200 times so it can actually finally get home with something. (Sean:) And how long would that carry on sending those requests? (Mike:) As long as I want. And, as soon as a socket dies, another one comes up, and it just keeps going. And, I mean, 67 lines of code, right, and here's the nice bit, "fun things to do", I can just use the net as normal -- my net is fine, right, I'm not using all my bandwidth to do this, I'm using barely any of my bandwidth, which is what I really like about it. This kind of attack is called a low and slow attack. So there's a couple of others, "RUded", [meaning] "are you dead yet?", is another one that does similar things. And, what's clever about them is [that] they're quite hard to detect, because what it's doing is totally normal HTTP, it's just doing it incredibly slowly, and when they designed this, and when they designed Apache, they never thought you would do something like that, and that is exactly the problem with these sorts of protocol attacks: the assumption that they will always do what you expect them to do, and they won't do these random, strange things. So, yeah, my favorite DoS.
