In this blog, we will see how to use an uninitialized Bash variable to bypass WAF regular expression-based filters and pattern matching.
The Uninitialized Variable
In the last two articles of this series of "Web Application Firewall (WAF) evasion techniques", we have looked at how to bypass a WAF rule set exploiting a Remote Command Execution on a Linux system by abusing of the bash globing process. In this part, let us see another technique that uses an uninitialized bash variable in order to elude regular expression-based filters and pattern match.
echo "uninitialized_variable=$uninitialized_variable"
Uninitialized variable has a null value (no value at all).
Declaring, but not initializing it, it's the same as setting it to a null value, as above.
By default, Bash treats uninitialized variables like Perl does: they're blank strings! The problem is that, it is even possible to execute commands concatenated with uninitialized variables and they can be used inside arguments too. Let's start with an example.
Assuming that we want to execute the command cat /etc/passwd, we can use the following syntax:
cat$u /etc$u/passwd$u
where $u doesn't exist and it's treated as a blank string by bash:
Conclusion
Why it's so hard to block this kind of request? and why WAF usually doesn't block the dollar character inside an argument value? Because it would be prone to many false positives. The best approach is the one used by CRS3that blocks only if 4 or more repetitive non-word characters are found in a single value. This is more clever than blocking specific characters, having less false positives.
