DoS: Back From The Dead?

Stay updated on FogMarks

Happy 2018!

January is the perfect after-holidays time to point out our goals for the next year. And to lose some weight (because of the holidays), of course!
FogMarks always aims to write the most interesting case-studies about the latest “hot” vulnerabilities, and 2018 is going to be super-exciting!

So, finally after a long break here we are again discussing a vulnerability that many though was dead: the Denial of Service attack.
I’ve heard a lot of statements in the sec community regarding DoS attacks and vulnerabilities. Most of them addressed DoS as “an attack of the past”, as a vulnerability that cannot affect the server side anymore, thanks to companies such as Cloudflare, Nexusguard and other load-balancing service providers.

As a result, a lot of bug bounty programs aren’t accepting DoS vulnerability submissions, and sometimes even forbid the researcher from testing, in fear of an affect on the system’s stability and user experience. And their right, sort of.

But- who said that a DoS attack has to be on the server? It takes two to tango – if the server is now “protected” against DoS attacks (by an anti-DoS/DDoS service), who is protecting the user?

Let me elaborate on that: Companies are too busy preventing DoS attacks on their servers, that they are forgetting that DoS attacks are possible against users as well. A Denial of Service attack, to my definition, is any attack which prevents a user from accessing a resource or a service from the server. This can be done by directly attacking the server – like trying to make him “shutdown” from over-traffic – or by directly attacking the users.

Actually, attacking the users is the more easy way to do it. In addition, in a lot of cases the company won’t even know that the user was attacked until the user will contact the company and say “Hey, I cannot access X”.

You all know what I’m about to say now. Which type of vulnerability can cause a DoS attack super fast to a specific user? An XSS of course!

Sending or planting an XSS payload which disrupts a certain service onto specific user/users causes a severe denial of service/resource to that user or users. This payload can be a simple redirection outside of the site, or even “document.write(”);” that is simply printing a white page or a misleading page.

A certain very known commercial company, which hasn’t allowed us to mention it’s name yet suffered from that exact attack.
When I first started to research their main product, I was told not to DoS or DDoS their servers, “because we have an anti-DDoS mechanisms that are preventing that, and we think DoS attack belongs to the past”. Of course that DoS from a different angle was the next thing I have done on their product 🙂

I come to understand that an XSS payload can be sent directly to a specific user or to a users group. That XSS was “universal” – it was executing from any page of the site, because of the messaging feature that appeared in any page. I planted an XSS payload which simply echoed a mock “404 Not Found” page onto the page. To prove that this issue was indeed severe, me and the head of their security response team have test the attack on the production site, against one of the developers. He response (“WTF? What happened to the site?”) was hilarious.

Although most of the modern servers are now vulnerable to DoS and DDoS attacks thanks to smart load balancing and malicious requests blocking services, the user is still out there – unarmed and unprotected. You should always treat any type of attack that can prevent an action from being fulfilled as a major security issue, regardless of the type of the vulnerability.

Happy & Successful 2018!