Occupy Burp Suite: Informing the 99% of What the 1%'ers Are Knowingly Taking Advantage of

Are we good? That's all right. I can do that. All right. So, this is our uh Besides Las Vegas talk on Burp. Hey, they're talking. Listen up. This is a big actual thing. And if you're not a [ __ ] speaker, not you should be quiet. All

right. So the uh title is occupy burp suite and kind of what we're meaning with that is we feel that there's a lot of users out there using burpswuite to test web applications and there's really not a lot of uh you know you go Google extensions or tips or what people are doing with it and there's really not a lot of information sharing out there. So, uh, I guess the whole theme of the talk is, yeah, a lot of us are using it. Not very many of us are kind of, uh, sharing what we're doing with it and, uh, hopefully we can kind of get people to motivate and, uh, help out. So, I am James Leser. I'm a consultant

at IO. Uh, I'm also on Twitter, infidel. And this is I'm Joseph Tartaro. I'm also a consultant at Ioactive. You can follow me on Twitter at juggi1xp. Um, I'm also part of the Telerofreak group at telreak.org and rc2600.net uh pound telreak if you're interested in any of that technology and freaking in general. All right, so I'm not really going to get a lot into burpuite. I'm sure you know if you're here a lot of you know what it is. It's a a tool for testing web applications. It follows kind of the basic uh intercepting proxy model of being able to intercept your requests and responses and allow you to view modify uh etc of the application. Um it

kind of offer you know for the most part it's getting to where it's starting to offer about everything you need to test uh basic web application functionality. Um, you know, you have proxy, target, uh, repeater, um, things like that. And, uh, also with, uh, you know, you have some pretty nifty automation tools that kind of help you get your task done. Spidering, obviously scanning can be very beneficial. Um, payload testing with intruder, uh, I would kind of call automated, even though it's a fairly manual, uh, process to set it up. Uh, everything, you know, is fairly, for the most part, beneficial to the everyday tester. So what happens when you're using Burpuite and you start testing uh web

applications that you start realizing that there are some limitations that are preventing you uh to perform your test. Um you know what are your options currently as of now? Uh these are kind of some I jotted down. one is you go run to another application and use it uh that probably will conduct the functionality you're looking for um or some way to uh to get around it. Uh you can also kind of use a tool and chain it through burp proxy to have it you know through the intercept so that it's all intercepted and in your target window and then you can still use burp uh pro to kind of uh review your responses and do any other

type of work with repeater etc after you have all that information populated. um you can use native functionality as a workaround, right? So it might not have been its intended use for development. Uh but after you start messing around with the tools, you're like, "Okay, wait a minute. If I set this setting off and then, you know, I enable this and cookie jar and I'll I'll set this macro uh you you know, you can start with chaining of a lot of the functionality. You can start kind of making a temporary workaround for your solution. And if none of those work, uh you basically start to extend the application. Uh of course, if it's applicable,

so extending Burp. So I'm going to talk a little bit about yeah writing extensions for Burp. I mean, generally when I talk to people about uh the process that they went through and um the entire situation, it usually comes down to there was functionality that they needed to do for either a custom web app or or anything along those lines and they wanted to add that to Burp and go ahead and write an extension and they had to go ahead and uh you do it in Java. You have like one Burp extender file and it worked great and they said, "Hey, we can go ahead and intercept with this. We can add functionality. we can go ahead and test

better and I'm going to go ahead and add something else. So they go ahead and hardcode some more tools in there and then they hard code some more and then you basically are stuck with a mess. It's a very sloppy file. You can't really hand it out to people. If somebody's already using their own extension, they can't really import you their or yours. They have to basically take your code, try to get to work with their code, and there's really no way to share it upon each other. And if you go on like Google and you find an extension that somebody already wrote, you're basically stuck using just their extension. And if you want to use

somebody else's, you have to go ahead and kill theirs and use the second one. Uh but not at the same time. So I guess we'll just go to limitations. Uh so limitations like I said uh if you have multiple extensions in that one file they're all printing to like the same console tab or the alert and it becomes a mess especially if you're doing something that takes user input you just you can't deal with it because if it's scrolling and and printing output the user's just going to get lost. um developing in Java obviously can take time especially for people who aren't used to it and a lot of the situations when we're writing extensions

