Are you currently experiencing an attack?

Are you currently experiencing an attack?

New Attack Method for Bypassing WAFs (Yours Might Be Vulnerable)

A “generic WAF bypass” technique has been discovered. It uses JSON to conceal an SQLi (SQL injection) attack, thus allowing the attacker to exfiltrate data or do other malicious activities.

Reblaze has always blocked this attack method. However, many other industry-leading WAFs had this vulnerability until a few days ago. 

This implies that others might still be exploitable. Perhaps yours is among them. 

In this article, we’ll discuss what this attack is, a (short) list of WAFs that protect against it, and how to test your WAF to see if your environments are vulnerable to it.

SQL injection 101

If you’re unfamiliar with SQLi, it’s a well-known approach for accessing private data from a server. Although it’s an old threat, and addressing it is a basic requirement for modern WAFs, it’s still prevalent enough today to be included in the OWASP Top Ten list (as part of the broader Injection category). 

To illustrate SQLi, here’s a simple example. Let’s say a web application constructs a string for a query to retrieve account transactions for a specific customer, based on a user-submitted argument called userName:

string query = "SELECT * FROM transactions WHERE customer = '" + userName + "';"

A legitimate user of the application would submit a valid value for userName, so that the query would resolve to something like this:

SELECT * FROM transactions WHERE customer = 'SubmittedUserName';

However, an attacker attempts SQLi by submitting this string instead:

foo' OR 'a'='a

If the application accepts and processes this input without validating it, the query that will be run is this:

SELECT * FROM transactions WHERE customer = 'foo' OR 'a'='a';

The hacker has created a logical OR condition which will be true for every record evaluated. Therefore, the query will return all records in the table.

Data exfiltration is not the only danger, because SQLi attacks can also be destructive. For example, some database servers allow a syntax where multiple queries can be submitted, separated by semicolons. So the attacker could input something like this:

foo'; DELETE FROM transactions; --

This will resolve to two SQL commands, followed by a commented line (designated by the double hyphens) that will be ignored:

SELECT * FROM transactions WHERE customer = 'foo';
DELETE FROM transactions;

…which will delete all records from the transactions table.

A well-understood threat

The examples above are basic SQLi, and a modern WAF should detect them easily. 

One of the primary tasks of a WAF is to parse incoming requests and look for threat signatures within them. SQL injection is an old and well-understood threat, so most WAFs are proficient at recognizing and blocking SQLi attempts.

(The best WAFs will even allow admins granular control over this. For example, some characters are used within SQL syntax that are also allowable in URLs within certain nations, but not in others. Therefore, a good WAF will understand these differences, and allow admins to adjust how requests are filtered, depending on the context and how those characters are used within the requests.)

The new vulnerability

Although SQLi has been around for many years, occasionally a new variation is found. 

This happened again recently, as revealed in this announcement by Claroty’s Team82. These researchers discovered a way to successfully pass SQL through many WAFs, by adding JSON to the inputs being submitted to an application.

Most database engines have supported JSON for years. However, in a rather surprising result, Team82 found that almost all the WAFs they tested did not. Thus, these WAFs did not filter the hostile inputs correctly.

More specifically, the team found that if they prepended JSON to an SQL injection attack, most of the WAFs they tested were unable to recognize the attacks, and passed the requests through to their backends. However, since most database engines can process JSON correctly, this would result in the requests being parsed and the SQL payloads being executed.

Returning back to the simple example above, instead of an attacker submitting this input:

foo' OR 'a'='a

They could submit something else instead, like this one tailored for a PostgreSQL backend:

foo' OR '{"a":"a"}' @> '{"a":"a"}

Here, the “@>” operator (meaning “does the left value contain the right value”) confused most of the WAFs that were tested, and prevented them from recognizing the SQLi attack. But again, since modern database engines are capable of understanding JSON, they would process the malicious input and therefore, would receive the hostile payload.

Which WAFs were vulnerable?

As mentioned earlier, Reblaze is not, and never has been, vulnerable to this type of attack. However, the same cannot be said for many prominent security solutions.

Team82 tested these WAFs:

  • AWS
  • CloudGuard 
  • Cloudflare
  • F5
  • Imperva
  • Palo Alto

The only one that blocked this attack method was CloudGuard. All the rest were vulnerable to it.

The good news is that Claroty reported the vulnerability to the other five vendors, and all five now say they have updated their WAFs to defeat this tactic.

The bad news is that there are many other WAFs on the market, with little transparency about how they would react to JSON-based SQLi attacks.

How to test your WAF

If your organization uses one of the many WAFs that have not, at this point, announced how they’re handling this issue, you should ask them about it.

If they aren’t forthcoming, you can test your WAF yourself. Team82 has added support for this technique to the open source pen-testing tool SQLMap. They even included a number of scripts for different kinds of database engines.

Protecting against future vulnerabilities

New potential exploits are constantly being discovered. The CVE alone publishes many new announcements each day, frequently at a rate of several per hour. 

Protecting against them is very challenging for many organizations, because a number of web security solutions–even some of the most popular services–are partially or fully self-managed. 

A self-managed solution means that admins have to keep up-to-date with the continually changing threat environment; they must consume the CVE feed, follow industry figures, watch videos, listen to podcasts, and perform other activities to stay current. They must also install patches and updates within their infrastructure, maintain a high level of expertise on the ecosystems that they’re responsible for, and (in perhaps the most challenging requirement) must write, test, and maintain new security rulesets and policies.

In today’s threat environment, organizations need to maintain a robust security posture at all times. Self-managed solutions are not the answer.

Reblaze is a cloud native, fully managed web security solution: a SaaS platform maintained by a team of security professionals. As new web threats arise, Reblaze is hardened against them immediately and automatically. Reblaze clients enjoy “effortless web security,” in a platform that is always up-to-date and always effective. 

Reblaze protects sites, applications, and APIs, and includes a full suite of security technologies: not only a next generation WAF, but also DDoS protection, advanced bot management, Machine Learning and UEBA (User and Entity Behavioral Analysis), ATO (account takeover) prevention, API security, and more.

For more information about Reblaze, or to get a demo, contact us here.

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.