 All right, yeah, I'm Jason, Jason Haddix and this is JP, Swagnito. And today we're going to talk about a tool that we created, an extension for Burp Suite, really two tools called Hunt. So we weren't the only ones who did this. Our security operations group, Fati and Ryan and Vishal also helped us with some of the data polling and everything like that. Mostly we work for bug crowd that runs, crowdsource, pentests and assessments and responsible disclosure. But all of us are bug hunters and pentests and code analysis people. And we're also really big fans of Burp Suite. So we spend most of our time hacking web apps inside of Burp Suite all day. And so we wanted to create these two tools to kind of extend us and kind of the knowledge to people who are either new in application security assessment or are looking for a different type of coverage in application security assessment. So the three problems that we're trying to identify with the two tools that we made. So in applications are getting completely large, lots of parameters. And you don't know really where to start. If you have a large domain that maybe has like 150 dynamic parameters where you're supposed to fuzz with different fuzz strings, it can get unwieldy. And you don't want to rely all the way on something like a scanner, right? They don't have full coverage. They're just fuzzing things until they crap over or something like that. So we wanted something to alert us when there are potential issues, specifically parameters that might be vulnerable to certain classes of vulnerabilities. But it's for manual testing. It's not for automated testing. We also noticed that there is this lack of tribal knowledge for younger testers, right? So, you know, JP may have been doing this for 10 years and knows that just by the name of a parameter, it probably interacts with a database or a templating engine or something like that. And he knows to fuzz for certain vulnerabilities in that place. But me, if I were a new tester, I wouldn't know to look there unless I had his expertise. So we wanted to kind of level up the testers who were at that skill level and transfer that tribal knowledge. And then we also noticed that there's no in-tool workflow for web hacking methodologies inside of BIRT, right? If you do web hacking and you want to record a large amount of data, you have to do it in a third-party tool. You can do it in BIRT notes, but it's kind of unwieldy. There just wasn't something that fit kind of what we were looking for inside of BIRT. So the current kind of solutions for to effectively find security bugs in web applications is, you know, you have a bad-ass hacker who can kind of eyeball parameters that are input places that, you know, where are vulnerable. So they can find security bugs, they may or may not use a methodology. They definitely have accrued some tribal knowledge of vulnerabilities. And you can do this as a bug hunter or consultant or something like that. There's also the solution of a dynamic scanner, which just throws limited test cases at parameters hoping that either an error occurs or a response occurs that it parses and recognizes that there's a vulnerability there. But those are cost-prohibited because a lot of those good scanners cost a lot of money. They're limited in their detection cases. They don't handle dynamic pages very well. They don't handle non-generic errors very well. And they don't handle authentication very well in most cases. So we wanted to be able to give people a way to manually test but know where to manually test and have some data behind it. So we built this into a hunt. So it's a tribal knowledge passive alerts. You get alerts when it sees parameters that are most often vulnerable to certain things. You get methodology inside of BIRT. And you also get a whole bunch of references that we added. So the BIRT advisories are really their write-ups on the vulnerabilities. But the best methods and the best stuff usually come from blogs like the cheat sheets that like Pentes Monkey has and, you know, for SQL injection and stuff like that. Or just, you know, members of the community. We found that we weren't using, you know, certain references inside the tool. We wanted to bring them inside the tool so that when you're training up a new application assessment person, they have all those links and resources right inside the tool. And they can get, you know, started as fast as they can, you know, manually testing some of these vulnerability classes. Okay. So the first tool is scanner, hunt scanner. So before we launch into what it looks like, you have to know kind of how we gather the data to make the alerts. So we, we are bug crowd. We do a lot of bug bounties over 600 run right now. And so basically this is just some fuzzy math. But programs that we have, if you times those by two targets, we average two targets per application. And these are usually targets are either subdomains or fully qualified top level domains. So like www.deathcon.org, forums.deathcon.org. Anything that really gives you different application functionality is going to be a target. And then we averaged about, every one of those places had about 15 dynamic parameters, unique parameters per application. So about 18,000 parameters seen over the kind of data set that we were looking at. So what we did with 18,000 parameters is reduce them to parameters with phones on them. Which was mostly all of them. And then we reduced it again to things that had P1 and P2 vulnerabilities on them. Which are high and critical level vulnerabilities. These are things that let you read the file system. They let you execute arbitrary code. They are a configuration vulnerability that allows you to see credit cards of other people. These are those type of bugs. So we reduced it to those bugs. And then we started sorting it for reoccurring instances. And this is really, you know, fuzzy data science. But it, it works. So then we include the top five to ten reoccurring instances of parameters to start alerting you when they fall through your Burke traffic. And then we actually review the top hundred possible permutations with some of these. And then we manually added some like Ansler data. So the FuzzDB project, SECLIS, and just some parameters that our buddies who worked at PEN test consultancies were like, I see this all the time with this VOM. So we added some stuff to this data set as well. So just, you know, a quick refresher for, you know, what we're talking about here. This is an example of a parameter in orange here, right? So this is where after the equal sign you're going to fuzz for, in this case, probably SECL injection. The ID parameter most often is associated with the database. So this is kind of what this talk is about is, is getting to this, right? When you see ID equals one, you put in tips, right? So this is the essence of scanner. All right. So this is what scanner looks like. So this is a totally separate tab. We didn't want to pollute. You're already made BERT instance. We didn't want to pollute the advisories of BERT scanner or anything like that. So we made a completely different tab. And we started with, I think, seven or eight classes of vulnerabilities that were P1 worthy. So here you can see on the left-hand side, we've funneled some traffic through BERT. And it's already started to alert us on common parameters that are vulnerable to server-side request forgery on the left. So here you can see the requests end up inside of a sub-tree on the left. You can see the kind of parameters we're talking about here. Destination, DER, URI, PATH, continue, et cetera, et cetera. These are all things that you're going to want to fuzz for server-side request forgery, probably URL redirection, things like that. So you'll have the request and the response and you'll also have an advisory that will go over in a second. So here's the advisory. You can see here that we added just some general stuff. But this is all customizable. You'll be able to customize yourself with your own built-in methodologies inside of BERT. It's very editable. So if you have a team and you have a resource list or a cheat sheet of some sort to do these things, you can add them now inside of BERT in your own advisories. So you have the location. And then for this one, obviously the SSRF Bible for this class of vulnerability is probably one of the best resources you can look at for SSRF. And there's a couple of other resources that we think are worthy to manually test vulnerabilities against a class of vulnerability like this. All right. So we're going to talk a little bit about the data that showed up when we parsed all of that stuff. So this is a sampling of the SQL injection data that we pulled out, right? And so if you look at this table, these are all the parameters that normally had critical SQL injection on them. So if you take nothing else from this talk, if you hate the extension, you probably use the data in some way and you're testing. So ID, update, sort, process, which you'll notice when you start reading these things is they're all related to database stuff. A new tester might not know that some of these things are related to databases and they might not know to test there. Custom headers showed up time and time again. JSON and XML web services, we can alert on types. But really we're mostly alerting on regexes of certain parameter names here. So column, code, field, et cetera. So this is the data for file traversal and directory traversal. So things like file, folder, root, style, load, location. This is where you're going to try to change paths or include files that aren't yours or cause some kind of error in that way or vulnerability. This was actually out of the bug crowd data this year. This was the highest critical vulnerability that we found over and over again. So server side request forgery that allowed local file reads. So this is this parameter set and we also found that it crossed over a lot with the file includes in the directory traversal parameters. So we actually alert on both data sets for this bug. A lot of money has been made off of SRF this year. OS command injection, a smaller list, but things like daemon, execute, upload, download, dirlog, things that are related to command line, stuff on Linux usually. The insecure direct object reference, things that are related to kind of the state of a user traversing an application, ID, account, order, dock, email, et cetera. And then this is server side template injection and debug parameters. I didn't make a nice table for the right hand one. So server side template injection, obviously template, preview, ID view, name. I would verify with this bug that you're actually targeting a template engine before you buzz for these, but still useful to have. And then the right hand side there, the JSON scheme is actually what this looks like and I'll show in a second how you go ahead and edit and add your own parameters. But that's the list for debug parameters that indicate things like logic vulnerabilities or special admin parameters that let you do special functions and things like that. So access, admin, debug, edit, grant, test, alter, clone, et cetera. So these are all language things that relate to vulnerabilities. So the implementation of the Burp Suite kind of API we used is I scanner check and I scanner issue. It makes a new tab. If you want to edit or make a second tab for alerts or anything like this, it's really just like one block of code. We've provided that pretty easily editable here. If you've ever made a Burp extension, it's in Python, so easily extendable. And then we'll do a quick demo. All right. So here we have Tesla.com, which is a bug crowd customer and they have a bounty. And so I've hooked them up to Burp. And on the left hand side, traffic has started flowing from Tesla.com through Burp. So the first thing that you want to do with this is make sure to set your scope, but I've already done that. And you can see here on the left hand side, traffic has already started to go through, especially for Tesla.com, which is what's going through right now. Now if I go to hunt scanner up here in the right and I collapse these, you can see that it's already starting to tell me that there's some places I should look manually for these vulnerabilities. So here I can see things associated to SQL injection, things associated to debug and logic, server side request, forgery, et cetera. So we'll go here. You can click here. Now you get this instance. So this domain had the page parameter on it. You can see the advisory for server side template injection, the request here, the response here. And then let's say you check this manually and it's not vulnerable to anything. You can actually remove it from the list by just checking it off and clicking up here. So it allows you to remove the stuff that you've already tested. So that's just a quick overview of hunt scanner and how hunt scanner works. Let me go back to slides. So the next tool is the GUI and the methodology part of it. All right. So we're talking about the GUI methodology. So I'm sure a lot of you guys are pen testers, vulnerability assessors. And when you're doing your testing, you're actually going to be doing, you know, going by a methodology. Unless you're some kind of, you know, yellow swag god hacker, you're going to be going by a methodology. And you'll be using things like, you know, the OASP testing guide, the web application hackers handbook, or you might even go by standards like HIPAA or PCI. So that's what I'm talking about when I'm talking about methodologies. For those of you who aren't professional pen testers or vulnerability assessors, why would you want to use a methodology? Because this is what you would need to prove that you did the work. So kind of like in, you know, second grade math, they want you to show the work. This is how you would do it. And we actually put that into Burp Suite so that it's easy to get, you know, your request and response pairs within there. And then when you're going to generate your report, it's already in there. So you don't have to go through the hassle of copy and pasting and all that nonsense, right? So the first thing that we're going to talk about here in terms of the GUI is that you can have a, there's a right click send to methodology section. So from anywhere in Burp where you have a request and response pair, you can actually just do a right click and you can see there's a line there that says send to hunt methodology. And then it has the sub folders and folders where you can actually put that particular request and response pair after you've actually done your testing to show that you've done the work and proved that, you know, there is a vulnerability there or, you know, if you have your POC in there, that's where you'll put it. So this is what it looks like in Burp as far as the methodology window. So you'll notice a few things here on the left hand bar. You'll see that there's a file tree there. So essentially it's the methodology that you're going to be using. And then we break it down by functionality. And for this one, this is the actual default kind of JSON file that we have included within hunt. And it breaks it down by areas of the application that you generally are testing for vulnerabilities. Things like the account, the account registration, money transactions, authentication, search, contact us. Those are usually the places where you're going to be testing for vulnerabilities and where you'll definitely find vulnerabilities of certain types. So for example, on the account page, you're going to be testing things like IDOR or cross-site request forgery, authentication bypass and stuff like that. So this is how I have it laid out. But if you have your own methodology, you can also just do it yourself. And it's a simple JSON file and we'll get to that in a second. And you can, you know, put in your own methodology. Everyone has a different methodology that they follow. But the important thing here is that we wanted to make it easy for the pentester to be able to actually put that methodology in Burp so that they're going through it and they're efficient at doing their work. So here you can see that there's a description. So not just for the seasoned pentester, but again, we wanted to address that tribal knowledge aspect. So if you have newer members on your team who aren't seasoned or, you know, aren't used to doing web hacking for particular testing here. So let's say, you know, for authentication bypass, I don't know, I don't know what the hell that means. I would see here on description that, okay, I would do this check for this particular type of vulnerability. The next tab here is called BUDS. So we do multiple requests and response tracking. So you might have multiple requests and responses for a particular vulnerability and they might be different attack vectors. So you can keep track of all of that here. And then when you go generate your report, boom, you already have all of your work in there, no copy and pasting. That's disgusting. Next thing here, the resources. So again, just like on the scanner window, we're going to have the resources for you. So again, you could put all of the resources here, SQL injection for example, you're going to use like pentest monkey, stuff like that, or you might even put in, you know, how to use SQL map on there, stuff like that. And then the note section. So we also have a note section here. So, you know, when you're doing your work, you might, you might go off and, you know, start doing SQL injection. You're not, you're not finding it or, you know, you have the error but you can't get a proper POC for it. And you want to, you want to work on it later. So you can leave notes for yourself, you know, try to break it manually. If I can't do that, then use SQL map. And then if all else fails, I'll send it to Bob or I'll send it to Jason because I suck at SQL injection. So the next thing here is that with the notes, you can send your actual JSON file to other people and they can load it up in their, in their burp instance, or you can even, you know, you could save it and then have it for your report. So just like in that instance with notes, if, you know, I want Jason, for example, to check my work for my methodology. It's like my first week on the job and I want to make sure that I'm doing it right. He can go ahead and look at it in his own instance and burp and it'll, it'll have all of the request and responses and he can do, he could check that. If, you know, I need help with SQL injection from someone on my team who is much better at, at SQL injection than I am, they can go ahead and do that, get the POC and then send it back to me and then I can keep doing my work. And this is the, um, implementation, uh, within, within burp itself. So we used iExtensionStateListener, iContext, um, menuFactory and itab and then that makes the burp tab, uh, hunt methodology. So, um, if you were to edit this and then, um, you know, add your own stuff here, uh, all you need to do is open up the code and then go into the create menus function and then mess around there. And then we'll do a live demo. So let's say, you know, so we're using, uh, the hunt scanner and the hunt methodology in conjunction, right? So, uh, let's say I send one of these to repeater so you can actually, um, you know, send all of these requests and responses from scanner to things like repeater and intruder and then you can continue your work there. So let's say I send it to repeater and I have one set up here. So I do, I do my hacking on here, I do my manual, uh, test and then I find that it is, uh, vulnerable. Let's see, this one. Um, and you know, it's there. I want to send it to my methodology now because I'm done and I want to prove my work. So, um, right click here, send to hunt methodology. Let's say I was testing for idore. I'll put it right here. When I go into the methodology, I'll go into functionality and account and then it's in, it's within the bug. So I, I can also, you know, just close it if, um, I don't want, I don't want it in there. So that's the typical workflow for, um, getting stuff in scanner and then doing the testing in repeater and intruder, sending that all into, uh, the hunt methodology. Now let's talk about the actual plugin installation. So, um, as we were talking about before, this is, this plugin lives within Burp Suite. So kind of the installation is that, uh, you know, we're using Jython. So the actual, uh, code is written in Python and then we use Jython to be able to use it within Burp because it's, it's using the JVM. So what you would do is, here in this, uh, Python environment, uh, you would go on the Jython website, uh, get the latest standalone jar and you would actually put it in here so that when, uh, Burp loads up the, uh, plugin, it'll, it'll go in there. Next is the actual installation of the plugin itself. So you would go into the extender tab and you would add it as a Burp extension. Uh, you'll notice here that there's an extension type. I set it to Python and then I set it to the actual extension itself. So then, uh, wherever that's living, select it and then you're off and ready to go. But more of the setup of actually using, um, hunt. So, uh, those of you who have used, uh, Burp a lot know that, um, the passive scanner can be, uh, pretty noisy. So depending on how you have your scope setup, you definitely want to do that. So you can see here, um, like with the example Jason gave earlier with Tesla, you would add the, in the target window, add scope, add Tesla here and it will only get Tesla, um, host names, uh, that match. After that, you would go into scanner and then you would, uh, select, uh, use sweet scope on the live passive scanner. So the scanner actually uses the passive scanner but none of that information will show up on, on the actual passive scanner window. It'll be in, within hunt. And, uh, kind of the effective way that we, we've seen, uh, this use and how we use it ourselves is that within the target window itself, you would go in there, um, click, uh, actually spider all of those items so you can get a lot of coverage for all the things that you need to test. And once that's all done, click passively scan selected items and all of that will end up in the, um, the scanner window. Cool. So another thing that we wanted to make sure, uh, was that it was easily extensible. So, um, so both, uh, methodology and, um, scanner, uh, can easily be extended to accommodate something like a new CVE that comes out tomorrow. Maybe BIRP doesn't have a check for or a specific vulnerability, um, that maybe you guys see in your environment but wasn't in our dataset. Um, so the scanner extensibility is just a JSON file. It's called issues.json. Um, and so, uh, you define, uh, something in this kind of schema with, uh, here you can see OS command injection is the one listed. Uh, and then all you have to do to add a new parameter alert is just add something at the bottom here. Here you can see under, uh, download I've added sexy param. Um, so this will now alert in the hunt window. Methodology is very much the same. JSON file. Um, you can set the top level pieces of the methodology, um, in this schema, um, this array and, uh, you can set, uh, text about it. Uh, you can set notes that automatically pop up with it. Resources, bugs. You can load them automatically, um, by filling out this JSON schema as well. So we'll go ahead and add something really quick. So I have the issues JSON file open, um, for my loaded, uh, hunt scanner. Um, at the top, the first one is insecure direct object reference and I'm just going to add, uh, custom parameter here. So, uh, I'll add beef cake. Alright, so I've added beef cake to, uh, the list and I will just save that. And now we will reload, um, hunt scanner. So you do that through extender, uncheck scanner, recheck scanner. Now I'll go to our site and we're proxied still. And here we will change this to, hopefully this works. So this obviously doesn't exist, uh, but it's still going to trigger the scanner. Hopefully. Alright. Uh, so let's go to scanner. I think that was an I door, right? Yeah, there's beef cake and there's our request and response. And now we could send this to either methodology or repeater to continue testing. So really easy to extend, um, both the, uh, the methodology and the issues in this. There's also the checklist and, um, we included two methodologies with this. So if you go into the default one, it's checklist.json. And here you can see this is kind of the schema. I'm not going to type up a whole new one, but, uh, pretty easily just to copy and paste one of these blocks here, uh, and create new methodology steps for your testers if should it apply to your work if you do something different or, uh, you don't like the methodologies that are included. So, cool. Um, so stuff we want to do that we haven't done yet. Um, so, uh, we want more methodology. So we included in this one, we included, um, the application functionality map, uh, that we tested and then we also included the web application hackers handbook methodology in the back of the book. Um, so these are things that we want to kind of improve on. This is all on github. We're looking for people to help with this stuff. Um, so PCI, HIPAA, Crest, OWAS, P-TES all have, uh, methodologies or reference each other for methodologies that are kind of modified. Um, so we would like to port these into that JSON schema so we can support, uh, using methodology for those. Um, we like BERT, but a lot of people like ZAP. So we could probably port this to ZAP at some point in the future. Um, more scanner vulnerability checks in classes with data sets from, not just us, uh, from other people. Um, more resources, uh, more testing resources for new people getting into application assessment. So cheat sheets, uh, guides on exploitation, good ones, um, internal methodologies for testing certain, uh, vulnerability classes, et cetera. Um, dynamic JSON structure source. So now in the methodology you can only have two nested methodology pieces. Um, and you have to support the rest via notes and tabs. Um, it's just something that we haven't been able to get around right now so we want to figure out that problem. Uh, the GUI is, uh, not up to par. We would like to make that better. Right now it only supports, um, uh, param equals value scanning. So we would like to support REST scanning at some point as well. Um, so REST URL support. Um, and then there was, you notice when we did the right click you only saw intruder and repeater. We'd like to include, um, some of the other full BERT helpers like, uh, the rest of the right click menu that you get in targets, uh, searching and highlighting, et cetera. But those APIs are a little harder to bake into a custom tab window. Um, we'd like to be able to, um, do some file name analysis instead of just parameters but we don't have data on that yet. We can parse it soon. Um, so instead of parameters like, uh, resource name or script name or something like that, uh, most vulnerable classes there. And then alert on content types, et cetera. So there's still a lot of work to be done here. Um, but, uh, but yeah, that's pretty good. And then, um, responses on errors. So, yeah. So that's, uh, that's the gist of the tool.