OWASP's Most Wanted

So you ask who is this OWASP and why do I care?

Well, let’s hear it directly from them:  “Open Web Application Security Project (OWASP) is a 501(c)(3) worldwide not-for-profit charitable organization focused on improving the security of software.  Our mission is to make software security visible, so that individuals and organizations are able to make informed decisions. OWASP is in a unique position to provide impartial, practical information about AppSec to individuals, corporations, universities, government agencies, and other organizations worldwide.  Operating as a community of like-minded professionals, OWASP issues software tools and knowledge-based documentation on application security.” (https://OWASP.org)

Whether you’re a pentester or a developer, you should be well versed in OWASP and the information they provide.  One of their most well-known offerings is their Top 10 Application Security Risks.  OWASP lists Injection as the top #1 vulnerability in their Top 10 list of application vulnerabilities.   

So, what is Injection?  According to OWASP, Injection can result in data loss or corruption, a lack of accountability or a denial of access.  This is done by breaking out of a fixed context within the page. For example, if the page expects user input to only be used in a non-executable context, but an attacker can escape that context, then the input might be executable. Things like SQL injection (SQLi) and Cross-site Scripting (XSS) are common examples of injection. In XSS, an unhandled quote character might break out of the HTML attribute and allow malicious JavaScript to execute in the browser. With SQLi, an unhandled SQL control character may allow a malicious SQL statement to execute against the database. A quick list of different attacks are found on OWASP’s Attack Category page, https://www.owasp.org/index.php/Category:Injection.

Today, let’s look at Command Injection together.  This occurs when the data added to the input contains code the attacker wants to be run by the operating system of the system hosting the vulnerable web page or application.

So, let’s see how this is attack works in an application and how we can exploit it.  I will be using SamuraiWTF in this demonstration. You can download the current release of Samurai from GitHub

Once I have Samurai loaded up I am going to launch Burp.  As shown below, Burp can be found by right clicking on screen in the VM.

As an aside, if you have never used Burp before I recommend taking a look at another one of our posts found at the following link /2018/03/burp-suite-continuing-the-saga.

Once I have Burp running, I want to set up my Firefox browser to use Burp. Make sure you change your proxy configuration, as shown below, so all traffic will be routed through Burp.

Also I need to make sure Intercept is turned off in Burp. Otherwise, Burp will hold all web requests and wait for you to manually forward them to the server.

Next I open up the DVWA application by typing http://dvwa.wtf in my Firefox browser.  Now I need to go through and map out the application by clicking on every function in the application. Additionally for this example to work, I need to change the security level to Low.

Once I have mapped out each function I can go back to Burp and look at the Site map tab under the Target tab and find the Post request from http://dvwa.wtf/vulnerabilities/exec/.

Now I am going to send that action to Repeater to manipulate the request. My goal is to break out of the context the application is executing. (Note the Content Length of the request to compare it later.)

As a quick tip, when using Repeater you always want to press the Go button prior to manipulating the request. This will allows us to verify that the session is still good and there is no anti-replay protections.

Now we are going to input a payload into the request to see what happens. I am going to replace ip=localhost&Submit=Submit with ip=localhost;ls -l / ; whoami;uname-a&Submit=Submit. Notice that I am adding commands and a ; (semi-colon) to attempt to break the context the application is running the payload within. You can use any system commands but using something like these that return output and aren’t interactive are often best.

I then press the Go button to have Burp Suite send the request to the application. If I look at the response, we can see the payload appears to have executed. We see this because the response contains the output from the commands I injected. In the screenshot below, we see the directory listing and the username the application is running as root.

So that shows an example of how Command Injection can be found and exploited.  Stay tuned to for more great articles and tutorials similar to this one.  You can also join our Slack channel at www.professionallyevil.com where you can chat with fellow security professionals.