Bypassing WAF with incorrect proxy settings for Hunting Bugs.

Let’s Suppose the target system has the address-:

By accident, I noticed that some CSS and JavaScript resources were available on the subdomain responsible for authenticating on the site.

The odd thing was that while browsing the end node (something like) I received an HTTP 404 response from the server, which made me suspect the presence of WAF (Web Application Firewall).

Looking at one of the applications on the host:

(for example, https: // targetdomain/appname/appname ), I got authentication at the address “ https: //auth.targetdomain “ .

So I noticed another strange thing during authentication. At some point, a redirect to an address like : “https: // targetdomain /? Cfru = aHR0cHM6Ly90YXJnZXRkb21haW4vYXBwbmFtZQ = =”

The string “aHR0cHM6Ly90YXJnZXRkb21haW4vYXBwbmFtZQ == “ is explicitly base64 encoded. After decoding, this payload it turned out to be nothing more than the “https: // targetdomain / appname” address , which I tried to access before starting authentication.

The turning point occurred at the moment when I made the following assumption: if the resource viewed directly, our HTTP request immediately goes to the WAF, where there is a rule that recognizes suspicious behavior (the malicious payload pointed to by “param”), sends an HTTP 404 error in response, and actually blocks the attack.

But what if we encode the url

in base64 and the resulting string:

And pass it through the parameter “cfru”:

In this case:

  1. The request goes through the WAF and is not recognized as suspicious.
  2. Then the request goes to Bluecoat, where the cfru parameter is decoded and a GET request is sent to the internal host.
  3. As a result, a vulnerability is initiated.

Bingo! Happy Hacking…….

Security Researcher | DevSecOps | Twitter:-