Re: [sqlmap-users] Determining blind UNION-able injections with SLEEP

[Miroslav S. <mir...@gm...>]

Hi.

A) As I see this "hybrid", you are proposing it as a way to do the "UNION"
based file write (INTO DUMPFILE).

B) Incorporating this "hybrid" technique into the standard tests would be
uberkill (from my perspective). I have a feeling that at least the
"time-based" injection would be detected in this kind of cases, so making
the "UNION" tests carrying the SLEEP would just detect the same thing (but
with usage of UNION technique), but with more requests.

So, to go back to the A). sqlmap already tries to use the "INTO OUTFILE ...
LINES TERMINATED" in non-UNION cases. Making post-detection tests for
number of columns is doable in the "file-write" phase, but I am not
convinced that it would do more good than the number of requests required
(as ORDER BY is expected to be unusable, we would need to pick the number
of columns incrementally).

Thoughts?

Kind regards

On Fri, Sep 11, 2015 at 8:43 PM, Brandon Perry <bpe...@gm...>
wrote:

> I have had this idea for a while, and I finally came across an injection
> that this was useful for me.
>
> Due to logic in the application, a generic UNION tacked on the end of the
> query doesn't work.
>
> However, a payload of:
>
> blah=foo"+union+select+null,null,null,null,sleep(5)--%20
>
> does result in a response coming back 5 seconds later than the baseline.
> Removing or adding a column to the union results in the baseline request
> time.
>
> This was very useful for me, because I was able to use this 'blind union'
> in order to write a file to the web root and achieve RCE, even though the
> union in and of itself would not let me pull data out en mass (the other
> time based payloads did work as well).
>
> This might be a useful check for sqlmap to implement. Currently, there are
> heuristics that sqlmap has to determine whether an injection point is
> union-able, but not exploitable with generic NULL/union char payloads. I
> think this is determined by the HTTP response data though, not the temporal
> aspect of the HTTP response.
>
> Thoughts?
>
>
> --
> http://volatile-minds.blogspot.com -- blog
> http://www.volatileminds.net -- website
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> sqlmap-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlmap-users
>
>


-- 
Miroslav Stampar
http://about.me/stamparm