Web application firewalls, also known as WAFs, are intended to protect web-based applications and application programming interfaces (APIs) from malicious HTTPS traffic coming from the outside, particularly cross-site scripting and SQL injection attacks, which never seem to fall off the security radar.
SQL injection in particular is a constant among the output of automated code scans and a frequent fixture on industry lists of top vulnerabilities, including the OWASP Top 10, despite the fact that it is acknowledged and relatively straightforward to solve.
If an attacker can get through the capabilities of web application firewalls (WAFs) to monitor and block traffic, they frequently have a direct route to important information about the company and its customers. Thankfully, such bypasses have been rare and have often taken the form of isolated incidents directed at a certain vendor’s implementation.
Today, Team82 disclosed a new attack approach that functions as the first general bypass of numerous web application firewalls that are marketed by market-leading manufacturers. Their bypass is effective with WAFs provided by Palo Alto, F5, Amazon Web Services, Cloudflare, and Imperva, the five most prominent companies in this space. Every one of the impacted vendors has accepted Team82’s disclosure and has issued solutions that include support for JSON syntax into the SQL inspection procedures of their respective products.
Research on Cambium Networks’ wireless device management platform that was unrelated to the development of this approach was where they got the idea of this technique.
This method depends first on comprehending the manner in which WAFs recognize and label SQL syntax as potentially harmful, and then on locating SQL syntax that the WAF is oblivious to. It turns out that this was a JSON file. When data is sent from a server to a web application, the JSON file format—which is an industry standard for file and data exchange—is often used.
Since over ten years ago, SQL databases have included support for JSON. The syntax of JSON is supported by default in modern database engines, and these engines also enable basic searches and changes, as well as a wide variety of JSON functions and operators. While most database engines provide support for JSON, same cannot be stated for web application firewalls (WAFs). Because vendors have been sluggish to add support for JSON, we were able to create new SQL injection payloads that incorporate JSON and were able to circumvent the protection that WAFs normally provide.
Using this innovative method, attackers might get access to a backend database and then utilize further vulnerabilities and exploits to steal information by either directly accessing the server or transferring it over the cloud.
This is particularly significant for operational technology (OT) and internet of things (IoT) platforms that have transitioned to cloud-based administration and monitoring systems. WAFs hold up the possibility of extra cloud-based security; yet, an attacker who is successful in evading these safeguards will have extensive access to the targeted systems.
Based on the results of our tests, they came to the conclusion that in general, WAFs use one of two methods to determine whether or not a request is malicious:
Search for terms that have been blacklisted The WAF is able to search for words that it identifies as SQL syntax, and if there are an excessive number of matches in a request, it will mark the request as an attempt at malicious SQLi.
The WAF is able to make an attempt to parse correct SQL syntax by using several components of the request in order to do this task. If the WAF is able to correctly identify SQL syntax in the request, it will mark the request as a potentially harmful attempt to execute SQLi.
In spite of the fact that most WAFs will utilize a mix of the two techniques in addition to anything else that is unique to the WAF, the two approaches have a single flaw: they both need the WAF to be familiar with the SQL syntax.
This simple JSON operator, in this instance @>, which checks to see whether the correct JSON is included in the incorrect one caused the WAF to enter an infinite loop, which in turn enabled us to send malicious SQLi payloads and get over the WAF’s protections. They were able to exfiltrate sensitive information utilizing our SQLi vulnerability by just appending some basic JSON syntax at the beginning of the request. This allowed anyone to access sensitive data stored in the cloud.
It is feasible to create new SQLi payloads by making use of the syntax of JSON. Because these payloads are not well understood, it is possible that they may be utilized to evade detection and to circumvent a variety of security measures. They were able to construct a list of true statements in SQL by using syntax from a variety of database engines, and the list is as follows:
PostgreSQL: '{"b":2}'::jsonb <@ '{"a":1, "b":2}'::jsonb Is the left JSON contained in the right one? True.
SQLite: '{"a":2,"c":[4,5,{"f":7}]}' -> '$.c[2].f' = 7 Does the extracted value of this JSON equals 7? True.
MySQL: JSON_EXTRACT('{"id": 14, "name": "Aztalan"}', '$.name') = 'Aztalan' Does the extracted value of this JSON equals to ‘Aztalan’? True.
Putting the Process Through Automation
They made the decision to add support for JSON syntax evasion methods to SQLMap, which is the most popular open-source exploitation tool. This was done so that they could demonstrate how significant this WAF bypass is.
Simply clone the most recent version of SQLMap from Github in order to utilize this script in order to test the bypass. If you would want to use this script.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.
