Successful SQLi WAF Bypass Shows (Again) how WAFs Cannot Stop API-based Attacks
Introduction
On December 8th, 2022, Team82 in Claroty, a cyber security company, published a new method to bypass web application firewalls and launch SQL injection attacks. SQLi is generally considered an “old-fashioned” style of attack, but one that WAFs could supposedly easily detect and block with the right rules and signatures. For this attack, the researchers embedded the SQLi code in a JSON payload, the default payload for REST APIs. The researchers demonstrated how this attack was able to pass through top-selling WAFs from these major providers: Amazon Web Services, Cloudflare, F5, Imperva, and Palo Alto Networks.
So how did the researchers perpetrate their attack? They prepended JSON syntax to the SQLi payload. While a WAF can detect a “traditional” SQLi attack (mainly by identifying a SQL syntax within a request by a set of rules), the aforementioned WAFs could not do it when JSON is prepended. Specifically, since no SQL syntax is identified, no SQLi attempt can be flagged. This lack of JSON syntax support within WAFs is critical because all major relational database engines, as the targets of SQLi attacks, support it natively.
The Need for Dedicated API Security Tooling
Over the last several years, attackers have changed their tactics, focused on identifying and exploiting business logic gaps by manipulating and abusing APIs. The nature of attacks changed enough that OWASP created a fresh OWASP API Top 10 list to detail these new threats.
It’s no surprise that WAFs would miss these new forms of attack, since you can’t build rules or signatures to detect them and they tend to unfold over a series of API calls. The Team82 attack, however, is interesting because it demonstrates that even the classic type of application attack that WAFs were built to detect can elude these platforms.
The premise of API security tooling broadly, and the Salt platform in particular, is that new approaches are essential to finding and stopping API attacks. We wanted to test our assumption that the Salt platform would have caught the WAF evasion method the Team82 used.
To do so, we ran a vulnerable RESTful API often used in API security research, posted on Hackazon, and then launched the Team82 attack against it. As we expected, the Salt platform immediately detected this API traffic via its dynamic and continuous discovery processes.
We also expected that beyond simply seeing the traffic, the Salt platform would also detect this API traffic as anomalous. We of course don’t rely on rules or signatures to spot potentially malicious traffic but instead apply dynamic anomaly detection leveraging our cloud-scale big data and ML/AI algorithms that we’ve tuned over many years. Indeed, the Salt platform immediately detected several anomalous aspects of this API attack, including:
1. SQLi attempt — Because the Salt platform analyzes API payload traffic, it detects the malicious SQLi even though it doesn’t parse the SQL syntax itself.
2. Parameter tampering within the per_page query parameter:
a. Unexpected suspicious characters — The Salt platform had learned that the value of this parameter should not contain any special character, but the malicious payload included JSON syntax related characters.
b. Type mismatch — The Salt platform had learned the value of this parameter should contain digits, and not a string, which the malicious payload used.
c. Length — The Salt platform had learned the common length of this parameter and the malicious payload is much longer.
Detecting Zero Day Vulnerabilities
Launching this API attack and watching the Salt platform immediately detect a broad set of anomalies was reminiscent of our experience with seeing an attempted Log4Shell attack in one of our customer’s environments and flagging the attack before anyone realized that vulnerability existed.
The continued evolution of attacks makes clear that new protection techniques are essential. No matter how advanced so-called “intelligent” WAFs get, they’ll also have the architectural limitation of seeing transactions one at a time and detecting attacks based on rules and signatures. Relying on just WAFs for protecting web services leaves companies vulnerable — Web API attacks will consistently get through, just as happened with this JSON-embedded SQLi attack.
Most API vulnerabilities are zero-day vulnerabilities. Log4Shell was, and vulnerabilities lurking in your company’s APIs are also zero-day vulnerabilities. To identify these gaps and prevent exploits of them, companies need the protection that only advanced ML/AI can detect. Finding such exploits requires a well-defined baseline, built over time, that pinpoints the anomalies associated with attack reconnaissance activities and attempted exploits. These algorithms must run against a long-term data set, collected over days and weeks, which demands cloud-scale big data. The amount of data retained in an on-premises solution will never be enough to detect these attacks.
We’d love to tell you more about finding zero-day vulnerabilities — reach out to us. Or to see the Salt platform in action, you can request a personalized demo.
