 I hope you didn't do anything too heavy because there's plenty of material you still need to cover. I've passed among you during the break and I saw a couple of technical issues, just a couple of notes. Hey, if Dojo doesn't work for you because of any virtualization issues, don't worry. You can still use either the local instance of WebGuard or the local instance you have here in the Wi-Fi lab of WebGuard. Both will work for most of the exercises that we have in this training. Second of all, many of the mistakes were related to people not activating their proxy or their proxy was actually down. So they didn't get any response from the website because either they closed Zap for some reason or because they forgot to change the icon of the foxy proxy and actually pick Zap in there. So a couple of guidelines to make sure that you're on the right track and your proxy is properly configured. If you have configured your proxy properly and you kind of like made sure that your browser worked with it, the foxy proxy icon outside of Dojo in your own PC should be blue. And inside of Dojo, the icon of MJ at the upper left corner here or whatever the plugin is called should be red. That's how you know that it's configured to a proxy. I don't know if it's the right proxy but it's configured to a proxy. If the upper left corner is grayed out in Dojo or foxy proxy isn't blue in your own PC, it's not configured to use a proxy so it won't work. Second, make sure that your proxy is running. Third, make sure it's running on the same port that you configured in either foxy proxy or the plugin in Web Security Dojo. Now, the plugin in Web Security Dojo already uses a predefined port 0883. There's no point changing the port in Zap within Dojo because it's working. It's already pre-configured. We're only changing the configuration in Zap when we install it ourselves in our own PC to avoid conflicts. They already thought about the conflict part in Dojo and fix it for us. Now, we have about three or four or five attacks, whatever we managed to cover in the time frame that we have, to discuss today. But before we continue, I want to complete the setup of Zap in your own PCs. Eventually, most of the participants in the course already got the basics, which is get the foxy proxy slash firefox slash zap setup working together. Most of you or most of the participants that I've worked with, I've seen that they were able to cause the interception parts to work properly. We were able to view HTTP communication and to figure out which relevant parts in the protocol aren't interesting. I'm not saying you've uncovered vulnerabilities not yet, but you managed to figure out the protocol. Now, we should be able to intercept requests and make sure the proxy is working in any event. So, a couple of nice features in Zap that I really recommend that you try now. It doesn't matter if you try it in front of a web security dojo or a hack-a-zone or a webgoat or the internet or your own website. It doesn't really matter. Just experience using the features in Zap in front of any website. So, it doesn't matter what the target is. It only matters that you do what I'm doing right now. So, let's talk about how do we actually modify values to Zap. So, up until now, we modified values either in the URL or in the GUI level. When you hacked into a web security dojo using O1 equals 1, you used an attack payload to the GUI. You used the attack payload on the actual textbooks. However, if the parameter would have been delivered in the URL, you could have also done it through the URL. It was all manual. You didn't really need Zap for any reason except viewing URLs or viewing the history of requests. However, we can use Zap to actually intercept requests and modify them. There's a very nice button here, the record button or whatever it's called here. See this button? That's one, the breakpoint button, the intercept slash breakpoint button. In order to intercept requests which are coming right now, we need to click it. So, let's say I'm going to send a new request here in Web Security Dojo. I'll use Dojo just to verify I won't have any garbage communication. I want to intercept the next request that I'm sending to Dojo. I'll click the intercept button and then I'll access any URL here in the application. Let's see if it actually worked. Let's see if I'm doing anything wrong. I'm getting something right here. Maybe I can find it on the website. Here I go using Zap and eventually, ah, okay. And eventually when I did it to work, it's not working for me. Okay, let's try it here. So, let's see. What you saw right now is me doing something in my browser window. Zap intercepted the request. See? Okay. So, the breakpoint element in Zap, let's just disable it for a second. And access some other URL. Let's say I'll access the login URL. We'll cause the browser to kind of hover and cause the proxy to kind of hover and intercept the request that you're currently accessing. Okay? Let's go to the last page in the history. Let's see if I'm doing it right this time. AAA, AAA sign in. You see what happened? Zap popped up to the front of the screen and you see the request to the login page of WebGoat being intercepted with the username and password that I have entered. Okay? So, the response was not sent to the server. As far as voice issues here. The response was not sent to the server. It was sent to the proxy and the proxy instead of delivering it to the website intercepted it and now I'm able to change it and release it. Okay? Not the way I did it to work with dojo. I'll figure it out later. But if I send, I don't know, whatever, whichever payload, attack payload I want to send I simply modify the values here and send the request to the player. Okay? Got it? Okay, so there's two things I can do with intercept. I can either release and immediately intercept the next request response sequence or simply release everything until the next breakpoint that I define. So, let's say I'm currently intercepting the following request and I'm sending, I don't know, SSS, SSS. Intercepting it and changing whatever. I should be able to release a single request and get the response. You see now? I intercepted the response. That didn't only intercept the request being sent from the browser to the server. It intercepted the response being returned from the server to the browser. So, I should be able to modify both the outgoing information, the request and its parameter and the returning information. The response HTML, whatever, I want to modify the content that the browser sees. So, if there's hidden flags, I can unhide them. If there's anything I want to change in the presentation layer, I can do it. Okay? In this case, it was a redirect instruction that will cause the browser to redirect to another page. Okay? So, I intercepted zap automatically because I'm releasing request by request with this button. The only intercept release, one request, intercept, one response and so on and so on. If the browser keeps sending requests, they'll keep being intercepted. Okay? I want you to try that right now in front of any website, not from Dojo with your local zap instance. Okay? Any website. Doesn't really matter. Intercept or click the intercept button, right here, the breakpoint button. Okay? Access any website that you want. Intercept a single request. See the request being intercepted and then release it. Okay? You can either release one request so you can intercept the response and all the consecutive requests and release all of them or simply disable the intercept in Italy, whatever you prefer. Okay? Give a shout. In the meantime, I want to show you, while I'm trying it, another method to modify communication of previous requests. Okay? Interception lets us modify request we'll see right now or communication it will testing right now but sometimes we want to attack just by taking a look at the tree and seeing interesting parameters. It's actually one of the key methods to identify vulnerabilities. Sometimes it's more than enough just to look at the names of the parameters in the tree. Remember we discussed parameter tampering? We talked about the parameter having a significance. So if we'll see, for example, the price parameter here, we didn't have to see anything in the page. We could have seen that in zap street. That's it. Just going over the parameter names presented in zap tree. Now, there's brackets that signify that the values are actually parameters in zap tree but you can see that there's a screen and menu parameters in the get URL and there's price quantity in submit parameters in the post body. Okay? You can see all the parameters of the request of previous requests and current requests in zap tree view. Okay? Now, we don't want to reconstruct or reproduce the scenario. We want to attack that entry point right now. We don't want to go to the browser, to the Google Drive process. We can do that with the resend feature. Okay? It's called repeater in verb, those of you who are fans. In zap, it's called a resend. Just right click either on the history, the request you want in the history, or simply on the tree and click resend. Okay? It will open up another pop-up and allow you to modify whatever you want in the original request and resend it. Okay? So if I want to buy something like zero or modify my card, there's a place to do it. So I can either do it using interception, like I'm doing a login right now I want to hack the login phase. I'll intercept the request, modify whatever I want and send the request to the server or I can do that directly from the resend features just by right-clicking on the request that I want to abuse, modify, etc. Right-click, resend, modify whatever I want and just press send. Okay? Much, much more convenient and typically we use it more than use the actual interception features in actual attack and pain. At least I do. Okay? So that's zap interception features. There's other methods to use zap, obviously, but we wanted to discuss another relatively complex scenario in zap, which is SSL interception. Okay? I told you that I'll postpone it to the end of the day, but you know what? I've decided otherwise because you guys are, you know, you're tired right now and if you're going to sleep, at least I give you a good subject to sleep. However, if you want to listen in the next half an hour and do it properly, you probably won't be able to use anything I'm teaching today at home because it won't work. Can I ask? These days, most of the websites will be using, testing, whatever, tell me in SSL. And since there's been SSL, if you won't know how to use the interception proxy with SSL, simply none of the stuff we learn will work. Figuring out how to make your tool work properly is key. Okay? So I really recommend, although it's a tedious process and it is tedious, that you listen how to do it and even write it down because once you get home, you'll forget it, it won't work, you'll replace the computer. It's one of the things that should write down. Although there are slides for it and you'll get them, you won't understand alone for a slide and you'll be too lazy without figuring out now. Okay? So listen carefully. To attack or modify communication in SSL websites, Zapp actually performs something called a many-in-a-middle attack against a browser. What Zapp does, the browser tends to initiate a secure SSL communication channel with the remote website, let's say Google or your bank or whatever. Now, the process of initiating a SSL communication channel includes switching certificates specifically from the server to the client. The server will respond to the client in the certificate, the client will verify the authenticity of the certificate and then a secure communication channel will be performed somehow. Black box, doesn't matter the details. However, somebody can intervene in the middle. Zapp can intervene in the middle between the browser and the server and replace the certificate, the server returns with his own certificate. So the factor, the browser will open a secure communication channel in front of Zapp. He will think that Zapp is the server and open a secure communication channel and Zapp will do the same in front of the server. So instead of the browser opening a secure communication channel in front of the server, he will open it in front of Zapp and Zapp will open another one in front of the server. The server will have two secure communication channels. However, the designers of SSL created SSL just for that eventuality. They tried to prevent malicious entities from intercepting communication and deciphering it in the network without your acknowledgement. So if you do just that in Zapp without any preconfiguration, you'll get warnings and exceptions and stuff won't work in your browser. It will tell you point blank that something is wrong and is right. To make the browser shut up because we're taking the attacker holes here. We're the hackers here in this course. We're going to import Zapp certificate to the holy grail of the browser, to the trusted root certification authority store. We're going to make sure that the browser completely trusts Zapp certification authority and if Zapp says for that matter. So we won't get any exceptions when we put Zapp in the many middle role. Okay, bottom line, we need to export Zapp certificate and import it into the browser that we use with Zapp. In order for the browser to ignore the fact that Zapp will serve as a man in the middle to trust it completely. That's the only way to work efficiently and consistently with SSL websites. To do that with Zapp, do it right now with me on your PC. Not on dojo, it's already pre-configured there. Going back to tools. Tools and options. Tools and options in Zapp in your own PC. There's a section called dynamic SSL certificate. Somewhere in close to the beginning somehow. Dynamic SSL certificates. Not need to change anything. You just need to save the certificate that Zapp has. You could also replace the certificate if you don't like it for whatever reason. You generally need to save it so we can export it to a browser. Store it in your download directory or some other directory that you can access. Desktop, whatever, doesn't really matter. After you save it on your desktop, it's all blah blah, something. Go to your Firefox browser. It can also be performed, it shouldn't be performed for other browsers if you use them with Zapp. Go to the options feature here. I'll wait for you to catch up. Go to the options feature. Let's hope I find it this way. Keep hiding it in different Firefox versions. It's very hard to keep track privacy and security. If you go to the tools options here, the toolbar and options button, go to privacy and security and scroll down, you'll eventually get to a certificate. A certificate section at the bottom of the page. Almost the bottom if you scroll it down. If you go to certificates and select View Certificates, View Certificates, I'll just shut it down to let you see. Get to that window, to the View Certificates window. Privacy and security View Certificates. You can go to the Authorities section and press Import. Then select the Zapp certificate. Just pick all files. You should see the Zapp certificate that you saved on your desktop. Auth, Zapp, root, CA, .cell. Choose that. If you'll see it for the first time, you may see optional checkboxes that you need to mark. Mark every optional checkbox you see in the import process and press OK to make sure that the certificate is associated with the highest level permission. I'll do it again. Just for those of you that didn't catch up. Go to the toolbar in Firefox and select Options. We go to Privacy. Pull it down to the end. You'll see Certificates. You click the View Certificates button. Go to Authorities and import the certificate that you stored on the desktop. That's the name. Auth, Zapp, root, CA. Auth, Zapp, root, Certification, Authority. Pick it. Select any optional fields that you have. Import it. Start Firefox just in case. Start Firefox just in case. Configure it to use Zapp and access an SSL website. Let's pick a website which is SSL and isn't completely fanatic. How about Google? Let's try Google. See Google uses HTTPS. See here? Google uses HTTPS. Google uses HTTPS. My proxy intercepts the communication. It's still working with Zapp. See here? Google, COL, Google.com, whatever. They're all appearing in my proxy preview. Okay? Now, I'm going to give you a couple of seconds to make sure it's working. Roy, are you here? Roy? Anyone having problems configuring their certificate? Okay. Roy will come to you in a second. If anyone didn't understand the explanation, do you want me to explain again or something isn't working? How to import it? Yeah. Guys, do you need assistance? No problem. We'll be there in a second. We'll go over the process again. Once again, start to finish just to make sure that the guys didn't understand how to fix it on the one and then we'll pass along you and try to fix it for you. Phase A, we need to export Zapp certificate. We export Zapp certificate using tools, options, dynamic SSL certificates. That's how we do it. We save it on the desktop and now we have something to import. Tools, options in Zapp, save, dynamic SSL certificates, have it on the desktop. Then we go to Firefox, go to the toolbar, go to options. We go to privacy and security. We scroll it down till the end. We'll see the certificate titles. The certificate title will pick the View Certificates button and then we'll import the Zapp certificate that we stored earlier. In my case, the certificate was already imported in the past, so it doesn't let me complete the import visual as it should, but that's more than good enough for our process. Now... It seems that Dojo doesn't have the certificate inside. Okay, it doesn't matter because you don't need to use Dojo for actual hacking outside of Dojo. It's totally designed for that. Dojo is more for training. You should use it to test internally. None of the internal websites in Dojo uses Zapp. So it's okay. The setup should really be performed more on your own PC, on Zapp. Because if you use it back home or in your own work environment, you won't be using Dojo. You won't actually raise an old virtual machine just to run Zapp. It doesn't make sense. If you need other tools, there's Kali Linux or other dedicated testing environments. You won't use Dojo for it. So my advice, configure it in your own PC. In Zapp in your own PC, let Dojo serve as a training ground. If you want a professional hacking testbed or you want a professional tool kit for security tools, it's Kali Linux. So... So far, we only covered a single attack. Okay? We only covered power tampering. We covered various methods to manipulate client originating parameters with business significance in order to abuse some business logic feature. Okay? Flags, identities, resource identifiers. I'm going to go through the solution that you should have gotten to in the various sections of the training. Okay? The exercise. And then I'm going to go on and cover additional aspects. You'll notice that I'm ignoring the last parameter tampering aspect, file names. This is because we're going to discuss it under the past reversal attack. We're going to cover later on today. Okay? So don't worry. We'll cover that. It's very interesting. It's all right. We'll get to that. So the solution... I'm going to go to Web Security Dojo first and then to Webgoat. Okay? In Dojo, if you would have accessed the application with a low-privileged user, I won't even do it with zap because you don't really need to. You can use the URL. There are various things you can see, but the most obvious one... most obvious one is the view account feature. Now, if you'll notice, the account has a number like every bank-slash-financial account has. It has a number. Your pension fund, you know, you have your number in the... in the pension fund. Your bank account number. You have a number. You have a resource identifier that you can access. Now, by clicking on the link to the account, you'll get the account information, but you'll also see a parameter signifying to the server side which value you're trying to access. Okay? See? I think I have something intercepting my request. Maybe. It was just slow. Okay? Now, it's hard to see, so I'll magnify it or try to magnify it somehow. Let's see if I managed to do that. Good. That's the URL that the browser accessed when I accessed an account. And you'll notice that there's an account identifier here in the URL. See that? Now, I'm currently the owner of account 201 and account 202. I've saw that when I accessed my menu so that I'm the owner because I'm allowed to view account 201 and 202. How about 203? Who's the owner? Probably on this account. How about 204? Okay? Now, you could have tied a couple of variations. Eventually, the next closest account would have been 301. Okay? Let's just see. That's better. Okay? So, my account 201 has $180, account 202, you know, has literally zero in it. If I access account or the link provided information on account 301, I'll just change the number in the URL from 201 to 301 or 400 or whatever. You'll see an account which isn't mine. It has different sounds, different transactions. Okay? A typical parameter tampering, you won't believe where those attacks work. Okay? Some of the people in the audience which I work with on a regular basis, they already know, it is everywhere. It's very hard to prevent this attack because you literally have to perform an inspection on permission everywhere. You have to validate the permission of the accessing entity in any URL in the application that accesses a resource. Now, it's very easy if there's 10 URLs in your application. How about 300 URLs? If there are 300 services in your application and there's a bunch of parameters, all of them dealing with resources, it's very hard not to forget one or two or 10. Okay? So an attacker with either lack or a consistent attacker, let's say that way, will probably identify those vulnerabilities if he's persistent. Okay? Now, that was the vulnerability that I wanted you to uncover in Secure Web App. There's other vulnerabilities, but that was the good example I wanted you to see. Okay? Now, in WebRoute, there was a shopping cart fraud very close to the demonstration we saw. We already talked about it and saw the parameter. I'll show it again anyway. I'll access Web Security Dojo just for a sec. No, Dojo, I'll access WebRoute. I'm sorry. Just for a second. I'll access the local instance with your permission. In the parameter tampering section, you have the exploit hidden fields and you have the shopping cart. We could have messed with the quantity, but you can mess with it with the GUI. You don't really need Zap or Oxy to make something which is in the GUI level unless they validate things in the client side and then you can bypass the input validation using Zap. Okay? And you can use Zap to modify the relevant sums. We'll do that by intercepting the request. Okay? Let's just intercept the next request. Let's do an update cart. Zap interception feature should have intercepted the request. Let's say we buy 100 products at Anna. One USD each. Okay? Fair trade. I say. Okay? It is for one of the participants here. Now, if I go to the total cost in the shopping cart, I'm just buying 100 units in $100. Okay? That's another shopping cart for what you can do with parameter tampering. Now, I think we've had enough about parameter tampering. Anyone has basic questions regarding the methodology of attacking, abusing identifying parameter tampering or potential to parameter tampering? No point being ashamed right now. There's very few sections in the course dedicated for questions. There's like, 150 participants. Raise your hand. Anything? Yes. You perform an ownership validation or association validation. The server side code. By the way, don't worry, we'll get to secure development aspects in the end of the course. I am intentionally postponing it. Okay? In the server side, in the server side, not the client side, the server side, should validate that the resource identifier is owned by the user attempting to access it. Okay? It requires, typically, either another query to the database or an index ownership table. And you load all the resources of the user to a table in the session, run whatever, and then you, you know, make any cross-example, make sure that the identifier is on through comparisons to the table. Okay? But I'm not just inspecting. I can do it in numerous ways. Sure. Another question? So, fantastic way to test for parameter tampering. And I encourage you to use it today, tonight, with e-commerce website. Not to actually hack them. That's illegal, remember? Just to look at the parameters, to figure out how the world works. Go to ZAP, not to... ZAP, go to ZAP comparison websites, like we discussed earlier, access various e-commerce stores and see the type of parameters that are being sent from the client. You will be amazed. Go to a couple. Don't stick with one and say, hey, it secures all the e-commerce stores' skill. Just suffer on. You don't need anything more besides just looking at ZAP's review. That's enough. The names of the parameter will signify their reason, their, you know, their purpose, discount, prices, whatever. Now, the second attack I want to discuss, it's not exactly a relative of parameter tampering. It's just as old as it is. It's called forced browsing. Okay? And the slide is on all backup on the first file, but I'll discuss forced browsing there. They'll probably skip the slide somewhere along the way. So, yes. Is there a way with ZAP that it has some sort of iterator that, you know, gets through... Yes, of course. The ZAP fast-testing feature, the automation feature, which is fantastic, by the way. I actually use it more than I use the ZAP feature. In that specific feature, I like the dictionaries. Okay? There's a various optional dictionaries that you can do ZAP. We'll get to that, but we will get to that once we discuss the automated features in ZAP. The reason I'm teaching ZAP and not ZAP free edition, which probably has better memory management, is because ZAP has built-in scanning and fuzzing features in the free version. There's only a free version. It's awesome. Okay? So, those features are very useful to the pentastars trying to enumerate. So, if you do that in Berkley edition, you'll be limited to the quantity or speed of the test. If you do that in ZAP, you know, there's no commercial restrictions. You can see, please, the enumeration feature. So, as an answer to your question, yes. To show it to you, if you ask, if I wanted to do an enumeration with ZAP for specific identifier, I'll go in ZAP. I'm going to show it in dojo specifically because I need the request to be visible. See? I'm not sure I'm working with ZAP here. No? Yes, ZAP is disabled. I'm going to route the application to ZAP. Let's say I want to do an enumeration for some sort of an identifier. I don't want to guess it all on my own. I'll go to ZAP and I'll right-click on the relevant request I want to fuzz. Okay? That's the professional term we'll use here. Fuzz testing. Okay? That's the request. It's very hard to see. Okay? So I'll right-click and press fuzz. It will open up the fuzzing window in ZAP and I can pick either numbers, characters, whatever I want. It's very slow here for some reason. I'll put it in another request. It will work the same in dojo and in ZAP. ZAP outside of dojo. You right-click on a certain request that you want to fuzz. You pick fuzz on that request and you'll get to that window. Okay? Now in this window we'll have to figure out what do you want to fuzz, which element of the request. So let's say I want to fuzz the URL or specific parameter or something else. I'll add a fuzz point to it. Okay? Right-click is fuzz. Pick the element you want in the URL. You can pick a couple of elements. And then ZAP will replace the three characters I selected with whichever list of values I add to it. Okay? So I can add a number of values. I can add strings. So if you want something numeric, open up an Excel. Write numbers one, two, three and drag it. You know, to 1,000 and copy the entire Excel sheet and paste it here. And then to replace it from, you know, whichever number you listed. Just, you know, just to show you what I'm doing. I'll just open up an Excel sheet. That's probably an easy work method. You know what I mean? Kind of old school here. I don't know. It's old school or, you know, being lazy to figure out the actual convenient method in ZAP. I'll just write one, two, three. Drag and drop it to whichever number I want. I don't know. 157. Copy the entire list of values that I... Anyway, copy the entire list of values that I have and paste it into this box in ZAP. The corporate box in ZAP. That's it. To replace the values with the values that I placed. Okay? That's pretty much it. It will take every value, like separated by CRLF, that I have placed here and replace the value in the request with it and gather up all the responses, okay? And let you see the various element of each response. It will tell you, hey, this response have, I don't know, 50 characters in the response. This response has an error code of 500. And to the differentiation of the responses, you'll be able to figure out which resources existed and which did not exist. Or you don't have permission to access them. Okay? Does that answer the question? Who asked you, by the way? Oh, okay. So, got confused. Too many participants. So, anyway, that's the first phasing feature. You also have dictionaries, by the way. We'll get to that once we discussed all those solid files and stuff like that, but that's enough for now. Okay? So, I started discussing forced browsing. Okay? Forced browsing is a very different attack. It's an attack in which, instead of directly accessing to a resource identifier, which isn't my own, I'm accessing a web page that I'm not supposed to access. In the previous days, you know, 2002, 3, 4, 5, 6, 8, 10, it was very common that security would have been enforced to good countermeasures. Meaning, if you would have been a simple user, the GUI, the Graphical Interface, the web pages presented to you in the menus in the website you're accessing only listed the URLs that you're supposed to see. But there wasn't any enforcement if you would have directly accessed a URL in another location that you weren't supposed to access. Directly accessing admin pages, for example. So, a nice story from a customer that is actually sitting here in the audience. An application I tested it for him a couple of years ago, probably 2009, something like that. They had a fantastic application. You know, it was beautifully designed. It was working pretty well, noise injection and stuff like that. It was supposed to be hard to hack. And they had a help feature in the application. Now, the help feature actually listed. It was kind of like a shelf product. Anyone could have bought it. It's not a website in the Internet. It's more like a product that you send to customers. You know, you send to customers. And the website, eventually the product was like a hosted website inside the organization. And the help page actually described how each user uses every possible feature in the application. Okay? Now, it included the help pages. It included screen captures. Beautiful thing about it. Since it explained the role of users and administrators, the screen captures in the help page actually included the URLs. Okay? So just reviewing the help pages, you could have seen the URLs of all the admin pages. So it was a Java application because that was the typical language the organization used. And just by writing, I think it was something like a slash admin slash ad users.js. Something like that. Without any authentication, nothing, without being authorized to the system, you could simply just directly access the admin sort of pages and the admin sort of user. And then that's it. You're in. They didn't forget to verify the authentication slash authorization in all the pages. You only forgot to do it in a few. But that's enough. Okay? Now, first browsing is an attack in which the attacker directly accesses an entry point in the server. A web page. A web service. A REST method. It doesn't really matter. Instead of going to the normal flow of authenticating to the system and only then going to, if he has permission, he either guesses the name of internal secret unauthorized high privilege pages or identifies them to other means. We'll get to those means later on. Okay? So, method. The attacker attempts to either bypass the authentication entirely. He doesn't have an account for the system. Or the attacker is a low privilege user and is attempting to access an admin or high privilege user resources, meaning pages, web services, et cetera. The method to do so is simply to guess the name and parameters required to access a high privilege slash authenticated entry point. Okay? As an example, let's take Web Security Dojo. Okay? To demonstrate it. I'll intentionally close up Dojo for now. Don't need it right now. Within Dojo, if you would have gotten, now, to the admin interface in Dojo, which is typically, you know, anytime you write all one equals one, you're typically the admin. So let's say I'll intentionally access the admin pages here. Within the admin account, within the admin account, there's the whole admin section here. You see that? There's a variety of pages that are only supposed to be available to an administrative user. When you logged out, logged in with the user, A Smith Andy, we didn't even get to those links. We weren't able to identify them. Okay? They weren't in our menu. Now those, no, features, they have an address in the website. In this case, those are web pages. So I'll just copy them to prove my point. I'll copy both of them. And I'll log out of the application, out of the application. Now, if an attacker would have been able to guess the name of those pages, for whatever reason, okay? And access them directly, there's two options. A, it wouldn't work because it's not authenticated. Or B, it would work regardless of authentication methods. Okay? In this case, you notice that I logged out. And even though I logged out, I just by writing the right URL address and directly accessing it, I already got in. And not only that I got in, I'm able to activate the feature that only administrator is supposed to activate. I can now enable, disable account, delete accounts, and whatever. Now, the funny thing is that administrative pages are much more prone to those exposures. I'll explain why. User-specific pages usually query something in order to present customers or content to the user. Usually a user identifier found in the session or something similar to filter the information presented to the user. Accessing those pages without any authentication means that there will be an exception because there won't be anything to filter in the queries. Typically, no authentication bypass. It's not it won't necessarily work. In many pages, in user-specific pages, it simply will cause exceptions and other elements will intervene with the attack. Since the administrator doesn't have any content filtering, there's no permissions being enforced on administrator. He's able to access everything. There's very little chance that there will be an exception because something will be missing. Lack of authentication enforcement won't be mitigated by any other controls. In general, forced browsing can be used to do a couple of things. Forced browsing can be used to bypass the authentication entirely and access internal entry points, either user-specific, rather, or administrative. Forced browsing can also be used to elevate the privileges of the user. There's two different types of checks. The developer may check, hey, is the user already authenticated? That's one check. The developer can also check, is the user authorized to access this page? Now, the developer may forget to do either one of those checks, for our purposes, bypassing or elevating permissions may be possible even if the developer is verifying whether the user is authenticated. So let's say I'm a simple user in some bank and I'm trying to access the administrator pages in the website. I may be able to access the web page because the developer isn't checking for permissions, but an unauthenticated attacker may not be able to because there's authentication validation, which is general. I won't know until I test both options, both as an unauthenticated user and as a low-privileged authenticated user. So to perform this attack, all I need to do is to figure out how to identify entry points in the application and access them directly. Let's talk about the how. By the way, anyone have any questions so far? Regarding false browsing, powerful tampering, anything? Okay, I'm guessing no. Okay, so to identify entry points, in general, I can use a couple of features in Zap. A, I can use the fast testing feature with a dictionary of files. That's one option, okay? I just do the fast testing with another request, which is more suited to it. Let's say I pick a website that can hack, legally. So I access my own website just for the purposes of this demo. I have the feeling I won't be suing myself. And I'll do some fast testing on it. Now, by accessing the website to Zap, it was added to Zap list of websites, I can just pick any URL I want in the website. With epoxy, too much calcium. I want to just pick any URL that I want to fast test on. So by picking the fast testing feature and selecting the entire URL, I'll be able to replace it with different page or directory names. That's just one way to do it. To do it, there's other methods I'll be showing there in a second. Now, by marking the URL element, okay, the page name, the entry point name element, and clicking end, I should be able to pick a file fuzzer. That's how it's called. A file fuzzer from a list of pre-configured fuzzers in Zap, okay? There's DeerBuster, there's other dictionaries you can import. I'll show you in a second how you can import them. Eventually, I'll just pick a couple of directories. In my case, I typically pick Raft and a couple of similar directories, dictionaries for file discovery, okay? So Raft, large, or Raft, well, probably small one. Raft, file, slower case. And then I simply, after picking the right dictionary to replace with a file name, all I have to do is just start fuzzing and then Zap will try all the possibilities and let me know what the results were for each possibility, what the response code were, 404 means typically that it doesn't exist, what does exist, and so on and so on. I can actually filter according to the request and response to see if anything specific different than 404 were identified or something with a very big size or different size was identified. That's one method. Another method is a more dedicated file discovery, dedicated method which was built into Zap. It also exists as an external tool, originally it was called, it still is called Gearbuster, it's another loss project, but it's kind of ingrained in Zap these days. You can simply right-click, let's see if I can see it here, right-click, attack forced browse site or forced browse directory or forced browse directory and children. What this option will do is to automatically attempt to identify files, directories and Zap directories depending on your choice in the URL or website of your choice. It will automatically try to identify files of various technologies and anything relevant. Now, you can be configured, you can configure the various lists it will use out of the dictionaries that you have. Now, it's not as, well, in my opinion, not as easy to configure as the typical Gearbuster, but it will work just the same, okay? That's another thing you can do, use dedicated forced browse in future. Finally, it does the matter of gaining quality dictionaries. If you want to discover security URLs in Italian websites, you have to identify relevant names. It will take just, you know, bad dictionary or may try to access relevant page names and entry point names. So Zap has a nice kind of like plug-in store feature, okay? Manage add-ons, that's the feature. I really recommend that all of you will click it right now. It's a great feature. If you're using it for developer development, SSDLC, QA testing or whatever, the extension here, the extension here can really help you out. It will need internet connection because it's going to download it from the repository, okay? And if you can either update your existing plugins or go to the marketplace and check for existing additional plugins. The reason I have so many dictionaries is because I installed various optional dictionaries of Gearbuster, of FastDB, of, no, SVN digger, a couple of optional dictionaries which are relatively high quality, it depends on how you turn it, okay? I will refer to it, but they're very good dictionaries and they're typically on using, on websites, they encounter some nice stuff, okay? So that's one method to identify secret entry points for forced browsing attacks. Simply to bootforce the website, perform a dictionary attack, not to uncover enumerated files and the directories. Another method is more, well, it's kind of a detective work, okay? You're already able to use Zap to crawl the application. The nice thing about Zap, it stores everything. This is the most underused feature in the industry. I don't know why. I'm working with a lot of printers at the privilege of, you know, training over a hundred printers slash hackers over the years, you know, probably a couple of hundred of developers, maybe even more. I've been doing training for one, 11, 12 years, something like that. So I've been teaching Zap and Bear for a long, long time and nobody ever uses this feature. It's so key to uncover and secure TRS. It's so easy. If you go to various web pages, spread pages in the application, Zap will store the content of all the HTML files, dynamic files, chess files, everything. In order to identify secret entry points, all you have to do is to seek dynamic extensions. That's it. That's it. So let's say right now in Tech API, I access Tech API and it's a JSP application. I would typically search Zap. I'll just delete the rest of the content so I won't be confused by irrelevant data. I'll just delete some content. It's very slow today, but it is. So guys, I'll actually restart Zap because I think doing the demo will work faster. I just put too much information into it. The only disadvantage of Zap, it has fantastic tool sets. Sometimes if you overload it with too much requests, it gets stuck, okay? It doesn't have the same issues. However, if you manage it properly and use it in the right context, it's very useful. Now, what I'll do is something I don't recommend you do for your own applications. I'm going to spider the application. The reason I won't recommend you to spider your own applications is because the spider feature actually accesses every possible page. So if you authenticate it, let's say to your bank, there's, like, buttons of the activate account, transfer one million dollars, whatever. There's various buttons. It will actually click all of them. Had a guy once, a pen tester. The same one I said that is, like, instructing yesterday. He did it for his Facebook account. He didn't have many friends there. There's, like, the remove friend button in Facebook. He didn't work to a friend. I'll do restart, okay? So anyway, so spider is dangerous in case I didn't emphasize that enough. So I'm going to use spider on this very specific website, only in this specific instance, so I can gather some content, okay? I'm going to disable the proxy because I don't want any garbage information in Zap. I want this search to be very focused, okay? So I'll use the attack spider feature very carefully and after a couple of spidering, well, after a couple of URLs that will be uncovered, I think that's enough for me. That's good enough. I'll do, I'll use the search feature in Zap. Now Zap has a fantastic search feature, so it searches everywhere in the request of the response, okay? I can actually define what I want to request, response, URL, whatever I want it to be found. So in my case, I want content being disclosed by mistake in JavaScript files, in HTML comments, stuff like that. Things that developers forgot, okay? So probably a long time ago, one of Israel's three major banks, that's, you know, as low as I get, one of the three, you can guess on your own, I had, you know, an application of the Clarex, the application of the Clarex use. Now it was a web application, and I right clicked on the main page and they'll just view the source. And there was an HTML comment there that says, the page runsql.sp is obsolete and should be removed, okay? Something like that, okay? It's saying, you just, you know, just don't do much, just copy and paste URL, and you get to the runsql page. There was no design whatsoever. There was a text box and submit. But, you know, select, you know, everything from CIS objects, presented the entire content of the script database, and then select in Italian, you got the point, okay? So developers disclose, you know, ridiculous amounts of content unintentionally. They disclose it in JavaScript files. They disclose it unintentionally in content. This is the best way to identify, seek identity points even in your application, okay? I've been using it for years. People don't understand how, how, if I know, vulnerabilities on top of other people, because there's simply entry points that other people don't identify. Yes? Search for that are more useful than the rest? Yes. Well, we used to have a methodology called log hacking. I don't remember to deal with it eventually. Over the years, it got posted. We didn't really publish it, in which we created all the search criteria to search in proxy logs. So we had dot extensions for specific technologies, such as .jsp, .do, .php, .js, .html. And you would filter all those results. Then eventually it got to comments and technologies. There's a bunch of those, okay? Now Zap has passive plugins, but the passive plugins can't uncover everything, okay? They can't do all the work for you, for you. And this specific task, uncovering secret entry points, it's a manual job, okay? It's a manual because sometimes the conventions of the URL are more complicated. You need to search for fragments. So in our example, just searching for .jsp in response will get a bunch of matches, okay? A bunch of matches, and we can go through them and identify different web pages in the application. Now sometimes we will have the same page. It might be tedious. Many, many, many scenarios will identify pages who would never have identified in other ways. I mean, you would see administrator pages. You would see old pages, obsolete pages. You would get a bunch of those, okay? So that's another method to identify those pages. Very effective for the purposes of forced browsing, okay? Now, in your exercise, later on, not now, you can use all methods. You can use guests on your own, search manually, use the fast testing feature, use the built-in Deer Buster engine within ZAP, the forced browsing feature. You can do it every month, or my recommendation, start with the search feature with the extension of the technology the website is developed in. If it's a PHP website, it has PHP extension, search for .php. Search for .php is the response, and see what is disclosed. If you are testing ARM or an ASP.net website, search for .spx, and so on and so on. Search for URLs and ether points, you'll see what you'll get, okay? If you are, those of you working inside some sort of bingo gamerate, that's a good opportunity to check your website and see what you're really exposing unintentionally to the user in your various libraries. Now, the extension to that, the extension to forced browsing, the other uses you can do with forced browsing is directly access files that contain sensitive content, regardless of whether or not they're dynamic, okay? We typically, the short term for it is backup files and OST records it as old backup and unreferenced files. That's the category in OST, okay? It's generally any file that we can directly access using forced browsing in the website, which is old, obsolete, unintentional, or compressed, which is a fantastic way to start a hacking day job, okay? Another story. Remember that back I told you earlier? Not him, one of his competitors. One of the big three, okay? They had a website to register online for various banking purposes, you know, to just start an account. Now, the website was a JSP website, okay? Well, I'm searching for specific pages. You should smile and look a shame at nobody, you know? He's not here right now. Anyway, so the website was written in JSP and the website directory name, there was a specific directory name. I don't remember what it was. It was enlist or join or whatever. The developer there wanted to create a backup copy of the directory, so he zipped it, okay? So if you would have written join.zip at the root URL of the bank, the entire source code of the website, the obsessive code, database queries, database passwords, truly amazing information, hard-coded passwords of secret accounts, stuff like that, okay? Would have been downloaded to your PC, okay? Same, I saw similar instances in numerous other websites, like backup files, zip file, compressed websites, and in the past, I had to do the entire job manually. These days, you know, zap has built-in features. Now, what can we identify? How does it look like? How does an old backup, compressed file look like? Now, it depends. A, there's backup files and source code files that we can access, but we typically aren't able to download them directly. There's a reason for that. Dynamic website technologies differ from, you know, dynamic files differ from static files in a very specific aspect. When I'm accessing an HTML file or a JavaScript file in technologies other than Node.js, the file isn't executed in the website. It's actually being downloaded to the browser as is, and the browser is, you know, passing it, presenting it, and that's it. It's only being executed in the client side. It's being downloaded from the website. A dynamic page is actually being executed when we access it in the server side, and the output of that page is what we see in the browser. We don't download the file. The server doesn't let us. It only returns the output of the execution of that dynamic page. That's how it works. Okay? Now, so accessing protected configuration files like WebXMN in Java, WebConfig in .NET, S-PIX, device S-PIX extension in .NET, JSP, all the various expansions in Java, in properly configured web servers, you're not supposed to be able to download them. However, the backup extensions of them, no, that's a completely different thing. Accessing .JSP.back, I mean, that's not an executable extension. The file will be downloaded immediately. Okay? .old.grandma.grandpapa. You pick the extension, it doesn't bunch of those. Okay? Accessing the obsolete extensions is a fantastic way to download the actual code of something very close to it without actually, you know, while skipping the old server side execution phase. Okay? So we can either access compressed elements of files. Okay? Z, the .tall, .tall, .tall, .tall, .tall, .tall. There's a bunch of tools that do that automatically. Berbsuit, .pore, has a very good engine. Zap has as well. Okay? Just to uncover backup files, there's a, you know, hard core backup extensions, adding one at the end, old backup, BCK, and so on and so on. And there's something which is, you know, it's very rare to see these days. Simply because technology isn't being used as much as it used to be, as much as it used in the past. Lucky me. Stop talking. Okay? So there's something called includes. Obsolute or relative obsolute technologies like JSP, it's still being used. And, you know, PHP have built-in features to include source codes from a centralized, you know, file. So a couple of files in the website can actually reduce the amount of code that the developer needs to write by including another file. Those of you who have CC++ developers, it's very much like the include instruction CC++. Okay? It differs from importing Java because not importing something, well, we're importing something that may reside on the web server. That's the whole point. Now include files are source code files with an extension that does not compile. Okay? So accessing an include file directory directly if we figure out where it is. Okay? Will actually cause the web server to refer to it not as dynamic code but as code which is static. So we'll get it back if we access it directly. All of those files, temp files, backup files, archives, just by either guessing them or enumerating them or no. Somehow accessing them directly will be able to no, get their sensitive content. Now before you figure out how do we get to those pages at all? How do we figure out which obsolete pages may exist in the application? There's a very nice way I want to show you. It's amazing in terms of what it can get you in penetration test. I can't emphasize it enough but it happens very effective specifically for obsolete content. It's called Wayback Machine. Anyone have about it? Except for the pentastars? Very few people, really. Wayback Machine. D-Wayback Machine. So Wayback Machine is a fantastic tool. It's not designed for pentesting but it's very useful for penetration testing purposes. It's actually an archive of the Internet in different periods. It's an online resource, freely useable, you can access it anyway and let's say you want to see a version of a website 10 years in the past including all the page names that existed 10 years in the past, it's there. Now give me a website. Not security agencies, right? Something I won't be assassinated for. Come on man. Something universal. cnn.com cnn.com Let's go to cnn.com and see... I think it's HTTPS these days but let's see what cnn.com means to us. I think I need a complete one but we'll see. It has the addition sub-domain these days. Just a sec. What you can see is that the history for this sub-domain edition cnn.com since 2001 you can actually see the changes in cnn.com throughout the entire history of the website. Not just that, you can actually access a specific instance in history and access all the pages that were documented in that specific year in cnn.com. All the names of the entry points all the names of all the content that you have. Let's say the current menu of the website presents 5 pages but I'm going to weigh back history a couple of years ago and I see 25. Those pages are likely still there in many cases developers don't have the mentality if it works, don't touch. Those pages are likely there and you might be able to access them. I did that a couple of weeks ago I had a pen test against Kiko's car service application I can't give its name but I can describe the service that I had in the past and they had a page called Encrypt which was an old page .aspx something like that. That application that page was actually responsible for a gazillion features that they had so you were able to actually decipher the SSO token of the application you were able to encrypt and encrypt and create your own authentication tokens for an admin user for any people they intended to delete it they wanted to delete it they just forgot about it they didn't want to mess around with the pages in the application so they just kept it there for years and using way back and comparing the URLs that I see there the URLs that I see after calling the application or to identify the gaps and access the absolute pages so that's another method to do to identify absolute pages well the first method is obviously fast testing and using Deer Buster and other those of you who use BELP or the Discover content feature is fantastic it's really good at identifying exactly those type of pages but if you want to do like a more thorough job you can do it with the machine and let's see I think you guys just earned your break let's see if I missed anything yeah well well I want to give you a couple of notes about the dangers of using ZAPS automated features yes yes of course it's in scope you're right I haven't talked to me about doing a second of course and then we melt down and figure out that people won't come to SecDev course which is pretty much a commodity these days so we kind of migrated it to half SecDev and half hacking and eventually went to majorly hacking and then a little bit SecDev which is what we have today we're getting all the SecDev material for the final phases we're actually giving you like a perfect page example all the steps you need to perform model to the end of a model any model to mitigate most of the common use attack these days as an answer to a question in terms of force browsing the specific mitigation is authentication validation need to validate an authentication value in the session authentication token whatever your authentication method is and permission validation a template attack the mitigation is to reduce the consumer control there's two methods really .NET has a fantastic feature of signing web controls maybe you've heard about it event validation and view state now those fields actually enable you to enforce to specific fields like text boxes, combo boxes more combo boxes and list boxes to make sure that the user won't be able to send values not originally in its list I won't discuss the how of it it's a bit more complicated but the server verifies a signature that if the client changed anything the server will be able to see that that is not a value he had an option to choose a better solution a much better solution is to avoid allowing the client to send the value from the client side entirely there's no reason in the world for the client to deliver the price to you does that make sense? I mean, unless you are a very, very generous dealer there's no reason for the client to send an easy mean flag to you or if this count equals zero to you you shouldn't get those flags and parameters from the client this is just bad practice although it's bad practice and it is 2017 trust me, I see it all the time all the time and some of the entities in the cloud we've been working together for years and they see the findings over the years it happens because the developer has no awareness that those values he has written in his perfect code from his perspective can actually be abused not to the client good the client good is protected how would somebody manipulate it especially in mobile applications or thickline applications it's just incomprehensible because they've never seen an interception proxy and how it works, okay? but it's there, but the solution reduce consumer control don't accept content from the client that you can accept from elsewhere only receive parameters that are known only the client can send them no choice but to get them from the client that's the best practice so, did I answer your question? for basing and authentication validation, authorization validation reduce consumer control okay and coffee break? coffee break? because I know you guys will be late I was the one late you know anyway I'm going to take a short break until 4 p.m. that's a lot of time for coffee, alcohol you know seven red bulls because I see the faces all in a sleep here, you know there's a red bull machine here really good stuff