we're out on the job we're uh with a client or anything and we need to get it going we need to get something up and running for this custom web app so obviously a scripting language uh would be better and uh there can only be one final outbound extension so when you go ahead and hardcode all these whenever it's making a request there's just that one final thing that processes it and you have no control over that and then um also you're limited to what Daft and Portsburgger give you access to. So they give you access to maybe spidering and adding stuff to scope but if they don't give you access to something like comparer you can't go

ahead and compare content links and look for a difference or encoder decoder or sequencer you're just stuck without that because they didn't give you access.

You want to talk about this one? Yeah. All right. So, with that being said, uh we decided to kind of start creating our own little framework here. And what we wanted to do was kind of sit down and kind of look at what we want to get as far as our objectives and making our lives a little bit easier with extending burp and using extensions within our testing uh methodology. So uh one of the first things we want to do is obviously simplify having multiple extensions running uh that involves some console and alert printing organization uh control over this final outbound processing you want to make sure uh like let's say for instance if you have a

bunch of tools uh that are modifying post data uh and you don't have the functionality built in to check that final content link to make sure it's accurate before it pushes out. You could you could have an extension uh sitting you know and it needs to be the last uh extension called or uh if you make any modifications to the request again that uh content link that it generated will not be accurate or could potentially not be accurate. So you do need to make sure that you have control over what extensions are running uh for the final outbound uh before they're actually pushed out on the wire. And then we also want to make sure that we can kind of uh

introduce some like individual extension configuration, right? Uh some extensions might need you to set values uh so that it can use um you know for what you're looking for. Do you really want to go into your code and change those values or can we actually supply you with an input uh that allows you to modify it within the application itself? Uh we also wanted to possibly le leverage scriptability. Uh right now there are two current methods that a lot of people are using to get some scriptability out of burp suite and then it's and its extensions. Uh one of them being uh using Ruby and the other one leveraging Python. Uh and then finally we want to have

control of input output. What are you supplying to your extension for input? Uh where's that output going? uh and basically help you uh have a little bit more control without having to go into your code and you know manually making those uh adjustments. So we built a framework uh one of the first things we did was we wanted to to you utilize Jython. Uh Jython is a uh Python for Java platform. uh you can basically look at it as like a gateway uh to communicate with Java through uh Python code. Um we also uh made it so it will dynamically find and load extensions on startup. This kind of creates a drag and drop scenario. you

know, you create your extension, you put it in a directory, you just go uh start Burp with extensions, and it's going to dynamically go out there, find it, and load it uh to kind of prevent some of that overhead and get your scripts or extensions up and running as quickly as possible. Uh we provided a guey interface, right? This was our method of trying to manage extensions. So instead of having everything print to a console log or uh the alert tab uh or out to a file, we have a guey interface that you can utilize that individualizes extensions allowing you to print to each individual extensions print tab or whatever uh custom uh guey interface you want to

provide with that extension. Uh last um we want to or I'm sorry not last here we want to provide a method for tracking and chaining of those final outbound extensions. So we want not only do you do we want that final extension but if you do want to chain them and you're careful with chaining we want to give you the ability to do so and we want to give this ability on a per tool basis. Uh and finally uh we want to reduce appending additional core code in the libraries right so when you write an extension you don't want to go back in your core code and you know start putting the uh instructions on how to

call it and load it. We want all that self-contained within the extension that the dynamic loader goes and grabs and that way you're not constantly appending these core library files. So uh basically to kind of give you an idea of how our extension is running is at least starts is on startup burp suite is going to start and one of the first thing that burp suite does when it starts is it calls the register uh extended callbacks method uh provided by the extensibility and what we did within this um uh register extender callbacks or at least one of the first things we did was we want to go out and dynamically load and find extensions. So

it's going to call our find extensions functionality which will go through um the file directory structure and actually find extensions withpy uh that have a class uh of subclass extensions so that you can actually identify that the file itself is an extension and dynamically load them and create an instance of the object uh and pass it back to burbick center or the register center callbacks. Then the next thing that's going to do is actually make a call out to our guey where it builds the body for the guey passing it all instances of uh extensions found and it's going to load um at least get it prepared or set up to load and it's going to pass all that information back

with the built guey body uh to Burp Excender and then last Burp Extender is going to make a call out to each individual extension where you would have your final code running. This is where you can add individual tabs within the guey. Uh you you know you can put uh information as far as who what the author is, what it does so that they can actually see it built up. Uh and then you can perform any type of functionality you would like um with the app whether it be a menu item clicked or uh or a request response instance. And that's basically it. It's fairly simple. We wanted to make it simple so that it was uh easily able to

