<div dir="ltr"><a href="http://infiltratecon.com/">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">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/">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">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">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">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">https://www.youtube.com/watch?v=Dh9Pa0kDfsc</a>)</div></div>