Bypassing WAF with incorrect proxy settings for Hunting Bugs.

Shaurya Sharma
2 min readFeb 24, 2021

--

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

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Shaurya Sharma
Shaurya Sharma

Written by Shaurya Sharma

Security Researcher | Bug Bounty | Exploitation | Twitter:-https://twitter.com/ShauryaSharma05

No responses yet

Write a response