adapt. Um you have a question. How much overhead does that? It's actually not much. Right. So you have you obviously have a guey built. It's built with swing. Um so we're just interacting back with Java uh through the Jython library. Um the find extensions is ran once and dropped. And the nice thing about it is that it basically builds uh an instance of each individual individual extension and keeps them loaded so that you're not sitting there rebuilding and rebuilding. So it's all self-contained. Everything back in Burp Extender every everything is in sync with the parent and then when you pass it to any other tool, it's going to have all that information. So it knows what tool tab to print to or at

least each extension knows and everything. So, as far as the overhead, um, it can actually be a little bit easier. Uh, and if we want, yeah, if you want to try and explain in detail. Well, I mean, basically, like you said, when it starts up, it's going to start every instance and it's going to associate each extension with a specific tool and store in a dictionary. So, all that's going to happen at startup and it's just going to be sitting there. And then when the guey goes ahead and loads, it's going to go through the um dictionary. And as you click on specific list items or tabs, it's going to basically pull the correct one out. So

it's not going to be like running as you click. It's all going to be right as load. And the nicest thing is it's all done at startup. So when you actually have requests and responses being performed or you're performing tasks, all this stuff is already built and stored uh and ready for you to call it. So kind of with that being said, after we kind of showed you a little flow, uh we'd like to show you some demos. Um, we know that there's going to be a lot of doubt with people where they're saying, "Hey, you know, not only now are we learning extensions, but we also have to kind of learn your framework and how to

utilize it." And, you know, that can be kind of a bit much. Uh, you know, why not simplify things and just do extensions. And what we want to try and show is that this is just about I mean, it is as simple if not more simple to write an extension using this method with the drag and drop and everything because all that core functionality is already built in. So, we're going to try and create a uh skeleton ext uh sample extension for you within a couple minutes. Uh load it into the directory, load it up in Burp and start it. So, you can actually just see that we you know what three four lines of code we add uh

to a basic skeleton that we provide. Um you can actually be up and running with a menu click item extension uh within Burp. And after that uh we'll try and pre uh give you like little previews of some extensions that we have already uh written. Should I do the demo first or I think I'll just go ahead and do the demo first instead of the actual development of the example extension. So let me go ahead and uh start this up and uh we'll supply just a bash script or batch script depending on if you want to do this on like a Unix uh OSX or Windows or whichever. But um this is our uh new

guey window that basically starts up with Burp at the beginning. And as you can see the list of extensions are on the side that we loaded up and you can basically choose which ones you want to do. They have their own guey um tabs and features that you can basically implement in your own code. So um the first thing that basically will always be on top is the uh process request extension. And this one handles all those out outbound um requests that we were talking about that were basically a pain. So you can basically choose what tool you want to use. Let's say repeater. You hit the plus sign and add which extension you want. So we'll

do our add a parameter test and then maybe gzip it right when it's done. And then now any request through repeater, it's going to go ahead and run that code. And if I decided I don't want that add parameter one anymore, I just remove it. And then the add parameter one. Right now there aren't any options, but if you wanted to, you could basically add code to add tabs and add any functionality and it would just basically update it live throughout the request. So let me go ahead and uh add something to our scope.

And if you haven't used Burp, basically the request was just intercepted by the prox by the proxy. So, I'm going to go ahead and uh add that to scope so I can start playing with it. And uh it's going to be right here. And as an example, uh extension, you can go go ahead and add like new buttons if you want to add a rightclick menu. So, we'll just go ahead and do a Google site index. And the reason we added this is because it's something simple, basic. It shows somebody how to use the framework. And it's also something that's useful. Uh, currently if you spider something, it would just go ahead and obviously touch

anything that was linked on the internal pages and crawl through it. But what about stuff that wasn't linked that Google knows about and Google found that you don't have to actually manually add anymore. So, as you can see, all the requests are going and populating. And then we can go here and it's basically telling us what it found and what it's adding. And anything that is not in scope, it will alert you and let you know. So you can just decide from then on if you want to go ahead and add that to scope and it will import it or or what you want to do. But the whole idea currently is the extensions will never do anything that

is not in your scope. You can quickly modify that but we didn't want to hand a framework to somebody and they go to a client start using Burp and their burp's following scope but all all the extensions that we gave them are just like hitting everything like we just didn't want you guys to run into that situation. So, as another example, um we'll go ahead and go over this uh drive by uh SQL uh tester that we basically wrote, which the whole idea was I don't know if uh you've ever been in a situation as a consultant where a company came to you and they're like, "Hey, we've been hit. We have in our database all these uh

