 Well, let's get started. Brent here is going to talk about hacking web apps. Apparently, the battery is a very misleading first slide. So let's give Brent White a big hand. Thanks. Thanks, man. All right. Hey, thanks, guys, for coming. Just to let you know, this is probably going to be the most disappointing that you've been in a long time. So I'm just going to tell you that now. All right, let's talk about baking apple pies this morning. My name is Brent White. I'm a security consultant with Solutionary. And if you have any questions, send them to a lot of people. So if you have questions about anything I talk about, or maybe something I didn't mention, please contact me on Twitter. I will respond to the best of my ability. All right. This was not my choice to put this on here, but for my own protection, thank you for having me add this there, Michael born. Okay, so basically in this talk, I want to talk about as a pen tester what happens from the very beginning all the way to the end for an assessment for web applications. At the time, I'm not going to be able to talk about actual web services, but mostly most specifically web applications. So there are a few things that have to start, they have to happen before you legally go and start hacking someone's website. Where are those things? Well, once that you go through contract and scoping and sales, then it comes down to us and we have what's called a kickoff call. And during this call, we talk about what were they expecting? Do they have a specific thing they want us to focus on? So if it's a bank, then they probably want us to try and focus on getting user data or credit information, things like that. So we talk about exactly what they're wanting. We talk about the limits, no denial of service, you know, avoid this web page, please don't, you know, delete data or anything like that. And then the scope and that actually is what website, what is the application, the URL. Next, in case something breaks, all hell breaks loose or something, you have to have a point of contact, somebody that you can call and say, hey, didn't mean to do this, but your site's down or, you know, whatever might happen. Hopefully that doesn't happen, but, you know, it's not a perfect world. Remember, a report is always expected at the end of an assessment. So the more evidence that you collect, the easier your life is going to be when you're reporting. So before I get started, there's a few things that I like to set up that way. As I'm going along, I can just copy, paste and put evidence as I'm going that way. At the end, when I'm report writing, I'm not, well, you know, shoot, I forgot to take a screenshot of this. So what do I use? Well, keep note is my actual application of choice. It's built in with Kali Linux and it's also available for other platforms. Again, there's several options such as Drata and other things like that. Just explore whatever works best for you, what you're most comfortable with. One of the reasons that I like to keep note is that you can easily create scripts. You can do scripting for it and it's very expandable. And you can easily export it as HTML files to give to a client or to share with your team members as well. And so just to kind of show you how I might group things, the one side says buy IP. So if I have several IPs or several applications I'm looking at and I want to make sure that I'm covering each one, then I might break it out and do a folder for each specific application or IP. Or if it's a smaller scope, then I'll just do it by vulnerability. And as you can see, I've gone in and color coded them. The darker ones are obviously your higher risk. And then the green, I do that. This is a visual reference of this information that I can go back to such as what's the scope or anything else that I might need to reference quickly. A few things, evidence gathering. Whenever you're going to report on a vulnerability, then you want to try and document the request and response for each vulnerability that way. When you give the report to the client, they can try and replicate it and try to resolve the issue. Any unscheduled downtime or issues, so if the client asks you to stop testing because there's latency or some issue with the application, you want to document that for the report review call. Changes in test data. So if you do create test accounts or you modify, let's say you get into someone else's account and you modify information, let them know that way they can go back and repair that if you happen to be testing in a live environment. And then again, and if you're testing something like a bank website or an online store or something and you're doing transactions, you want to log those that way. Of course, they can cancel that and give you your money back. And then this next one should be pretty obvious. Don't share any screenshots or data of any hacks that you found for the client. That probably wouldn't make them happy and you'd be against your agreement in the contract. So I'm going to apologize. There's so much stuff to cover. So I'm going to try and keep things high level. That way, those who are interested in getting into hacking web apps, this is more of an outline for you to go back and say kind of look at the names of the programs and learn these programs and to kind of just kind of get you on the right track of how to get started. So evidence gathering, you want to make sure when you do find a vulnerability that you get as a clear legible screenshot of that vulnerability. That way, when you put it in the report, you can actually tell what it is. I've seen a few reports where it was really tiny. It was a screenshot of the entire screen. And the part that mattered, you couldn't really read it because it was so small. So just, you know, trim out the stuff that isn't needed, make it where it's nice and big and you can actually read it. So call out the specific issue during the write up. That way, again, they can actually see what was sent. So you can see the highlighted part where on this particular one, I found SQL injection. And so I highlighted the payload or the code that was sent for the username parameter. And then again, as you're going through, let's say, for example, the SQL injection I was just talking about, if there are multiple parameters, you want to go through and look at that for each and every parameter. So you actually want to go through and document every parameter that's vulnerable to that particular SQL injection, for example. Don't just find one and just give them one. You actually need to be diligent and go through and look at every parameter to make sure everything's being covered. And then you want to have a certain methodology or a checklist to go by. And when I say checklist, I want to be very clear that I'm not limiting you to that checklist. That's just merely a reminder. Okay, have I fuzz all of these parameters? Have I looked at this? Have I looked at this? And this is just a kind of a thing to help keep you on track because as a pen tester, you're going to be doing a lot of things like this and maybe have several projects going on at once. So this is just kind of a tip to help keep you keep you on track to make sure that you're not overlooking or forgetting something. That way the client is getting the most value for their dollar. And then again, you know, you're not trying to go to sleep one night. And then you remember, oh, I totally forgot to look at this whole portion of this application. So at the end, you know, it does kind of make you happy, I guess, had to find a stupid picture for this one. So there you go. Okay, now getting into getting into the actual assessment part, you want to look at anything you can find the OSINT, which stands for open source intelligence, if you're not familiar with that, you actually want to go through use different tools such as search engines. If there's been a previous compromise, you might find credentials on something like Pastebin, ReconNG, all these there are several different tools for OSINT that actually will crawl and help save time by crawling the web for you and finding this data. Again, look for any previous hacks. That's always a good thing to tell a client like you guys have already been owned. You've got a lot of cleaning up to do. Any known malware or anything? So again, this is a manual process. It's very time consuming, but it can be very, very rewarding. And why is that? Well, I've actually found database types, database schemas, test credentials, and so much more information through archived emails, development forums, so many things that have pretty much given me the keys to the kingdom for that assessment. Talking about more about OSINT, there's a great tool by Lee Bayard called Discover. And as you can look at the screen and kind of get an idea of a few things that it covers for you, the automation tool will help things go a little quicker. Okay, so you might be asking, well, if you're a hacker, why are you running automated tools? That's not cool. We're supposed to go in and do everything manually and according to Hollywood, the faster you type, the better of a hacker you are, things like that. Okay, well, automated tools are great because they actually are a huge time saver with assessments. They cover a wide, a wide range of tests very quick, and it really helps you to find the low hanging fruit. You'll be very clear on this, and this is something that I know a lot of other pen testers get really irritated about. A vulnerability scan is not a pen test. I know that's a common misconception. So, if you know people that think this, please correct them. It's just a vulnerability scan. It's only doing what the scanner knows what to look for. It's not putting in that human element of manual testing. So, and to those that still think a vulnerability scan is a pen test, then this is here, right here. So, why use automated scanners? Again, they cover a lot of things, and so once they're finished, you still need to go through and validate the things they found. So, you want to weed out any false positives. I know a lot of automated scanners have tools where you can actually replay a request to see if you can get the same response or maybe modify it to see if it is a false positive. Don't just rely on those results because there are several that will give you false positives on the same vulnerability over and over on several web apps. So, not saying anything bad about the scanners, but trust and verify as well. So, automated scanners. I want to talk about a few that I like to use and some of the more popular ones out there. Nessus by Tenable is great. It looks at the host, the web app, everything, SSL TLS layer. It also does basic content discovery and it just kind of looks at a whole. IBM AppScan is another one that we like to use and it's a little more focused. You can go in and you can modify a lot of things from parameters that you don't want to have looked at, pages you want to exclude and things like that. So, it's a little more focused for web apps and it's a tool we like to use. Another favorite of mine which you'll hear me talk about quite a bit is Burt's Suite Pro. It has a built-in active scanner that will actually go through and look at things similar to other scanners and you can also spider content. So, basically what spidering does is when you load a page, anything, any links or anything that are in that page, it will visit that and then on that page, any links that will visit that and basically just keep spidering out, trying to go ahead and build the trees and everything for you so you can see sort of a layout of that application. Nick 2, I like this Nick 2, Nick Toe, however you say it, it's a pretty good tool too for looking for default pages, non-vulnerabilities, CGI testing and quite a bit more and I like to use this standalone because it gives me a lot more control and I can really dial down based on that specific web app that I'm looking at. So, if you're dealing with a framework such as WordPress or Drupal or Joomla, things like that, there are actually automated scanners geared towards those as well. WP Scan obviously, that's for WordPress. It looks for known WordPress vulnerabilities, outdated plugins and so on. The ones for the other platforms also do do similar things. So, look into those, those are all built into Cali. A good one for finding sort of brute forcing directories that might not be linked in any other way is Derbuster by OWASP and that's probably kind of hard to see on the screenshot so I apologize but basically you can load your own custom lists or use the list that come with it and you can go through and just let it run and it will try to find and locate its hidden files and folders. Very useful. Make sure you give yourself enough time for this because it can take a while and again there are many more pre-installed options in Cali and this sort of shows you the directory structure where you can go in and find these tools if you're not familiar with the operating system and then there are other you know free options such as Saints and Expos and numerous others. So just kind of you know get familiar with these tools, find what works best for you and I know on YouTube and other things there are several videos, free tutorials to help you learn these specific tools and sorry I don't have enough time to really cover all those things with you today but again this is just sort of to help you get going in the right direction and get started. Automated scanning pro tips, verify the settings of the automated scanner. Don't just put in the URL and click go. That's cause problems, it's just not really a smart thing to do. You want to look at the settings, make sure you're not going to you know do something that's going to cause denial of service. Clients we found out never like that at all so avoid that. You know if you need to throttle it back and change the number of threads you can do that too and again you can add pages or functions that they might want you to avoid and something that we found is kind of common with web apps as a client will say hey this page is our contact page if you scan it we're going to get thousands and thousands of emails from your automated scanner and that can flood things, it's cause problems so make sure that you ask what do you want us to avoid what pages do we need to stay away from and because there are times where that will cause issues and then when you're already and you've got everything set up after you verify the settings you can start to scan. Okay now let's talk about some manual testing and this this kind of bleeds over into automated so again once your automated scanners are finished and you have some things to go after instead of just verifying those things see if you can take those further so you don't want to just see okay well there's potential cross-site scripting and then go and do a pop-up alert box of one you know it's pretty lame doesn't if you really need to show an executive of why this is important to allow budget or something to actually get this fixed go deeper and look at you know maybe including keystroke scripting or cooking the browser with beef or something like that the beef application there's so many more things you can do with it so actually look at those results and take them further than just the automated scanner so make it look more real world what would an attacker do that's what you're trying to get across here and then you actually want to explore the application through a proxy program and again there's burpsuite pro again it's an excellent program all the guys that work with that's kind of a standard application for us again there's the spidering and content discovery tools to help you find more things that you might not see when you're manually going through each page and then again the derbuster from oas you know a way to sort of tailor exploits and see what it might be vulnerable to is to look at the server response kind of verify what is this running because most of the time it will tell you you know apache and then the version number or is and so on that way you can see okay this is how i need to focus my scanners or my attacks towards this this host parameters parameters are basically anything that take a value and they send it on to get a response just want to look at those and you want to let's say if the parameter is name okay instead of just putting in names try putting in actual you know maybe sequel injection or cross-site scripting or anything that is not expecting and that's kind of the whole point right is take something and give it information that it's not expecting to try and make it behave different if you can do that and start getting different responses that is kind of the rabbit trail you want to go down cross-site scripting again i've already mentioned that if you're not familiar with cross-site scripting you got to look it up you got to become familiar with it because there are a lot of really good attack vectors and more websites are vulnerable to this than we would like also you want to look up things like cross-site request forgery sequel or LDAP injection local and remote file inclusion so again in burpsuite pro you can actually load your own list so if you have a long list of of cross-site scripting or sequel injection commands that you want to throw in a parameter you can load those in or it comes with one some some pretty solid ones already that you can try Xenotix however you say that by OWASP is also a really good cross-site scripting testing tool it's for Windows platform and basically it shows three browser types and you tell it the url in the parameter and it will just run and run and run and it will actually go through and i found a few things from this that other tools didn't find or that i couldn't find through some manual testing so i highly recommend checking that out then if you think you have sequel possible sequel injection save that request to a file and then you can actually run that through sequel map or other sequel ninja barbecue sequel there's so many different types of sequel injection tools built in the Cali or four other operating systems as well so something else you want to look for whenever information is being sent is it sensitive information in the url is it showing the username and the password in clear text is that the session cookie and as silly as that sounds we've actually found that several times and so if someone's sniffing traffic or it's saved in the history then someone's got you know they can grab that that session token and and become your user or you know if they see your username and password or even if they just find your username you can start brute forcing with password lists and try to make your way in that way okay and to prevent death by powerpoint because i know i'm throwing a lot of information at you we'll look at this happy dog with a with a hot dog for a second awww has anybody seen the video of this by the way it's this dog just standing there and they give it a hot dog and it has its eyes closed like it is so happening it's like wags its tail for like like two minutes so okay i'm moving along authentication these are these are things i'm telling you that you actually want to look at for for bypassing things and to actually hack websites so authentication can it be bypass what does that mean well if there is a url for admin can you get to that url as an unauthenticated user or if you're not an admin if you're just a regular user can you still view that those are things that you want to look for when you log off can you take that session token put it you know and log use it again or does it create a new one every time you log in this is you know something else you can try if you're logged in as one user can you go ahead and log in under the same username in a different browser does it allow multiple multiple sessions sometimes that's not really a bad thing but i think you know based you know given certain cases for example bank you might not want to allow the same user to be logged in at the same time on a website you want it to end that session of the other person that way this you know provides a little more security with that you also want to look at password requirements can you set your password to one two three or banana or something that's easily guessed you know a very common password you want to make sure that it's strong password requirements for that application when you change your application can you go back and use an old password again why is that bad well let's say you've been compromised before and that list is on the website and someone says well okay time to change my password and their old password is out there and then again they're so only use that password again well there's a possibility that that an attacker come come by and use that list of passwords that were found from a previous breach and if it's their current password again or it's never been changed you've got problems look at the host not just the web app again you know what is it running is it Apache is it a vulnerable version of Apache are there admin portals available like cPanel if so you know try default credentials for that group force it see what you can do to get in uh there've also been a few times where we found backup files backup database files so you just grab those with no authentication you go through you find the information usernames passwords it's pretty good good stuff for us not for the company necessarily again with the host do they have any dangerous HTTP methods enabled such as put copy as you know you can group those together to basically compromise the host delete that's pretty obvious why that would be bad so you want to look at those things you know are they vulnerable to directory traversal or shell shock or heart bleed or whatever else is out there that's unknown vulnerability with you know easily to get you know public exploits again you want to look at ssl tls settings are they using weak ciphers with known vulnerabilities if they are you want to document that stuff take care of it let them know and again um you know there are methodologies methodologies from owasp as well as uh you know several other checklist to kind of help you stay on track and these things will let you know kind of how to look for different things and so if you're new to uh assessing or hacking web apps go to what go to the owasp site look at their methodology and that will actually help you know help you walk through exactly what to look at what things to look for how to assess those and so on um then practice in the lab if you're new to this you do not want to be learning this stuff while you're touching a client website bad things can happen uh just make sure you take the time to set up a lab there's a lot of information on how to set up labs out there uh so you know check that out if you're not too familiar and then once you're ready go hack some websites so that's that's basically it for my slides and my talk i think we have some more time if anybody has questions or anything so the question was is there anything that i recommend for setting up a lab um you know there it kind of depends on exactly what you're wanting to do i mean if you're wanting to look at web apps there are um as helmet what's the name of the the vm yeah there there's so many different vulnerable vms that you can download that are purposefully vulnerable so you can go in and test things like sequel injection and things like that uh basically basically just you know if you run a vm few vms on your machine that'll be enough to get you started just so any more questions my favorite tool probably the monkey wrench no burp suite pro honestly is my favorite it's that it's pretty robust you can actually again as i've mentioned you can there's manual testing automated scanning throwing your own lists you can craft your own responses and there's so much that you can do with burp suite so i'm sorry i'm not sorry no sequel okay okay of like mongo db things like that yeah there are there are tools uh like that as well you know mentioned um and sequel map and things like that there are also tools written specifically for testing sequel injection against mongo db and things like that out there as well great question so get how do you help developers recreate the attacks so earlier when i was talking about reporting uh in the reporting in a good report it will actually show you the requests that that i sent to the server so it'll be the full post or get requests or whatever it was and i will actually highlight in there what i sent that was malicious and that caused that normal activity and i give that to you and you guys can use something like burp suite or fiddler or something else where you can actually just copy and paste that request in there hit send and you should get the same results a plugin for burp for yeah so well again that's one of the great things about burp is because it's so widely used it's being actively developed for and there's a great plugin for it specifically for sequel map where you can there's a after you go and set up the tool and everything you basically just send that straight into uh that plugin and it will run it through sequel map and everything for you then if it finds something a tab will open up and it'll link and say hey we found something that way you know it does save time from the manual process of you know command line from sequel map so that is an option what's that soap and rest apis uh you can use those as well through burp you can also test those and i know ibm ibm app scan also you can you know throw the like the whistle and everything in there and help fuzz those parameters and things like that it was that was that the question okay cool yeah so the question make make sure i got this right so the example that i showed where i found the sequel injection in the username parameter is that something i would tell the client right away yeah so we have a process where if we find uh like a serious or what we consider a critical vulnerability we escalate that right away to let them know hey this is here uh this is pretty it was pretty easy to find pretty easy to exploit and we got some information we shouldn't have been able to get it's a good question uh other than that being a pretty common and frustrating thing uh you just that's again that's where you want to find these exploits and try to take them further and make them more real world scenario that way you can say okay obviously this this vulnerability exists this is what an attacker could do with it because this is what we actually did and here is proof that we did this and and then they'll argue well i don't see that that's a critical risk it needs to be a low or you know something silly like that so basically you just you go to them and there might be certain cases where uh based on the vulnerability you know where maybe it could be you know lowered a little bit based on their use but that's just something that you need to talk to the client about uh but just make sure that you document things well again you you exploit it to the fullest within the scope and then just let them know hey this is how you guys can really be screwed over and then just just take the dialogue from there and kind of work it out to a client so how i'm sorry i didn't quite yeah so you're talking about you know how basically how do you evade their ids things like that so when this is something that we actually talk about during the kickoff call is they will say well you know we have this firewall in place and you say well that's good but we only have a week on this project we don't have time to really go through and uh you know craft everything to see if we could potentially bypass this so uh you want to let them know hey whitelist us because we don't really that's pretty cool we don't really have time to do this so you just let them know hey this is a time thing you let us see what's behind that that way if an attacker does get behind that then we fix those issues yeah probably one second please uh never mind ask the guy next to you that asked that a second ago this is it oh he got it cool let me explain what's going on how many people are first timers here all right so we have a little tradition at defcon if you speak at defcon this is your first time you have to take a shot during your talk and it's just kind of how we do it here first time listeners have to bring their own but thank you welcome to defcon thank you guys i'm glad you did that towards the end yeah so what do i read each week what do i look at to stay current on things i'll tell you um this might not sound like the most professional thing but i get more useful information from twitter and from following info sec leaders on their fellow hackers uh those guys i mean constantly that's that's what we do right so when we find something when we see an article you might see the same article 15 times in an hour but you saw it right so let's say for example shell shock dropped my whole feed that as soon as it came out it's talking about shell shock the next hour it was so and so has developed a you know a proof of concept or an exploit check it out here so within a couple hours of shell shock being announced we were you know the guys who work with we're all already trying out these proof concepts and code and then you heard about it on the news or you know a larger thing you know maybe two or three days later everyone's freaking out about this but here we are actually already trying it out so uh twitter is a great resource so html 5 yes there are some actually uh just uh quick google search and you'll there's actually a few tutorials and tests and things like that that you can go through and practice it things you can look for so yeah it does have some issues see i think i've time for just a couple more what kind of okay any good application for testing the mongo i'm sorry i'm having a really hard time here you'd like screaming at me like like i owe you money or something mean applications any resources for testing mean applications not anything that i can think of right off sorry uh just messes me on twitter i'm sure i've got something i can send it over to you anything else all right guys you've been awesome thank you for uh for listening to my talk today appreciate it yet if you have questions contact me on twitter find me outside uh and then i'll i'm more than happy to do what i can for you thank you