Bypassing NGFW/WAFs using data format obfuscations

A lot of network security solutions today supports a lot data format inside HTTP and other protocols. The main question here is understanding, based on traffic analysis, which data formats such as JSON/Base64/XML/etc should be applied to which field.

This is an analytically unsolvable problem because it requires understanding the application business logic by traffic analysis. Many of the solutions are using simplified methods to address this. In case of HTTP these approaches are:

1. Using the Content-Type header
2. Using the first suitable data format
3. Requiring manual configuration of the data format for each field

The first method looks reasonable but has important shortcomings. Firstly, not all the data fields have a Content-Type meta information. For example, simple GET data parameters like this:

?jdata={"json":"here"}

Secondly, an attacker can easily set different Content-Type header value than expected by application. It would not be a great idea to trust the data from the same request where you want to detect an attack payload, would it?

Practically it means that most vendors are selecting formats automatically and the first suitable parser will be applied. This practice opens up new opportunities to bypass attack detection systems. To exploit this an attacker should construct the payload in such a way that it will be well-formatted data like JSON and still a valid payload like SQL-injection at the same time.

Here are some examples below:

?injection={"'union/*":"*/select", ",2,password, ":" FROM users;#"}

It’s a classic SQL injection payload the same as:

' UNION SELECT 1,2,password,4 FROM users--a-

But for the detection system with JSON parser this data looks differently:

SQL injection payload as a valid JSON data

The detection logic will be applied to each key and value in this JSON separately. Separately these keys and values do not represent an attack. But all them together is an attack and this attack is transparent to the detection systems because of the JSON parser.

The same trick can be used to camouflage the payload as XML data. The payload below is a valid XML document and SQL injection as well:

<?xml version="1.0"?><a att1="'union/*" att2="*/select" att3=",username," att4=" FROM user;#">I'm an XML. Trust me!</a>

SQL injection payload as a valid XML data