specific strings or whatever, and uh here's our logs." and there's about 20,000 requests and you have no idea which one got through because they're all the same payloads on the same parameters and you just don't know. So this idea is that you know you go ahead and you find like you know say like a blind SQL injection on a client you're like oh hey here it is proof of concept and then they go okay we fixed it you go and check and it's like no you didn't fix it all you did was sanitize the words wait for you know you didn't actually fix anything. Um, so the whole idea is that you can include a bunch of

intrusive payloads and it will just hammer it and it will keep track of uh basically what requests are being made and logging it. So I'm just going to go ahead and make a a fake request with uh parameters real quick.

So, I'm just going to make a test me and a uh a test, right? And we'll go ahead and send those over. And now I can go ahead and run uh drive by SQLite test. And as you can see, it's printing out the requests that it made and which ones uh which parameters it modified. and it keeps a account in reality and it basically logs it to the directory too with the current date. So when the client comes back and they're like hey we saw ioactive 667 in our database we can see which exact parameter uh basically got through and which one wasn't sanitized on there. Yeah. So as you can see let's see uh

test 1 2 3 4 SQL payload. We didn't really give you guys real payloads. You guys can populate those yourself. But yeah, they're right there. Um, I guess another thing would be like this uh payload encoder. And obviously Burp already has uh it's an encoder and parser. Burp already has an encoder. So I didn't really have anything to add to it uh except for like double URL encode. Um so a quick example like whatever it's more of ease for when you're doing the parsing so you can just quickly grab it and encode it. So the parser is basically for if you're in a situation you're been hitting these parameters and you're like I'm trying to

get this thing to pop and everything's going through but uh that damn semicolon is sanitized. I just can't get that semicolon through. You can basically just go ahead and hit semicolon enter. And these are all payloads that aren't using the semicolon. And you can populate that in our um directories where we'll have a payload. You can add any directories with the names of which payloads you want and any text files and it will crawl through and basically let you know what's there and and yeah dynamically update it which whatever you want. So anything that obviously saves time is going to be helpful. And a what's difficult about this is a lot of the extensions that we've written we

actually can't even share with you guys because uh one they've been for specific clients and two they're probably not going to be useful because they were for a custom web application that was doing something crazy weird. Um but that's the whole idea right where we're giving you stuff that might be useful but if you're in this weird situation where let's say do you want to explain that one that you ran into? Yeah. Yeah. So like a nice example right is um uh which cross tokens that one or that time. Okay. Yeah. So if you start um testing a lot of web services, you will see some pretty fascinating things with what they're doing to validate the request.

And um you know uh kind of an example of what some of people are doing are uh for a request you will take UTC time of the current request uh plus all the values in a parameter uh maybe match that with a a publicert and uh hash that up and B 64 it send it along with the header and server side that web service is going to basically produce the same thing. It sees what your UTC time is um within its header. Uh grabs all the values of the request that was sent in the header uh matches it with its C hashes it and B 64s it. So it basically checks to make sure that all your values are accurate

and it was sent within like 3 seconds of the time of that the request actually states with inside the uh the B 64 hash. So that's kind of a difficult thing to do um with uh you know native functionality and that's a a really good example of what you would be doing as an extension um you know providing uh valuable data to the client at least being able to properly test uh their web service. Um and we went ahead and included uh some example skeletons for you guys. There's like a simple skeleton that's going to go ahead and add rightclick menu or kind of like a little hello world. Um, and there's also an advanced

skeleton that will basically give you an idea of like using Jython and um, building a guey and it it should be pretty simple to basically look at it and and piece out the code that you want and and go from there and obviously looking at Java docs and and everything. So you guys should be able to go ahead and take this and run with it hopefully. That's the whole idea and everything's dynamically loaded. So, uh, Portzswer just started up a forum. And our goal is to hopefully people can just go ahead and be like, "Hey, I wrote an extension. Here's my quick Python file. You can open it up, look at it really quick. It's like 30 40 lines and just drag it

in your folder and it's going to work. You don't have to deal with any underlying framework code. You don't have to touch anything in a framework. Even if you want to write something, the only thing you have to touch is that small bit of extension code that you that you basically were working with. and communicating with the actual framework itself. You're dealing with like a couple lines uh for some API calls and that's that's really it. Everything else is just Python. So, if you're cool with Python, you're going to be good with this. So, I'm just going to go ahead and uh I guess make an example. You guys can watch and he can explain it

