<p dir="ltr">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&#39;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&#39;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&#39;m sure many know. And it&#39;s scary how many organizations never update Oracle nor disable such functions to abuse...</p>
<div class="gmail_quote">On Apr 1, 2016 1:07 PM, &quot;Dave Aitel&quot; &lt;<a href="mailto:dave.aitel@gmail.com">dave.aitel@gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just to be annoying, I&#39;m going to add to this list by replying to my own message:<div><br></div><div>8. Unicode is a huge deal. People forget that a lot of the data you&#39;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. </div><div><br></div><div>For the most part people think &quot;SQLMap&quot; is as good as it gets, and it&#39;s still great and very useful but it of course, has many limitations when it comes to doing things in the wild.</div><div><br></div><div>-dave</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 1, 2016 at 11:38 AM Dave Aitel &lt;<a href="mailto:dave.aitel@gmail.com" target="_blank">dave.aitel@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="http://infiltratecon.com/" target="_blank">INFILTRATE 2016</a> is coming up and the office is super quiet because everyone else is helping set up the training at the Fountainblue. It&#39;s &quot;go time&quot; which means I can only fuck things up with my preemption and annoying questions and high levels of anxiety. So I&#39;m watching talks on different things as a salve.<div><br></div><div>In particular I noticed this recent talk on BSQLi being advertised on the twitters <a href="https://www.youtube.com/watch?v=7WA9Muvt4Sg&amp;feature=youtu.be" target="_blank">https://www.youtube.com/watch?v=7WA9Muvt4Sg</a> , by <span style="color:rgb(51,51,51);font-family:Roboto,arial,sans-serif;font-size:13px;line-height:17px">Keith Makan. It starts off with an interesting discussion on Bug Bounties, which is illuminating. Why on Earth do companies who don&#39;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 <a href="http://infiltratecon.com/" target="_blank">INFILTRATE </a>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&#39;s talk about penetration tests.</span></div><div><br></div><div>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&#39;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&#39;m going to put in list format some things that you will find in the Wild with BSQLi.</div><div><br></div><div><div>All of these things were in <a href="http://infiltratecon.com/miguelturner.html" target="_blank">Miguel&#39;s INFILTRATE talk in 2013</a>, which nobody seems to have noticed has made BSQLi exploitable in the wild, squeezing the last drops of life from a dying bugclass . :)</div></div><div><br></div><div>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.</div><div><br></div><div>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&#39;ll never know which two those are in practice. Slow is fast, as they say.</div><div><br></div><div>3. If you&#39;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.</div><div><br></div><div>4. Doing N-Gram prediction on values you are pulling from the database can result in significant speedups. I.E. pulling data from the &quot;Hosts&quot; table and first character is an &quot;l&quot;-&gt; guess &quot;localhost&quot; and see if it works. (We use Python&#39;s nltk for this)</div><div><br></div><div>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.</div><div><br></div><div>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&#39;ve seen on a webpage, and searching for that in the database, overwriting it, and testing. </div><div><br></div><div>7. A super large percentage of BSQLi problems are in the login page, no matter what platform was used to make it.</div><div><br></div><div>-dave</div><div>Resources:</div><div><div><a href="http://infiltratecon.com/miguelturner.html" target="_blank">http://infiltratecon.com/miguelturner.html</a> (This talk goes over all the points in this email for those who did not attend INFILTRATE 2013)<br><div><br></div></div><div><a href="https://lists.immunityinc.com/pipermail/dailydave/2013-January/000299.html" target="_blank">https://lists.immunityinc.com/pipermail/dailydave/2013-January/000299.html</a> (original post on this)<br></div></div><div><br></div><div>(Another talk on BSQLi from DefCon 20: <a href="https://www.youtube.com/watch?v=Dh9Pa0kDfsc" target="_blank">https://www.youtube.com/watch?v=Dh9Pa0kDfsc</a>)</div></div></blockquote></div>
<br>_______________________________________________<br>
Dailydave mailing list<br>
<a href="mailto:Dailydave@lists.immunityinc.com">Dailydave@lists.immunityinc.com</a><br>
<a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" rel="noreferrer" target="_blank">https://lists.immunityinc.com/mailman/listinfo/dailydave</a><br>
<br></blockquote></div>