[Dailydave] Blind SQL Injection Still Worky Worky

[Dave Aitel]

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/f62df907/attachment.html>