as I do it. But yeah, so we wanted to show you that, you know, how easily this can be done that it's not really a lot of work to get something into the guey working and printing at least to a guey tab. so that you uh you don't have it all cluttered within the console or uh alert functionality. So this is kind of the general skeleton uh that is all is required to get an extension up in uh the guey. You can see the first class how it's simple skeleton. It is using a subclass extension. That is what our um functionality that goes out and dynamically loads extensions for. or it's actually opening up each and every

file looking for this extension of subclass extension saying okay you must be an extension and it loads it up. So then you can go through and you know uh add any type of info of what uh the actual name is, what its usage is, you know, author. Uh feel free to leave my name in it if you want. Um uh but all the code that's basically run as far as getting the guey set up is done within this finish launching uh function that is originally it's that last functionality that's called on startup uh by the register extender callbacks method. you want to talk about register menu item click right so register menu item click is a

method that is been included uh within the burp uh extension APIs um so it's you can actually go view the documentation on you know what it's accepting uh and you know uh basically when it's performed but in the short it's performed anytime you actually click that menu item and it's going to uh p basically invoke uh the new class for the menu handler below. Sorry, I guess I modified. I just can't type and talk at the same time. So, currently right now there's uh just a print to log tab and that's in our extension file which is almost like a bridge between everything. So, even if you wanted to add something to the actual framework, which um if you want

to add a feature, sure, go for it. Just that's where you're going to modify it. And and currently, so the person just says print log tab, you click the simple example button, right? So, if I want to go ahead and take this a little bit further, but I have no idea what I'm doing because this is my first time loading it. I can go ahead and look at some of the other extensions that we have here. So, I'm just going to open up like this Google one for example, right? And I see, okay, when they click the item, it goes ahead and grabs the length of the message info and it checks the range and and it gets the URL. So, sure,

let's go ahead and grab that that piece of code. And I'll just go ahead and uh copy that in here. get rid of the stuff we're not using. And uh instead of calling this function that doesn't exist obviously because we're in the a different file, I'll just uh print to the log tab instead.

What's that? Uh rap. It's tab. Okay. So, we're going to go ahead and save that. Load this back up.

Make a couple of requests. So, we get something inside of Burp. Yeah. Yeah. So, basically, uh, what I told it to do was it's grabbing the message info, which is the request info, and I'm calling the get URL function. So that's just basically what I'm going to have it do is just print the URL to the log tab access which yeah you have complete access to the request and also the response which whatever you want to do. So I'm going to go ahead and just uh I'll just highlight all these and right click simple example menu item simple skeleton and it totally didn't work. Okay, so it wants a string. So basically, we'll just exit this,

wrap it in a string

and reload it. and everything uh I put inside of a try except because I don't know if any of you guys have done any burp development but in that alerts tab is where all the exceptions happen and it's a complete pain in the ass to actually see where the error happened and scrolling the window and and making it larger to actually read everything. So everything should just print straight to the console log if you have an error.

We'll see.

So, there we go. I didn't add new lines, but as you can see, it printed each URL there. So, I mean, that's basically like, as you can see, it's pretty simple to piece stuff together. Uh, I guess I could add a gooey really quick if you want to hold this mic just to show. Yeah sure. Uh, we just want to, you know, show you that we built a lot of functionality within our extensions. We try to come up with ideas. Okay, we're not utilizing this functionality yet. Can we build an extension for it? Right? Because we want to have examples where people can go in, look at them in Python and say, "Hey, okay, that's easy. I can kind of adapt

that uh with my own functionality. I see what they're doing with um the reports or with a request um or how they're handling just specific method calls. Um uh so we wanted to make sure that we had all that functionality kind of built within those extensions so that you can go go back look at them and review them. I'm just copying the guey from the So what he's going to what he's actually going to do is just take this and show you how easy it is to add another guey item to that uh sample extension. Just basically add like another tab or something like that where you can build it out. All that all the guey information per

extension is going to be self-contained in each extension so that you don't have to like I said go back in your libraries and start changing things. The gue is basically set up listening saying hey do you want to add another tab do you want to add something else and where do you want what tool do you want to add it to?

having an error. Did it

Do you have Jax area added up top? I'm just fixing something. He's just fixing something real quick. Modified from other code.

