In this post, we will start our attack on the ResourceSpace Digital Asset Manager. First, we need to configure the attack environment we want to use for this engagement.
⭢ BurpSuite Setup
Continuing from Part 2, we have completed the set up of our test environment and created a normal user to log into the web application.
Now that ResourceSpace is up and running, we can start our attack on the web application. Let’s take a look at setting up the attack proxy we discussed in Part 1.
After opening BurpSuite, the first thing we need to do is start a new project, and select a directory and file location to save our data. BurpSuite will auto-update our data as we go, so starting a new project is a good idea to avoid losing data on a power outage or something similar. After clicking next, you are asked about the type of configuration you want to use with this project. Here, we will select the Burp default option as seen in the image below.
In the next few steps, we need to set the Target and the Scope of our attack, along with configuration settings for the Live Scanning tool. An easy way to get the target is to copy and paste the URL from the browser directly into the Target -> Scope tab as seen below.
The next step would be to click on the Scanner -> Live Scanning tab and set Live Active Scanning to use the default suite scope which we defined in the last step. This way, as I browse the resourcespace.local site through the proxy, BurpSuite will start to actively scan and fuzz all of the insertion points it can detect while I browse. We will also be disabling a few scan options since we know that we are using MySQL as a database, we can disable checks for Oracle and MSSQL. We are also going to ignore XSS and DOM Reflected scans since this is outside the scope of this engagement.
Depending on the engagement, you would usually take advantage of the Burp Extender and the various BApps to assist in your work. For this specific task, I am going to enable the CO2 module which will add some functionality to BurpSuite. To enable the module, go under the Extender -> BApp Store tab and make sure it is enabled.
Now that we have BurpSuite setup for a basic vulnerability scan, we need to setup a web proxy in our browser of choice to ensure we are accessing the resourcespace.local domain through the proxy instead of connecting directly. Since I will be using Chrome as my browser for this engagement, I will be using the FoxyProxy plugin to add the BurpSuite proxy settings as shown below.
Now that we have our attack proxy setup, along with our Chrome extension to use the attack proxy instead of connecting directly, we can start attacking the web application.
The Attack Process
To start both the passive and active scanning process, we are going to pull up the ResourceSpace URL within our Chrome browser on the Arch Linux host machine. First, make sure the FoxyProxy is set up to use the BurpSuite proxy instead of directly connecting to the target, then open up the resourcespace.local URL to login as the General User we just created. Now the way I have BurpSuite setup, we will want to manually browse the site so that Burp proxy can run some active scanning techniques on the pages we are viewing. This is a good tactic to use, as manually you can identify those pages that have a lot of user input, or multiple parameters that may be interacting with a database, or some other kind of service on the back-end.
After narrowing down my possible targets, I was able to identify a page with multiple input forms and multiple options for the user. The page/script in question was called collection_edit.php and was used to manage your assets collections within ResourceSpace.
After fuzzing all the parameters on the page, BurpSuite was reporting on some Interesting Input Handling within the keywords parameter when using specific characters in the POST query. Now, this issue does not necessarily indicate a vulnerability; it is merely highlighting behaviour worthy of manual investigation, so let’s take a closer look at this behaviour.
It seems the keywords parameter is treating the character combinations of \\ and \\\ differently during the POST request. This usually means the developers have misconfigured the user input sanitation process somehow, but still does not mean its vulnerable to attack, so we need to look a bit more. In order to check this issue further, we are going to move this same request over to BurpSuite’s Intruder by right-clicking on to the request itself and choosing the option Send to Intruder.
Ahh! As you can see in the image above, we have triggered a MySQL error in some of the Intruder payloads we used, so let’s take a closer look at the error itself.
(database) line N/A: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘\\\”)’ at line 1
insert into collection_log(date,user,collection,type,resource, notes) values (now(),’2′,’1561′,’e’,null, ‘keywords = \\’\\\”)
Now that we know we have a MySQL error that is being triggered by a \\\’ character combination, so let’s send this request to SQL Mapper to generate all the cookie and session data we need to use SQLmap to fuzz the keywords param. Once we generate the SQLmap command data, we will run it in a terminal with some verbosity so we can see the requests being sent.
Bingo! SQLmap hit on three different injection types using the keywords parameter, so we know we can compromise the database at this point.
However, we need to test the other parameters on the page to see if they show the same behavior that the keywords parameter did. So it seems this parameter is either bypassing the checks, or the checks designed for this keywords parameter were flawed. We need to take a closer look at the code responsible for parsing the parameters within the collection_edit.php file.