Welcome back, my aspiring web app hackers!
In this series on Web App Hacking, we are exploring the multitude of ways of hacking web applications. Here, we are delving into the most widely used Web App Hacking tools, BurpSuite (BurpSuite is on my essential hacking tools list here).
In an earlier post here at Hackers-Arise, I demonstrated how to hack web app using LFI or local file inclusion. In this tutorial, I will show you how to use BurpSuite to include remote files OR RFI.
What is RFI
Remote File Inclusion (RFI) is an attack on a web application that targets vulnerabilities when the web application references an external resource or script. The web application is designed to be able to call external scripts and resources that enhance that usability and aesthetics of the application. When they do so, they can be vulnerable to calling resources from outside, providing the hacker the opportunity to include shellcode to control application or resources to deface or otherwise modify the site.
Remote File Inclusion, like so many web application attacks, occurs due to improper validation of inputs. If the web application sanitizes the inputs or otherwise restricts inputs, RFI become impossible or more difficult.
In this tutorial, we will use BurpSuite against the vulnerable Mutillidae II web application to deface the web site.
Step #1: Start Mutillidae II
Open the Mutillidae II application in OWASP BWA with your browser in Kali Linux like below.
Step #2: Start Burp Suite
Next, start BurpSuite and enable the Intercept in the proxy. For more information on using BurpSuite and the proxy, refer to the initial BurpSuite tutorial here.
Set your browser to proxy your web traffic.
Now, login into the Mutillidae II application with the Intercept on in BurpSuite.
Step #3: View the Login Page in the HTTP History and Intercept
Now, we should be able to view the login page from both the proxy and the HTTP history tab.
First, go the HTTP history tab. You can see the login page below.
From the Intercept tab in the proxy, can you also see the page below.
Note that the GET requests page=login.php. We can manipulate that request to upload either shellcode to control the site or other resources to manipulate the web site.
Now, when we forward the GET, we see that the browser displays the login page.
What if we manipulated that request to include another resource such as an outside URL? Let's try.
Step #4: Manipulate the page request for login and provide instead a URL
With the Intercept On in the BurpSuite, let's try logging in again.
Now, with the GET request in our proxy, let's replace the login.php with the URL of our favorite cybersecurity training site, www.hackers-arise.com.
When we forward the request, the Mutillidae II web site now displays the www.hackers-arise.com website and NOT the login.php screen! We have successfully hacked the website with RFI!
Summary
The page parameter of Mutillidae II does not include proper data validation that would only allow legitimate resources to be included. As a result, we were able to provide parameters or resources that enabled us to display contents that should not be allowed. If that web application included whitelists of allowed resources or data validation, this type of web attack would be stymied.