You can see for the most part when we start opening these things that we're able to get extensions pretty much done in under 100 lines of code for the most part. some of the ones where we're, you know, where we're seeing limitations where we're trying to adapt like uh when we showed the um blind SQL injection uh extension, you know, we're basically trying to replicate what intruder does. We're trying to identify all parameter names and values and basically mark those out and then uh send a payload to it. So that's kind of our way being that we don't have a lot of good functionality with intruder, that's our way to kind of cheat it and uh utilize

it. and you don't really have a lot of good uh you know uh visibility into the responses. So what we're doing to as workarounds are looking at things like uh a response content length um you know to try and get at least a confidence rating on if the response is different and should there actually be manual review uh you know sending it to a repeater or something like that so that you can actually go in and take a look and and validate uh what the extension might potentially be flagging

it's using other function

Whatever. Oh well. Anyway, um I don't want to add we don't want to add libraries up to the top or what import uh swing. So, uh we're going to move on back to the presentation. Right. Yeah. So, that kind of concludes the demos where we we at least tried to show you a sample uh try to demo some of the extension showing, hey, you do have control over a final outbound extension. Um little tiny things like one being able to add uh items in the target through uh such things as calling a Google site. Uh doing a little bit of Google indexing. You can even add words to it like look forback uh with a Google

site and it'll add those. So you can do a little bit of Google hacking now within uh uh Burp Suite. uh obviously full request modification uh trying to show that with a SQL injection uh tester where we're actually taking a full request breaking it down and doing whatever uh functionality we need to do to perform our task uh and then pushing on the wire and uh uh yeah sure no I'm on the next one right because you did the oh yeah all right so basically yeah sorry about that I pulled a bunch guey code that was calling functions that didn't exist and we don't have time to go through it but um basically what's next that we want um

we're communicating with Python to Java uh currently we can go from Java to Java obviously and we can implement it in the framework but all the dynamic code that I added that was pulling all the extensions it's going to take a while to basically add more code to dynamically pull the Java one so soon uh you can write it in Java if you really want to um we want to also uh increase uh guey configuration. So as an example, kind of like just everything like adding buttons, adding tabs, instead of having the user have to learn Jon and play with Java and play with Python, maybe just kind of like make little functions that they can

include and be like add tab, add button, add whatever and just put the arguments in there. So it will just make it easier for you if you don't have any Java experience. Um obviously optimization of code. Uh we just found out like two weeks ago that we're speaking here and so I did a lot of code in like two weeks and got it up and running. I don't know how clean it is. You guys can uh yell at me over Twitter about it if you really want to. Um but we're going to be optimizing it and cleaning it up for uh the future. Um we want to do live refreshing. Um I don't know if you

noticed that every time I made a modification I had to close burp out and reopen it. And um yeah, we want to basically remove that. So either there'll be a button or it will just like yeah anything where you can drag and drop and not actually close your actual burp session but just it will update it and include it and this live and uh better control of output. Right now we print to the log tab but and somebody can basically write to the file if they want to and they just write it in Python but just something easier so they can choose like which ones they want to do, which ones they want to print to and uh have functions to to go

from there. And then obviously more extensions and more contributors. Uh this whole idea is we look at something like metas-ploit and the community took it and ran with it and it's obviously doing great. Uh end mapap scriptability engine people are just writing uh you know scripts for it. It's running great. Uh Burp's had extensibility for like 2 years or something and there's like maybe four extensions you can find on the internet. It just like doesn't make sense, you know. Uh, and everybody we talk to that do web app pent testing or pentesting in general, they'll basically say that Burp is their go-to weapon. Um, but they're not using extensions. So, I don't know if they're just spending a

lot of time manually testing everything else. I don't know. So, in conclusion, uh, we're kind of thinking about this whole thing as a rule of supply and demand. Uh obviously uh one of the things one of the reasons why people use Burpswuite is it is constantly being updated. I mean this thing they're pushing out new versions you know every couple months and it's actually with functionality that you would utilize. So uh we've been kind of uh been told that uh demand is taken into consideration when new functionalities are being built. So, you know, I keep pushing, you know, open up extensibility, open up extensibility, and it's like, well, that's great, but you, you know, you're

willing, you know, you guys are the only people using it. If there's more demand for it, I bet you, you would see a lot more, uh, extensibility. So, uh, if the demand comes, I'm guessing what's going to happen is he's going to be able to open some stuff up and give us some more options. Our observations on options that we would kind of like to start uh having come in are uh all requests actually from the extensions themselves uh should go through a tool extension. Currently right now if an extension makes a a request it goes through uh the tool repeater and that can be a little bit difficult um with kind of keeping things

