Bypass WAF: Burp Plugin to Bypass Some WAF Devices

I wrote a blog post on the technique used by this plugin here a while back. Many WAF devices can be tricked into believing a request is from itself, and therefore trusted, if specific headers are present. The basics of the bypass approach can be found in an HP blog post here.

I have been implementing Match/Replace rules in Burp to auto-add these headers to requests sent to sites protected by WAFs for a while but decided to create a plugin that could be used to add the headers to active scans, repeater requests, intruder requests, etc. I came across this article from Fishnet Security that really got the ball rolling.

First, I implemented the plugin in Python as that was quick and easy and I actually needed it pretty quick on a recent project. Then I did some quick research on how to implement it as a Java extension to enhance efficiency.

To use this plugin to add the necessary headers, first you need to either download the Python version of the plugin, the Java version of the plugin, or the Java source and compile yourself. Once you have the plugin, start up Burp and navigate to “Extender->Extensions” and click the “Add” button. Choose an extension type of “Java”, if using the Java Plugin, or “Python”, if using the Python version, and then navigate to the extension path. The configuration should look something like:

Add the Extension

The plugin should now be loaded and display something like:

Loaded Extension

Now you need to navigate to “Options->Sessions” and then click on the “Add” button for the “Session Handling Rules” configuration section as shown below:

Add Session Rule

Give the rule a name and then click the “Add” button in the “Rule Actions” section, and choose “Invoke a Burp extension” as shown below:

Edit Session Rule

You should be able to select “Bypass WAF” in the drop down box as seen below:

Extension Action Handler

Click “Ok” and then select the “Scope” tab. Enable all the tools that you want to be in scope for the extension and then set the scope. I like to enable scope for all tools and limit scope on requests to those that have been added to the suite scope as seen in below:

Rule Scope

Bypass WAF contains the following features:

Most of the new features are based on Ivan Ristic’s WAF bypass work found here and here. A description of each feature follows:

  1. Users can modify the X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr headers sent in each request. This is probably the top bypass technique i the tool. It isn’t unusual for a WAF to be configured to trust itself (127.0.0.1) or an upstream proxy device, which is what this bypass targets.
  2. The “Content-Type” header can remain unchanged in each request, removed from all requests, or by modified to one of the many other options for each request. Some WAFs will only decode/evaluate requests based on known content types, this feature targets that weakness.
  3. The “Host” header can also be modified. Poorly configured WAFs might be configured to only evaluate requests based on the correct FQDN of the host found in this header, which is what this bypass targets.
  4. The request type option allows the Burp user to only use the remaining bypass techniques on the given request method of “GET” or “POST”, or to apply them on all requests.
  5. The path injection feature can leave a request unmodified, inject random path info information (/path/to/example.php/randomvalue?restofquery), or inject a random path parameter (/path/to/example.php;randomparam=randomvalue?resetofquery). This can be used to bypass poorly written rules that rely on path information.
  6. The path obfuscation feature modifies the last forward slash in the path to a random value, or by default does nothing. The last slash can be modified to one of many values that in many cases results in a still valid request but can bypass poorly written WAF rules that rely on path information.
  7. The parameter obfuscation feature is language specific. PHP will discard a + at the beginning of each parameter, but a poorly written WAF rule might be written for specific parameter names, thus ignoring parameters with a + at the beginning. Similarly, ASP discards a % at the beginning of each parameter.
  8. The “Set Configuration” button activates all the settings that you have chosen.

All of these features can be combined to provide multiple bypass options. I intend to add the following features, at a minimum, to future versions:

  1. HTTP Parameter Pollution – Automatically perform HPP attacks on GET/POST parameters.
  2. HTTP Requests Smuggling – Automatically perform an HTTP request smuggling attack on each request where a dummy request is added to the beginning and the real (smuggled) request is added at the end.

I have been adding features rapidly and it is very possible that the above will be in the code by the time anyone actually reads this.

That is all you need to do. You can get the extension here.

Leave a comment