[Inori]

I thought this was a clever "fuck the rules"-type attack, and it's still unpatched as of Apache 2.4.23.

Full disclosure, I made a python implementation that performed seamlessly in my pentest lab.

[millionandbell]

hey i can finally dos someone now with my crap ass network just joking, but this is rather interesting, i subbed to their channel thanks for the share

[d0ntjump]

This will be a fun toy and thanks @Ao- for sharing.

[insidious]

I saw this!

It's really interesting. Never thought there'd be something thats almost opposite of a Ddoss attack but does the same thing.


Computerphile has a bunch of great videos, I highly recommend checking them out if you haven't already

[Dyme]

woah sick computerphile cutting age hax I feel like I've been transported back to 2004!!!

But srsly this has been around since you were in diapers... and it's silly to say "lmao itz still unpatched in latest version of apahce!!!" because it's not something you can 'patch' without inertly altering the functionality of a web server. Implying that this type of attack can be patched would be akin to implying that DDoS attacks can be patched. These types of attacks, due to their nature, can only be mitigated, not patched. And if you are under the impression that this problem is apache specific, I would reconsider that notion as this problem has been proven to exist in other web servers as well (check: https://github.com/valyala/goloris), due to the nature of how ALL web servers work if not configured differently.

With that being said, mitigation of Slowloris is painless and standard considering how long its been around. Good luck finding a target that isn't implementing mod_reqtimeout or something similar to mitigate these attacks... you are much better of conducting a DDoS or an application specific DoS if you're looking to down a web server, as the chance that a server you are looking to target is vulnerable to this type is attack is practically zero.

[Inori]

woah sick computerphile cutting age hax I feel like I've been transported back to 2004!!!

But srsly this has been around since you were in diapers... and it's silly to say "lmao itz still unpatched in latest version of apahce!!!" because it's not something you can 'patch' without inertly altering the functionality of a web server. Implying that this type of attack can be patched would be akin to implying that DDoS attacks can be patched. These types of attacks, due to their nature, can only be mitigated, not patched. And if you are under the impression that this problem is apache specific, I would reconsider that notion as this problem has been proven to exist in other web servers as well (check: https://github.com/valyala/goloris), due to the nature of how ALL web servers work if not configured differently.

With that being said, mitigation of Slowloris is painless and standard considering how long its been around. Good luck finding a target that isn't implementing mod_reqtimeout or something similar to mitigate these attacks... you are much better of conducting a DDoS or an application specific DoS if you're looking to down a web server, as the chance that a server you are looking to target is vulnerable to this type is attack is practically zero.

I never said mitigation wasn't impossible; I decided to play with some techniques on my test lab after I got the program to work.
Never underestimate human stupidity, though. I mean, come on, Adobe stored user passwords in plaintext and they're worth millions. If that can happen, I'd be willing to bet that there's some sizable servers out there with no counter to slowloris.

[Dyme]

I never said mitigation wasn't impossible; I decided to play with some techniques on my test lab after I got the program to work.

Could you provide the relevant settings of your apache configuration along with the specs of your server... I've tried launching an attack on a digital ocean box (494 MB RAM) running Jessie with the default settings for apache2 and it doesn't seem to do anything lol. I had two different scripts run for about 45 minutes at a time and nothing happened.

My installation is using the prefork NPM, however none of the NPMs directives (Ex. MaxRequestWorkers) are defined in the configuration file by default.

Never underestimate human stupidity, though. I mean, come on, Adobe stored user passwords in plaintext and they're worth millions. If that can happen, I'd be willing to bet that there's some sizable servers out there with no counter to slowloris.

My main point is that finding a server in the wild that is vulnerable to this type of attack is beyond unlikely, especially if apache is not vulnerable with the default configuration, which is what my testing is suggesting so far. So why waste time creating a script for it when there are much more effective and widespread ways to conduct a DoS attack. It's like if I were to now, in 2016, write an exploit for the windows xp ms08 netapi vulnerability. Not only do a lot of other exploits for this vulnerability already exist, but the chances of me ever being able to use it in a practical situation are zero. Is it possible that some machine some where is still vulnerable to the attack? Sure, I suppose so. But will I ever come across that machine when 99.999% of all applicable machines are no longer vulnerable? No - so why not write an exploit for something I actually might be able to find in the wild with relative ease?

But I mean, if it is your inclination to recreate DoS tools from decades ago then by all means have fun. I am simply suggesting you focus on more modern and relevant vulnerabilities so that you learn stuff that may actually be useful to you in the present or near future.

[mothered]

Never underestimate human stupidity, though. I mean, come on, Adobe stored user passwords in plaintext and they're worth millions.

Very true Indeed.

Of the 800-900 websites I've compromised In the last couple of months or so, I'd say around 15% of sites stored user credentials In plain text. I've saved everything, so sometime In the very near future, I'll create a thread and post all screenshots In their unedited form. From a security standpoint, the security risks, poor configurations and vulnerabilities Is appalling.

On topic here, much appreciate the contribution.
Thanks.

[suprabro]

Very interesting. The video was great so thank you very much for sharing it. I checked out the channel too and It really have some interesting stuff. It's so weird that his channel or videos have not showed up in my recommendations.

[xssinj]

This will be a fun toy and thanks for sharing.