[Dailydave] Blind SQL Injection Still Worky Worky

Fri Apr 1 20:39:37 EDT 2016

In the wild, sqlmap works just great for bsqli and you can pass custom
Python code to do exactly what Miguel discussed in 2013 to speed up
extraction. In production penetration tests though, there is usually an
unspoken rule -- and often contractual -- not to overwrite data in the DB
no matter how trivial the data, such as an image. But if you are not sqli
in DBA role, you may need temporary table views to store the output, which
may also not be feasible. I can say pretty unequivocally that bsqli or sqli
is still in nearly every org pentest I have done, in some app, somewhere --
usually internet exposed. That's pretty bad given 20+ years of trying to
educate developers on the topic. Blind SQL are lucrative if you can exploit
them efficiently, and Miguel's talk was really good to discuss that. But
maybe only Immunity Websiege has bsqli reliably implemented unless you
write your own custom tools or modify existing ones ;) If you have Oracle
db though, you can do things like XML blind sqli to HTTP or FTP (firewalls
permitting) to dump large amounts of data quickly out of band, as I'm sure
many know. And it's scary how many organizations never update Oracle nor
disable such functions to abuse...
On Apr 1, 2016 1:07 PM, "Dave Aitel" <dave.aitel at gmail.com> wrote:

> Just to be annoying, I'm going to add to this list by replying to my own
> message:
>
> 8. Unicode is a huge deal. People forget that a lot of the data you're
> looking for will be in Unicode character sets, and all the research and
> modeling you did on applications in only English is probably off.
>
> For the most part people think "SQLMap" is as good as it gets, and it's
> still great and very useful but it of course, has many limitations when it
> comes to doing things in the wild.
>
> -dave
>
>
> On Fri, Apr 1, 2016 at 11:38 AM Dave Aitel <dave.aitel at gmail.com> wrote:
>
>> INFILTRATE 2016 <http://infiltratecon.com/> is coming up and the office
>> is super quiet because everyone else is helping set up the training at the
>> Fountainblue. It's "go time" which means I can only fuck things up with my
>> preemption and annoying questions and high levels of anxiety. So I'm
>> watching talks on different things as a salve.
>>
>> In particular I noticed this recent talk on BSQLi being advertised on the
>> twitters https://www.youtube.com/watch?v=7WA9Muvt4Sg
>> <https://www.youtube.com/watch?v=7WA9Muvt4Sg&feature=youtu.be> , by Keith
>> Makan. It starts off with an interesting discussion on Bug Bounties, which
>> is illuminating. Why on Earth do companies who don't already have extremely
>> mature Vulnerability Management programs, including continuous scanning,
>> invest in Bug Bounties, I wonder, after listening to him talk for 5 minutes
>> about how the typical process works on BugCrowd. Going to ask the DoD that
>> when they present at INFILTRATE <http://infiltratecon.com/>next
>> Thursday, along with some nagging questions I have about how legal
>> protection and indemnification works in the Bug Bounty world (or, more
>> likely DOES NOT WORK, which is scary). :) But that is completely beside the
>> point for now! Let's talk about penetration tests.
>>
>> Most penetration tests are not penetration tests! They are web
>> application assessments. And when you find SQLi you note it and move on and
>> it becomes the developer's problem. But what if you wanted to actually
>> penetrate that website? Everyone knows what to do if you have Error
>> messages, or can tell the difference between a True and False result with
>> your SQLi (using differences in page sizes, for examples). But now I'm
>> going to put in list format some things that you will find in the Wild with
>> BSQLi.
>>
>> All of these things were in Miguel's INFILTRATE talk in 2013
>> <http://infiltratecon.com/miguelturner.html>, which nobody seems to have
>> noticed has made BSQLi exploitable in the wild, squeezing the last drops of
>> life from a dying bugclass . :)
>>
>> 1. The only truly portable way to find and exploit BSQLi is timing (and
>> even that is hard on some databases). Research based on different page
>> responses is largely not going to work in the wild unless you are luckier
>> than we are.
>>
>> 2. Lots of research assumes you can do hundreds of concurrent requests to
>> a web app all at the same time. This is NOT TRUE IN THE WILD. What happens
>> is you will DoS some random part of their infrastructure by trying, which
>> is non-optimal. This is also true when looking at two applications which
>> share infrastructure. You'll never know which two those are in practice.
>> Slow is fast, as they say.
>>
>> 3. If you're using Timing based techniques (which you probably ARE) then
>> there is a different cost for a True and False result. Optimizing your
>> algorithms for False results is important.
>>
>> 4. Doing N-Gram prediction on values you are pulling from the database
>> can result in significant speedups. I.E. pulling data from the "Hosts"
>> table and first character is an "l"-> guess "localhost" and see if it
>> works. (We use Python's nltk for this)
>>
>> 5. You will spend a lot of time doing checksums and re-pulls on data
>> because Timing techniques will occasionally give you mangled data for
>> various reasons.
>>
>> 6. You really only want to do BSQLi in order to identify a writable
>> binary blob you can overwrite with things and re-request. For example, on a
>> page that has a picture of a product you want to buy, like an Emoji Pillow,
>> you can overwrite that with an encoded copy of the entire username/password
>> table, and just pull it down all at once using a GET request. This process
>> can be automated to a certain extent by hashing data you've seen on a
>> webpage, and searching for that in the database, overwriting it, and
>> testing.
>>
>> 7. A super large percentage of BSQLi problems are in the login page, no
>> matter what platform was used to make it.
>>
>> -dave
>> Resources:
>> http://infiltratecon.com/miguelturner.html (This talk goes over all the
>> points in this email for those who did not attend INFILTRATE 2013)
>>
>> https://lists.immunityinc.com/pipermail/dailydave/2013-January/000299.html (original
>> post on this)
>>
>> (Another talk on BSQLi from DefCon 20:
>> https://www.youtube.com/watch?v=Dh9Pa0kDfsc)
>>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20160401/fb4480a5/attachment-0001.html>