WAFs are great, they can add an extra layer, and they can make attacks more difficult. But they are not the end-all-be-all. They have their flaws and thus as a developer you still need to write secure code and fix known open vulnerabilities. I thought it'd be interesting to review some of the concepts found in the Bypass WAF Cookbook to illustrate how this can be.
.NET specific % symbol - Some versions of IIS/ASP allow the % character in the url but actually ignore it when processing. Therefore if your url was 'http://mysite.com?a=sele%ct * from users' then IIS/ASP will actually just run 'http://mysite.com?a=select * from users'. Why is this a problem? If you wrote a Snort, IDS, or WAF regex rule to search for the word 'select', then 'sele%ct' may not match but will still run in IIS/ASP so you just found a way to possibly bypass the WAF if it can't handle that and perform some sql injection attacks!
.NET specific %u symbol - Some versions of IIS/ASP allow the %u to specify unicode characters instead of ascii. Therefore if your url was 'http://mysite.com?a=sel%u0065ct * from users' then IIS/ASP will actually just run 'http://mysite.com?a=select * from users' because %u0065 is unicode for 'e'. Why is this a problem? If you wrote a Snort, IDS, or WAF regex rule to search for the word 'select', then 'sel%u0065ct' may not match but will still run in IIS/ASP so you just found another way to bypass the WAF. Now WAFs may be getting smarter and learning tricks like this, but it's difficult if not impossible to capture all these scenarios. Like the author mentioned, a windows firewall bypass was found where in multibyte unicode sets, sometimes multiple codes resolve to the same character so like %u0065 and %u00f0 might both resolve to 'e'.
Apache specific http methods - Some versions of Apache are too lax in their http method syntax and thus you don't even need the word 'GET' in the request and it'll still perform one. Thus if your rule specifically looks for the 'GET' keyword, it won't match but yet Apache will still serve the request, thus you can send this malformed request, the WAF doesn't match the rule, but Apache still process the request ... bypass!
PHP specific normalization issues - Some version of PHP may parse the Content-Type header in strange ways that can trick the WAF into thinking it's requesting an image but PHP will process a non-image request.
HTTP parameter method changes - There are usually multiple ways to submit parameters, like GET, POST, and Cookies on a website. Sometimes a WAF may look only for GET and POST and thus you can use a Cookie to submit the same parameter and bypass the WAF.
Content-Type header changes - The WAF is inline and has to take performance related shortcuts. So it may decide to filter out or ignore certain types of data. So it's possible to bypass the WAF by tricking it into thinking the request is ignore-able ... such as switching the Content-type to 'multipart/form-data' (which is a method for transferring bulk form data to a server)
Parameter pollution - Another trick is to send multiple parameters like 'http://mysite.com?a=1&a=2&a=select * from users'. Now which 'a' will the WAF look at? The first or the last? And which will the web server use? If you can find a mismatch such that the WAF picks one but the Web Server picks the other, then you have a bypass!
Database tricks - If you have a WAF rule that's looking for a space followed by the word union you may find bypasses by finding characters that databases (like mysql) access beforehand like '\N' ... such that a URL like this 'http://mysite.com?x=1=1\Nunion select * from users' passes by the WAF rule, but the web server still processes it as a valid statement. Of course you can do other tricks too that involve certain string manipulation functions like CONCAT, SUBSTR, etc. and it's not likely the WAF can understand them all, yet the database will know exactly what to do with them.
Performance Bypass - Another concept is that the WAF's usually have a timeout period or some performance threshold, if they can't finish analysis in X period of time then they ignore it. Thus if you can find a way to submit a larger or slower than normal request that the WAF ignores but the web server takes the time to process, you just found a bypass!
Application Layer IP Filtering - Another concept is that some WAF's allow certain IPs to bypass and go directly to the Web Server (perhaps your corporate assets for performance reasons, etc.). The problem then is some of those headers or attributes can be spoofed to tricking the WAF into thinking you're coming from a different ip (such as using x-forwarded-for, etc.). If you can trick it into thinking you're one of the allowed ips, them bypass!
There is no simple fix, as you can see the bypasses could occur at the WAF itself, at the Web Server (IIS/Apache), at the language (PHP), at the database (mysql) or anywhere in between. Thus you can't trust WAFs as your only saving grace. Instead you should implement your WAF as 1 layer in your defense that would also include Firewall, IPS, secure coding, etc.
Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.
No comments:
Post a Comment