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

Security Researcher | DevSecOps | Twitter:-https://twitter.com/ShauryaSharma05

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

{UPDATE} 1line dot - stroke puzzle game Hack Free Resources Generator

12 Cybersecurity tools I learned in 2021

Tryhackme-0day

Power Coin Airdrop is complete

Top 5 Best FREE VPN in 2021: Protection & Site Unblock

Weekly update

CheckDot Partnership With Kryxivia MMORPG Metaverse

{UPDATE} Gonga Hack Free Resources Generator

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Shaurya Sharma

Shaurya Sharma

Security Researcher | DevSecOps | Twitter:-https://twitter.com/ShauryaSharma05

More from Medium

RCE on micro_httpd web server

Writeup: CSRF vulnerability with no defenses @ Portswigger Academy

MFA (Multi-Factor Authentication)

How To Fix The RCE Vulnerability In dotCMS (CVE-2022–26352)