Original text by Nikos Danopoulos
Ghost Labs performs hundreds of success tests for its customers ranging from global enterprises to SMEs. Our team consists of highly skilled ethical hackers, covering a wide range of advanced testing services to help companies keep up with evolving threats and new technologies.
Last year, on May, I was assigned a Web Application test of a regular customer. As the test was blackbox one of the few entry points — if not the only — was a login page. The tight scoping range and the staticity of the Application did not provide many options.
After spending some time on the enumeration phase by trying to find hidden files/directories, leaked credentials online, common credentials, looking for vulnerable application components and more I was driven to a dead end.
No useful information were received, the enumeration phase had finished and no process had been made. Moreover, every fuzzing attempt on the login parameters didn’t not trigger any interesting responses.
Identifying the entry point
A very useful Burp Suite Extension is Bypass WAF. To find out how this extension works, have a quick look here. Briefly, this extension is used to bypass a Web Application firewall by inserting specific headers on our HTTP Requests. X-Forwarded-For is one of the them. What this header is also known for though is for the frequent use by the developers to store the IP Data of the client.
The following backend SQL statement is a vulnerable example of this:
|mysql_query(«SELECT username, password FROM users-data WHEREusername='».sanitize($_POST[‘username’]).»‘ ANDpassword='».md5($_POST[‘password’]).»‘ AND ip_adr='».ipadr().»‘»);|
More info here: SQL Injection through HTTP Headers
Where ipadr() is a function that reads the $_SERVER[‘HTTP_X_FORWARDED_FOR’] value (X-Forwarded-For header) and by applying some regular expression decides whether to store the value or not.
For the web application I was testing, it turned out to have a similar vulnerability. The provided X-Forwarded-For header was not properly validated, it was parsed as a SQL statement and there was the entry point.
Moreover, it was not mandatory to send a POST request to the login page and inject the payload through the header. The header was read and evaluated on the index page, by just requesting the “/” directory.
Due to the application’s structure, I was not able to trigger any visible responses from the payloads. That made the Injection a Blind, Time Based one. Out of several and more complex payloads — mainly for debugging purposes — the final, initial, payload was:
And it was triggered by a similar request:
|GET / HTTP/1.1|
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.21 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.21
The response was delayed, the sleep value was incremented to validate the finding and indeed, the injection point was ready.
As sqlmap couldn’t properly insert the injection point inside the XOR payload, an initial manual enumeration was done. The next information extracted was the Database Length. That would allow me to later identify the Database Name too. Here is the payload used:
Of course, Burp Intruder was used to gradually increment the database length value. It turned out that the Database Length is 30. To find the Database Name Burp Intruder was used again with the following payload:
To automate this in an attack the following payload was used:
During the attack I noticed that the first 3 characters are the same with the first character of the domain name I am testing. The domain were 20 character long. I paused the intruder attack, went back to repeater and verified like this:
Indeed, the server delayed to respond indicating that the 15 first characters of the Database Name are the same as the domain name. The database name was 30 characters long. I had to continue the attack but this time with a different payload, starting the attack from character 21, in order to find the full database name. After a few minutes, the full database name was extracted. Format: “<domain-name>_<subdomain-name>_493 ” With the database name I then attempted to enumerate table names.
Similarly, a char-by-char bruteforce attacks is required to find the valid names.
To do this I loaded the information_schema.tables table that provides information about all the databases’ tables. I filtered only the current’s database related tables by using the WHERE clause:
|«XOR(if(Ascii(substring(( Select table_name frominformation_schema.tables where table_schema=database() limit 0,1),1,1))=’100’, sleep(5),0))OR»*/|
As the previous payload was the initial one, I simplified it to this:
|«XOR(if((substring(( Select table_name from information_schema.tables|
where table_schema=database() limit 0,1),1,1))=’a’, sleep(3),0)) OR «*/
Again, the payload was parsed to Burp Intruder to automate the process. After a few minutes the first tables were discovered:
After enumerating about 20 Tables Names I decided to try again my luck with SQLmap. As several tables where discovered, one of them was used to help sqlmap understand the injection point and continue the attack. Payload used in sqlmap:
|XOR(select 1 from cache where 1=1 and 1=1*)OR|
By that time I managed to properly set the injection point and I forced sqlmap to just extract the column names and data from the interesting tables.
Notes and Conclusion
At the end of the injection the whole database along with the valuable column information was received. The customer was notified immediately and the attack was reproduced as a proof of concept.
Sometimes manual exploitation — especially blind, time based attacks — may seem tedious. As shown, it is also sometimes difficult to automate a detected injection attack. The best thing that can be done on such cases is to manually attack until all the missing information for the automation of the attack are collected.