Bypassing WAF With Incorrect Proxy Settings


Author
: Timmy Security Staff


Hello friends! What do you think are in common between participating in a bug-catching competition and network security devices? Usually nothing. On the other hand, security devices allow for virtual patching and are used regularly to reduce the reward of researchers for finding bugs ... but what follows is the exact opposite story: we received an award for a misconfigured security tool. We will not disclose the company name (other than the Fortune 500 organization) or any of the vulnerable components. We will only consider the technique used due to its extreme and disarming simplicity.


Purpose research

It all started with the study of a goal that at that time was not considered worthy of attention. Suppose the target system has the address


"Https: // targetdomain"

... Almost by accident, we noticed that some CSS and Javascript resources were available on the subdomain responsible for authenticating on the site, related to a Java component that was well known for being vulnerable to a remote code execution vulnerability.

The odd thing was that while browsing the end node (something like


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

) we were receiving an HTTP 404 response from the server, which made us suspect the presence of WAF (Web Application Firewall). Why could this particular system give an error when trying to access resources of a certain kind (specifically - to files . Css and . Js )? The hypothesis immediately arises that we are dealing with WAF. After several more blocked requests, the presence of a rule in the WAF was confirmed, blocking access to the target system.


"Strange" thing

Looking at one of the applications on the host (for example, https: // targetdomain / appname / appname ), we got to authentication at the address " https: //auth.targetdomain " . We 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 turned out to be nothing more than the "https: // targetdomain / appname" address , which we tried to access before starting authentication.


The question immediately arose, what was the "cfru" parameter actually? Some research shows that we are dealing with the web filtering technology of the well-known proxy server Bluecoat, and now we have a little better understanding of the details of the remote infrastructure. The HTTP requests sent to the target system interfered with at least one WAF device and Bluecoat proxy before reaching the web servers and the application server, as shown in the figure below.


Idea

As soon as we discovered that the "cfru" parameter was publicly available, the thought immediately arose - no portal authentication was required to transfer our payload.


Thus, we began to encode the URLs of external domains under our control in base64 and pass the resulting strings through the "cfru" parameter. We were hoping that it would be possible to implement something like SSRF (Server-Side Request Forgery). However, in the end, everything turned out much more interesting.


Unfortunately, at that time we did not receive a single HTTP request in response. However, on systems visible from the internet, we have seen the process associated with DNS resolution, starting with the name "targetdomain". It seemed that outgoing TCP connections from the target site were denied except for DNS traffic. Then, instead of initiating SSRF requests to external hosts, attention was turned to internal subdomains: https: //auth.targetdomain , https: //blog.targetdomain , https: //www.targetdomain, and so on.


We started passing some of the above base64 encoded URLs through the "cfru" parameter and almost immediately noticed another oddity. For some URLs, we received an HTTP 302 redirect response. In some cases, there was no response. In the latter case, instead of the body of the HTTP request, the response contained the HTML code of the requested resource, as if Bluecoat forwarded the request to the target resource and received the content back, acting as a web proxy. The most important point is that this phenomenon was observed even when we passed through the "cfru" parameter a subdomain responsible for authentication on the portal ( https // auth.targetdomain ), and specifically on the portal where, as we assumed, the vulnerable Java component was located. to remote code execution.


Crucial moment


The turning point occurred at the moment when we made the following assumption: if the resource


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

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


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

in base64 and the resulting string


“AHR0cHM6Ly9hdXRoLnRhcmdldGRvbWFpbi92dWxuZXJhYmxlX2VuZHBvaW50P3BhcmFtPW1hbGljaW91c19SQ0VfcGF5bG9hZA ==“

pass it through the "cfru" parameter


https // targetdomain /? cfru = aHR0cHM6Ly9hdXRoLnRhcmdldGRvbWFpbi92dWxuZXJhYmxlX2VuZHBvaW50P3BhcmFtPW1hbGljaW91c19SQ0VfhcZGF5=bG9


In this case:


The request goes through the WAF and is not recognized as suspicious.


Then the request goes to Bluecoat, where the cfru parameter is decoded and a GET request is sent to the internal host


As a result, a vulnerability is initiated.


Bingo!

We see the result of executing a malicious payload (in the form of the "hostname" command) passed through the DNS (as mentioned earlier, outgoing TCP connections to our host on the Internet were blocked).

Dns Query to an internal host

Moreover, we played around a bit with the payload to get the results of the injected commands returned directly as part of the HTTP headers during the server response.

Result of executing command in HTTP header

Conclusion

As a result, two errors in the configuration can be distinguished:


The bluecoat proxy acted as a “forwarder” of requests instead of responding with an HTTP redirect as with other URLs (which would cause subsequent client requests to be caught and blocked by WAF).


There was no rule implemented at the WAF layer to analyze the decoded cfru parameter before being passed to Bluecoat to see if the content of the request matches one of the blocking rules configured on the WAF side.


We immediately reported the vulnerability to the company and received a financial reward.


The main thing: virtual patching comes in handy if you need a little time to fix a serious vulnerability. However, if you use virtual patching instead of real patching, sooner or later someone will hack you.


Previous Post Next Post