At PortSwigger, we regularly run pre-release builds of Burp Suite against an internal test-bed of popular web applications to ensure it remains extremely effective against real-world websites. Most recently we have been testing Burp Suite on Magento, a popular open source eCommerce solution. Using purely automated functionality, we quickly found a number of SQL injection vulnerabilities in the Magento sample site, ‘LUMA’. This post will provide a step by step walk-through showing how we found the vulnerabilities using Burp's automated crawl and scan, verified it using the Repeater, and finally exploited it by using the Intruder to launch a boolean based blind injection attack to dump out the contents of the backend database.
As part of testing Burp’s functionality, we first map out the application. In this test we used Burp Spider in conjunction with Burp’s session handling rules to spider “LUMA”.
Having spidered the application we were able to move to the testing phase. We actively scanned the whole application from the Target “Site map” tab.
Burp Scanner produced a number of issues, most notably a number of SQLi issues. After examining the Issue “Advisory” and “Request” and “Response” tabs, the next step was to manually verify the issues to ensure that the Scanner is correctly reporting vulnerabilities.
We used Burp Repeater to verify the SQL injection issues. The Repeater tool allows you to repeatedly change and resubmit the same request, and review the response. We used a similar methodology to one used in our tutorial page “Using Burp to Detect SQL Injection Via SQL-Specific Parameter Manipulation” to validate the Scanner’s findings. We used a calculation containing an ASCII command to show that the application is evaluating input as an SQL query.
climate=251-ASCII(1)
We were able to dump the database using boolean based blind injection. For example, the following payload will tell you whether the username starts with 'm':
climate=202 and (SELECT user() LIKE 'm%')
It is possible to automate this process using Burp Intruder. The following screenshots show how this payload has been used to enumerate the username for the database.
In the Intruder "Positions" tab we added two insertion points in to the payload. We also set the attack type to "Cluster bomb". This attack type uses multiple payload sets, iterating through each payload set in turn, so that all permutations of payload combinations are tested.
We configured the first payload to use the underscore character from 0-20 in length. This allowed us to test each character in the second payload in intervals of one bit. For example:
climate=202 and (SELECT user() LIKE '____n%')
In the second payload we used characters that one might expect to find in a typical username.
We sorted the results by length and by grep matching a word found only in positive responses from the application. The results table shows a username we were able to extract from the database and how the underscores allowed us to alter the position of the second payload set;
climate=202 and (SELECT user() LIKE 'm%')
climate=202 and (SELECT user() LIKE '_a%')
climate=202 and (SELECT user() LIKE '__g%')
climate=202 and (SELECT user() LIKE '___e%')
climate=202 and (SELECT user() LIKE '____n%')
climate=202 and (SELECT user() LIKE '_____t%')
climate=202 and (SELECT user() LIKE '______o%')
Vulnerabilities in sample sites pose two key threats - developers may fail to fully remove the sample content, or even worse they may mimic its insecure coding practices and create highly exploitable stores.
We reported this vulnerability to the Magento Security Team on 15th December 2015, providing the ASCII payload and the database dump as proof-of-concept. The Magento Security Team responded quickly to our report, patched the vulnerability on January 20th 2016 and offered a generous bug bounty.
This once again shows that with a series of simple steps, Burp's scanner to be used to unearth vulnerabilities in even extremely popular web applications.