[Dailydave] Blind SQL Injection Still Worky Worky

[Dave Aitel]

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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20160401/61a55681/attachment.html>