How to Shot Web (Better hacking in 2015)
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Haddix, Jason
2014 was a year of unprecedented participation in crowdsourced and static bug bounty programs, and 2015 looks like a trendmaker. Join Jason as he explores successful tactics and tools used by himself and the best bug hunters. Practical methodologies, tools, and tips make you better at hacking websites and mobile apps to claim those bounties. Convert edge-case vulnerabilities to practical pwnage even on presumably heavily tested sites. These are tips and tricks that the every-tester can take home and use. Jason will focus on philosophy, discovery, mapping, tactical fuzzing (XSS, SQLi, LFI, ++), CSRF, web services, and mobile vulnerabilities. In many cases we will explore these attacks down to the parameter, teaching the tester common places to look when searching for certain bugs. In addition he will cover common evasions to filters and as many time saving techniques he can fit in. Speaker Bio: Jason is the Director of Technical Operations at Bugcrowd. Jason trains and works with internal application security engineers to triage and validate hardcore vulnerabilities in mobile, web, and IoT applications/devices. He also works with Bugcrowd to improve the security industries relations with the researchers. Jason’s interests and areas of expertise include, mobile penetration testing, black box web application auditing, network/infrastructural security assessments, binary reverse engineering, and static analysis.
 This is how to shot web, better web hacking and mobile hacking in 2015. I know Dan Kaminski is talking right now so I really appreciate everyone being here. He's way smarter than me. So this is me. I work for Bug Crowd. I'm the director of technical operations. I manage a team of hackers who validates the bugs behind the scenes of a bug bounty, large scale bug bounty program. In 2014, I participated as only a researcher. I didn't work for them yet. And this talk is about my methodology that I used there to do web hacking as well as a little bit of mobile stuff, as well as stuff I learned from other researchers while doing this work. So what is this really about? It's just how to hack stuff better and practically. And I put a lot of memes and some of them are not funny, apparently, my wife says. So it's okay. Some more specifically, what I did is I started off with my methodology, which was a normal pen tester methodology when I started doing this work, a basic web application assessment. And so I then went out and manually parsed out all of the public researchers of all the bad bug bounty hunters I knew. So there's about 150 people that I knew just around the Twitter scene, not Twitter scene, sorry. Twitter scene, as well as people I just knew who were good at it. And so I went through every single article they had ever written from the beginning of the crowdsource bug bounty scene. And also all of the Google and Facebook programs that I could find, like enterprise-based bug bounty stuff. And I created a presentation around what I distilled around that knowledge. So this is kind of the stuff that I'm going to bring in this presentation, philosophy shifts from doing bug bounty testing to, you know, from web app testing, traditional web app testing, discovery techniques, mapping methodology, parameters often attacked, useful fuzz strings, bypass or filter evasion techniques, and some tooling that I think is cooler than other tooling. So cool. So the first section is philosophy. So the differences between kind of bug bounty hunting and being a web pen tester, you know, I'm not really to argue this debate. There's a lot of people who feel strongly about both sides and they're both right, honestly. But when you get down to the practical work, you introduce a lot of stuff here. You introduce time onto a security tester, right? They're not used to competition when they're doing this kind of stuff unless you're playing in a CTF, which, you know, you're used to that. And I played in some CTFs, so I was kind of used to it. You know, you're only incentivizing it in one side for what you find and not the hours you put in. So, I mean, this is a basic overview of how they differ, but the talk's more about the technical stuff. But yeah, you basically tailor your methodology based around finding stuff in the 20% as opposed to the 80% across application assessment. So we'll go into how that 80-20 rule kind of fits in the rest of the slides. So if you're doing regular web app assessment, you're following these two Bibles, right? The OAS testers guide or the web application hackers handbook. This is usually what you're trained from and what your internal methodologies are built off of it. Almost any of the good consultancies. And the authors are, you know, super great testers, right? But these take you from A to Z. And, you know, even though they find good bugs, they take a long time to complete in their full scale. So bug bounties are different. So if you want to do web hacking, you want to get started, these are what you go for. But my talk is a little bit different. So let's talk about discovery in web application assessment for a bounty. So what you want to do in a bug bounty is basically find the road less traveled. And this is if you're aiming to get paid, I think. So you can attack the flagship application that the company has, right? But really, that's not where the vulnerabilities are going to be most of the time. That application has been tested by a pentest team. It's probably had a bug bounty on it for a long time. What you really want to find is the parts of the applications that are like subdomains or maybe obscure web servers on different ports. You want to find acquisitions that maybe the company has had recently that came in from a different development team. And they might have a whole slew of problems that came from a whole different group. You want to look at functionality changes and redesigns on sites, mobile websites, because they're set to render differently on your phone. And also new mobile app versions when you're testing. So we're going to go into some tools and stuff I use to find a new surface area for you to attack. So reconNG is this tool that basically allows you to do a whole bunch of automated OSINT stuff. And one part of it is it has all these modules to do subdomain brute forcing and subdomain discovery. Now subdomain discovery is a big part of finding applications that have been left out there. I mean marketing spins up a site, dev spins up a test site, like you have integration stuff left up. So finding those and hacking those and getting RCE or code execution through those sites is kind of where you can get big payouts. So this script, what it does is it iteratively scrapes Google for all subdomains on a given web property. So let's say Acme.com. This will find, this will scrape Google for everything that is in Acme.com and then iteratively remove those results until you're down to this long list of subdomains. It also scrapes Bing, Bydude, Netcraft and brute forces subdomains like your common fierce tool would. So this is on GitHub. It's a simple shells wrapper around reconNG. So you need to have reconNG installed. If you use Cali Linux, you can just pop the script in and go. So yeah, so this is the output of something like that against a company like this. You can see there's a lot of output. You can see a lot of domains here that have gone under assessed as far as you go. This is that idea of iterating through Google to find subdomains. So here you have site and then minus dub, dub, dub sites. And then I found on the first hit was Sandbox. So I removed that on the next run through. And this is that scraping that's happening that the tool is doing. And then you get more entries floating to the top. So you get credit apply or business or shopping or advertising and you just keep on removing these until you have all of them. And then you brute force and then you end up with a huge list of sites to assess. And then you want to go through and on your entity that you're attacking, you want to find any mergers or acquisitions that maybe aren't the domain that you're given. But they've just purchased a company. So Oculus purchased by Facebook, had some bugs and they got popped as soon as they were acquired and they were not under the Facebook six month rule or I don't know if it's six month or I can't remember how long. But yeah, they got popped immediately. And that was a whole different dev team but owned by Facebook and worthy for an RCE bug. They got hit with SQL injection and a custom header and that was great. Well, not great, but it was good for the bounty hunter. So Wikipedia for Facebook and Google does this really well. People update these things all the time when there's an acquisition for stock reasons. So keep an eye on these if your company has purchased something else and they have some new domain and it might not be in the bug bounty brief yet, you can go after this. If you're doing those types of bounties. There's also a repository of links of every kind of phone that's come out on Facebook and PayPal and Google. I like to share this information. This one is hosted on Facebook. I have no idea why. The links in there and the slides have hyperlinks. These are all the blog articles that reference bugs here. Why is this important if somebody else has already found these bugs? Because bugs get represented across the domain in different places. So you can tell a lot about an organization once you read these articles and find the same bug in other locations. Like those subdomains you found, maybe rogue web servers and things like that. It also kind of tells you what they're going to do to fix them, like how they filtered out input. You get a lot of intel around the application. So really doing a lot of research on your target can't help. But it's not the fast stuff. So port scanning. I mentioned port scanning. So port scanning is not just for NetPen. So yeah, I mean, how I hacked Facebook, there was an article by Ryan Dewhurst who was like, I started up port scanning and found some weird server which was a Jenkins script console with no auth. And that was it. So I got in. Simple as that. Like $8,000 bug or something like that. Or even more, I don't remember. So is.net, the Microsoft domain that evangelizes.net had RDP open to the world with MS-12020 on it, vulnerable. So that was the thing. So yeah, just go ahead and use a simple end map syntax to start port scanning all of your sites and make sure you check all those services. This syntax will port scan for all ports on a domain as well as pull out any HTTP servers, titles and display those in the output. It's a SIN scan and OS fingerprint and stuff like that too. So mapping. So you found all of these new servers, right? Like maybe subdomains or maybe you found an acquisition or something like that and now you want to move into mapping an individual application. And taking notes is really important when you're doing this, whether you're doing it inside of like a notepad or just using pen and paper or like Evernote. I use Evernote. All my bugs are templatized so when I find them I can just copy and paste into the disclosure email or whatever like that. So these are some mapping tips that I use right away. So Google is actually your friend, right? You can get a lot of parameter information from just Googling a domain and figure out like what happens there. I know there's some like parameter parsing scripts. I couldn't find a really good one for this presentation but just will parse parameters out of the Google cache stuff. But really the next big thing is directory brute forcing, right? Finding unlinked content. Content that's not supposed to be there. So a lot of people use like Durbuster or Content Discovery and Burp for this kind of thing. And that's good. They're good lists but those lists were created by going out and spidering the Internet and finding every path after the top level domain and then prioritizing them. There's some other lists that are better for this type of work. So the raft lists are these lists that came out of a talk maybe four or five years ago. Raft was an application proxy. It was a decent one but it's since been discontinued but its lists for directory brute forcing have lived on. They are a spider of the Internet's Robot Docs text files. So everything that everybody doesn't want you to see is in this directory brute forcing list. So it's super sick. I can't tell you how many bugs I found just using this list. Like config files, badly configured git stuff. It's just all over the place. SVN Digger is another list like this. They went out and spidered all the SVN projects. So if your site or your target is an open source place you can take all the paths that have been converted for you to directory brute force to get better application coverage or find config files. Git Digger is the same thing for Git. So after you do some unlinked content discovery or directory brute forcing whatever you want to call it you move on to try and identify your platform. So there's just some really simple wins here. Wapilizer and built with are Chrome extensions that you can just click and they will give you pretty much the whole stack by looking at the headers, the comments and the pages, the way they render like analytics things that have been integrated and they'll just give you like the whole server stack. And they'll even give you version numbers if they can identify them. So Wapilizer and built with are super sick. Retire.js is one of my new favorites. It will profile all of the server side JavaScript libraries and tell you if they're out of date as well as give you all the vulnerabilities before that patch or your vulnerable version has. So you'll get a list of prioritized cross-site scripting or whatever is in jQuery at the time. And then once you identify all of these servers, version numbers, you just go check for CVEs and server side stuff. So that's pretty standard. That's web stuff. But these are some good tools. Now if you happen to come across a CMS which is like the pentesters training because those things suck and the plugins suck, you want to use these two tools. WP scan for WordPress. A lot of people use this already. It will identify all plugins and users for WordPress install as well as look up any volums that are associated with those plugins that have been disclosed. And then CMS map for Drupal and what is the other CMS Drupal and? There you go. Thank you. Awesome. So those are the two that have really yielded any value for me across CMSs. So here you see a screenshot of WP scan. And it's, you know, found a version of a plugin or a theme that already has like cross-site script or a file upload vulnerability in it. Sometimes there's false positives. Honestly, for what this script does, it provides so much value. So it's great. So the directory brute forcing, we talked about a little bit earlier. I mean, the workflow for this, a lot of people do. But I just put the slide in here because I see a lot of people do it a little bit weird. I see people brute force like off the top level path a lot and then just stop, right? And so they'll get some errors and they don't know what to do with it. So they'll go to acme.com and get a 200. And then they'll go to backlog and they'll get a 404 and they'll get more 404s and more 404s and you know there's nothing there. But then they'll hit like control panel and see a 401. And then they'll be like, well, I can't do anything that I'm not authorized, right? So they don't brute force after control panel. There's so many like messed up access control on web server bugs that you can exploit. If you just brute force after that, you'll probably find something. So I just see this a lot where people stop after the top level domain when they're doing directory, you know, enumeration. So that's kind of the workflow you're doing there. Some other things that you can do is mapping and vulnerability using open source intelligence. So these are one, two, three, four, five sites, six methods that you can use to find already published bugs or almost already public bugs. I mean, I guess they're considered like end day or whatever. But xss.com, reddit, XSS, punk spiders actually a burp engine that just scans the Internet. So if your target is a high profile site, information might already be in here for your test and you can pull it out and use it to your advantage. Even if those bugs have already been disclosed and I've found bugs that were on here but not disclosed to the customer through the bounty, so that's actually worked before. It was like a super easy win. They help you get a feeling for what the company has faced before as far as issues like prevalent cross site scripting, cross site request forgery, file uploads. And then you can do regression testing on all the domains that you found earlier in the presentation. So yeah, go out and use these resources to try to find bugs in the platform as quickly as possible because they're free and they're already out there. And the customer should know about them anyway. It's the responsible thing to do. Okay, so this is my intern Ben. He's never spoken before at DEF CON. Neither have I actually. This is my first DEF CON speaking. But he did an awesome project and he's going to talk about it for a couple seconds. I really like it. So hello, everyone. My name is Ben. Like Jason mentioned, I'm an internal bug crowd on Jason's team. For the past couple of months, we actually gathered a bunch of JSON files that includes all the metadata for each bug bounty program that's out there. So there's 250 plus bounty programs that are included in this project and they all include information like how much a minimum bounty is, how much a maximum is, what mobile apps are included, what web apps are included and what's not included in the scope of the program as well. And we actually use all this data and fit it into different scripts like you can see on the screen. We fit it into NOC and it just went through all of it. Every single one of those programs and brute force them for subdomains. And this also is available on GitHub account and everyone can go and use it if they want to. So the JSON files look similar to this. This is Yahoo's program a couple months ago. If that's updated, we don't know. But what we have is a DNS record that shows that's the yahoo.com itself and all subdomains of it and Flickr and all subdomains of Flickr are included in the scope as well as all the mobile apps that are included in the scope as well. And as you can see in the bottom, there is two domains which is yahoo.net and its subdomains and yahoo.net itself not being included in the scope of the program. So what we ended up doing with this using Ruby, we wrote a script, we fed every single one of those JSON files and we crawl them. And using grep, for a sample for this one, we grep redirect and you can see there was a, we couldn't disclose the domain but there was a bunch of sites out of out there that had to redirect out there that you can easily report and take them out and report to the vendor. Taking it further, we, same idea, we use all the JSON files and we fit that into Intrig, which Intrig is an API framework that is for intelligence gathering and it does a bunch of tasks that you can see on the right left side of the screen. Includes doing supplement brute force, web spider, end map and you name it, we can do it with Intrig. So also Intrig is available on GitHub as well, it's open source, go ahead and fork it and commit to it if you need to. We ended up doing four Intrig as we parsed every single JSON file with help of Ruby and I can see at the line when it says R, we are taking the task which is called DNS brute sub which is a supplement brute force and we need to give it an entity and options that are all included in the manual and we are running that for a JSON file which at the bottom shows it's being assigned an ID that you can just go in your local host and check it out and see what Intrig has found. So for example we did Intrig.io and for DNS brute force you can see all those sub domains that have been out there that Intrig found with their IP addresses as well. And make sure you guys check it out, it's like I said it's online and you guys could, the possibilities are it's infinite, you can do whatever you can think of out there with those and being a bug bounty hunter I think it's a huge tool for everybody out there. Awesome. Yeah, that's a sick tool and a sick framework both mapping and recon entry. Like I mean if you've used Focca and Maltigo and everything like that it's like an open source version of those licensed tools. I love both those tools by the way, just saying like using both if you can but Intrig is going to be sick, you guys should check it out. Okay, so on to, where are we at? Off in session. I'm going to have to blow through some of this because this presentation is long and there's a ton of stuff in here. So auth related bugs. The one thing I want to say about these, these are low shallow bugs that everybody hates people to report in bug bounties. The problem is if people start not paying attention to them you can't chain them to do bigger things. So we've had multiple bugs or I've had multiple bugs where we've had a couple small issues like with password resets or something like that and then we've chained them to make a critical, critical account takeover bug. So these are really important but these are the kind of bugs that a lot of people see in the hashtag like beg bounty instead of bug bounty. People really don't like them. Don't discount them, just note them and if you don't want to, if they're out of scope don't do anything with them but you might be able to use them later. That's all I really have to say about some of these. So session, the kind of same things, right? So failure to invalidate old cookies, like new cookies on login or no new cookies on login and time out, never under cookie length. These are all things you're going to be able to use later when you need to chain bugs but a lot of times they're out of scope. So either out of scope or unappreciated or duped or something like that. But yeah, you should keep them in mind when you continue testing because they can be chained into bigger issues. So the big part of this one is actually tactical fuzzing. So I go through a couple different injection types or vulnerability types here and so we're going to talk about cross site scripting and some research that some really cool people have done. So the core idea of cross site scripting, right? Does the page functionality display something to the users? That's kind of the question I ask myself. Can I get reflections somehow with JavaScript? And so you can do manual testing which is great, right? And you can enter in your meta characters and see if they return. But really when I'm trying to work fast in a bug bounty I have three or four like magic strings that I use. And so you probably use them before. The technical definition for them is polyglot payloads. These are web polyglot payloads. And so the first one you'll probably recognize. This one is arsenakes. They used to call it the arsenic battering ram or when I worked in pentests they used to call it came out of the XSS cheat sheet. You probably use this before. You put it into the search bar or comment field and then you pray that you get cross site scripting, right? So this is the first one. This is actually a multi-context filter bypass based polyglot web payload. It's a mouthful, I know. But basically it's designed to evade filters. It's allowed to execute in different web contexts. And it's really cool. So I have three of these strings that I cite here that if you're just doing bug bounty hunting you can use and just kind of move along on your critical functions on the site. So this one is from a researcher named Sharjah Ved. He does cross site scripting research. I think he did his PhD in cross site scripting which to me blows my mind. So this is a multi-context filter bypass based polyglot as well. So you can see here that he's trying to mark up in a whole bunch of different contexts. He's got an at sign here to trick email filters or maybe a form only takes emails or something like that. He actually ran this along like the Alexa top 100 and 80% of them were vulnerable to just their search parameters with this string. So Moramo for you guys doing bug bounties. This one is one by Matthias Carlson. Is he here right now? Is Matthias here? Hey, there he is. He's awesome. So he did a whole presentation on this idea, polyglot payloads and websites. So this is his multi-context polyglot payload. And so this is one that I use now. So thank you. Other XSS observations when I started parsing bug bounty work as well as getting bugs myself. So finding input vectors is important. So finding customizable themes or profiles that you CSS but then you can trick them into using JavaScript to execute cross site scripting. A lot of names of like events or meetings in any application that deals with those types of things. A URI based XSS is still a big thing when people pull things from the URI and render it for some reason. Importing from a third party, so things like Facebook integration where there may be filtering characters but your site actually displays Facebook data in line. So you can set your name on Facebook to script alert and it will alert on this site. JSON post values that didn't return the correct content type. A lot of people discount web services right away because they think that the content time won't execute cross site scripting or won't execute JavaScript. And so you have to really check and make sure they're returning the content type otherwise you can get reflected XSS and a lot of web services like that. File upload names when you're uploading file just try to change it to script alert or whatever like that. It's going to echo that file name back usually a lot of places. Uploaded files themselves. This is a huge one actually that's all over the place. So a compiled Swift file or an HTML file that's designed to execute its own JavaScript and you basically attack a file upload. So a lot of file uploads, there's a whole section here about file uploads. We'll talk about it more in a little bit. Custom error pages where they're echoing out what you can't find, put XSS strings in there. Fake parameters where the page might parse some fake parameter data and put it into your response and then log in and forgot password forms. Also this is a Swift parameter XSS is a huge thing as well. I don't think I've ever found a Swift file that I've decompiled that hasn't been vulnerable to either cross-site scripting or remote file include. Actually Dennis here is the guy I ask questions to that all the time. So there's things like J player and all of these like caught software that are Swift files that do like media or whatever. So there's a whole OWAS page on the common params that these players use and then also the injection strings but these you have to kind of do more manual analysis. So to do that manual analysis I use this tool called flash bang which I think is super awesome. It's by cure 53 you drop it a Swift file on the other end comes out all of the parameters that might be vulnerable to cross-site scripting. It decompiles it for you and it displays them along with if they're going to execute out of the context of the Swift file. I highly suggest this tool if you're going to do some Swift hacking. It's way better than a lot of the old ones. So SQL injection. The core idea does the page look like it might need to call on some stored data obviously. This is Menteus SQLI polyglot where it will execute in single quote, double quote and straight into query context. So I've seen a lot of cross-site scripting polyglots and you remember these are things that actually scanners are starting to do. They don't want to send a million fuzzing payloads to a parameter because you have like eight million parameters on a page so it just takes forever to scan things. So Menteus in his presentation has this string and I imagine a lot of fuzzers, web fuzzers and scanners will start to pick up on this type of thing if they haven't already. The idea of these multi-context injection strings. So this is awesome as well. So for SQL injection to kind of go through and fuzz things I also use this project called the sex list project and it's got a whole bunch of fuzzing lists in it. It was a fork of the fuzz DB and then we added to it with username and password lists and all this crazy stuff. Daniel Measler here actually helped me curate it and we decided together. And it's invaluable, right? It's got like by type of injection so if you want to just do like a login bypass in my SQL it's got all those curated, all those strings curated that you would usually use as you SQL injection there. I highly suggest using this and I just load these into the burp into intruder when I want to attack a form or something like that. Some parameter I think is vulnerable. So other observations. So blind is the predominant SQL injection. You hardly ever get error based SQL injection anymore. And so like in those cases you use like benchmark strings and stuff to make the page take a long time to load and that's how you identify. Whether you take it the whole exploit way is up to you, right? We have a lot of researchers I know who just want to identify and move on, right? I like to run SQL map eventually because it's still king. I mean there's no other tool that does it as good as SQL map. And that's actually something I learned doing the research was that everybody use SQL map at some point. So yeah, some tips for SQL map. Basically when you're doing this you can actually parse a whole burp log file so like enable burp to do logging and parse the whole log file and actually fuzz the whole log file with SQL map. It takes forever. It's not like the greatest way to do things but it's also offering a lot of coverage. If you're up against some kind of like black list or something like that, SQL map has tamper scripts that you can use which basically encode all of your attacks so that you can try to evade black list. There's a really good guide on there. It's somewhere on the bug crowd forum on DBMS specific syntax for SQL map tamper strings. So if you're going up against MS SQL or MySQL or something like that, there's a simple string you can pass into SQL map and start fuzzing those parameters and get past black list. And then a really fast way to instrument SQL map is SQLI PI which is a burp extension and basically allows you to right click on any window and burp and send that request to SQL maps API running on your local box. So you can just be inside of a burp, right click and start fuzzing the parameter if you need be. So some common parameters and injection points like any ID value, currency values, item number values, sorting parameters, I'm not going to go through all these. They're all on the slide. And eventually this is all going to be on GitHub anyway so you guys can just grab it and use it in your methodologies if you think it's useful. But these are the kind of places where I saw the most injection and where I, you know, my research parts out of other places showed me. This is SQLI PI so right click on a request, send it to SQLI PI scan and now that burp renders scanner results in the target tab but it doesn't look like this anymore but you get the idea. So this is my cheat sheet of SQL injection resources when I do SQL injection broken down by my SQL type and these are cheat sheets that let you know manual syntax based on my SQL. A lot of these people are like pentas monkeys, lists are old, they're still the best. You have to use these and you have to have them handy when you're doing injection. So there's some really edge case ones at the bottom like access which God who uses access, that sucks. Ingress, DB2, Informix, XQI3 and Active Record for Ruby on Rails. So I keep those handy in my Evernote when I'm doing SQL injection testing and when I see errors or long load times or something like that I start getting in that mode. So file uploads and file inclusion is the next area. So local file inclusion, the core idea is does it or can it interact with the server file system. Liffey is my cool favorite tool for doing this. Also you can do it manually so I have all of my LFI scripting stuff up on SecList under fuzzing and LFI. So you can see here I've tried a bunch of blacklist bypass or encoding to try to get common system files. This is on the SecList project. Common parameters or injection points for this type of stuff is like you would think of this but it's good to have it in the list. So like file, location, locale, path, display, load, read or retrieve, these are the most common parameters that you'll find those in. Malicious file uploads. This is an important and common attack vector when doing this type of testing. Not only just to upload like a Swift file and get XSS off of it but you can also do pretty cool attacks. One of the ones I like a lot and it's a DOS, basically an image that specifies itself to be super large but isn't so you can upload it and the server will write all this or will allocate all of this space for it on disk but it's actually not that big of a file and you can DOS the application server using images crafted like that. There was a whole blog on it. And then you can actually, one of the things I think is interesting, I'm not going to go into too much but there's a slide about it, is bypassing like security zones and storing malware on client servers. So there's as well as polyglot web payloads. There's also polyglot files which can execute code in different contexts. Like if you think of a parser reading a file, it basically will look until it finds what it wants and then execute that. So you can create like a jar that is actually an executable. So if I make an executable that is malware but I upload it to your server because you allow me to allow a jar, well is that a vuln? Like I don't know. Like you are technically storing malware on your server for me, right? And I can send the black hats to go retrieve it but can you do anything about that, right? Are you going to implement a parser to look through the binary data and cut stuff out? I don't think so. It's kind of hard to do. So interesting question there. It's kind of another road. Dan Crawley did a presentation on it here at DEATHCON and it was super sweet so you should check that out. Oh, no. Technical errors. That came at the perfect time actually. Oh, wow. Okay. That's what we're doing. Yeah, we're doing shots. Okay. So he's a first time speaker and actually has a little story. Go ahead. Go ahead. I guess he mentioned that you went to DEATHCON like what? DEATHCON 16. DEATHCON 16, he met someone. No, no. I met Julia, my wife here. He met his wife here. Yeah. You know. Give him a hand, huh? Cheers. Cheers. Welcome to the Clare Box. Cheers. That's good. Thanks, man. Now back to the show. I mean, if I can deal with the laptop issue. Are these guys doing all right? Should I kick them off the stage or do you want to keep listening to them? I can go. Do you want to keep listening? All right. I guess you can start. Okay. Can you give me a second until my throat stops burning? No. Okay. All right. All right. Let's see if this works. Sweet. Okay. So file upload attacks are a thing. I've never seen any better presentation to guide you along the road of file upload attacks than this guy, Sarusha Dali's presentation. And if I butcher names, I'm sorry. I love all these guys. They're bug hunters just like me. About file upload vulnerabilities. This includes doing new and novel attacks as well as old attacks to get files past black lists or upload bypassing extension trickery or stuff like that. I'm trying to give you guys resources as well, like the ones I would use. A lot of this actually got parsed into the new OWA's app set testing guide, most of it at least. So I would check that out too. As an intro to malicious file uploads and getting shells and web shells and stuff. Oh, this is what I talked about, Dan Crawley. And I don't know that guy's real name. But yeah, these are the types of binary files that can execute in different ways. So you can see they have a PDF that's a zip, that's a MBR or so. Interesting research here coming out there. I would like to see interesting bugs come out of it. So remote file includes and redirects. Common parameters there. Destination continue redirect, URL, URI, window next. Common black list bypasses. These are all kinds of escaping tricks that you use normally in web stuff. But these are the most common ones I found. These are also insect lists in the LFI and RFI fuzz lists that I use often. So for RFI. These are the common parameters. File folder, path, style, template. Yes, yes, yes, yes. So these are where I saw the most bugs or other researchers published data around their RFIs. And so these are kind of the type of parameters you can do. And I think eventually, right, the thing you do here is you write a perfect extension. I haven't yet, right? But that just like automates any time you see these. It sends it to like logger or something like that. So you can just go test them later. I haven't done it because I just do it with eyeballs, but it's probably the better way to do it, is write an extension to do this work. Okay. So cross-site request forgery. How much time do I have? Ten minutes? Okay. I think I can do it. Okay. So CSERF, everybody knows about CSERF, right? Like how do you execute CSERF? You find some function in the website that does something, right? And you, it's a security related function. Change password or whatever, right? There's a list later of the functions. And then you right click and burp and create proof of concept. That's like CSERF nowadays. So what you really have to focus on in bug bounties is CSERF bypass. It's customers who have CSERF protections but haven't implemented them enough. So common CSERF bypass is in my research, Yielded, removing the token from the request, removing the parameter value from the request, adding control characters to the parameter value, using a second identical CSERF parameter or changing the request method. So check this out. This tool has gotten no love. I don't know why. I think it's been out for two years already. Have any of you used this tool before? No. Good. Give you something to take away. So what Burpee does, you enable logging and burp and you crawl a site completely that has cross site request forgery protection in it, right? Like a CSERF token. And then you create this template and tell it what the token was, what a good result is for getting a page, what an error page looks like. And this template is actually really easy to edit. This is the sample one. This has been out for, I think, two years already. I don't understand why people don't use this super sweet, right? So then you write this template. It's a Python script. And then you run his Python script Burpee on your Burp log file and it re-requests all of those across the whole domain, every request that you've ever made in Burpee, re-requests with those first three attacks for CSERF bypass. Then it produces an HTML report telling you which ones gave different error messages, which ones came out the same and prioritizes CSERF bypasses for you. So he made a lot of money doing this to Facebook and Twitter. Because it wasn't a direct Burpee extension, it didn't get a lot of notice. I randomly found it on GitHub and I was like, sweet, this is awesome. So this is part of the HTML output. Here's the base request. Here's the crafted, the first crafted request and then the response. And then you get a report back saying if they came back the same, it diffs them. So I highly suggest that tool. It's linked in the talk. Another way to do it is just to check for every request across a whole Burp log file that didn't have the token in it, the actual parameter. So this is another script that does that. It's another Python script that runs on a Burp log file also that went undetected kind of a little bit. So super sweet. I use these all the time and finds bugs with these all the time. So CSERF just some common critical functions like add and upload file, you know, password change, email change, transfer money, your currency, delete a file, edit your profile, things like that. So these are commonly where you see CSERF that rewards big bugs. So privilege, transport and logic kind of get mashed into a section. So privilege, you know, auth and logic kind of get blurred a lot but my testing thing is just, you know, you have an administrative user, you need a couple of accounts to do this and then you have a low privilege user. And then, you know, the low privilege user just tries to directly call functions that are only for an admin, right? Pretty simple. But to automate that across multiple functions, you might need some tooling. So this is what I use for that. It's called autorize. This one is available on the Burp store. And basically, you spider a site completely, you run through it, all of your post requests as an admin user, then you go through as a lower user and you give that information to autorize and you run the tool and it tells you which ones the lower user was able to access that the admin user was also able to access and you look through those in your Burp output. So common functions or views that I check for privilege escalation or anything like that and these can be actually combined with the last two sections. Add a user, delete a user, start projects, change account info, view customer analytics or like there's a page that tells everything about whatever that site does. You want to try that view, payment processing view like receipts or any view with any PII on it. You want to focus on. So this is what that looks like. Autorize, browse using a high privilege user, log in with a low privilege user, Burp re-requests everything and gives you prioritized output. So insecure direct object references is one of my favorites because I want a badass pair of gaming headphones a couple months back. So I found a bug in a really cool company and I had to disclose it and I ended up calling them on the phone and their help desk guy was like I have no idea what you're talking about and then I actually linked in spam to everybody of the IT group of that company and finally someone accepted and I tell them listen I'm legit, I'm not like an asshole, I'm not extorting you, I just want to tell you this exists because I was buying a pair of headphones already and they're Astros by the way, they're awesome. And they fixed this bug. So the receipt function basically was an IDOR, you could just iterate up and down and find other people's receipts with their credit card info on it. And they sent me two free pair of headphones and I have one and one goes to Daniel for his birthday but I forgot to bring it. I'm sorry, but they're sweet headphones, I guarantee they're awesome. Anyway so IDOR is five minutes, okay cool. So increment, decrement, negative values, attempt to perform sensitive functions, substituting user IDs, things like this, these are how you test IDORs. These are common functions of user files that deal with IDORs so everything from the C-SERF table, anything that says UID, password or user hashes, emails, images that are supposed to be private. So you can go through the slides and kind of go through this. And all this is going to be up on GitHub and if you have questions or whatever. So this is a simple IDOR, I don't know why I put a simple IDOR in here, this is DEF CON, you guys probably knew this, you see this numerical value and you're like oh what happens if I change it and you get someone else's receipt. This is exactly what I did to another place. This was a disclosed bug that's patched so don't worry about that, they had a bug bounty. Transport, you need to enable HTTP everywhere, there's this awesome script that will basically take up our blog file, again, every request in your site tree over HTTP instead of HTTPS so you can see what's going over insecure channels. Instead of having to sort columns and burp and do all this stuff, I find this really useful so it will try to downgrade everything and then you report like this is a SSL downgrade attack or whatever. Logic, logic clause are usually pretty manual. The one I see a lot is substituting hash parameters where there's like prices or something like that and they've hashed it and it's irreversible or they've done something to it and it's irreversible or I'm too dumb to reverse it, right? But just finding another item that's cheaper, taking its hash and substituting it and usually what it's an e-commerce payment or something like that and so doing that usually yields the product for less money. So step manipulation, this is like the bread and butter example everybody gives for logic clause, like there's multiple steps like order or put things in cart, order, check out, pay, ship, so you just skip everything or you put everything in your cart and then you just ship everything because you have the whole process in verb and so you just skip a process. Using negative quantities or using negatives and quantity values, so I've actually had websites pay me credit because I put in a negative value on some price thing or a negative quantity, right? Like order number equals one, usually I want to buy one thing and I put in like negative 20 and then they've credited my account like $1,000 or something like that. Mission level DOS, this is one that's kind of interesting, right? It's not actual DOS, right? I'm not advocating bug bounty like using a bot net or anything like that but I've seen sites that just can't handle just like parsing a parameter with, you know, 40 zeros in it or something or me putting in like a math function as a parameter value and the server is like, I don't know what to do, let me try to process this somehow and it just falls over so those are interesting. And then timing attacks, I think there was a DEF CON talk about timing attacks so you can check that out. I'm really running in, so data storage is really important, check these files for data storage as well as logging. This is the best tool to quickly get spun up on iOS, it's called IDB, it's by Daniel Mayer, basically jail breaker phone, install this tool. It gives you a full GUI list of the handler of all of the files, all of the encryption values, if it's using exploit mitigation, et cetera, et cetera, et cetera, it's the most functional tool. I think it's partly based off a talk I gave a long time ago and he made it in Ruby and it's super sick, it's the best way to get into iOS testing if you've never done it before. This is a thing about logs, we got to go. Those other volums, I repeat them again, don't discard them, content spoofing, refer to leak which, security headers, path disclosure, keep them in your pocket later to escalate if you can use them. This is one idea of like, if I have five or 30 minutes or something like that, what can I do? So I tried to time myself with the methodology using this stuff in here. So in 15 to 30 minutes I can do most of this using Burp and the automation, maybe an hour, it depends on how motivated I am. So these are the steps I'd go through, I'd register, I'd hit the password reset, I'd go to all the forms that do security functions, I'd check the cookie, I'd perform a numeration on any UIDs I see in the URL, I'd directory brute force using one of the short lists in the background, I'd upload a file if it had uploads and within 30 minutes or an hour I can usually find some pretty darn good bugs. Things take with you, crowd source is different, it's the same but different. You find like 20% of the edge case stuff instead of 80% and a lot of stuff goes quick, data analysis is cool, you could probably do a 15 to 30 minute web test and done right, you could get some major volums, set lists, polyglots are cool and follow all of the bug bounty people on this list, I put them all into a Twitter list for you and you can watch them hack things and talk about their findings. Also, there's a lot of stuff that didn't get put in here, there was a lot of data that I didn't get to parse, 50% of the data is still unparsed, someone put it up on GitHub as a get book I think or maybe just mark down and you guys can contribute to it if you care enough, if you just want to take it and use it, that's fine. I have to go in there, more tooling that I found, XSE, that's actually meant to say SSRF, a bunch of cool SSRF techniques, capture bypass, more detail on logic flaws and to add Android mobile tools that I use often. 13 memes, is that okay? Good. All right. Attribution and thanks, these are bug hunters who did things in this presentation, all of them are super awesome, I respect every single one of them or who made tools. Also my team at bug crowd, John, Todd, Ben, Ben, Grant, Fati, Patrick, Katie, Kim, Abby, Casey, Chris and Sam and everybody in the bug community, I love you guys, I love doing this for a day job. That's it. Thank you.
 This is how to shot web, better web hacking and mobile hacking in 2015.  I know Dan Kaminski is talking right now so I really appreciate everyone being here.  He's way smarter than me.  So this is me.  I work for Bug Crowd.  I'm the director of technical operations.  I manage a team of hackers who validates the bugs behind the scenes of a bug bounty, large  scale bug bounty program.  In 2014, I participated as only a researcher.  I didn't work for them yet.  And this talk is about my methodology that I used there to do web hacking as well as  a little bit of mobile stuff, as well as stuff I learned from other researchers while doing  this work.  So what is this really about?  It's just how to hack stuff better and practically.  And I put a lot of memes and some of them are not funny, apparently, my wife says.  So it's okay.  Some more specifically, what I did is I started off with my methodology, which was a normal  pen tester methodology when I started doing this work, a basic web application assessment.  And so I then went out and manually parsed out all of the public researchers of all the  bad bug bounty hunters I knew.  So there's about 150 people that I knew just around the Twitter scene, not Twitter scene,  sorry.  Twitter scene, as well as people I just knew who were good at it.  And so I went through every single article they had ever written from the beginning of  the crowdsource bug bounty scene.  And also all of the Google and Facebook programs that I could find, like enterprise-based bug  bounty stuff.  And I created a presentation around what I distilled around that knowledge.  So this is kind of the stuff that I'm going to bring in this presentation, philosophy  shifts from doing bug bounty testing to, you know, from web app testing, traditional web  app testing, discovery techniques, mapping methodology, parameters often attacked, useful  fuzz strings, bypass or filter evasion techniques, and some tooling that I think is cooler than  other tooling.  So cool.  So the first section is philosophy.  So the differences between kind of bug bounty hunting and being a web pen tester, you know,  I'm not really to argue this debate.  There's a lot of people who feel strongly about both sides and they're both right, honestly.  But when you get down to the practical work, you introduce a lot of stuff here.  You introduce time onto a security tester, right?  They're not used to competition when they're doing this kind of stuff unless you're playing  in a CTF, which, you know, you're used to that.  And I played in some CTFs, so I was kind of used to it.  You know, you're only incentivizing it in one side for what you find and not the hours  you put in.  So, I mean, this is a basic overview of how they differ, but the talk's more about the  technical stuff.  But yeah, you basically tailor your methodology based around finding stuff in the 20% as opposed  to the 80% across application assessment.  So we'll go into how that 80-20 rule kind of fits in the rest of the slides.  So if you're doing regular web app assessment, you're following these two Bibles, right?  The OAS testers guide or the web application hackers handbook.  This is usually what you're trained from and what your internal methodologies are built  off of it.  Almost any of the good consultancies.  And the authors are, you know, super great testers, right?  But these take you from A to Z. And, you know, even though they find good bugs, they take  a long time to complete in their full scale.  So bug bounties are different.  So if you want to do web hacking, you want to get started, these are what you go for.  But my talk is a little bit different.  So let's talk about discovery in web application assessment for a bounty.  So what you want to do in a bug bounty is basically find the road less traveled.  And this is if you're aiming to get paid, I think.  So you can attack the flagship application that the company has, right?  But really, that's not where the vulnerabilities are going to be most of the time.  That application has been tested by a pentest team.  It's probably had a bug bounty on it for a long time.  What you really want to find is the parts of the applications that are like subdomains  or maybe obscure web servers on different ports.  You want to find acquisitions that maybe the company has had recently that came in from  a different development team.  And they might have a whole slew of problems that came from a whole different group.  You want to look at functionality changes and redesigns on sites, mobile websites, because  they're set to render differently on your phone.  And also new mobile app versions when you're testing.  So we're going to go into some tools and stuff I use to find a new surface area for  you to attack.  So reconNG is this tool that basically allows you to do a whole bunch of automated OSINT  stuff.  And one part of it is it has all these modules to do subdomain brute forcing and subdomain  discovery.  Now subdomain discovery is a big part of finding applications that have been left out there.  I mean marketing spins up a site, dev spins up a test site, like you have integration  stuff left up.  So finding those and hacking those and getting RCE or code execution through those sites  is kind of where you can get big payouts.  So this script, what it does is it iteratively scrapes Google for all subdomains on a given  web property.  So let's say Acme.com.  This will find, this will scrape Google for everything that is in Acme.com and then iteratively  remove those results until you're down to this long list of subdomains.  It also scrapes Bing, Bydude, Netcraft and brute forces subdomains like your common fierce  tool would.  So this is on GitHub.  It's a simple shells wrapper around reconNG.  So you need to have reconNG installed.  If you use Cali Linux, you can just pop the script in and go.  So yeah, so this is the output of something like that against a company like this.  You can see there's a lot of output.  You can see a lot of domains here that have gone under assessed as far as you go.  This is that idea of iterating through Google to find subdomains.  So here you have site and then minus dub, dub, dub sites.  And then I found on the first hit was Sandbox.  So I removed that on the next run through.  And this is that scraping that's happening that the tool is doing.  And then you get more entries floating to the top.  So you get credit apply or business or shopping or advertising and you just keep on removing  these until you have all of them.  And then you brute force and then you end up with a huge list of sites to assess.  And then you want to go through and on your entity that you're attacking, you want to  find any mergers or acquisitions that maybe aren't the domain that you're given.  But they've just purchased a company.  So Oculus purchased by Facebook, had some bugs and they got popped as soon as they were  acquired and they were not under the Facebook six month rule or I don't know if it's six  month or I can't remember how long.  But yeah, they got popped immediately.  And that was a whole different dev team but owned by Facebook and worthy for an RCE bug.  They got hit with SQL injection and a custom header and that was great.  Well, not great, but it was good for the bounty hunter.  So Wikipedia for Facebook and Google does this really well.  People update these things all the time when there's an acquisition for stock reasons.  So keep an eye on these if your company has purchased something else and they have some  new domain and it might not be in the bug bounty brief yet, you can go after this.  If you're doing those types of bounties.  There's also a repository of links of every kind of phone that's come out on Facebook  and PayPal and Google.  I like to share this information.  This one is hosted on Facebook.  I have no idea why.  The links in there and the slides have hyperlinks.  These are all the blog articles that reference bugs here.  Why is this important if somebody else has already found these bugs?  Because bugs get represented across the domain in different places.  So you can tell a lot about an organization once you read these articles and find the  same bug in other locations.  Like those subdomains you found, maybe rogue web servers and things like that.  It also kind of tells you what they're going to do to fix them, like how they filtered  out input.  You get a lot of intel around the application.  So really doing a lot of research on your target can't help.  But it's not the fast stuff.  So port scanning.  I mentioned port scanning.  So port scanning is not just for NetPen.  So yeah, I mean, how I hacked Facebook, there was an article by Ryan Dewhurst who was like,  I started up port scanning and found some weird server which was a Jenkins script console  with no auth.  And that was it.  So I got in.  Simple as that.  Like $8,000 bug or something like that.  Or even more, I don't remember.  So is.net, the Microsoft domain that evangelizes.net had RDP open to the world with MS-12020 on  it, vulnerable.  So that was the thing.  So yeah, just go ahead and use a simple end map syntax to start port scanning all of your  sites and make sure you check all those services.  This syntax will port scan for all ports on a domain as well as pull out any HTTP servers,  titles and display those in the output.  It's a SIN scan and OS fingerprint and stuff like that too.  So mapping.  So you found all of these new servers, right?  Like maybe subdomains or maybe you found an acquisition or something like that and now  you want to move into mapping an individual application.  And taking notes is really important when you're doing this, whether you're doing it  inside of like a notepad or just using pen and paper or like Evernote.  I use Evernote.  All my bugs are templatized so when I find them I can just copy and paste into the disclosure  email or whatever like that.  So these are some mapping tips that I use right away.  So Google is actually your friend, right?  You can get a lot of parameter information from just Googling a domain and figure out  like what happens there.  I know there's some like parameter parsing scripts.  I couldn't find a really good one for this presentation but just will parse parameters  out of the Google cache stuff.  But really the next big thing is directory brute forcing, right?  Finding unlinked content.  Content that's not supposed to be there.  So a lot of people use like Durbuster or Content Discovery and Burp for this kind of thing.  And that's good.  They're good lists but those lists were created by going out and spidering the Internet and  finding every path after the top level domain and then prioritizing them.  There's some other lists that are better for this type of work.  So the raft lists are these lists that came out of a talk maybe four or five years ago.  Raft was an application proxy.  It was a decent one but it's since been discontinued but its lists for directory brute forcing have  lived on.  They are a spider of the Internet's Robot Docs text files.  So everything that everybody doesn't want you to see is in this directory brute forcing  list.  So it's super sick.  I can't tell you how many bugs I found just using this list.  Like config files, badly configured git stuff.  It's just all over the place.  SVN Digger is another list like this.  They went out and spidered all the SVN projects.  So if your site or your target is an open source place you can take all the paths that  have been converted for you to directory brute force to get better application coverage or  find config files.  Git Digger is the same thing for Git.  So after you do some unlinked content discovery or directory brute forcing whatever you want  to call it you move on to try and identify your platform.  So there's just some really simple wins here.  Wapilizer and built with are Chrome extensions that you can just click and they will give  you pretty much the whole stack by looking at the headers, the comments and the pages,  the way they render like analytics things that have been integrated and they'll just  give you like the whole server stack.  And they'll even give you version numbers if they can identify them.  So Wapilizer and built with are super sick.  Retire.js is one of my new favorites.  It will profile all of the server side JavaScript libraries and tell you if they're out of date  as well as give you all the vulnerabilities before that patch or your vulnerable version  has.  So you'll get a list of prioritized cross-site scripting or whatever is in jQuery at the  time.  And then once you identify all of these servers, version numbers, you just go check for CVEs  and server side stuff.  So that's pretty standard.  That's web stuff.  But these are some good tools.  Now if you happen to come across a CMS which is like the pentesters training because those  things suck and the plugins suck, you want to use these two tools.  WP scan for WordPress.  A lot of people use this already.  It will identify all plugins and users for WordPress install as well as look up any volums  that are associated with those plugins that have been disclosed.  And then CMS map for Drupal and what is the other CMS Drupal and?  There you go.  Thank you.  Awesome.  So those are the two that have really yielded any value for me across CMSs.  So here you see a screenshot of WP scan.  And it's, you know, found a version of a plugin or a theme that already has like cross-site  script or a file upload vulnerability in it.  Sometimes there's false positives.  Honestly, for what this script does, it provides so much value.  So it's great.  So the directory brute forcing, we talked about a little bit earlier.  I mean, the workflow for this, a lot of people do.  But I just put the slide in here because I see a lot of people do it a little bit weird.  I see people brute force like off the top level path a lot and then just stop, right?  And so they'll get some errors and they don't know what to do with it.  So they'll go to acme.com and get a 200.  And then they'll go to backlog and they'll get a 404 and they'll get more 404s and more  404s and you know there's nothing there.  But then they'll hit like control panel and see a 401.  And then they'll be like, well, I can't do anything that I'm not authorized, right?  So they don't brute force after control panel.  There's so many like messed up access control on web server bugs that you can exploit.  If you just brute force after that, you'll probably find something.  So I just see this a lot where people stop after the top level domain when they're doing  directory, you know, enumeration.  So that's kind of the workflow you're doing there.  Some other things that you can do is mapping and vulnerability using open source intelligence.  So these are one, two, three, four, five sites, six methods that you can use to find already  published bugs or almost already public bugs.  I mean, I guess they're considered like end day or whatever.  But xss.com, reddit, XSS, punk spiders actually a burp engine that just scans the Internet.  So if your target is a high profile site, information might already be in here for your  test and you can pull it out and use it to your advantage.  Even if those bugs have already been disclosed and I've found bugs that were on here but  not disclosed to the customer through the bounty, so that's actually worked before.  It was like a super easy win.  They help you get a feeling for what the company has faced before as far as issues like prevalent  cross site scripting, cross site request forgery, file uploads.  And then you can do regression testing on all the domains that you found earlier in the  presentation.  So yeah, go out and use these resources to try to find bugs in the platform as quickly  as possible because they're free and they're already out there.  And the customer should know about them anyway.  It's the responsible thing to do.  Okay, so this is my intern Ben.  He's never spoken before at DEF CON.  Neither have I actually.  This is my first DEF CON speaking.  But he did an awesome project and he's going to talk about it for a couple seconds.  I really like it.  So hello, everyone.  My name is Ben.  Like Jason mentioned, I'm an internal bug crowd on Jason's team.  For the past couple of months, we actually gathered a bunch of JSON files that includes  all the metadata for each bug bounty program that's out there.  So there's 250 plus bounty programs that are included in this project and they all include  information like how much a minimum bounty is, how much a maximum is, what mobile apps  are included, what web apps are included and what's not included in the scope of the program  as well.  And we actually use all this data and fit it into different scripts like you can see  on the screen.  We fit it into NOC and it just went through all of it.  Every single one of those programs and brute force them for subdomains.  And this also is available on GitHub account and everyone can go and use it if they want  to.  So the JSON files look similar to this.  This is Yahoo's program a couple months ago.  If that's updated, we don't know.  But what we have is a DNS record that shows that's the yahoo.com itself and all subdomains  of it and Flickr and all subdomains of Flickr are included in the scope as well as all the  mobile apps that are included in the scope as well.  And as you can see in the bottom, there is two domains which is yahoo.net and its subdomains  and yahoo.net itself not being included in the scope of the program.  So what we ended up doing with this using Ruby, we wrote a script, we fed every single  one of those JSON files and we crawl them.  And using grep, for a sample for this one, we grep redirect and you can see there was  a, we couldn't disclose the domain but there was a bunch of sites out of out there that  had to redirect out there that you can easily report and take them out and report to the  vendor.  Taking it further, we, same idea, we use all the JSON files and we fit that into Intrig,  which Intrig is an API framework that is for intelligence gathering and it does a bunch  of tasks that you can see on the right left side of the screen.  Includes doing supplement brute force, web spider, end map and you name it, we can do  it with Intrig.  So also Intrig is available on GitHub as well, it's open source, go ahead and fork it and  commit to it if you need to.  We ended up doing four Intrig as we parsed every single JSON file with help of Ruby and  I can see at the line when it says R, we are taking the task which is called DNS brute  sub which is a supplement brute force and we need to give it an entity and options that  are all included in the manual and we are running that for a JSON file which at the bottom  shows it's being assigned an ID that you can just go in your local host and check it out  and see what Intrig has found.  So for example we did Intrig.io and for DNS brute force you can see all those sub domains  that have been out there that Intrig found with their IP addresses as well.  And make sure you guys check it out, it's like I said it's online and you guys could, the  possibilities are it's infinite, you can do whatever you can think of out there with those  and being a bug bounty hunter I think it's a huge tool for everybody out there.  Awesome.  Yeah, that's a sick tool and a sick framework both mapping and recon entry.  Like I mean if you've used Focca and Maltigo and everything like that it's like an open  source version of those licensed tools.  I love both those tools by the way, just saying like using both if you can but Intrig is going  to be sick, you guys should check it out.  Okay, so on to, where are we at?  Off in session.  I'm going to have to blow through some of this because this presentation is long and  there's a ton of stuff in here.  So auth related bugs.  The one thing I want to say about these, these are low shallow bugs that everybody hates  people to report in bug bounties.  The problem is if people start not paying attention to them you can't chain them to  do bigger things.  So we've had multiple bugs or I've had multiple bugs where we've had a couple small issues  like with password resets or something like that and then we've chained them to make a  critical, critical account takeover bug.  So these are really important but these are the kind of bugs that a lot of people see  in the hashtag like beg bounty instead of bug bounty.  People really don't like them.  Don't discount them, just note them and if you don't want to, if they're out of scope  don't do anything with them but you might be able to use them later.  That's all I really have to say about some of these.  So session, the kind of same things, right?  So failure to invalidate old cookies, like new cookies on login or no new cookies on  login and time out, never under cookie length.  These are all things you're going to be able to use later when you need to chain bugs but  a lot of times they're out of scope.  So either out of scope or unappreciated or duped or something like that.  But yeah, you should keep them in mind when you continue testing because they can be chained  into bigger issues.  So the big part of this one is actually tactical fuzzing.  So I go through a couple different injection types or vulnerability types here and so we're  going to talk about cross site scripting and some research that some really cool people  have done.  So the core idea of cross site scripting, right?  Does the page functionality display something to the users?  That's kind of the question I ask myself.  Can I get reflections somehow with JavaScript?  And so you can do manual testing which is great, right?  And you can enter in your meta characters and see if they return.  But really when I'm trying to work fast in a bug bounty I have three or four like magic  strings that I use.  And so you probably use them before.  The technical definition for them is polyglot payloads.  These are web polyglot payloads.  And so the first one you'll probably recognize.  This one is arsenakes.  They used to call it the arsenic battering ram or when I worked in pentests they used  to call it came out of the XSS cheat sheet.  You probably use this before.  You put it into the search bar or comment field and then you pray that you get cross  site scripting, right?  So this is the first one.  This is actually a multi-context filter bypass based polyglot web payload.  It's a mouthful, I know.  But basically it's designed to evade filters.  It's allowed to execute in different web contexts.  And it's really cool.  So I have three of these strings that I cite here that if you're just doing bug bounty hunting  you can use and just kind of move along on your critical functions on the site.  So this one is from a researcher named Sharjah Ved.  He does cross site scripting research.  I think he did his PhD in cross site scripting which to me blows my mind.  So this is a multi-context filter bypass based polyglot as well.  So you can see here that he's trying to mark up in a whole bunch of different contexts.  He's got an at sign here to trick email filters or maybe a form only takes emails or something  like that.  He actually ran this along like the Alexa top 100 and 80% of them were vulnerable to  just their search parameters with this string.  So Moramo for you guys doing bug bounties.  This one is one by Matthias Carlson.  Is he here right now?  Is Matthias here?  Hey, there he is.  He's awesome.  So he did a whole presentation on this idea, polyglot payloads and websites.  So this is his multi-context polyglot payload.  And so this is one that I use now.  So thank you.  Other XSS observations when I started parsing bug bounty work as well as getting bugs myself.  So finding input vectors is important.  So finding customizable themes or profiles that you CSS but then you can trick them into  using JavaScript to execute cross site scripting.  A lot of names of like events or meetings in any application that deals with those types  of things.  A URI based XSS is still a big thing when people pull things from the URI and render  it for some reason.  Importing from a third party, so things like Facebook integration where there may be filtering  characters but your site actually displays Facebook data in line.  So you can set your name on Facebook to script alert and it will alert on this site.  JSON post values that didn't return the correct content type.  A lot of people discount web services right away because they think that the content time  won't execute cross site scripting or won't execute JavaScript.  And so you have to really check and make sure they're returning the content type otherwise  you can get reflected XSS and a lot of web services like that.  File upload names when you're uploading file just try to change it to script alert or whatever  like that.  It's going to echo that file name back usually a lot of places.  Uploaded files themselves.  This is a huge one actually that's all over the place.  So a compiled Swift file or an HTML file that's designed to execute its own JavaScript and  you basically attack a file upload.  So a lot of file uploads, there's a whole section here about file uploads.  We'll talk about it more in a little bit.  Custom error pages where they're echoing out what you can't find, put XSS strings in there.  Fake parameters where the page might parse some fake parameter data and put it into your  response and then log in and forgot password forms.  Also this is a Swift parameter XSS is a huge thing as well.  I don't think I've ever found a Swift file that I've decompiled that hasn't been vulnerable  to either cross-site scripting or remote file include.  Actually Dennis here is the guy I ask questions to that all the time.  So there's things like J player and all of these like caught software that are Swift  files that do like media or whatever.  So there's a whole OWAS page on the common params that these players use and then also  the injection strings but these you have to kind of do more manual analysis.  So to do that manual analysis I use this tool called flash bang which I think is super awesome.  It's by cure 53 you drop it a Swift file on the other end comes out all of the parameters  that might be vulnerable to cross-site scripting.  It decompiles it for you and it displays them along with if they're going to execute  out of the context of the Swift file.  I highly suggest this tool if you're going to do some Swift hacking.  It's way better than a lot of the old ones.  So SQL injection.  The core idea does the page look like it might need to call on some stored data obviously.  This is Menteus SQLI polyglot where it will execute in single quote, double quote and  straight into query context.  So I've seen a lot of cross-site scripting polyglots and you remember these are things  that actually scanners are starting to do.  They don't want to send a million fuzzing payloads to a parameter because you have like  eight million parameters on a page so it just takes forever to scan things.  So Menteus in his presentation has this string and I imagine a lot of fuzzers, web fuzzers  and scanners will start to pick up on this type of thing if they haven't already.  The idea of these multi-context injection strings.  So this is awesome as well.  So for SQL injection to kind of go through and fuzz things I also use this project called  the sex list project and it's got a whole bunch of fuzzing lists in it.  It was a fork of the fuzz DB and then we added to it with username and password lists and  all this crazy stuff.  Daniel Measler here actually helped me curate it and we decided together.  And it's invaluable, right?  It's got like by type of injection so if you want to just do like a login bypass in my  SQL it's got all those curated, all those strings curated that you would usually use  as you SQL injection there.  I highly suggest using this and I just load these into the burp into intruder when I want  to attack a form or something like that.  Some parameter I think is vulnerable.  So other observations.  So blind is the predominant SQL injection.  You hardly ever get error based SQL injection anymore.  And so like in those cases you use like benchmark strings and stuff to make the page take a  long time to load and that's how you identify.  Whether you take it the whole exploit way is up to you, right?  We have a lot of researchers I know who just want to identify and move on, right?  I like to run SQL map eventually because it's still king.  I mean there's no other tool that does it as good as SQL map.  And that's actually something I learned doing the research was that everybody use SQL map  at some point.  So yeah, some tips for SQL map.  Basically when you're doing this you can actually parse a whole burp log file so like enable  burp to do logging and parse the whole log file and actually fuzz the whole log file  with SQL map.  It takes forever.  It's not like the greatest way to do things but it's also offering a lot of coverage.  If you're up against some kind of like black list or something like that, SQL map has tamper  scripts that you can use which basically encode all of your attacks so that you can try to  evade black list.  There's a really good guide on there.  It's somewhere on the bug crowd forum on DBMS specific syntax for SQL map tamper strings.  So if you're going up against MS SQL or MySQL or something like that, there's a simple string  you can pass into SQL map and start fuzzing those parameters and get past black list.  And then a really fast way to instrument SQL map is SQLI PI which is a burp extension  and basically allows you to right click on any window and burp and send that request  to SQL maps API running on your local box.  So you can just be inside of a burp, right click and start fuzzing the parameter if you  need be.  So some common parameters and injection points like any ID value, currency values, item number  values, sorting parameters, I'm not going to go through all these.  They're all on the slide.  And eventually this is all going to be on GitHub anyway so you guys can just grab it  and use it in your methodologies if you think it's useful.  But these are the kind of places where I saw the most injection and where I, you know,  my research parts out of other places showed me.  This is SQLI PI so right click on a request, send it to SQLI PI scan and now that burp  renders scanner results in the target tab but it doesn't look like this anymore but you  get the idea.  So this is my cheat sheet of SQL injection resources when I do SQL injection broken down  by my SQL type and these are cheat sheets that let you know manual syntax based on my  SQL.  A lot of these people are like pentas monkeys, lists are old, they're still the best.  You have to use these and you have to have them handy when you're doing injection.  So there's some really edge case ones at the bottom like access which God who uses access,  that sucks.  Ingress, DB2, Informix, XQI3 and Active Record for Ruby on Rails.  So I keep those handy in my Evernote when I'm doing SQL injection testing and when I  see errors or long load times or something like that I start getting in that mode.  So file uploads and file inclusion is the next area.  So local file inclusion, the core idea is does it or can it interact with the server  file system.  Liffey is my cool favorite tool for doing this.  Also you can do it manually so I have all of my LFI scripting stuff up on SecList under  fuzzing and LFI.  So you can see here I've tried a bunch of blacklist bypass or encoding to try to get  common system files.  This is on the SecList project.  Common parameters or injection points for this type of stuff is like you would think  of this but it's good to have it in the list.  So like file, location, locale, path, display, load, read or retrieve, these are the most  common parameters that you'll find those in.  Malicious file uploads.  This is an important and common attack vector when doing this type of testing.  Not only just to upload like a Swift file and get XSS off of it but you can also do  pretty cool attacks.  One of the ones I like a lot and it's a DOS, basically an image that specifies itself to  be super large but isn't so you can upload it and the server will write all this or will  allocate all of this space for it on disk but it's actually not that big of a file and  you can DOS the application server using images crafted like that.  There was a whole blog on it.  And then you can actually, one of the things I think is interesting, I'm not going to go  into too much but there's a slide about it, is bypassing like security zones and storing  malware on client servers.  So there's as well as polyglot web payloads.  There's also polyglot files which can execute code in different contexts.  Like if you think of a parser reading a file, it basically will look until it finds what  it wants and then execute that.  So you can create like a jar that is actually an executable.  So if I make an executable that is malware but I upload it to your server because you  allow me to allow a jar, well is that a vuln?  Like I don't know.  Like you are technically storing malware on your server for me, right?  And I can send the black hats to go retrieve it but can you do anything about that, right?  Are you going to implement a parser to look through the binary data and cut stuff out?  I don't think so.  It's kind of hard to do.  So interesting question there.  It's kind of another road.  Dan Crawley did a presentation on it here at DEATHCON and it was super sweet so you  should check that out.  Oh, no.  Technical errors.  That came at the perfect time actually.  Oh, wow.  Okay.  That's what we're doing.  Yeah, we're doing shots.  Okay.  So he's a first time speaker and actually has a little story.  Go ahead.  Go ahead.  I guess he mentioned that you went to DEATHCON like what?  DEATHCON 16.  DEATHCON 16, he met someone.  No, no.  I met Julia, my wife here.  He met his wife here.  Yeah.  You know.  Give him a hand, huh?  Cheers.  Cheers.  Welcome to the Clare Box.  Cheers.  That's good.  Thanks, man.  Now back to the show.  I mean, if I can deal with the laptop issue.  Are these guys doing all right?  Should I kick them off the stage or do you want to keep listening to them?  I can go.  Do you want to keep listening?  All right.  I guess you can start.  Okay.  Can you give me a second until my throat stops burning?  No.  Okay.  All right.  All right.  Let's see if this works.  Sweet.  Okay.  So file upload attacks are a thing.  I've never seen any better presentation to guide you along the road of file upload  attacks than this guy, Sarusha Dali's presentation.  And if I butcher names, I'm sorry.  I love all these guys.  They're bug hunters just like me.  About file upload vulnerabilities.  This includes doing new and novel attacks as well as old attacks to get files past black  lists or upload bypassing extension trickery or stuff like that.  I'm trying to give you guys resources as well, like the ones I would use.  A lot of this actually got parsed into the new OWA's app set testing guide, most of  it at least.  So I would check that out too.  As an intro to malicious file uploads and getting shells and web shells and stuff.  Oh, this is what I talked about, Dan Crawley.  And I don't know that guy's real name.  But yeah, these are the types of binary files that can execute in different ways.  So you can see they have a PDF that's a zip, that's a MBR or so.  Interesting research here coming out there.  I would like to see interesting bugs come out of it.  So remote file includes and redirects.  Common parameters there.  Destination continue redirect, URL, URI, window next.  Common black list bypasses.  These are all kinds of escaping tricks that you use normally in web stuff.  But these are the most common ones I found.  These are also insect lists in the LFI and RFI fuzz lists that I use often.  So for RFI.  These are the common parameters.  File folder, path, style, template.  Yes, yes, yes, yes.  So these are where I saw the most bugs or other researchers published data around their RFIs.  And so these are kind of the type of parameters you can do.  And I think eventually, right, the thing you do here is you write a perfect extension.  I haven't yet, right?  But that just like automates any time you see these.  It sends it to like logger or something like that.  So you can just go test them later.  I haven't done it because I just do it with eyeballs, but it's probably the better way  to do it, is write an extension to do this work.  Okay.  So cross-site request forgery.  How much time do I have?  Ten minutes?  Okay.  I think I can do it.  Okay.  So CSERF, everybody knows about CSERF, right?  Like how do you execute CSERF?  You find some function in the website that does something, right?  And you, it's a security related function.  Change password or whatever, right?  There's a list later of the functions.  And then you right click and burp and create proof of concept.  That's like CSERF nowadays.  So what you really have to focus on in bug bounties is CSERF bypass.  It's customers who have CSERF protections but haven't implemented them enough.  So common CSERF bypass is in my research, Yielded, removing the token from the request,  removing the parameter value from the request, adding control characters to the parameter  value, using a second identical CSERF parameter or changing the request method.  So check this out.  This tool has gotten no love.  I don't know why.  I think it's been out for two years already.  Have any of you used this tool before?  No.  Good.  Give you something to take away.  So what Burpee does, you enable logging and burp and you crawl a site completely that  has cross site request forgery protection in it, right?  Like a CSERF token.  And then you create this template and tell it what the token was, what a good result  is for getting a page, what an error page looks like.  And this template is actually really easy to edit.  This is the sample one.  This has been out for, I think, two years already.  I don't understand why people don't use this super sweet, right?  So then you write this template.  It's a Python script.  And then you run his Python script Burpee on your Burp log file and it re-requests all  of those across the whole domain, every request that you've ever made in Burpee, re-requests  with those first three attacks for CSERF bypass.  Then it produces an HTML report telling you which ones gave different error messages, which  ones came out the same and prioritizes CSERF bypasses for you.  So he made a lot of money doing this to Facebook and Twitter.  Because it wasn't a direct Burpee extension, it didn't get a lot of notice.  I randomly found it on GitHub and I was like, sweet, this is awesome.  So this is part of the HTML output.  Here's the base request.  Here's the crafted, the first crafted request and then the response.  And then you get a report back saying if they came back the same, it diffs them.  So I highly suggest that tool.  It's linked in the talk.  Another way to do it is just to check for every request across a whole Burp log file  that didn't have the token in it, the actual parameter.  So this is another script that does that.  It's another Python script that runs on a Burp log file also that went undetected kind  of a little bit.  So super sweet.  I use these all the time and finds bugs with these all the time.  So CSERF just some common critical functions like add and upload file, you know, password  change, email change, transfer money, your currency, delete a file, edit your profile,  things like that.  So these are commonly where you see CSERF that rewards big bugs.  So privilege, transport and logic kind of get mashed into a section.  So privilege, you know, auth and logic kind of get blurred a lot but my testing thing  is just, you know, you have an administrative user, you need a couple of accounts to do  this and then you have a low privilege user.  And then, you know, the low privilege user just tries to directly call functions that  are only for an admin, right?  Pretty simple.  But to automate that across multiple functions, you might need some tooling.  So this is what I use for that.  It's called autorize.  This one is available on the Burp store.  And basically, you spider a site completely, you run through it, all of your post requests  as an admin user, then you go through as a lower user and you give that information  to autorize and you run the tool and it tells you which ones the lower user was able to  access that the admin user was also able to access and you look through those in your  Burp output.  So common functions or views that I check for privilege escalation or anything like that  and these can be actually combined with the last two sections.  Add a user, delete a user, start projects, change account info, view customer analytics  or like there's a page that tells everything about whatever that site does.  You want to try that view, payment processing view like receipts or any view with any PII  on it.  You want to focus on.  So this is what that looks like.  Autorize, browse using a high privilege user, log in with a low privilege user, Burp re-requests  everything and gives you prioritized output.  So insecure direct object references is one of my favorites because I want a badass pair  of gaming headphones a couple months back.  So I found a bug in a really cool company and I had to disclose it and I ended up calling  them on the phone and their help desk guy was like I have no idea what you're talking  about and then I actually linked in spam to everybody of the IT group of that company  and finally someone accepted and I tell them listen I'm legit, I'm not like an asshole,  I'm not extorting you, I just want to tell you this exists because I was buying a pair  of headphones already and they're Astros by the way, they're awesome.  And they fixed this bug.  So the receipt function basically was an IDOR, you could just iterate up and down and find  other people's receipts with their credit card info on it.  And they sent me two free pair of headphones and I have one and one goes to Daniel for  his birthday but I forgot to bring it.  I'm sorry, but they're sweet headphones, I guarantee they're awesome.  Anyway so IDOR is five minutes, okay cool.  So increment, decrement, negative values, attempt to perform sensitive functions, substituting  user IDs, things like this, these are how you test IDORs.  These are common functions of user files that deal with IDORs so everything from the C-SERF  table, anything that says UID, password or user hashes, emails, images that are supposed  to be private.  So you can go through the slides and kind of go through this.  And all this is going to be up on GitHub and if you have questions or whatever.  So this is a simple IDOR, I don't know why I put a simple IDOR in here, this is DEF CON,  you guys probably knew this, you see this numerical value and you're like oh what happens  if I change it and you get someone else's receipt.  This is exactly what I did to another place.  This was a disclosed bug that's patched so don't worry about that, they had a bug bounty.  Transport, you need to enable HTTP everywhere, there's this awesome script that will basically  take up our blog file, again, every request in your site tree over HTTP instead of HTTPS  so you can see what's going over insecure channels.  Instead of having to sort columns and burp and do all this stuff, I find this really  useful so it will try to downgrade everything and then you report like this is a SSL downgrade  attack or whatever.  Logic, logic clause are usually pretty manual.  The one I see a lot is substituting hash parameters where there's like prices or something like  that and they've hashed it and it's irreversible or they've done something to it and it's irreversible  or I'm too dumb to reverse it, right?  But just finding another item that's cheaper, taking its hash and substituting it and usually  what it's an e-commerce payment or something like that and so doing that usually yields  the product for less money.  So step manipulation, this is like the bread and butter example everybody gives for logic  clause, like there's multiple steps like order or put things in cart, order, check out, pay,  ship, so you just skip everything or you put everything in your cart and then you just ship  everything because you have the whole process in verb and so you just skip a process.  Using negative quantities or using negatives and quantity values, so I've actually had  websites pay me credit because I put in a negative value on some price thing or a negative  quantity, right?  Like order number equals one, usually I want to buy one thing and I put in like negative  20 and then they've credited my account like $1,000 or something like that.  Mission level DOS, this is one that's kind of interesting, right?  It's not actual DOS, right?  I'm not advocating bug bounty like using a bot net or anything like that but I've seen  sites that just can't handle just like parsing a parameter with, you know, 40 zeros in it  or something or me putting in like a math function as a parameter value and the server  is like, I don't know what to do, let me try to process this somehow and it just falls  over so those are interesting.  And then timing attacks, I think there was a DEF CON talk about timing attacks so you  can check that out.  I'm really running in, so data storage is really important, check these files for data  storage as well as logging.  This is the best tool to quickly get spun up on iOS, it's called IDB, it's by Daniel  Mayer, basically jail breaker phone, install this tool.  It gives you a full GUI list of the handler of all of the files, all of the encryption  values, if it's using exploit mitigation, et cetera, et cetera, et cetera, it's the  most functional tool.  I think it's partly based off a talk I gave a long time ago and he made it in Ruby and  it's super sick, it's the best way to get into iOS testing if you've never done it before.  This is a thing about logs, we got to go.  Those other volums, I repeat them again, don't discard them, content spoofing, refer  to leak which, security headers, path disclosure, keep them in your pocket later to escalate  if you can use them.  This is one idea of like, if I have five or 30 minutes or something like that, what can  I do?  So I tried to time myself with the methodology using this stuff in here.  So in 15 to 30 minutes I can do most of this using Burp and the automation, maybe an hour,  it depends on how motivated I am.  So these are the steps I'd go through, I'd register, I'd hit the password reset, I'd  go to all the forms that do security functions, I'd check the cookie, I'd perform a numeration  on any UIDs I see in the URL, I'd directory brute force using one of the short lists in  the background, I'd upload a file if it had uploads and within 30 minutes or an hour I  can usually find some pretty darn good bugs.  Things take with you, crowd source is different, it's the same but different.  You find like 20% of the edge case stuff instead of 80% and a lot of stuff goes quick, data  analysis is cool, you could probably do a 15 to 30 minute web test and done right, you  could get some major volums, set lists, polyglots are cool and follow all of the bug bounty people  on this list, I put them all into a Twitter list for you and you can watch them hack things  and talk about their findings.  Also, there's a lot of stuff that didn't get put in here, there was a lot of data that  I didn't get to parse, 50% of the data is still unparsed, someone put it up on GitHub as a  get book I think or maybe just mark down and you guys can contribute to it if you care  enough, if you just want to take it and use it, that's fine.  I have to go in there, more tooling that I found, XSE, that's actually meant to say SSRF,  a bunch of cool SSRF techniques, capture bypass, more detail on logic flaws and to add Android  mobile tools that I use often.  13 memes, is that okay?  Good.  All right.  Attribution and thanks, these are bug hunters who did things in this presentation, all of  them are super awesome, I respect every single one of them or who made tools.  Also my team at bug crowd, John, Todd, Ben, Ben, Grant, Fati, Patrick, Katie, Kim, Abby,  Casey, Chris and Sam and everybody in the bug community, I love you guys, I love doing  this for a day job.  That's it.  Thank you.
DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_0_167.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_168_911.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_912_1211.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_1212_2939.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_2940_2999.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_3000_4427.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_4428_5303.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_5304_5399.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_5400_6983.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_6984_8735.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_8736_9071.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_9072_9887.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_9888_12647.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_12648_14147.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_14148_14207.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_14208_14303.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_14304_14375.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_14376_14435.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_14436_14591.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_14592_20327.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_20328_23315.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_23316_25223.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_25224_26075.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_26076_26723.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_26724_27575.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_27576_28667.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_28668_29675.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_29676_29723.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_29724_30935.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_30936_31559.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_31560_31859.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_31860_32747.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_32748_33743.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_33744_35243.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_35244_37823.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_37824_39347.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_39348_39419.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_39420_40487.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_40488_46295.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_46296_46415.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_46416_49643.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_49644_51395.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_51396_51527.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_51528_51587.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_51588_51815.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_51816_53147.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_53148_53687.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_53688_55187.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_55188_55235.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_55236_55787.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_55788_57275.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_57276_58559.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_58560_59099.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_59100_59507.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_59508_59627.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_59628_60095.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_60096_61847.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_61848_63551.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_63552_64019.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_64020_64427.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_64428_64571.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_64572_65159.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_65160_67667.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_67668_68543.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_68544_68591.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_68592_68903.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_68904_69155.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_69156_70055.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_70056_71591.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_71592_71675.png DEF_CON_23_-_Jason_Haddix_-_How_to_Shot_Web__Web_and_mobile_hacking_in_2015_-FAjxUOKbdI_71676_72574.png