 In this course, I decided to change the order in which we learn attacks. Typically, you know, information security courses, people start with SQL ejection courses, scripting. The reason I started with different attacks, like a parameter tampering, because I wanted you to get types of attacks that are easy to identify, and I'm following with the same course here, by teaching you Pastel, Versa, LFI, RFI, SSRS. Okay, those are vulnerabilities, and we'll discuss what they are in a moment, that you can identify just by looking at the parameter names and values in the tree of the intersection proxy. If you get it, if you understand what the meaning of the parameter is, you'll be able to identify vulnerable instances in moments once you mark the various web pages of the website. It doesn't require any sophistication or any, you know, exceptional sophistication. Just paying attention to details and understanding the mechanics. So if parameter tampering, you know, false browser, people will deal with primarily the business logic elements, I'm not including the backup file section, they kind of have tackled the business logic aspects, Pastel, Versa, LFI, RFI, it's actually a bunch of technical attacks that enable attackers to cause the server to access resources that the developer did not intend us to access. Okay? It's a method to cause the server to fetch us resources that are secret hidden in internal network, in the internal file system, the developer had no clue he would abuse his features to obtain. Okay? Now, I'll try and teach those exposures in a kind of like layered method. So I'll teach the basics, attacks first and then on top of them I'll teach additional extended attacks and so on until we reach to, I will not choose the pinnacle to the last attack, which is kind of an exploitation method called SSRF, server-side-request surgery. I don't know. It's something I see a lot these days, in my opinion, well, we can need to very nice exploits against organization and, you know, let's start. Anyway, fine inclusion attacks, that's the category Pastel, Versa, LFI, RFI, SSRF, they're all classified under. It's those attacks that abuse features in the application that refers to file, refer to file URLs, directories or other, you know, resources which are servers, networks, IP addresses, files, directories, and cause the server by manipulating client originating inputs to access other resources. You'll see those features which are legitimate and necessary everywhere. For example, let's take, come on, softpedia, download.com, the earlier versions, okay? When you wanted to download the file, you had to tell the web server which file to download. If the file wasn't stored on the front-end server, it would typically be received as a parameter, the file you wanted to download, right? So I had to set the server request like getmyfile.jsp, question mark, file equals the file you want to download. I don't know, whatever, gain.exe, okay? So in various locations in, you know, pretty much every application, there's parameters that originate from the client side that include either files or URLs. Let's say, let's take Facebook, for example. When you share a link to an external reference in Facebook, Facebook has to receive that external reference from you, right? So there should, when you send a message and it includes some sort of URL, Facebook has to receive a parameter with a URL from you. So by design, some of those services need to accept a legitimate value that contain a reference to a remote or local file, okay? However, attackers using a variety of attacks can manipulate those values to cause the server to access other sensitive resources. And we'll start with the most obvious one, okay? Pastroversal attack, okay? Pastroversal attack, directory traversal, as once we used to call it, over a local file inclusion, a closely related attack, okay, primarily for PHP, are a set of attacks in which we cause the server to a parameter that receives a file or directory name to access sensitive files inside the server, source code files, configuration files, database files, Linux key files, and so on and so on and so on and so on. Whatever you want to access that's inside the permitted context of the application in the web server, okay? The concept is actually simple. Any time we find a parameter that receives a file name as input, instead of sending the input, we'll send the name of whatever file you want to access with traversal characters. The concept of traversal characters is quite simple. We simply send characters that signify to the operating system or to the class accessing the files that we actually refer to the directory below the current directory, okay? So let's say we're actually accessing C, you can see, you can see, okay? C.myfiles.hostedfiles, let's just send the name so it makes no sense. Application files and uploaded files, okay? Let's say a specific user is trying to download the file he uploaded into the application, okay? And his file name is myfile.exe, okay? So he's probably sending a request to the server to a feature that exists in the server, the client isn't writing the server side page. There's a page that the developer implemented for him, for him to be able to get the file, okay? So it will be server.com.getmyfile.sbx, question mark, file equals myfile. So what a malicious user or an attacker can do is instead of accessing myfile, access other files in the operating system or web server. You can do that by using traversal characters. For example, by sending slash dot dot slash dot dot slash and boot in it, just as an example, okay? It's not necessarily the most sensitive file I'll try to get. Here, if the server, if the developer in the server side appends that, thank you very much for not defining it. I would have, no, it would have taken two hours to know from my side. But anyway, if the server appends the relative URL that I'm sending to the full URL it's constructing, the end result will be something like this. One directory, another directory, backwards one directory, backwards one directory, boot in it. So my payload would actually cause the web server instead of fetching the directories, instead of fetching files from the permitted directory, the developer originally intended for me to access files in, it will allow me to access files in the root folder of the operating system, okay? So it's, okay, how about we talk a little bit about the mechanics, I mean? How about I demonstrate something? I think that will work really well. Those of you with Web Security Dojo, there's a couple of complicated experts here, I want to show you a really simple one, it's not as visual as the rest of the application, but it will prove my point, okay? So if you access the application section in Web Security Dojo, just open a new Firefox instance, you'll get to a bunch of applications that are accessible in Web Security Dojo. All of them is an application called WAFSEP. And there's a bunch of valuable entry points there, and specifically, there's a bunch of entry points valuable to past addresses. So eventually, once Web Security Dojo will start, in the meantime, I'm going to access WebBoard to see which one works first. The action flows, how do they categorize it? See, insecure storage probably, I'm guessing, nope. Okay, so I'm going to get to the application, to WAFSEP, and while it's loading, I'll take the files, okay? So in WAFSEP, there's a bunch of test cases, a bunch of valuable entry points under the category LFI. It really is more a past reversal than actual LFI, local file inclusion vulnerabilities, but for our demo purposes, that's more than enough. There's a specific web page here, and each one of those, there's a specific structure to the web pages here. Each web page is expecting to receive a specific file name from the user, okay? Although the user only sends a single input by implementing traversal characters, man, this is slow. I apologize for that. It's called WAFSEP. Relative pass, good. Just be patient, good. So the file that I have here is Eclipse Ely, okay? It's just a relative pass in, we'll see, the absolute directory is, I'm finding, is var, lib, tomcat 8, webapps, WAFSEP, okay? I'll just produce the size of the window and increase the font size so you'll be able to see it. Any good? Better? Okay, so instead of accessing the Eclipse any file, I can access other files that are more interesting for my point of view. For example, this is a Java application. In a Java application, I can try to access the WebXML file, which is a sensitive file that enables me to, you know, it includes all the relevant specific configuration of the application. Now, in a normal attack scenario, I would try all the possibilities, all the possibilities, dot, dot, slash, dot, dot, slash, dot, dot, slash, and the name on the file. I would try every possible option until I get the file of my, you know, the file I'm trying to access. So in my case, I would try dot, dot, slash, web, inf, dot, web, XML. The Java developers around you should be familiar with this file type. If that won't work, I'll try slash, dot, dot, slash. If that won't work, I'll try twice, dot, dot, slash, and so on, and so on, and so on, and so on, okay? Until I get to the file I want. But to do that, I have to map out the appropriate injection I need to append, okay? To do that, I'll use a simple, to do that, I won't do it now because there's no time in this specific demo. I'll just get to the file I want. I'll just do a run, one directory, two directories, three directories, back, okay. So dot, dot, slash, dot, dot, slash, web, inf, dot, web, XML, okay? Not sure if it will work, but let's figure, let's find out. Let's see if I'm injecting the appropriate value. Maybe it's not the context I'm found in. Let's see the context I'm found in. Maybe just one, but let's try. Be patient, no luck for me. Not, let's cheat. I like cheating. Yeah, maybe. I don't remember the specific test case and I don't have the time to go to the entire, you know, actual attack in, you know, tile and error right now. I'll just copy an exploit that works with your permission, of course, or without your permission. I'm not sure it will work in Linux because I don't know which permissions they have for the application, but it might actually work. I need to see if I really, possibly could have figured it out by myself. Anyway, okay. It won't work because we need additional slashes, I'm guessing. Yeah, we need additional slashes, that's the same. It will be, it will take me a minute longer. Oh, seriously, did you see what happened? See just what just happened? Three slashes, dot dot slash, dot dot slash, dot dot slash, find download dialog. Why? Wanna guess what I'll see? Wanna guess what I'll see? Okay. In case you don't wanna guess, let's just take a look. Performance of the VM. It's a bit too slow for my taste, okay? And I'm just, I'm going to let you settle with this popup and get to it eventually someday. In general, what happened is that I just accessed a file that is hosted on somewhere inside the hard drive. In this case, the ATC passability file, which is no, it contains the users and hashes, not the password hashes, but users and devices in the Linux operating system, okay? In this case, Ubuntu, or Xubuntu. So, instead of accessing the file the developer intended, which was, I don't know, a clip scene, I accessed another file in the system, which could have been a configuration file, source code file, a history file, listing all the other files in the system that were recently accessed, or any other content I managed to guess or enumerate, okay? There's various methodologies that also prevent the need for enumeration, like accessing the Linux history file, which will be downloaded and then return the various files that exist in the system, assuming they were accessed, and then following through and downloading additional files. Part nine, and the developer, if the developer has such an exposure in the system, he will probably be able to download almost everything you want from the application, and if there are some permission issues, probably everything you want from the server. And if he's using very specific classes to implement the feature, anything that is available to download from his network, okay? Why? Because you can access URLs to various methods. You can use pass, no, the typical pass that you recognize, like on Linux, dot home, dot whatever you want, dot directory, okay? Dot filename, or in Windows CD file. But you can also use other references. It may be supported by the underlying protocol implementation class, okay? The underlying file access class, such as shares in Microsoft, okay? Accessing another location in the network, okay? Or you can access other elements in this input, such as, I don't know, you can use the file format, the fantastic format that enables you to access full pass or other elements in the network, okay? And so on and so on and so on. All of those methods enable you to access resources that are available somewhere in the network without necessarily the developer intending you to, okay? Now, the ability to enumerate the correct file may be difficult and it may cause some trial and error. But there's a method to immediately know if the feature is at least partially vulnerable or not. And it's really simple. It's only comparing a bunch of strings to each other. I think probably should demonstrate it in a webgold because the demo would work faster. So I'll just take a second to identify the relevant pass or version feature here. I want to show this method in method that Mel, that beats me where they hide it, really. Access control, that's right. But sure, it seems like it falls down to me. Okay, maybe, maybe. Okay, I got it. You're right, you're right and I'm wrong, okay? So that's the feature, I think. Let's say try that with a epoxy, the section epoxy. I want to demonstrate the detection method because I want it to sit really well with you. Go to the latest requesting or subs up and let's analyze it. Okay, so I have a file parameter. That's one of the easiest way to identify the potentially vulnerable location to pass traversal SSRF, if you see a file or URL in one of the input fields, okay? Instead of trying all the possible extensions to know if the location is vulnerable, I can make a simple comparison, a very simple comparison. So command injection accessing this file will yield a certain content, okay? I'll get a certain content, see? That's the content that I'll get, okay? And if I access a file that doesn't exist, I don't know, content injection, two, two, three, three, one, one, something that doesn't exist, I'll get another response, okay? Now, to figure out what does exist and what does not exist, I'll need some sort to do. Already allowed in the directory, okay? I need to compare the responses. For that purpose, I'm going to use Burp although I said I'll use up one as much as I can. I'm going to use the feature comparison element in Burp, okay? Fantastic feature, the compare in Burp. I'm going to use it to compare the responses that I'll get from the various attempts I'm going to make, okay? Going to take the response I get to a legitimate valid file name. If that's really the case, I'm not sure that's the case. I'm not sure I'm getting a success here or a, so I'll access a legitimate file. I'll take the response it was provided and I'll copy paste it to Burp's compare, okay? Just a sec, just a sec, be patient. Then I'll access a file that does not exist to verify that valid file and invalid files get different responses. As a precondition to make this comparison. So that the response I get to a valid file and accessing an invalid file, let's say a file that I know doesn't exist, something like that, okay? I'll copy the response and let's verify that there's a difference between them, okay? So if I compare the results, I'll see that the difference is primarily in the exception. See that? Whether a file exists or doesn't exist, okay? I get different responses for that. See that? I also see the past, the application is trying to access in the response, okay? Now, by sending a valid traversal character that attempts to signify the meaning of the same directory, I should get the same response I get for a file file. For example, dot slash or slash dot slash we'll learn a second, dot, a single dot means in terms of past characters, the same directory. Double dot, dot dot slash means the upper directory. Accessing command injection dot html and dot slash command injection html, it is the same thing for past purposes, okay? So I should be able to get the same identical response. Let's see. I'll copy paste it to a bear point. Let's compare the first request, which is valid to the third request, which is supposed to be almost identical. I am guessing there will be a slight difference, but I am guessing wrong. There's no difference. It's exactly identical, which means that the traversal character worked. You with me? I use the traversal character, a very simple one, okay? And it worked. I access the same file. Let's use a traversal character with an extra dot, okay? See that? Extra dot and let's compare that one and upper directory. Actually, I think this is a bad test. I'm not sure it's gonna work. Not in this example. Mainly I'll go back to WhatsApp, but let's give it a go anyway. I didn't work very well in this example. I think I'll go back to WhatsApp today, example. Unfortunately, unfortunately. So, okay. The problem I have with WhatsApp is that the original file isn't necessarily something that exists in the platform. I'm not sure they in study to the clips in it, which is why I didn't try to demonstrate it. Maybe they did, maybe they didn't. They didn't, okay? This is why I didn't want to use the platform for this specific installation. So what I do is to cheat. Imagine the etcpasswd.dot slash whatever to be the legitimate file, okay? Dot slash passwd should yield the same result. It wins the same directory. Make sense? What happens? I still get the file. Dot dot slash should not yield the same result. So unless I'm a really, really unlucky pen tester in which tested the application that has every possible files in every possible directory, it should probably give me a different result, okay? Which is exactly what I'm getting right now. If dot slash created a response identical to a file I know that exists and dot dot slash create a result almost identical to a file that does not exist, this location is 90% vulnerable to pass traversal, okay? Without even identifying the file, it's vulnerable. Just this small comparison because it shows you that traversal character works and that paths have been concatenated without sufficient validations. Otherwise, the dot slash validation would have been blocked. Does that make sense? There are instances in which the developer tries to smart us by checking for dot dot slash. So we'll use dot dot backslash in Java to still work or we can use other types of traversals like slash dot dot slash, okay? Other combinations to bypass the signatures, bottom line, it's so simple. Dot slash filename versus dot dot slash filename. If dot slash the original filename that exists works just as the valid file that was originally in the input and the other combinations does not, you'll probably have a vulnerable location, okay? So how about I write the methodology down in the slide? Okay, let's explain it once it's in front of you. I'll get back to the source code samples in a second. Don't worry, okay? So in general, detection. I identify a file that exists. I try to access that file with a traversal, this a traversal variation, meaning the same directory. I can use a traversal character of either windows or Linux dot backslash dot slash doesn't matter, okay? As long as I manage to carry to the original file and get the same result. And then I use a traversal character that signifies an actual directory. That should be enough. Now, how does it look behind the scenes, okay? How does it look behind the scenes? I'm going to give you a couple of source code examples. It's really how to show source code and black examples for exposures such as backup files or tampering because it's really logical. It's really easy once the attack is technical like a traversal. So in our demo, in our scenario, I'm giving you two examples, one in Java one for one valid from Java and one vulnerable in Java and one not vulnerable because it uses the appropriate validation. So in the upper example, you'll see that input is being received from the client side, those of you who are developers, to into a parameter called file name and then the file name parameter is concatenated into a pass alongside the pub folder in green up there, okay? Without any validations whatsoever. So any traversal characters that the user will send from the client side, they're just workers they are as they are, okay? In the example below, we'll see the OSP ESAPI validator being used to sanitize the input and make sure that it's a file name that doesn't include any traversal characters, okay? That's like a good example. Things you can do it, common things. A, we can access the configuration files of the application, web XML, web config, depending on the technology that we attack, okay? Using a simple pass traversal method dot slash dot slash with the directory the configuration is found on in the application of the web server. We can access the operating system file if we have enough permissions. This is not something we can take for granted. Something we have, something we don't. Typically in hardened services, we have a harder time with it, but it's still exploitable to some extent, okay? Well, that's pretty much it. In terms of exercise, there's two locations I want you to exercise this exposure. Since the not sure we have much time to do so, we'll have a short exercise session in a couple of moments, okay? You can easily use Wafsep to exercise. Wafsep is located in a WebSQL DDotter as part of the application stream there. Or you can use a Insecue Web App which has a pass traversal vulnerability. A bit hard to detect, but you can identify there. So if you want to write a couple of names of applications, you can test your pass traversal skills against. Those are the applications, okay? Well, this is nice. It enables us to access sensitive files of the server, but I want to show you a couple of attacks. Then it can get us a bit further. How about accessing any resource in the network? Okay? Even more powerful with the light exploitation method, okay? So if LFI, pass traversal, refer to local file inclusion, files located in the current hard drive, and sometimes with the right pass characters and very specific support files in the network, remote file inclusion is by definition including an external file in the content that the server returns. It works somehow differently, though it is a file-related attacks. I'm going to describe a PHP variant of the remote file inclusion attack. PHP, as a language, is famous in allowing you to import external code into your server. You can even import code residing in other servers into your application. It works, okay? Remote file inclusion for PHP abuses that exact feature. If, for some reason, the developer includes content that originates from a client-provided URL, which can occur in many scenarios. If the developer embeds a picture that you sent the URL to. If the developer wants to append an article into its web page and you're providing the article because it's a talk-back in WhatsApp or in Facebook, okay? Or for various other reasons, instead of sending a URL to a simple web page or simple article, you can actually send a URL to your own malicious source code. So if the developer in PHP is actually including the content in terms of the use of the include instruction, it's going to be compiled or more accurately embedded into the PHP page, including it in runtime. So it's not going to be included as clear text or no, just static content. It's going to be executed in the server side, which is key. Being able to upload your own malicious code into a website is, you know, that's, that's the aspiration. That's what we hope to be able to achieve either directly or indirectly as hackers. We try to gain remote control over the server. The best way to do so efficiently is to run our own code on the server. That's really hard. We have to figure out how to deliver our source code to the server and cause the web server to execute it. Alpha, it is in its PHP variant, gives us all that. It enables us to pinpoint the server side page to a remote code that we wrote in another server, cause the page to include it and then execute it on the server side. It's kind of like origin on demand, that developers just doesn't figure, didn't figure it out. At least they didn't figure it out in the past. It's quite early this day, but you know, it's still, we still find it from time to time. So the point is this, we first, we identify a parameter sent from the client to the server that includes a URL by definition as a default input. For example, if you analyze the communication to Facebook or to other social networks, you may see that when you share a post with the URL, there's a parameter with the URL being sent from the client to the server. If the server performs operations on that value, processes it as in fetching the content, maybe you can do something to the server because of it. So, remote file inclusion, if the server is vulnerable to it, generally allows us to embed our code, at least into the presentation to the browser or to the server side code. Now, if you were at time to cut the course and scripting, you won't have any time in this course. I will discuss vectors such as cross-site scripting, VRFI or various combinations. At the moment, that stick with remote file inclusion as a feature that enables us to include code from an external source, which will be executed in our servers. I want to show you a short example. It's in JSP, and I haven't seen it working in newer JSP versions. It's, well, I don't think it's working, it is in newer JSP versions anyway, but the concept is clear. It should work the same in PHP. There's an include instruction in the page, and the include instruction is based on a client-side parameter. The include instruction was meant intentionally by the developer for the user to upload or refer legitimate content. Images, articles, whatever, but the user abuses it to refer the web page to include other malicious content in the same development language, the page, the server-side page is implemented in, okay? Now, there's various examples in other technologies, not all of them with the same impact as PHP or older JSP versions. Actually, in other technologies, it's pretty much limited to phishing, XSS, and other relatively mid-impact slash low-impact exposures, which is why hackers invented SSLF, okay? SSLF, and I'm going to give you a short explanation and maybe even a demo, is an attack that makes any RFI exposure, so even vulnerabilities less than RFI, vulnerabilities that don't present the content of the file accessed back to the user, exploitable. SSLF is simply abusing the page that fetches files instead of accessing external files, accessing internal files in the internal network. Think about it that way. Let's say Facebook is letting me send, let's say Facebook accepts URLs from the client side in inputs in order to enable me to share articles with my friends. If you remember, when you send a link in WhatsApp or Facebook of an article, they will typically fetch an image of the page and present it alongside the link. Do you know what I'm talking about? You'll see when you share a link with a news group or use article or whatever in WhatsApp or Facebook, you'll actually see an image of the external website alongside the post. It's kind of a way to beautify the message that Facebook or other social networks uses, and it means that it doesn't only take the URL you provide in the input, it fetches the content. So if it's so kind to fetch the content from external sources, maybe it's kind to fetch the content from internal sources as well. So let's say the page in Facebook or in, you know, it's not necessarily, I'm not discovering a new vulnerability in Facebook, I'm just giving Facebook as an example. Let's say the page in the social network that uses the, that passes the content looks something like that, okay? URL to share, http, fansite.com. That's something that the user typically shares. It shares a location which has an article or, I don't know, something else that the user, I said other users, they might be interested in seeing. Instead of accessing the URL, I can access something like that, then understand the impact of that. Now what that is? 160, 192, 168, 01. Where is this IP address located? Even, maybe, it may be the outer, it may not be the outer, I don't know what the outer IP address is, it may be anything that whatever was defined by the ID, it means title, this is an address in the internal network of the organization. Now if the page has a fetch feature outside, why wouldn't it have a fetch feature inside? There's barely the firewalls inside, and this compared to whatever it is, I mean, whatever it is, whatever it has to go to get to the outside world, so it has a better potential of working, and by accessing default interfaces, I can actually access default content, get back default responses of various services. In this case, the administration service of the outer, okay? So if I use that, for example, in a vulnerable location in web route, I'll be able to access the outer in the Wi-Fi that the network is hosted on, so if you do that to me, in my training app, you'll be able to do just that, find the location, valuable to a service in web route, and access the enter port, that's one thing you can do. You can also access and de facto port scan any resource in the network, by using a fuzzer with the right amount of configuration, you can access address one, two, three, four, you can access port 1,000, 1,001, 1,002, you can test every possible variation, not only access every, well, every possible interface in the internal network, you can map it out, okay? And you can even deliver parameters in the URL. You can send parameters such as user equals, puzzle equals, and maybe forget accepting interfaces, you can boot force credentials in internal services. Think about it, it's almost a Torjan, it's not as powerful as a Torjan, but it's a limited capability Torjan, in a feature that people would have ignored, in PHP they would have parted, hey, people can include a sensitive source code in our content, okay? They can cause their own code to be exited in the server side, but in technologies that aren't PHP or optional GSP, this attack would have been in the past, rated as a mid-sevility, but using SSRF exploits, server side, the first forgery exploits, you can access any resource in the server side just by sending a URL with the right content, okay? Now, how to look for those exposures? Remember I mentioned something about Zap and watching the tree and the parameter inside, okay? The nice thing about developers is because people, you know, they educate them well and they teach them all the best practices, they tend to use names with meaning, okay? Does it make sense? Because they tend to use names with meaning, they tend to use names with meaning that tells us what the input is supposed to contain. So let's say we see pass equals, a parameter called pass or a parameter called, I'll show you some good examples here. I won't get it here, anyway. So let's say I see a parameter in Zap's tree view that says pass or file or directory or whatever. As long as it is a parameter, I can conclude that there's a good chance that it may include URLs or pass, the pass parameters that I can mess with. Now, I gave a methodology to identify whether a location is vulnerable to pass traversal. I want to give you the same methodology for RFI SSRF, very simple methodology. Let's say I have an option to send a URL parameter to one of the web pages, okay? Like in this case. I don't know which other says exist in the network and guessing the one address can make me figure out it's not vulnerable, although it is vulnerable, okay? A simple method is to use the localhost command, okay? With a port, I know the web server is listening to. Typically, the web server port I'm currently accessing. I would test a couple because maybe there's a router in the middle or not, reverse proxy or whatever. But I would test combination under localhost. There's no chance that the web server won't be able to access localhost or 127.001. If that works, if I'm getting in the included content, the same content that exists on the actual target server, let's say I'm accessing Facebook page and it's vulnerable and I'm including Facebook's own page and I see it twice in the response, this means that Facebook is vulnerable to SRF. It means that the location that accepts the values from the client side is really fetching them even from the internal network because it accepted and fetched a location from the site. Localhost, okay? And from there, it's just a matter of figuring out if they have filters at all on internal IP addresses and figuring out whether it's 192.68 or 10.00 or 172.00 or whatever their convention is. In many cases, you can actually find hints in the HTML that tells you whether or not the convention they use is relevant or not. Remember we talked about Zapp search features? I would search. Maybe they have it in their HTML comments. 192.168, maybe one of the developers put an IP address in a comment. You'll be able to see it and then figure out the convention that they use. So you don't have to guess that much. Just have to use the proper tools and be or thought about it. Questions so far? You guys seem so poor at this hour. Five. We typically use the courses before and after we do it in 5.30, don't worry, people will survive, yes. Well, you're surviving, that's okay, but I still want to give you a really short break because I want to talk about secure development and maybe, maybe, maybe cover just one more aspect in hacking and I need you to listen to me. And right now, you guys are near golf, seriously. So I really saw that amazing red bull machine outside. I'm not sure it's free, but it has fantastic juice that is not healthy for you but keeps you awake. Go get one. 10 minutes, guys. Just 10 minutes, you want to go home, okay? Fresh it up and get back to class.