Bypassing WAF with incorrect proxy settings for Hunting Bugs.

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

"Https: // targetdomain"

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).

"Https: //auth.targetdomain/vulnerable_endpoint? Param = malicious_RCE_payload"

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.

https: //auth.targetdomain/vulnerable_endpoint? param = malicious_RCE_payload

But what if we encode the url

https: //auth.targetdomain/vulnerable_endpoint? param = malicious_RCE_payload

in base64 and the resulting string:

“AHR0cHM6Ly9hdXRoLnRhcmdldGRvbWFpbi92dWxuZXJhYmxlX2VuZHBvaW50P3BhcmFtPW1hbGljaW91c19SQ0VfcGF5bG9hZA ==“

And pass it through the parameter “cfru”:

https // targetdomain /? cfru = aHR0cHM6Ly9hdXRoLnRhcmdldGRvbWFpbi92dWxuZXJhYmxlX2VuZHBvaW50P3BhcmFtPW1hbGljaW91c19SQ0VfhcZGF5=bG9

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…….