Project maintainers confirm that they intend to address filter bypass vulnerabilities
UPDATED Filters applied by Libinjection, the SQL injection defense library, can be bypassed in order to execute blind SQL injection attacks against vulnerable applications.
Libinjection is an open source C library that detects SQL injection (SQLi) payloads using lexical analysis.
Menin told The Daily Swig that the tool is widely used in conjunction with web application firewalls (or WAFs, which are not to be confused with network-level firewalls).
“For example, ModSecurity uses it via the ‘detectSQLi’ operator that returns true if an SQL injection payload is found,” he adds, citing the example SecRule ARGS “@detectSQLi” “id:123,block”.
Bypassing with arithmetic operators
Menin, an OWASP Core Rule Set developer who specializes in breaking WAFs, demonstrates how a request that tries to check if the parameter ID can be injected with SQL syntax (/index.php?id=1+AND+1=1) was successfully identified by LibInjection as an SQLi attempt.
However, attackers could use a list of arithmetic operators, string functions, and conditional SELECT syntaxes to evade detection, the researcher adds.
Menin, who is also co-founder of cybersecurity video producer Rev3rse Security, demonstrates a scenario whereby attackers could check whether a parameter with a numeric value ‘2’ is vulnerable to SQLi by replacing ‘2’ with an arithmetic operation.
While libinjection intercepts “most SQLi classic attempts like 1+OR+1=1”, its filters can be bypassed with MySQL functions.
For example, miscreants could “insert comments inside the SQL syntax, such as sEleCt/*foo*/1”, but “this kind of payload is well blocked by [a] WAF that uses libinjection,” says Menin.
However, he offers a payload that bypasses “a WAF using libinjection to exploit” a hypothetical SQLi flaw in a WordPress plugin.
The RLIKE operator then allows the researcher to “brute-force the hashed password value by checking the response body length after adding characters to the regular expression”.
The := assignment operator, meanwhile, causes the user variable on the operator’s left-hand side to take on the value to its right, he says. This “may be a literal value, another variable storing a value, or any legal expression that yields a scalar value, including the result of a query” if it yields a scalar value.
You can perform multiple assignments in the same SET statement, he adds.
“Unlike =, the := operator is never interpreted as a comparison operator. This means you can use := in any valid SQL statement (not just in SET statements) to assign a value to a variable.”
All syntaxes used by the researcher in the previous methods – expression, comments, RLIKE, and assignment operator – can be deployed here too, a finding he credits to GitHub user ‘Seedis’.
Fix is forthcoming
Menin says he has asked the Libinjection project maintainers “for fixes and commits in the past but without success”.
However, Felipe Zimmerle, Lead dev for ModSecurity, contacted The Daily Swig after this article was published to confirm that another issue was recently addressed and that, with the help of friends, he will be engaging with Menin to fix the flaws (the project has recently been moved to a new repository).
Even before these filter bypass flaws are fixed, Menin still believes the tool generally detects SQLi attacks more effectively than expression-based rulesets.
“Libinjection does great work and blocks a lot of SQLi payloads,” he explains.
“My advice is to use libinjection with a strong rule set as the OWASP Core Rule Set 3 that can cover all its weaknesses and prevent bypasses without false positives.”
This article was updated on September 19 to reflect the fact that project maintainers intend to address the flaws unearthed in Libinjection