>>Let's get started, Brent is going to talk about hacking web apps or he has very misleading first slide. Let's give Brent white a big hand. [Applause] >> Thanks. All right. Thanks guys for coming. Just let you know this is probably going to be the most disappointed that you've been in a long time. I'm just going to tell you that now. I'll talk about baking Apple pies this morning. My name is Brent white. I'm security consultant with -- and if you have any questions, I know a lot of you have questions about anything I talk about or maybe something I didn't mention contact me on Twitter I'll 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, Michael Borne, everybody got it? Okay, so, basically in this talk I'm going to talk about, as a pentester what happens from the very beginning all the way to the end for an assessment for web applications. I'm not going to be able to talk about actual web services but more specifically web applications. So, there are a few things that have to happen before you legally go and start hacking someone's website. What are those things? Well, once that you go through contract and scoping and sales, then on to us. We have what is called a kick-off call. During this call we talk about what are 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 to focus on getting user data or credit information things like that. We talk about exactly what they're wanting, we talk about the limits, avoid this webpage, please don't delete data or anything like that. Then the scope, that actually is what websites, 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 say, didn't mean to do this but your site is down. Or whatever might happen. Hopefully that doesn't happen, but, you know, its 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. 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 put evidence as I'm going as the report writing, shoot, I forgot to take a screen shot of this. So, what do I use? Well, heat note is my actual application of choice. It's built in with Kali Linux and for other platforms. Again there's several option such as Dratus and other things likes that. Whatever works best for you what you're most comfortable with. One I like is keep note, that you can easily create scripts, you can do scripting for it and it's very expandable. You can export it as HTML files to give to a client or share with your team members as well. And so just to show you how I might group things, the one side it says B.I.-IPs 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 color coded them the darker ones are obviously higher risk. And then the green, I do that, this is a visual reference of just 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 to document the requests and response for each vulnerability. When you give the report to the client they can try and replicate and try to resolve the issue. Any unscheduled down time or issues, so if the client asks you to stop testing because there is latency or some issue with the application you want to document that for the report review call. Changes in test status if you do create test accounts or modify, let's say you get into someone else's account you modify information. Let them know that way they can go back and repair that if you have you happen to be testing in a live environment. And then again if you're testing something like a bank website or an online store or something you're doing transactions, you want to log those, that way cancel that give you your money back. And then this next one should be pretty obvious. Don't share any screen shots or data of any hacks that you found for the client. That probably wouldn't make them happy you'll be against your agreement in the contract. So, I'm going to apologize, there's so much to cover I'm going to try to 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, the names of the programs and to kind of get you on the right track and how to get started. In evidence gathering you want to make sure when you do find vulnerability that you get clear, ledgible screen shot that have 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 screen shot of the entire screen, part that mattered you couldn't really read it because it was so small. Just trim out the stuff that isn't needed, make it where it's nice and big and you can actually read it. The specific issue during the write up that way again they can actually see what was sent. You can see the highlighted part where, on this particular one I found SQL injection I highlighted the pay load or code that was sent for the user name parameter. Then again as you're going through, 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 make sure. Everything is being covered. Then you want to have methodology or a checklist to go by. And when I say checklist, I want to be very clear here, not limiting you to that checklist, that's just merely a reminder, have I -- all of these parameters have I looked at this, this is just a thing to help keep you on track because as a pentester you're going to be doing a lot of things, maybe have several projects going on at once this is just a tip to help 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. You're not trying to go to sleep one night then you remember, oh, I totally forgot to look at this whole portion of this application. At the end, 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 the actual assessment part. You want to look at anything you can find, the Osint, Osint you want to go through dues different tools such as search engines. Previous compromise, you might find credentials on something like case bin. Recon-ng, several different tools for Osint that will actually crawl, help save time by calling -- for you and finding this data. Again, look for any previous hack that's always good thing to tell a client, like you guys have been owned you have a lot of cleaning up to do. Any known malware or anything. 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 e-mails, development forums, so many things that have pretty much given me the keys to the kingdom for that assessment. Talking more about Osint there's a great teal, called discover. And you can look at the screen and get an idea of a few things that it covers for you, automation tool helps things go a little quicker. Okay, so, you might be asking, well, if you're a hacker where are you running automated tools? That's not cool. You are supposed to go in do everything manually, according to Hollywood the type -- faster you type the better of a hacker you are, things like that. Well automated tools are great because they are a huge time saver. With assessments, they cover a wide range of tests very quick. And it really helps you define the low hanging fruit. Very clear on this, this is something that I know a lot of other pentesters get irritated about. A vulnerability scan is not a pentest. Common misconception, 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, to those that -- vulnerability is a pentest, then this is you right here. Why use automated scanners they cover a lot of things. 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. Scanners have tools where you can 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 this, but trust, verify as well. Automated scanners, want to talk about a few that I like to use. Some of the more popular out there, Nessus by tenable is great. It looks at the host, the web app, everything SSLTS layer, does basic content discovery. Just kind of looks at it as a whole. IBM app scan one we like to use. It's a little more focused. You can go in and you can modify a lot of things, parameters that you don't want to have looked at. Pages you wanted to exclude, things like that. It's a little more focused for web apps. Another favorite of mine is Burp suite pro. It has built in active scanner that will go in and look at things similar to other scanners. You can also spider content. Basically what spiderring does is when you load a page anything links or anything that are in that page it will visit that and then on that page any links -- basically just keeps spiderring out trying to go ahead and build the trees and everything for you so you can see sort of a layout that have application. Nikto, pretty good tool for looking for known vulnerabilities, CBI testing quite a bit more. I like to use the stand alone, lot more control and really dial down based on that specific web app. So, if you're dealing with a framework such as word press or Drupal or things like that, there are actually automated scanners for those as well. WP scan obviously that's for word press. Looks for known word press vulnerabilities, outdated plug-ins and so on. The ones for the other platforms also do similar things. Look into those, those are all built into Kali. A good one for finding sort of -- directories that might not be linked in any other way is Dir buster by OWASP, probably hard to see I apologize. You can load your own custom lists or use a list that come with it. You can go through and just let it run and it will try to locate as hidden files and folders, very useful. Make sure you give yourself enough time for this because it can take awhile. Again there are many more preinstalled options of Kali this shows you the directory structure where you can go in and find these tools if you're not familiar with the operating system. Then there are other free operating nexpose and numerous others. Just 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 that help you learn these specific tools. 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, get started. Automated scanning, pro tips, verify the settings -- settings of the automated scanner don't just put in the URL and click. It causes problems, not really a smart thing to do, you want to look at the settings, make sure that you're not going to do something that's going to cause -- clients we found out never like that at all. So avoid that. If you need to throttle it back and change the number of threads, do that, too. Again, you can add pages or function, is that they might want to you avoid, something that we found is kind of common with web apps is the client will say, hey, this page is our contact page, if you scan it we're going to get thousands and thousands of e-mails from your automated scanner. That can flood things, it's caused problems. Make sure that you ask what do you want us to avoid, what pages do we need to stay away from. Because there are times where that will cause issues. Then when you're all ready set up after you've verified the settings, you can start the scan. Now let's talk about some manual testing. This kind of bleeds over into automated, so again, once your automated scans are finished you have some things to go after instead of just verifying, see if you can take those further, you don't want to just see, okay, well, there's cross site scripting, go and do a pop-up box of one. Pretty lame, 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. Look at maybe including key can stroke scripting or hooking the browser -- or something like that, the beef application. There's so many more things you can do with it. Actually look at those results and take them further just automated scanner. What would an attacker do, that's what you're trying to get across here. Then you actually want to explore the applications through a proxy program and again there's burp suite pro again, excellent program. All the guys I work with that is a standard application for us. Again, there's the spiderring and content tools to help you find more things that you might not see when you're manually going through each page. Then again the Dir buster. A way to sort of tailor exploits and see what it might be vulnerable to to look at the server response, kind of verify what street this running because most of the time, Apache, then the version number or IAS or you can see this is how I need to focus my scanners or my attacks towards this host. Paramaters. Parameters are basically anything that take value and send it on and get a response. Want to look at those, you want to -- let's say if the parameter is name. Instead of just putting in names, try putting in actual -- maybe SQL injection or cross site scripting or anything that is not expecting. That's kind of the whole point, right? Take something and give it information that it's not expecting to try to make it behave different. You can do that, 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 become familiar with it because there are a lot of attack vectors and more websites are vulnerable to than we would like. Also you want to look up things like cross-site request forgery. SQL app injection, local and remote file inclusion. You can actually load your own list, if you have a long list of cross-site scripting or SQL injection commands that you want to throw in a parameter, you can load those in or it comes with ones, some pretty solid ones already that you can try. Xenotics, however you say that, is also really cross-site scripting testing tool. It's for Windows platform. Basically it shows three browser types and you tell it the URL and the parameter. It will just run and run and run. And it will actually go through -- I found a few things from this that other schools 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 SQL, possible SQL injection, save that request to a file then you can actually run that through SQL map or SQL Ninja, barbecue SQL so many different types of SQL injection tools built into Kali or other operating systems as well. Something else you want to look for. Whenever information is being sent, is it sensitive information. In the URL is it showing the user name and the password in clear text, as silly as that founds we've found that several times. So if someone is sniffing traffic or saved in the history then someone's got y know, they can grab that session and become your user or if they see you're user name and password or just find your user name, you can start brute forcing with password lists try to make your way in that way. Okay. Death by PowerPoint. Lot of information. Look at this happy dog with a hug for a second. Aww. Has anybody seen the video of this, by the way? It's this dog just standing there they give it a hot dog and it has it's eyes closed it's so happy just like wags it's tail for like two minutes. Okay. Moving on. Authentication, these are things I'm telling you that you actually want to look at for bypassing things to actually hack websites. Authentication. Can it be bypassed? 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 admin 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 and log use it again or does it create a new one every time you log in. This is something else you can try for your logged in as one user and log in under the same user name in a different browser does it allow multiple sessions. Sometimes that's not really a bad thing but as -- given certain cases, for example, a 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 provides a little more security with that. You also want to look at password requirements. Can you set your password to 1-2-3 or banana or something that is easily guessed, very common password. You want to make sure that you have 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. Let's say you've been compromised before and that list is on the website, someone says, well, okay, time to change my password. Their old password is out there then again, I want to use that password again. Well, there's a possibility that attacker can come by use that list of passwords that was found from a previous breach if it's their current password again or never been changed you got problems. Look at the host not just the web app. Again, what is it running? Is it Apache, is it a vulnerable version of Apache. Are there admin portals available like C-panel. If so, try default credentials for that, brute force it, see what you can do to get in. Also been a few times where we found back-up files. Back-up database files. You just grab those with no authentication, you go through, find the information, user names, passwords, it's pretty good stuff for us not for the company, necessarily. Again with the host, do they have any dangerous HTTP enabled, such as put and copy. You know you can group those together to basically compromise the host. Delete, that's pretty obvious why that would be bad. You want to look at those things, are they vulnerable to direct reversal or shell shock or heartbleed or whatever else that is a known vulnerability with easily get public exploits. Again, you want to look at SSL, TLS settings are they using weak Cyphers with phone vulnerabilities, document that, take care of it, let them know. Again there are methodologies from OWASP as well as several other checklists to help you stay on track. These things will let you know kind of how to look for different things. To hacking web apps go to the OWASP site look at their methodology and that will actually help you walk through exactly what to look at, what things to look for, how to assess those and so forth. Then practice in the lab. If you are new to this, you do not want to be learning this stuff while you're touching a client website. Bad things can happen. Just make sure you take the time to set up a lab. There is information on how to set up labs out there, so check that out if you're not too familiar. Then once you're ready, go hack some websites. So that's basically it for my slides and my talk. I think we have some more time if anybody has questions or anything. [ inaudible ] So the question was, is there anything I recommend for setting up a lab. You know, it kind ever depends on exactly what you're wanting to do. If you're wanting to look at web apps there are -- help me. What's the name of the VM -- yeah. There's so many different vulnerable VMs that you can download that are purposesfully vulnerable so you can go in and test things like, SQL injection things like -- basically just if you run a VM on your machine that will be enough to get you started. Any more questions? My favorite tool? Probably the monkey wrench. Burb suite pro is my favorite. Pretty robust. You can actually again as I've mentioned there's manual testing, automated scanning, throw in your own lists, you can craft your own responses. There's so much that you can do with Burp suite. I'm sorry. No SQL? Okay. [ inaudible ] For like Mongodb things like that? There are tools like that as well. I mentioned SQL map and things like that, there are also tools written specifically for testing SQL injection against MongoDb out there as well. [ inaudible ] Great question. How do you help developers recreate these? Earlier when I was talking about reporting. In the reporting -- good report it will actually show you the requests that I sent to the server. So will be the full post or get a request or whatever it was. I will actually highlight in there what I sent that was malicious and that caused abnormal activity. Give that to you, you guys can use something like burp suite or something else where you can actually just copy and paste that request. Hit send and get the same results. [ inaudible ] A plug in for burp for -- [ inaudible ] Yeah, again, that's one of the great things about burp because it's so widely used it's being actively developed for. There's a great plug-in for it specifically for SQL map where there's -- after you go set up the tool and everything you basically just send that straight into that plug-in and it will run it through SQL map and everything for you then if it finds something, a tab will open up it will link say, hey, we found something. That way it does take time from the manual process of command line from SQL map. That is an option. [ inaudible ] What's that? Soap APIs? You can use those through burp you can also test those, I know IBM app scan also you can throw the thing in there and help find those parameters. Is that the question? Okay, cool. [ inaudible ] So the question, make sure I got this right. So, example that I showed where I found the SQL injection the user name parameter is that something I would tell the client right away. We have a process where if we find like serious or what we consider a critical vulnerability, we escalate that right away to let them know, hey, this is here, this is 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. [ inaudible ] Other than that being pretty common and frustrating thing, 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 vulnerability exists. This is what an attacker could do with it because this is what we actually did. Here is proof that we did this. And then they will argue, I don't see that that's a critical risk. It needs to be a low. Something silly like that. Basically you go to them, there might be certain cases based on the vulnerability where maybe it could be lowered a little bit based on their use. But that is just something that you need to talk to the client about. Just make sure that you document things well. Again, you exploit it to the fullest within the scope. And then just let them know, hey, this is how you guys can really get screwed over just take the dialogue from there and work it out between the client. [ inaudible ] I'm sorry. I didn't quite -- basically how do you evade their IDS. This is something that we actually talk about here in the kick-off call they will take we have this fire wall in place, well, that's good. But we only have a week on this project. Time to really go through and, you know, craft everything to see if we can potentially bypass this. So, you want to let them know, white list us, because we don't really -- that's pretty cool if we don't have time to do this, just let them know, the time thing, let us see what's behind that, that way if an attacker does get behind that then we fix those issues. [ inaudible ] One second please. [ inaudible ] Never mind. Ask the guy next to you that asked that a second ago. He got it. Cool. >> Let me explain what's going on. How many first timers are here? All right. We have a little tradition at DEF CON. If you speak at DEF CON this is your first time you have to take a shot during your talk. This is just kind of how we do it here. [ Applause ] First time listeners have to bring their own. But thank you. All right. >> Welcome to DEF CON! [Applause] >> Thank you guys. I'm glad you did that towards the end. [ inaudible ] What do I read each week. What do I look at to stay current on things. I'll tell you. 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, those guys, constantly, that's what we do, right? We find something, we see an article you might see the same article 15 times in an hour. But you saw it, right? Like say, for example, shellshock dropped my whole feed, as soon as it came out was talking about shell shock. The next hour it was, so-and-so has developed a proof of concept or an exploit, check it out here. So, within a couple hours of shell shock being announced we were -- guys we work with we were trying out these proof of concepts and code and then you heard about it on the news or a larger thing, maybe two or three days later everyone is freaking out about this. But here we are actually already trying it out. Twitter is a great resource. [ inaudible ] Yes, there are some, actually just quick Google search there's actually few tutorials and tests like that that you can go through and practice it. Things you can look for. It does have some issues. [ inaudible ] I think I got time for a couple more. What kind of -- [ inaudible ] Any good application for testing the -- I am having hard time hearing like scream it at me like I owe you money or something. [ inaudible ] Mean applications, any -- testing mean applications. Not right off the top of my head. I'm sure I have something I can send over to you. Anything else? All right, guys, you've been awesome. Thank you for listening. Appreciate it. [ Applause ] Again, if you have questions, contact me on Twitter find me outside, I'm more than happy to do what I can for you. Thank you.