separated, right? So, one of the options you do have with extensibility is being able to determine what tool uh you could pick a tool and say, you know, for proxy do these this functionality for, you know, spider do this functionality. So, being able to separate repeater items and items that are actually called from your extension would would be beneficial. Uh, obviously, we would like to have increased access to intruder uh scan results uh at least with input, right? like if we're finding uh if we're flagging vulnerabilities with our extensions, it'd be pretty cool to be able to add them into the report um with the request and response so that you can still go through your uh verification uh

you know methodology. Uh and then uh you know as easy as adding adding simple methods to assist with handling request responses. Examples would be uh get method you know just letting us know whether it's a get or post. We're kind of using some uh crude methods of doing that right now. So it it is a simple thing and it would be nice if it's just built in natively and you can uh have access to it all the time. Uh the other one would be get response time, right? So if you're doing uh blind SQL injection attacks with like wait for delay, um you know, we're doing something crude within our extensions like literally setting time and counting

how long it takes for the response to come back. Well, if Burp's kind of chugging along, there could be a huge delay by the time it pushes it back to the extension. So, if if he's able to actually as it's being pushed out, the the clock is running from that to the actual burp receiving the response and we can see that time would be actually quite beneficial. So other things that uh would you know kind of nice to happen is uh you know participation you know uh start going out there downloading uh some of these extensions that are out there and trying them. Ours are going to be uh released very shortly. When we first got here uh

luckily our employer likes to come to us and remind us that we need uh some open source licensing on all of our code and we're like okay there goes releasing it today. Right. So, we're going to go populate all that information out there so that we can get our code out and uh let you guys play around with our extens extension framework um soon as possible. Um uh obviously endorsing and contributing to the new uh community forum. Uh one of the things that we first wanted to do when we uh started this talk was build it more on a campaign, right, of getting more people to do this stuff. And we even went out got our own domain you know like burp

extensions.com and we were going to set up a forum etc etc and literally within days of submitting uh our talk information uh boom here comes a new forum up on uh on portswigger.net. So uh yeah we don't want to create our own anymore. We'd ra we we'd kind of rather embrace what's going on. You know the ultimate goal is to get people to use this. So, uh, from this point, if it's there and it's being, you know, done by the actual developer, we want to kind of embrace it. So, get on those forums and like start sharing some information. Um, you know, blog posts, uh, tips, tricks, workarounds. Half the stuff I know is either stuff I found out just by, uh,

you know, literally going through Burp on a daily basis or, you know, a mentor kind of shows you a cool little trick and you have it to yourself. And I I've even tried googling some of these tricks that I know of. um you know and I don't even see them online. So, one of the things that we really wanted to do uh time wasn't going to be an option here was do a lot of tips and tricks. So, one of the first things we're going to do is on our website just start doing a couple days worth of blog posts of, hey, this is what we're doing with intruder, you know, um, this is what we're doing when

we're handled, you know, with when we get handed kind of this issue or, you know, this is what we do with web service testing kind of thing and get a lot of information out there. Uh, so that other people can be using it and hopefully uh, what will follow is information that I can read that other people are doing. Uh, that's going to that's going to, you know, teach me something new. Finally, the end uh we'd obviously like to thank David Roberts. He was the first person who did the uh uh basically Java to Burp using Jython uh gateway. So, we are using uh his framework, you know, open up the code, look at it. It's very

um you know, there's really not a lot of ways to write it. We're using it. It works absolutely fantastic. So, we're going to continue to do it. Uh obviously any pre-esters, uh consultants at IO really helped us out. Um things can get a little madness when you're passing a lot of um instances of classes and you're going back and forth. So it was really nice to have them uh for us to utilize uh my dog BB because she's awesome and obviously Sterling Mallerie Archer for his great uh wisdom with helping us uh with our extensions. And uh just to add in on like the last slide, um Daft and Portfigger have actually been like uh extremely uh

proactive developers. Um there have been countless things that we've emailed them about and that have been implemented in versions of Burp now. And um even when we went ahead and submitted our outline for this talk and we showed it to him, he actually went ahead and like warned us like, "Hey guys, I saw that you had that feature. You're going to release that extension. I implemented it. It's going to be out in about a week or two. Just an FYI." Um, so yeah, he's been proactive. We've emailed him with him a lot. Uh, super awesome, super cool dude. Um, so yeah, if there's anything in Burp that you want, like email them, tell them about it. And especially for you

