TL;DR:

Utilizing a blend of header smuggling and header fuzzing, sophisticated HTTP attack techniques can effectively deliver DDoS payloads, either by evading detection by Web Application Firewalls (WAFs) or by targeting WAF-encoders themselves.

Long Version

During our DDoS-Tests we are constantly looking for new attack-vectors to be used in more sophisticated scenarios, aka RedTeamings. Last year we wrote about "Stack-Attacks", and with this article we want to dive into this realms again and presenting an interesting attack-vector that targets the stack between the edge of a network and applications, this time: the WAF.

Many companies are using WAFs to protect their webservices and at minimum a ruleset that protects against OWASP Top 10 attacks. Any WAF we have looked at implements some sort of de-obfuscation to find attacking payloads that are decoded as Unicode, Hex, B64 etc. De-Obfuscation is usually done by internal decoders, and this decoding can be "expensive", in terms of processing power.

And "expensive" operations on the target_side is what we want as an attacker, since this behavior might lead to a successful DDoS.

Sooooo ... with that knowledge above and our play instinct been activated, we build a traffic-generator-prototype that could:

  • load different payloads like shellshock, sqlinjections, xxe-attacks or custom strings
  • encode the payload with different encoders (HEX, Unicode, HTMLEntities, URLEncode, Base64 and a handfull more)
  • add the encoded payload to different parts of the request (headers, POST-payload, URLs)
  • use any HTTP-Request-Methods and Content-Types randomly, like GET/POST/POST_JSON/HEAD/OPTIONS
  • add variable amount of custom headers from a list of possible request-headers and add either garbage or the encoded payload as value for the header

That generator ended up to be basically a big fuzzing-tool for webrequests to see what happens if you throw garbage onto WAFs.

And, oh boi, that thing makes fun.

With that yet very brutal method we were able to achieve different things, depending on the used WAF-Technology:

  • reach backend-servers we did not expected (similar to request-smuggeling)
  • overloading WAF-payload-encoders and thus disabling them effectively
  • getting the attack successfully delivered through the WAF

These are some findings that are interesting:

  • crafting POSTS usually never forced a Response-Status 412/417
  • POST-Requests(and rarely HEAD/TRACE/OPTIONS) can be the better attackvector, if the method is not blocked
  • during attack-preparation we could measure a significant timedelay when we enforced errors on the WAF (503), resulting in roughly twice the requesttime than with all other requests, leading to the conclusion, that this particular request is kind of "more expensive" on the WAF, a good indicator for a usable attackvector. Later on in the real attackscemario we simply deep-fried the WAF
  • the more header you fake, the more blocks by WAF, but also more forced errors on the backend/WAF and lesser successfull requests

Below you will find screenshots of the behavior of different WAFs/Providers, and since we are in talks with vendors to test and fix their problems, we will not name them here (yet), but besides 2 of the big names, we found ways to sneak past WAFs or attack the WAF directly nearly everywhere, both in cloud and OnPrem-Appliances.

Screenshot 1: forcing HTTP-Errors 502 (Backend) and 503 (WAF) during a test

the following output shows Target 1 with GET/POST-request, protectecd by a WAF with forced errors and Target 2, our own Testsite, not protected by a WAF, thus no HTTP Errors 403/401

Conclusion

There is a growing interest in abusing HTTP-Requests for any kind of malicious activities, as @deadvolvo had shown in his recent research, released in the articles "From Akamai to F5 to NTLM... with love." and "HTTP is dead... Long live HTTP?!".

Using a naive approach, we found a couple of ways to abuse WAF-decoders or bypass WAFs to deliver payload to backends, that can be usefull in a DDoS-Attack.

In realworl-tests, the blueteams had a hard time to mitigate the attack when delivered by a normal-sized botnet.

We will explore this attackvector in more detail for the next RedTeaming engagements

References and further inspirations: