JSON-based SQL injection attacks trigger need to update web application firewalls

Security researchers have developed a generic technique for SQL injection that bypasses multiple web application firewalls (WAFs). At the core of the issue was WAF vendors failing to add support for JSON inside SQL statements, allowing potential attackers to easily hide their malicious payloads.

The bypass technique, discovered by researchers from Claroty’s Team82, was confirmed to work against WAFs from Palo Alto Networks, Amazon Web Services (AWS), Cloudflare, F5, and Imperva. These vendors have released patches, so customers should update their WAF deployments. However, the technique might work against WAF solutions from other vendors as well, so users should ask their providers if they can detect and block such attacks.

“Attackers using this novel technique could access a backend database and use additional vulnerabilities and exploits to exfiltrate information via either direct access to the server or over the cloud,” the Claroty researchers said in their report. “This is especially important for OT and IoT platforms that have moved to cloud-based management and monitoring systems. WAFs offer a promise of additional security from the cloud; an attacker able to bypass these protections has expansive access to systems.”

Bypass found while investigating other vulnerabilities

The Claroty researchers developed this attack technique while investigating vulnerabilities they found in a wireless device management platform from Cambium Networks called cnMaestro that can be deployed on premises and in the cloud. The cloud service operated by Cambium provides a separate isolated instance of the cnMaestro server for each customer and uses AWS on the backend.

The team found seven vulnerabilities in cnMaestro including a SQL injection (SQLi) flaw that allowed them to exfiltrate users’ sessions, SSH keys, password hashes, tokens, and verification codes from the server database. SQL injection is one of the most common and dangerous web application vulnerabilities and allows attackers to inject arbitrary SQL queries into requests that the application would then execute against the database with its own privileges.

After confirming their exploit worked against an on-premises deployment of cnMaestro, the researchers attempted it against a cloud-hosted instance. From the server response, they realized that the request was likely blocked by AWS’s web application firewall, which detected it as malicious.

Instead of giving up, the researchers decided to investigate how the AWS WAF recognizes SQL injection attempts, so they created their own vulnerable application hosted on AWS and sent malicious requests to it. Their conclusion was that the WAF uses two primary methodologies for identifying SQL syntax: searching for specific words in the request that it recognizes as part of SQL syntax and attempting to parse different parts of the request as valid SQL syntax.

“While most WAFs will use a combination of both methodologies in addition to anything unique the WAF does, they both have one common weakness: They require the WAF to recognize the SQL syntax,” the researchers said. “This triggered our interest and raised one major research question: What if we could find SQL syntax that no WAF would recognize?”

WAF vendors overlooked JSON in SQL

Starting around 10 years ago, database engines started to add support for working with JSON (JavaScript Object Notation) data. JSON is a data formatting and exchange standard that’s widely used by web applications and web APIs when talking to each other. Since applications already exchange data in JSON format, relational database engine creators found it useful to allow developers to directly use this data inside SQL operations without additional processing and modification.

PostgreSQL added this capability back in 2012, with other major database engines following over the years: MySQL in 2015, MSSQL in 2016 and SQLite in 2022. Today all these engines have JSON support turned on by default. However, WAF vendors did not follow suit, probably because they still considered this feature as being new and not well known.

“From our understanding of how a WAF could flag requests as malicious, we reached the conclusion that we need to find SQL syntax the WAF will not understand,” the Claroty researchers said. “If we could supply a SQLi payload that the WAF will not recognize as valid SQL, but the database engine will parse it, we could actually achieve the bypass. As it turns out, JSON was exactly this mismatch between the WAF’s parser and the database engine. When we passed valid SQL statements that used less prevalent JSON syntax, the WAF actually did not flag the request as malicious.”

After confirming that the AWS WAF firewall was vulnerable and they could use JSON to hide their SQLi exploit, the researchers wondered if other WAFs might have the same loophole. Testing of WAFs from several major vendors proved that their suspicion was correct, and they could use JSON syntax to bypass SQLi defenses with only minimal modifications among vendors.

The researchers reported the issue to the vendors they found vulnerable but also contributed their technique to ​​SQLMap, an open-source penetration testing tool that automates SQL injection attacks. This means the bypass technique is now publicly available and can be used by anyone.

“Team82 disclosed its findings to five of the leading WAF vendors, all of which have added JSON syntax support to their products,” the researchers said. “We believe that other vendors’ products may be affected, and that reviews for JSON support should be carried out.”