guys with extensions and framework stuff. Um, like yesterday, I was talking to a lot of people and they aren't developers, like they have never done anything like that and they don't want to touch it, but they have ideas and they have stuff that they want Burp to do. Uh, make a forum post. Say, I want to request this extension. Like, hit me up on Twitter or something or LinkedIn. just let me know and I'll write it. I don't care. Um I mean for the last like 2 3 weeks I've been writing so much framework stuff. Uh I've kind of lost track of what I wanted to actually add to Burp. So yeah, that's really it. So

any of that we also what we wanted to do while we kind of have everyone's attention is kind of get some statistical information out there. Uh I ended up tweeting it. I'll go put it on like BB extensions. Hopefully besides LV will just tweet it for us or something. But we do kind of have a a little survey. how, you know, are people out there doing this kind of stuff? Um, if not, what's preventing you from doing it, right? We we'd kind of like to know because we want people to start using this uh using Extensibility and sharing uh their their lessons learned basically um with it. So, uh if you're not doing it, why? And what what would you like to

see? And uh all stats that we get like we hope to actually share this information so we can actually see are we accurate? Is there 99% using it and only one, you know, 1% out there sh kind of sharing it? So, um, that that pretty much concludes our talk. Are there any questions? Questions? Yes.

I can't hear. I'm sorry. What was that? Right.

So her her question was basically like what are we passing? We are passing a lot of information. Are we passing things like load state and save state? It really depends on what it is right. So if it's a request response, the actual entire uh message info is being passed and that can that you have method calls to that like get uh URL, get host, get request, get response. Um there's basically other method functionality as far as save state and things like that. You wouldn't necessarily save state to an individual request response instance. It would be kind of from a global side. So all that functionality is on the global side. Yes, you can um preload

individual configurations. Um you can have it save state. You know, you can even set a timer so it's saving state every couple hours. I know that Burp is automatically doing that, but you can kind of have save states within your own individual text files. Um so yeah, all method all method calls that are available to you from Burp extensions is currently still able to be utilized within our framework. Anybody else? Yes. For spider. Um so uh his he his question was we're spidering uh basically some websites um with our extensions and what are the limitations as far as spidering uh with the extension. And there's there's for the most part really not. Uh the only um

main issue with uh spidering is what you're passing is just the URL. So if it's a post object, you don't really want to start with a post object because it's just going to hand the generic URL through the spider. Um but uh we do automate uh so for instance we also have tools in our framework that are outside of the extensions themselves. Uh an example of this would be um handling things from end mapap, right? So when you're scanning uh let's say an internal class B network within MAP you could take that that GNA map the GRPable MAPAP file load it through one of our scripts supply it with keywords such as AD 443 IAS Apache and it's going to spit out IP

and port a list of it that will basically then as arguments import into Burp and then we'll actually have it parse that information add those IPs uh with their ports into scope and then give you the option of starting spider header on each and every one of those. So you can kind of like, you know, go get coffee or whatever you need to do while it's just spinning all of your items in scope. Anybody else? One more. What's that? Right. So his question was, "Are there any plans to add Ruby support?" Uh, do you want the I'm a Python coder and here's my like I'm gonna say something bad about Ruby or or um No, you know, it

would be really cool, right? So, I was thinking about it like if what if you literally just had um your main controller still natively built in Java and then it's utilizing both Ruby and Jyon implementations. I don't know if that's necessarily possible, but you know, why not? If you're going to collaborate and bring things together, why not do it as much as possible at the at at the current point? We know that being able to run extensions with our framework in both Java and in Python are uh you know, you're able to do it. As far as also adding Ruby, you know, I really don't know, but it's definitely something that's worth looking into for

the three of them out there. Actually, I was talking to uh my buddy David Shaw from Red Spin yesterday, and he's a huge Ruby guy, and uh he wants to basically add Ruby support to this also. And uh yeah, at first I was like, dude, do you really want to slow down a Java app even more? Like, come on, dude. Like, have you ran Metas-Pl? Like, you want to wait 10 minutes for it to start? But no, we're going to go ahead and implement that. Um and it should be here soon, hopefully. There's nothing wrong with Ruby. There's lots of things wrong with Ruby. I'm a parole guy. My cat walks on the keyboard and makes code.

Yep. That's it. Thank you guys. [Applause]