 So yeah, we're going to be talking to you guys today about a tool we've been working on called Barbecue Sequel. First we're going to talk a little bit about ourselves because we are narcissists. My name is Ben Taves. I'm a security consultant and researcher at NeoHapsis. NeoHapsis is a small pen testing shop and application security shop in Chicago. I do mostly network and application pen tests. And my name is Scott Barron. I'm a senior security consultant at NeoHapsis. A similar background has been doing app sec work. A lot of social engineering, pen tests, that kind of stuff and research. Alrighty, so we are here to talk to you guys, like I said, about Barbecue Sequel. Barbecue Sequel, it's a sequel injection exploitation tool. In some senses it's a new dog that we're teaching old tricks. Like I said, it exploits sequel injection. There's about a million other tools that do that. It's also though a new dog that we're teaching a new trick. It's stupidly fast, it's easy to use, and it gets those hard to reach spots. And we'll be talking a lot more about what the hell I mean by that. Alright, so just so we get everybody on the same page, and we know you guys all come from different backgrounds, we're just going to do like a really quick explanation of what sequel is and what sequel injection is. I'm hoping this will go pretty quickly. Oh yeah. And then we'll just get right, whoa. Sorry, dude. And then we'll just get right into it. So what is sequel, right? And I'm assuming most of you guys have probably set up a database at some point, or you write applications and interact with sequel, right? And it's a structured query language in which we use to interact with a database system. Sequel injection is when we inject syntax into the application sequel queries, right? And this is when we do all the fun stuff when we're doing, you know, application security assessments and that kind of work. So let's go ahead and walk through basic sequel injection, right? We got some pseudo code up here. Have the username Masthietti and the password secret, right? We kind of imagine this query is we're going to select everything from the user's table where username is the username and password is password, right? And so the query evaluates, and this is generic, right? This is database agnostic we're talking about here. So we have, you know, select star from users where username is Masthietti and password is secret. All right. So what does sequel injection look like, right? So sequel injection, we're trying to kind of break out of that query syntax, right? And when we break out of that query, or that query statement, we can kind of start to construct our own query on top of the query that the application is supposed to execute, right? So we have some more pseudo code up here. We're inserting in the value you name so we can kind of imagine like a web request, right? You know, you're passing in parameters and whatnot. So we have the username parameter and the password parameter and we're going to go ahead and pass in pwned tick or one equal one. There's a typo there. Basically, that's kind of going to, when you look down at the way the query evaluates to, you see that it kind of basically breaks us out of the way that the query looks. So if we step back and look at how the query should look, inserting that tick symbol allows us to escape out of the query and basically say, well, if the username is pwned or it's one equals one. And since one equals one always evaluates to true, we basically get access to the system, right? So blind SQL injection, which is what we're going to mainly be focusing on because this is the primary use case for our tool, is when you're still trying to alter SQL syntax, but you really can't see the results of what you're doing, right? So it's not like you're injecting something and something is getting displayed to the screen showing you what you're executing. You're actually more interested in other kinds of use cases, which will give you clues on if your injection string is working or not. It's a little bit more complex SQL syntax. It's not quite as trivial as some of the other SQL injection attacks that are out there. But the primary goal is still dumping the database and, you know, winning as much as you can, right? So let's take a look at the blind SQL injection case. And so we'll kind of walk through this and I'm sure you guys have seen this before, but basically we're going to do the same kind of attack we were doing earlier, but we're not going to be able to see the results, right? And so we're escaping out of the query with the tick and then we're going to do a substring, which I'll explain in a little bit what that is, to grab the user name. And the query evaluates to something like you see below. And the stuff in gray is commented out. The double tick, I'm sorry, the double dash is basically a comment character. And as you guys are being familiar with SQL know that there's a couple of different ways to terminate a SQL string. So let's go ahead and kind of walk through what the blind SQL injection looks like or what these components are. So you have a better understanding of how this works, right? So we're selecting star from users where password equals tick, and username equals. And then we kind of close out at that point and here's where we inject our code, right? So we're saying or the ASCII, which is going to take a character and turn it into an int, the substring command, which is going to basically slice this string, all right? And the way that works is it's going to slice the first position, so which happens to be a select statement. So basically what we're saying here is we're going to grab the first, we're going to first query the user object. And then you see the one and the one, let me highlight where that's at right here. We're going to grab the first character and we're going to grab one character. So we're going to select user, so let's say user's root, right? We're going to convert root, that first letter R into an ASCII equivalent, I don't know what R is, but, and then we're going to say is it greater than 63? 63 happens to be a question mark. If that happens to be true, we're going to have some different interaction with maybe the response of the web server. So let's go ahead and say that we're doing a Boolean-based blind sequel injection, and based on the status code of the server, we might get a 404 if we do something that evaluates to true, or we get a 200 if we do something that evaluates to false, right? So that's the thing with blind sequel injection. We're kind of trying to, we're keeping track of different objects of the HTTP request, things like the amount of time it takes for, all right, we have to do a shot here. Yeah, I'm sorry. It's to have gone tradition first time speakers, they have to do a shot. How about a round of applause for these guys? That's good. My eyes lit up when they pulled out the whiskey. So, yeah, so what we're really kind of talking about here is, you know, we're thinking about these different ways that we can determine if what we're doing is correct and incorrect, and we're not going to spend too much time talking about the different ways to validate blind sequel injection. But we're going to go ahead and just kind of move forward here to kind of explain where this problem arise and why we kind of even started working on a tool in the first place when there's all these other awesome tools out there. When you're doing blind sequel injection, there are a couple different ways you can kind of search through the data, right? And the way that the current scripts and tools work, typically it's some sort of binary search. That binary search helps you determine if your character is, you know, the right character and it logs in, et cetera. Tends to be one character at a time. Some of the tools out there have options to do multi-threading and whatnot. I think sequel map, you can do up to 10 threads at a time. But we kind of noticed that performance can be a little bit questionable and sometimes you might get some false data. And it's generally very time consuming, right? You're not executing one query to get the results you want. You have to execute multiple queries and you kind of have to step through all this kind of junk to get the end result. And like I mentioned earlier, there are awesome tools out there. Sequel map, awesome. I, you know, use it on many assessments, sequel ninja, the mole. They all have great features and they're sweet. But when these tools don't work, what do you guys end up doing, right? You kind of end up maybe coming up with your own query. Maybe there's some weird nuance where your requests have to be double URL encoded or you can't use ASCII for some reason or maybe some command that you think you should be able to run on a database server just doesn't work. Maybe the database administrator has made some specific policy or rule that won't allow you to run some of these kinds of commands. So you end up firing up a Ruby script or a Python script and you kind of write out your own logic and like, it's kind of a pain in the ass, right? And it takes a lot of time and you, you know, you test and you debug, you test and debug. And we're kind of thinking about what if there was a way where we could kind of take that process out of it. The whole part where you have to write these very customized scripts for when things don't work. And that's when we enter awesome artwork. We take some really tasty meat on the left and some like sweet looking IBM graphic of how databases look. And then we enter barbecue sequel, right? Yeah. So like Scott was saying, the point of the tool is to exploit blind sequel injection. And hopefully you guys all are at least a little bit familiar now with what the hell that means. So for those hard to reach spots, compared to some of those other tools that we're talking about, this is not automatic. The point of the tool is not to find the volume for you. It's not to do your job for you. This is for helping you exploit something that you already know how to exploit. This is not a skittie tool. So in a lot of the benefits that we see from making you do a little bit more of the legwork is that we can be very versatile. We can be very database agnostic. So it doesn't really matter where you're trying to use it, how you're trying to use it. It's just performing the logic. It's performing the request. So you do have to do more legwork, but you get a lot of benefits out of that, the versatility and speed. We put a lot of work into trying to make this thing very performant. And I think we really did a pretty good job with that. I'm going to talk a little bit about the use of the tool. So like any tool that is going to be making HTTP requests for you, you need to specify what request you want it to make. So you need to tell it what URL, the HTTP method. That's the basics. On top of that, you can specify any other aspect of the HTTP request. A lot of the other tools out there, it's limited in what it will allow you to do. The way that we built the tool, it's sitting on top of a really, really cool HTTP library that I'll talk about a little bit more later. And that library itself is very versatile and we really try to leverage that to give you as much control as possible and to really build out the exact request that you're trying to make. So you can specify cookies, headers, encoding methods, what it should do if it encounters a redirect. If you want to do a multi-part file upload as a part of your attack, you can do that. HTTP authentication, basic or digest or what not. If you need to chain it through proxies, you can specify all of that. So in addition to those things, which most other tools will hopefully allow you to provide, there's a couple of other things that you have to provide. And this is when we start talking about it being more of a semi-automatic tool as opposed to an automatic tool. You need to specify where the injection is going to go into that request. So it's not going to find the volume for you. It's not supposed to find the volume for you. This is an exploitation tool. So you need to tell it where the vulnerability is, where it's going to be injecting the SQL logic, the SQL syntax into the existing request. Additionally, you're going to need to specify what that syntax looks like. This is what allows us to be database agnostic. For people who have worked with a variety of databases, there's a lot of syntax variations, which is kind of crazy because it's SQL, you know. But whenever I find myself trying to exploit SQL injection on an Oracle database, I have the hardest time because I don't like selecting from dual. If I want to select one, I don't want to select from dual. I hate Oracle. I'm a my SQL guy, so I like the fact that it doesn't matter what the database is because you are the one providing the syntax. Once again, this is what makes it a semi-automatic tool as opposed to an automatic tool. And by the way, we made up that verbiage. There's no such thing as an automatic, like we made up the term semi-automatic. I hope that's okay with you guys. So yeah, that first part I was talking about where you specify where in the query, I'm sorry, where in the HTTP request the SQL syntax is going to be injected, where the vulnerability is essentially. I don't know if I can get my mouse. Yep, there we go. Oh shit, this is going to be hard. All right. So right over here, you see what looks like a templating language. And that is because it is a templating language. I opted not to use an existing templating language. I kind of rolled my own because it was simpler for this. So here you see a URL, or here too actually. You see the URL and then you see this thing called query inside of this dollar sign curly brackets. So that is where the syntax, that's where the vulnerability is, that's where the SQL is going to get injected into the URL. But the cool thing is I was telling you how you can use, or how you can specify pretty much any part of the HTTP request. You can specify anything you want. You can also put the injection anywhere you want. So if you have some, if the vulnerability is in the host header or if it's in the user agent or if it's in a cookie or if it's in the file from the multi-part upload, I'm pretty sure you can even do injection in the HTTP method. I think that that would probably break a lot of things and probably not a good idea and probably wouldn't work. But yeah, so you use this templating language where you specify query with this in these brackets. It's kind of a templating tag and you can put that anywhere. So down below you see the data. That's going to be the data section of the URL or of the HTTP request. You can put it in there, in the cookies. One of the other kind of cool things that I tried to do and I got some flag from some Python guys for this. I made it so for specifying cookies and for headers, you don't have to write it out like it is in the raw HTTP packet because that's how a lot of tools are. You can specify it as a dictionary, like a Python dictionary. I know a lot of security folks are Python people so I thought that would be really handy because I really hate trying to specify in SQL map how I want a header to look. So yeah, as you can see here with cookies, like I said, they're exactly the same with headers. Oh shit, I lost my mouse. Sorry. The fourth line down. You can specify cookies and headers as a dictionary and I think that's pretty cool. But yeah, the benefit of this, making you specify where the vulnerability is, is that the tool doesn't have to understand your data. You can be doing some totally bizarre serialization format, anything you want. The tool doesn't give a crap. The tool just wants to know what your request looks like and where it needs to inject. So yeah, this serialization format, if there's some weird processes that you have to go through to make the request work, doesn't care about that. Encodings doesn't care. We'll actually walk through a demo later. Yes. Something we've been seeing very frequently on web application assessments is requiring HMAX signing of particular values and the URI. We've been seeing this more often. So we actually, we'll talk about ways to use the tool to do some of the more kind of advanced stuff that might be a little bit more difficult using some of the other tools that are out there. Yes. So yeah. And then the second thing that I said that you need to provide that you might not need to provide another tool is some of the SQL syntax. Again, here you see the templating language that I was talking about. So here is the, what is going to be injected into the spot that we were talking about in the previous slide. And you're going to need to specify a variety of things in order to make a blind sql attack work. Scott was talking a little bit earlier about how usually when you're doing a binary search in blind sql injection, you're going to be trying to modulate things like what row you're trying to select, what substring you're trying to do. So if you're selecting a user from the database, you're trying to grab the first character and you're trying to figure out what that is before you move on to the second and third character. So you need to use this templating language to specify where all those variables go. And we'll actually, when we do the demo, we'll step through pretty much all the tags that you can use when using the tool and how they work. So if this seems a little confusing now, it actually will make a lot more sense when we go through and run the demo. And nine times out of ten, you're hopefully going to be able to reuse one of these queries that we've already written. It looks a bit intimidating. I agree. I'm intimidated. But yeah, the benefit here, like I was saying, it's database diagnostic. So if you're using a database that isn't using sql at all, but you can still do a blind sql injection attack, or I guess it would just be a blind injection attack, but if you're using something with a screwy syntax, it doesn't matter. You just need to specify what the query is going to look like overall and where you can control these pieces of information within the query. So yeah, this helps you to not need to care about sql syntax, character limitations. It also can be useful for evading IDS and IPS because a lot of times, you'll see people doing, taking ASCII codes and generating their strings from that to, because of character limitations. So if you need to do that, you can do it. That's the point there. The other cool thing is if you need to do something really crazy, like Scott was saying, HMAX signing, I don't know any tools where you can specify that some parameter needs to have an HMAX signature. Let's say you need to do quadruple URL encoding. If you need to do something weird, we put in hooks. So you can provide your own Python that will, it's a method and it will be provided with each HTTP request before it's sent. And if you need to do something absolutely bizarre, you can specify that that needs to be done. And that's another thing we're going to talk about in the demo. We're going to give an example of the HMAX signing. And I think this is one of the really cool features about this tool is that it really allows you to totally customize things. If you need to do something totally crazy, you can do it. It's not our problem. It's not the tools problem. You just need to do it. So you need to know what you're doing. And there's multiple places where you can get the hooks at. So if you need to do weird processing on the response, you can do that too. Pre-request and post-request. These are all things that I'm borrowing from this request, HTTP library that I was talking about. We'll get into that a bit more later. Now I believe it's time for a demo. If anyone's still away. This is the chopper. What website should we try to attack? You think we should try to go after the NSA? I bet you can pull this out. All right. I guess we're going to try to take down the NSA. It's going to look pretty cool. All right. So let's see. What's their website? NSA.gov? All right. So here we have the NSA. Awesome. I'm sure there's probably a really awesome admin login for this website. Let's see if you can find it. We just ran Durbuster on it all day. All right. So look what we found. There's a file on the NSA.gov called sqlvom. Never expect that. Look at that awesome login, guys. It's crazy. All right. So basically the password for this user's secret. So we get a message when we log in. It says you are authors. These are one. Here are some secrets. When Ben types an incorrect password, we get a different response. And we're going to kind of use this as a seed for our attack, right? So we're going to conduct a blind sequel injection attack against this login form. And we're going to use the fact that the response sizes are different. And as you see Ben right now, he's kind of doing the or one equals one. He's trying to. Yeah. Good job, zoom in on that. Trying to. Yep. And now we're off to user one. So go ahead and do or one equals two. Bad credits, right? So now we have kind of a true and false statement. And we know that we can pivot off the fact that the response code size is going to be of a different length, right? So that'll be what we're going to use when we actually conduct the attack to determine if what we're doing is working or not. All right. So go ahead and do a little bit more of an advanced string here. Actually, I'm going to build this out in an editor. Excellent. Or I could be lazy and just use the one I wrote earlier. There we go. So we're going to go ahead and copy out a kind of a pre-built out string we've done here. This is very similar to the demo we walked to earlier, right? We're going to do a substring of the user and we're going to see if it's greater than the value of zero. We're going to comment out the rest of the query. Yep. So we're taking the first character of the username and looking at the ASCII value of that and we're trying to guess what that is essentially. Right. So this is pretty straightforward blind sequel injection. We wanted to keep the demo simple but you can kind of imagine that query string could be anything you could possibly imagine. We'll show you why that's the case when we actually run the tool. And the reason why I just copied something different is because that is a URL encoded version of that. So things like the hash character don't get interpreted as the fragment portion of the URL. Alright cool. So we know that we got our query built out and we know that it's working. So at this point go ahead and do it's false statement. So see here we're looking at the first character and if we say it's greater than zero, it turns out to be true because the first character has an ASCII value that's greater than zero. If we ask if it's less than zero, we get a false statement. It interprets as false. Cool. Alright so at this point we got our query built out. Now it's time to run barbecue sequel. And so I'm going to talk a little bit about the UI here. Basically this probably looks familiar. Anybody use the social engineering toolkit? Anybody? Okay. Handful folks. Yeah so Dave, I talked to Dave because I really like this UI. He said go for it. So we kind of took his code and just hacked a hell out of it. Added a couple of feature improvements to make it a little bit more slick but this user interface gives you a really nice way to set up all the complicated request options that's here. And so we'll kind of go ahead and just walk through some of the different configuration options, some of the features of barbecue sequel that make it distinct and unique. So first let's go ahead and take a look at the barbecue sequel options. Step back. Cool. Alright so barbecue sequel has a following configuration parameters and we'll kind of walk through each one. Let's go ahead and take a look at query first. Cool. You guys see, is it okay or is it pretty hard to read? Working on it. Okay. That'll do. That's what we're injecting. Cool. So this is what we're injecting. So I'll talk a little bit about the template tags here and how this works. As I kind of mentioned before, you need to specify template tags for particular areas of the query that you want to inject in. And it's pretty straightforward here. We're basically saying we're going to do the substring for selecting data from data. And we're going to use row index, right? So row index is going to specify which row we're going after the data. Character index is going to specify which character position are we going after. You'll kind of see this notation that we have a print or colon and then we have a number. These are kind of the default values you want to specify. So we're basically saying we're going to start with row one. We're going to start with character position one. And then we need to specify our comparison operator, right? Typically you're going to want to specify the greater than operator. And then we're going to compare that against the character value zero. Once again, that's just a default value. So you don't need to be too concerned about that. There's a couple other tags that you can actually specify that we're not using in this example. Let's say you're doing a time-based blind sequel injection attack. And you'll see in the description here, we try to do a pretty good job with the documentation. You can specify the template sleep, for example. And then you can specify the number of seconds or milliseconds you want to sleep. So you can do time-based blind sequel injection as well. And one other thing that's important to note here, we're talking about how queries will either evaluate as true or false essentially based on the comparator value. So these default values, you want to build out something that's going to evaluate as true. And that way the tool can start to learn what a true response looks like versus a false response when it starts switching between the greater than and less than symbol. Exactly. All right, so let's go ahead and... So a couple other options we have here and we'll just kind of just walk through them. We have the CSV output file. So if you want to, you can dump all your results to a CSV. We can specify techniques. One thing that Ben was doing when he was doing the research for some of the libraries here was could we improve our exfiltration of data by doing a frequency-based analysis search. And in some circumstances we actually found that it was more effective. But in general, binary search is what we recommend using. Comparison attribute, you'll see when you actually click and take a look at that particular section. But you can specify. Go ahead and show that so they can see all the different options. We can determine if we're doing the injection correctly based on the following attribute. Status code, URL, time, size, text, content and coding, right? So you have all these things you can kind of cue off of. And the tool is intelligent enough to help you determine if those things are changing or whatnot. So let's go ahead and do size. Cool. And then one of the really sweetness things about barbecue sequel is concurrency. Ben will go into greater detail when we finish the demonstration about how this tool is wicked fast. But here you can specify the number of concurrent micro threads you want attacking the database. We're going to go with 75 because that sounds pretty cool. So one other thing to say about the comparison attribute. So this is what's changing when you switch between true and false. So if it's time, if the query takes longer to a value when it's true, you specify time. If it's the size of the response, you specify size. Just to make that clear. Cool. And then let's go ahead and take a look at the HTTP parameters. At a minimum, you need to specify the URL and the method that you're going to use. But as we kind of talked about earlier, you could specify any of these different attributes. You could specify data. You could specify if you need to provide off, basic off or something like that. So here you just kind of configure. And one thing we should mention is that if you enter something incorrectly, so let's say you're typing out a URL or some sort of value and you just botch it and you have like seven backslashes or something in it. We have these validator methods and we'll talk a little bit about that later. That'll make sure what you're entering is like actually well-formatted data. And that can be kind of handy when you're setting up a really complicated request. If you imagine doing that on command line and not really working very well and you're like what the hell what did I do wrong? Well here we're trying to check each individual component when your SQL command takes up the whole terminal. Yeah that sucks. Alright. Do we need to talk about this one? Yeah so in the URL you'll see that we're basically specifying the tag injection right? So this is where we're going to say, this is where we're going to inject our query into. The tag must be specified in some part of the HTTP request. As Ben mentioned earlier, it doesn't need to be in the URL. It can be in a cookie, it can be in a header. It could be in pretty much any part, any object of the HTTP request. So. Alright so let's go back. And now for the fun stuff. So let's go ahead and run the exploit. What it's doing right now is like I was saying, trying to establish what it means for a response to evaluate is true or false. Oh it's doing some test ones and then it asks you for confirmation. So yeah we're kind of seeing here right? We see this, the response size for the following is 3644. We can kind of tell that that's definitely different than 3602. And when we are kind of building out and testing our query in the first place by hand. This looks pretty good. So let's go ahead and fire it up. Alright so basically what's happening right now is we are at super crazy high speeds doing boolean based or binary search, blind sequel injection based off the size. So this is all data from the database. You see the number of requests in the bottom left here. Number of failures. We see how many rows we've numerated. We see the working number of threads. We see the time of the attack and the amount of characters per second. So right now we're averaging 38 characters per second which is pretty damn quick. And we'll wait until the tool finishes running. Why the hell does the NSA have this in their database? Cool. Alright thanks guys. So at this point it dumps out all your data into a list object. A Python list. And you can just hop into your Python interpreter and start working with the data. So Ben's going to go ahead and just reformat it. Maybe print it out, clean it up a little bit. There we go. So it gives you the data right at your fingertips so you can start munging with it and formatting it the way you want to format it. Cool. Alright. Back to PowerPoint. Alrighty. So like I mentioned earlier one of the things that we really tried to work hard on with this tool is getting it to be very, very fast. There's two main things that we were playing with with this. The first is how we're making our HTTP route. So a lot of tools and I historically also have used threading when I needed to do many things at the same time. We're not doing that here. The other thing that I'm going to be talking about in terms of speed is the search algorithms that we're using. Scott touched on that briefly earlier. I'll cover it in more depth very shortly. So first the concurrency. I'm using a library called G requests and I'm sure not many people have heard of that. It's a combination of Python's G event and the Python requests library. First I'm going to talk a little bit about what G event is. G event is a coroutine based Python networking library that uses screenlets to provide high level synchronous API on top of the lib event event loop. Alright can I move on? Alright so I'm going to talk a little bit about what that means. So what we have is coroutines and you can think about coroutines as being functions essentially. But you're spawning a bunch of them that run at the same time. So this seems familiar if you've done threading. But the thing here is that the event or the process scheduling is much more explicit and we have much more access to that. So you're spawning up all of these functions, all of these coroutines, only one of them is actually running at a time. And what happens is that it runs until it hits blocking IO. And what blocking is is when you're trying to read and whatever you're trying to read isn't ready to be read. So for example if you're trying to read off of a socket, that's blocking IO. So if you have one thread and you're not doing any sort of event driven stuff, when you hit blocking the program just hangs and waits until it can read. So with G event though when it hits blocking it jumps to that next coroutine and then execution picks up there. And then as soon as that coroutine or that function hits blocking IO it jumps to the next one and then to the next one as it hits this blocking. And what you wind up with is what's called an event loop where you have something that seems a lot like threading but you're not actually doing threads. And you don't have a lot of the overhead that you have with threading but it's functionally like threading. And this is different also than a lot of the other event driven stuff. This is not callback based. This is coroutine based which makes it a lot more accessible to those of you who've worked with threading before. And what you can do though is because you have this ability to jump to the next coroutine when you hit blocking, you can have hundreds of outstanding requests. So you can make an HTTP request and then when you're waiting for the response, you're not sitting there waiting, you're executing code in the next coroutine. So this is what allows you to have a lot of shit going on at the same time. And we get a lot of performance out of that. So then the other thing that GRequest does is it combines G event with requests. Request is a really, really cool library. They call themselves HTTP for humans. This was designed by Kenneth Wright. He's a really awesome API designer. He's written a lot of cool stuff. He's a great developer. I've had fun trying to contribute to this library. It's really, really nice. For those of you who are Python people and who've worked with URLib2, I really, really, really hate URLib2. It sucks to use. I'm sorry if whoever wrote that is here. I really doubt that they are. But I don't like talking crap about other people's stuff. But I hate URLib2. This really is request, HTTP for humans. It makes your life way easier if you're ever doing anything like this tool. So yeah, when you combine G event and request library, you wind up with G requests. So you're able to do good evented HTTP in Python. Which is a pretty cool thing to be able to do without much work. The other main thing that we're doing for performance is we're using different search algorithms. So when we're talking about how we're grabbing that substring and we're grabbing the first character of the user name and we're getting the ASCII value of that, what you intuitively might want to do is you want to check that value against each possible ASCII value. So this is what's called the linear search. It takes a long time. Here's kind of an example, hopefully that makes sense if it doesn't, I'm sorry. You're going one at a time until you find the right answer. So you're saying is the first letter of the user name, is it an A, is it a B, is it a C? Until you find whatever it is. The average case with this is N over 2. Best case is 1. Worst case is N. For those of you, I guess people who know what that means probably already know that. So the typical thing that you'll see with the SQL injection tool is what's called the binary search. Here you're still looking for that value. You're trying to figure out what the first letter of the user name is in the example that we've been using. But instead of going one by one, you take the whole space of possible values, you chop it in half, you say is it in this half or is it in this half? That's why we're using this greater than, less than symbols in the blind SQL syntax. And then you keep going down and down and down, cutting it in half and half and half until you find the value. And the performance of this average case is O log N, which is a significant improvement over a linear search. And that's by default what barbecue SQL is using. The other thing that we were playing with and it can be beneficial in some instances is to do frequency based search. I know some other tools have done this before. I decided to try it myself. It's fun. So what I did is I analyzed thousands of open source books for the character frequency. And what I found, which isn't surprising for anyone who's done any cryptography, is that the most common character in all of these books was the space character followed by E, followed by T, followed by O, followed by A. So here, when I was talking about the linear search where we're checking against one character at a time saying is the first character A, is it B, is it C, is it D? Here, instead of going A, B, C, D, we're going based on the likelihood that we're going to encounter that character. So we're going to start with E, T, O, A. And that's what's, that should be pretty familiar for anyone who's done any sort of cryptography. The other thing that I did to kind of enhance that a little bit is doing a diagram frequency analysis where we're not only looking at what's the most common character, we look at the last character we found and we say what's the most common character that's going to follow that. So the most common characters that are going to follow an E are an R or an N or a space. So instead of, and we try to factor that into the decision of what order we're doing when we're doing a linear search. So if you think about English, you know, if you see an L, you're probably going to see another L after that. That's the most common thing. So that's what we're talking about here. This is very, very effective against non-entropic data. So if you aren't looking at hashes, if you're looking at English, if you're looking at plain text, it's very good because there is that structure and that order and that well-defined frequency. So here with English, I was essentially dumping the books that I had previously used for generating the sample. About 10 requests per character. Python, which is a little bit more structured because it's a programming language, we see even better performance with eight requests per character. I think I was trying to dump the whole Django source code, which is kind of a lot, but I wound up getting eight requests per character, which is good. Credit card numbers, I got about 5.5, which is kind of funny because with a normal binary search, or excuse me, with a normal linear search, you'd expect to get five exactly, but somehow I managed to get 5.5. So not quite as good. Yeah, I kind of screwed that one up, I guess. Yeah, but when you compare it to a binary search with English, you get 12 requests per character, so you get a slight performance improvement. One other thing we kind of wanted to step through real quick was why don't you show the hooks that we're working on today? Oh, sorry, yeah. So yeah, before we were coming here, we were trying to think of, we added this functionality that we were kind of mentioned earlier that you can kind of hook into the request object to do really funky stuff when you're doing blind sequel injection. And one of the things that I came across on a recent assessment is that I needed to Hmax sign each request. And it was kind of a pain in the ass, and you know, you kind of imagine that like if you're trying to do an assessment and you have to do that, you're like, well, this is kind of frustrating when I have to whip up some Python proxy and do all this stuff. If you find blind sequel injection on that type of object, you can use the hook code that Ben will talk about here. Yeah, so like I was saying, we have these hooks so you can intercept each and every request right before it gets sent, or you can intercept the response right after it gets received. And what this allows you to do is it allows you to do funky things like Hmax signing parameters. So the way that you implement this, or the way that you use it with the tool, the way that you use it with the tool is that you create a file called BBQSQL underscore hooks dot PY in your current working directory. And if anyone can think of a better way of doing this, please let me know. It's hard to import in Python from arbitrary files like user defined files. If anyone knows a good solution for that, let me know. But so yeah, you have to make the BBQSQL underscore hooks dot PY. And then in here, you'll define your own functions. And for a request hook, you're going to have a function that accepts your request. And this object is from that requests library that I was talking about. And once again, if you haven't checked it out in your Python person, you should definitely check it out. So yeah, it's going to take the request object and then you can do whatever the hell you want to it. So if you want to grab the URL and you want to parse it, is what we're doing here. And then we're Hmax signing the query portion of the URL, grabbing the hex digest. Now I have an Hmax. You can put that back into the URL and then return the request. So now you just, you're Hmax signing every single request, which is pretty cool. Right, and we can do all sorts of things. Another hook file that we actually wrote was the quadruple URL encode. Now I've never come across that on an assessment, but sometimes you see double. Sometimes you see double if you're attacking an oracle database or something, right? So I don't think we have enough time to do the demo, so we'll just step back. Is that all for me? No. Okay. So I talked a little bit earlier, but the UI is basically built on the source for the social engineering toolkit. And I also mentioned that input validation is performed on each configuration option. This is really handy. At least we found it to be pretty handy because, you know, you're setting up these really complicated requests and things can get hairy pretty quickly, right? Especially if you're doing something weird. So by performing input validation on each of those objects within the UI, we can kind of help you or guide you along the way of you building out your complicated requests. Let's say you build out that really awesome complicated request and you're like, all right, well this was, you know, kind of a pain in the ass, I got it all built out. You can go ahead and export that to a configuration file. Reason to config parser library in Python. So it's really easy to work with. From there, you could kind of just go in, let's say you've built out this complicated request. You can kind of copy some of the configs and maybe all you're at this point just changing the query object, right? And as we also mentioned, you can also export the results as a CSV file. So in a nutshell, that's barbecue sequel. And you know, here's our credits and whatnot. We want to, once again, thanks Dave Kennedy for the social engineering toolkit stuff and being so kind, letting us use this awesome UI. And we thank you guys for coming and hearing about this new tool. And also, Neohapsis is hiring if you guys are in AppSec and want to talk to us. Come talk to us. We get a bonus if you come and work for us. And download the tool.