 This is BurpKit using WebKit to own the web. Please welcome Nadeem Duba. Hi, everybody. Thank you for coming out. I thought I was going to have some big competition with Charlie Miller. I thought none of you were going to come out. You're going to go see some car hacking. But I guess thank you for coming out. So my name is Nadeem and today I'll be presenting BurpKit using WebKit to own the web. I'm currently the founder of Red Canary in Ottawa, a one-man shop, security shop. I love hacking. Exploiting stuff, making tools to break stuff. I've done some prior work, deploy Tego, Defconn 20, and Canary, which was a fork of deploy Tego. Now it's being used by a bunch of companies and pie my proxy. So if you want to see my GitHub page, there's plenty of tools there that you can play with. I'm sure there's something that will meet your requirements. What I'll be talking about is basically how to integrate WebKit into your security tools and how I manage to integrate WebKit into Burp Suite. So we'll be going over just kind of the basics of what WebKit is and how I used it in BurpKit, design considerations, implementation, and I'll show you some demos. And finally we'll have some final thoughts and hopefully some time to answer any questions. So BurpKit came around because I kind of felt that we were stuck in this state where we have these massive web applications running the web today. They're all kind of mashups of everything. They've got Facebook Connect, they've got Twitter feeds, they've got Ajax web service calls that are kind of rendering different parts of the web page. And we're not really getting the full picture if we're simply HTML scraping. But our security tools, they're not really advancing. We're still stuck doing kind of console-based hacking. We have some gooey apps like Burp Suite, Zed, and so on. In fact, the only app that I think that has a web view is proxy.app from WebSecurify. But it's not really a security tool. So we're kind of stuck in the middle ages. And I was really getting frustrated at client sites because they had these really huge apps and I'm using Burp Suite and there's no real way to see if there was an XSS, if there was a bunch of Ajax calls that had to be made ahead of time within Burp Suite to render the content in the page. So like I said, our tool kit, mostly console, we have Burp Suite which is like the de facto web pen testing tool. And in Burp Suite, we only have that really lame renderer tab which uses Lobo and it's kind of like the neglected child because nobody ever uses it from the guys that I've spoken to. And the other ones, trials and set, are just proxies in WebSecurify's proxy.app as I said, has a web view. So when I set out to build the tool, I kind of had this criteria. I said we really need to start taking advantage of modern web browsing capabilities in our tools. And these tools, like the web, they need to be able to interpret parsed JavaScript. They need to be able to dynamically render and inspect content. Because the web browser itself is an excellent parser. It's an excellent tool and it can give you a lot of capabilities. We're not taking advantage of it. And most importantly, we needed the tool to interact with the DOM and vice versa. So WebKit. What is WebKit? If you're not familiar with WebKit, most people think it's Safari but really it's the core of Safari. It's the layout engine and it's the core of a lot of other web browser products. But it's basically the web layout engine software component that renders different parts of the page. And we've seen forks of it in Chrome and other Android browsers and other products. I like this definition, though, from the grug. WebKit is basically collection of views after freeze that somehow manages to render HTML probably via buffer overflow in WebGL. So if you look at WebKit, it's essentially this core set of libraries and they're broken up into two major components. One is the JavaScript core. It's responsible for everything JavaScript. So parsing, interpreting JavaScript, JSON, garbage collection, debugging, et cetera. The second one is the web core and that's responsible for everything else. So you get the web inspector, that neat thing where you right click on the web page and say inspect elements, that's part of web core. The HTML rendering, that's part of web core. CSS, et cetera, all of that is part of web core. And essentially when you try to bring WebKit into your tool, you're primarily dealing with these two major components and different libraries will give you different levels of abstraction to WebKit because WebKit can kind of get really hairy. So here are a few known implementations of forks and forks of WebKit. We all know Apple, Safari, the web browser, Android. Nokia has an implementation in QT and Java effects just recently after the release of 1.8 update 30 I think started getting WebView natively bundled with Java and we have GTK and so on. And what's interesting here on the graph on the left, you can kind of see that two major companies that are driving the project are still Apple and Google, even though Google has completely forked away from WebKit, they now have their Google Chrome but there's still major contributors to the project. So there's a lot of players. And so the question is why use WebKit? Why did I use WebKit? So the reason why is because primarily we have widespread adoption. So what that means is that the websites that are out there today, they're all going to be compatible with WebKit. You're not using links browser. I'm not going to embed links browser where nobody's barely using it and no website is catered to that technology. I want to use something that everybody's kind of coding their websites for. And the second part is that there's lots of language support. So if you go on the web and you're looking for a language binding for WebKit, there's tons of stuff out there for Java, Python, CC++, JavaScript. There's lots of implementations out there. It's portable across many platforms, primarily because Google and Apple wanted their browser to work on all the major platforms. So you're good in that respect. And it can interact with the DOM and JS engine. It gives you basically an API. So the cons are you're going to be susceptible to the same bugs that affect the WebKit libraries. So if there's a use after free that somebody finds, your tool is probably going to be susceptible to that same thing. It's hungrier for system resources. That's kind of expected because you have a whole bunch of stuff going on to render the page, execute the JavaScript, et cetera. But that really, those two cons were not, you know, they didn't really drive me away from WebKit. I mean, okay, so the code is susceptible to bugs, but really I'm assessing client websites. Unless they want to exploit me, you know, I'm not really worried. So how can you use WebKit? As I said before, there's a whole bunch of language bindings available. These are some of the major languages that are supported already. Libraries on the other side. What I used in this project was effects WebView. And I'll go over why. So BurpKit. BurpKit is basically the, you know, the combination of BurpSuite, one of the best tools for security testing Web apps, and Java effects is WebView or WebKit implementation. In Java effects, what they provide you is essentially the very high level API, which gives you direct access to the WebView, which is responsible for rendering the web page and the debugger needs some hacking, as well as the web engine, which is responsible for JavaScript rendering. And what I was able to do with this is provide a real rendering tab. That's right. There's no more Lobo. So what you're going to see in a few minutes is a demo of a real render tab where you see Google fully rendered, not broken up in a Lobo tab. It also has a bidirectional bridge between BurpSuite and WebKit. I'll go into that in a few minutes. Some of the design decisions. So when I was actually designing this, I was looking all over the web for Java implementations of WebKit, and I came across two leaders. Java effects, which comes with Java, and JX browser. JX browser is an excellent alternative. It uses Chromium to provide you with a Java interface. But the only problem was that to redistribute my project, I would have to redistribute 250 megs of libraries with the project. So that was kind of unattractive. The other part of it is that it wasn't free. It was closed source. And basically, I was tied to whatever the developers chose to expose to me in terms of an interface. And finally, the API wasn't that clean. It was kind of clunky. So some of the pros and cons of Java effects. It's easy to use the WebKit implementation. It has a clean API. It's very Java-esque. So if, you know, you're not going to be confused with all sorts of funky function calls, it has a complete JavaScript bridge. So that means that you can actually inject Java objects into the JavaScript engine. And you can actually retrieve JavaScript objects and play with them in the Java virtual machine. It leverages the Java URL framework, which is hookable, and I'll go into that later. It does provide some debugging profiling information, which is only available through some hacking. They don't really document it. So it's still a work in progress, but at least it's bundled with Java 1.8+. The cons, in terms, when I say the API is incomplete, I mean, you're not getting Web Inspector. You're not getting any of the things, the nice things that you see in a Web browser. Some of the stuff, you have to kind of reinvent the wheel. You have to redesign those GUI components. There's little documentation on the advanced features. And what I mean by that is that if you wanted to actually use the debugger function, you really have to dig through that source code to find where the debugger is exposed in the API. And they're kind of labeled as deprecated, so it makes you nervous. Like, is this thing going to go away in a near future, or is it going to stick around? So it gives you an indication that they're still working through the API, but at least they give you enough to work with so that you can actually make some really neat tools. And there are still some rendering bugs as expected, but for the most part it does a really great job. So the implementation. So I had various challenges when I had actually tried to embed WebKit into Burp Suite. One of them was that Burp Suite was using the swing event loop. And swing is this really old GUI library that for some reason a lot of people are still hooked on to probably because of the availability of some advanced GUI components. And WebView was written for Java effects, the effects event loop. And so there had to be some sort of integration point there. Web Engine doesn't have a load content with base URL. So what that means is that if I wanted to load an HTML page with a base URL so that I can get different images and stuff from the server but have the content in my desktop on the client, sorry, it wasn't possible so I had to find some way of hacking it. And finally Burp Suite had to interact with JavaScript and vice versa. So the first challenge was very easy to solve. There were a few gotchas. Java effects luckily gives you a JFX panel which allows you to embed an effects event loop into swing GUIs. But you had to be really careful with interweaving synchronous function calls. So what that means is that if I had a getter method that went through swing thread first, Java effects second and then back to swing or the other way around, then I would run into deadlock issues because the threads would be waiting. So there was a lot of hacking with wrappers. I had to do a lot of eager fetching to make sure that the appropriate resources were allocated on the appropriate event loop. And this is something that you would have to do if you were working with swing and Java effects at the same time. The second challenge, loading content with a base URL, the reason we needed that is because Burp Suite actually has a repeater tab. And that repeater tab essentially allows you to repeat a request, look at the response. Now in order to look at the response in a real render basically with WebKit, I didn't want to reissue the request because all I have access to in terms of support for requests was get. And the other reason is that I don't want the response to change based on time. I want to actually see what I got in the response tab in WebKit. So I had to hook the Java.net URL protocol handling framework. And luckily WebView uses that framework to process HTTP requests, any HTTP request really. So the entire HTTP request framework is hookable. You can actually intercept responses, change these responses and so on. So I implemented two new handlers and that's basically what you see the code there is basically the minimum API, the minimal amount of implementation that you have to do in terms of overriding the preexisting protocol handlers. And what those protocol handlers did was they actually just tagged requests that were supposed to be repeated. They tagged the user agent with a shot-one sum of the response. And if my protocol handler saw that shot-one sum, it would then just fetch the content from a cache rather than going live to the server. So that was a really fun exercise because it involved a lot of just digging in the source code and figuring out how things worked. The third challenge was really easy to fix in the end. The only thing that I ran to were the deadlocks, but essentially that Web Engine bridge is readily available for you to use. You just need to know how to use it, how the Web Engine returns objects. That's all documented. The only gotchas there are that in some cases this Web Engine uses a really funky reflection algorithm to determine whether or not a field or function is accessible. So you had to write a lot of wrapper classes to get around that funky reflection algorithm. And as I said before, there's a lot of cases where you have to eagerly instantiate swing components in the right event loop, in the swing event loop. So this is the final product, the before and after. On the left you see Lobo, very ugly Google page, and on the right you see Google in all its glory. So here, let's show you what BurpKit looks like. So BurpKit, you get three extra tabs, one of them is a bonus. BurpKitty, which is a full web browser, and you have basically a JavaScript console here at the bottom, an XSS tracker, which I'll show you later, a page resource tab which shows you kind of href references and other references to content within the page. And the nice thing here is that you can right click on these and you can send them to any part of the Burp Suite framework. So if I send to repeater, you'll see that in the repeater I get the request that WebKit made with all the cookies that it has in its store so that you can maintain the session within Burp Suite. And as well, if I go into, if I repeat a request, you'll see that there's an extra BurpKit tab, and that's essentially the same view that you see in BurpKitty. Unfortunately, the screen is too small here. Let me see if I can get rid of this toolbar. Okay, so you see Google here. And basically this view, you're going to be able to see in any message editor tab within Burp Suite. So it'll even manifest itself here in the proxy history list. So if we have an HTML document that gets returned, you're going to see these as well here. Even intruder. The other nice thing here is that I've added a BurpScript IDE tab. And what that allows you to do is it allows you to build JavaScript-based web applications, client side web applications. So if you wanted to write a Burp Suite plugin in JavaScript, you can. If you want to write some advanced HTML scraper, you can. It basically allows you to use WebKit to navigate pages, to extract that information, to interact with Burp Suite at the same time, send that information from WebKit to Burp Suite, and so on. And finally, there's a Jython tab for all you Python users. It's not related to WebKit, but that's just an extra bonus. So, no more Lobo. And I hope that was kind of impressive, but we'll give you some demos. So the first demo, the XSS tracker. And this is where I think a lot of the, is my screen still up there? Okay. A lot of the potential for WebKit, where we can use WebKit really effectively here, is in XSS tracking. So let's say you have a scenario, which, you know, I come across a lot, where I want to know where, how bad a stored XSS vulnerability is. So what I can do is, I can send, I can send this to the repeater. Oh, sorry. I don't know what happened to the resolution there. It just kind of flipped on me. Thank you for telling me. Let me see if we can, is that better? Just let me know. Arrangement mirror. I don't know where it changed. Is that better? Sorry about that. Let's see if we can just increase it just a bit, just to get some more real estate on the screen there. Is that good? All right. Great. So let's say I want to track an XSS. So one of the things is, I'm using Tried Editor. Obviously, it allows you to render random HTML. And I find this XSS vector. Let's just pretend this is the app. And I want to track XSS across the app, a stored XSS vector across the app. So what I can do is I can taint a value in the alert box. I can put a tainting value. And I'll just generate a random ID. And when I press go, you'll see that when I go to the Burp Kit tab, it tells me that I've had one alert. You don't see an alert box. You just see that one alert. And it shows you what the contents of the alert are in JavaScript console. Now, if I push over to XSS tracker, you'll see that there's an entry there. It basically says that I've detected the tainting value, I've detected an alert. It originally came from this web page. And now it's in this web page. So now you have a really easy way of understanding how far a stored XSS vulnerability has gone in the app. So how bad it is. So that's the XSS tracker. I think that's an example of how we can use WebKit to perform dynamic analysis in the app in a very easy way. So we don't have to inspect HTML. The nice part about this now is let's say I want to get the money shot. And I really want that alert box so I can take a screenshot. So you can toggle this button here. You can press go again. You get the alert box. Let's take the money shot, screenshot there. And we're good to go. Let's find that screenshot. All right. Let's put it at the stop. There we go. Just so we show you. And there we go. So that's the money shot. So, and the last thing that I'd like to show you here is that let's say you wanted to do some, you know, web inspect. You can always launch Firebug Lite. It comes up with an inspector. And you can do all the same things that you do with Firebug right from Burp Suite. So that's the XSS demo and part of the repeater tab. So now the next demo I'm going to show you is some DOM interaction and how we can actually scrape Twitter for followers. So I've included on the DVD with this project a bunch of examples. And this is going to be on GitHub later. But I've included a bunch of examples that you can use. And this is kind of one of the things that I do when I do OSINT. And it's just a quick way of just dumping a user's Twitter followers. So I just want to highlight this one feature here. In the bottom right hand corner you'll see that refresh button. I don't know why it's just blanking out there. But what that does is it essentially creates this loop that you can trigger every time a page navigation happens. So every time document.onload is triggered this script gets run. So you've essentially created a loop with the document.onload. So let's press play. It asks you what user you want to scrape. I'm going to pick this random user that I picked in the demo room. And as you can see it's scrolling down to get all of the user's followers and collecting all of this information. And now I can save to CSV. And let's take a look at the results. And there you go. I got a full list of Twitter followers not doing anything. Just running my burp script. So essentially what I've done there is I've extended the JavaScript API to include a whole bunch of things like injecting JavaScript libraries like jQuery, CSV lib, a whole bunch of things that come from Node.js. And I've also added some extensions to allow you to write directly to the file system so that you can create, you know, scrapers for things like LinkedIn, for instance. If you're doing a penetration test and you want to know all the employees of a certain organization, you want to collect that so you can build an email list and hit it against OWA. Then you can go on LinkedIn. There's an example for LinkedIn in the examples directory where you can scrape all the employees' names and create the email lists. The next example that I'd like to show you is an example of how I was able to get this to work with the Burp Extender API. So I'm just going to use a simple example here. I'm going to use the verbose proxy listener. And what that does is essentially just gives me a brief listing of what messages are going through the proxy. So this is just proof that you can use JavaScript to write your Burp Suite plugins. Oh, did I press play? I don't think I did. There we go. So there we go. So that's an example of a Burp Suite plugin written in JavaScript. And finally, if you wanted to do something GUI-based, you could always use, there's also an example there for the text editor and where's the repeater. So this is ripped from Burp Suites, from Port Swiggers web page. So if I just press go there, come on, you see serialized input tab, that was created using JavaScript as well. So I've basically given you the facilities to interact with WebKit from Burp Suite and vice versa. Have JavaScript interact with Burp Suite as well. And I hope to extend this to include some new features like multi-tabbing and so on. There's a lot of examples in the project. And I'm very eager to see what you guys can come up with in terms of ideas to extend the project, ideas on how we can leverage WebKit. As you can see, there's a lot of potential promise using WebKit, the WebKit library with our security tools. And we don't have to be stuck in the middle ages with console-based apps or very rudimentary rendering apps like Lobo Library. So to end this talk, I think I'm ahead of time, but I'd like to thank my lovely wife who let me come here after having our beautiful baby two weeks ago. And just in sight, she's been a really great guy in terms of feedback and testing and giving me tips on the presentation. So thank you, Justin. Dirk Lieberman, he was the guy that actually created the network browser component, the network timeline component that you see in BurpKit, this thing here, network timeline. And finally, Thomas Micula who created the code editing component as well. Great job on that. Java FX team and a whole bunch of other people. If there's plenty of time for questions, I'd be more than happy to field them. The question is, is it available on GitHub? It will be tonight. My GitHub is, let me put it up here. I forgot that. There's my GitHub. And zoom in. There you go. And I have business cards here if you'd like to chat with me over email if you have questions regarding the BurpKit toolkit. The question was, does BurpKit go through the proxy history? Does it have a BurpKit tab in the proxy history? Oh, not yet, but I'm working on that. HTTP to support, what about HTTP to support? That would be based on what the WebKit library implementation supports at the time. I can't guarantee that. The question is, does cross-site scripting work for DOM or reflect? It works for any kind of cross-site scripting.