Google dorking to SQL injection

Greetings Hackers, In this write-up I'll declare how I found boolean based SQL injection on a Microsoft Server web app from google dorking, So let's start.

The program I'm talking about is a private program so I will refer to it as vuln.com .

Getting The Sub-domain

After using tools like amass and subfinder I got some decent results, however I wanted to use google dorking, more specific Bing Dorking. I used the following dork: domainName+inurl:admin in my case: vuln+inurl:admin notice that I didn't use the tld to get more and non exclusive results. The purpose of this dork is to search for admin keyword in any URL related to the domain so I could get any exposed admin panel.

In the first page I found the following:

I've found this subdomain before by using the tools I mentioned, but I didn't get anything except the main page, even after performing directory search I didn't reach this path. And here lies the power of dorking.

Mapping The Site

When I entered the page it was a normal HTML page with no functionalities. Before trying anything I thought of accessing the parent directory which is /arcgis and I got redirected to the following page :

Directory indexing that reveals most of the services + the current version of ArcGIS REST , Nothing sensitive here so I decided to search with the current version for any CVEs and I found that It's actually vulnerable to CVE 2012-4949 that says that this version is vulnerable to SQLi in the where parameter in the following URL:

/arcgis/rest/services/{Service-Name}/query?f=json&where=featured=true&returnGeometry=true&spatialRel=esriSpatialRelIntersects

The main problem here is that there were a lot of services and each one has other branching links and it was frustrating to search in every section. So I used hakrawler which is a web crawler to get me most of the links hoping to find any service that makes use of the query endpoint

echo "http://sub.vuln.com/arcgis/rest/" | hakrawler -d 4 -subs -u and it got me this

Bingo

Analysing The Parameter

When I went to the URL I found this page :

I can see input field for the vulnerable parameter which is a good sign, The CVE didn't contain any info nor exploits, It only said the the parameter was vulnerable.

So I tried the very basic payload to analyse It's behavior .... a single quote '

Seems a promising result, Now let's try to cope with the query logic. We all know that where statement usually deals with boolean values , for example where user='admin' right ? what if we add this to our query

From this detailed error we can notice that we are dealing with SQL Server and also no column called user. There was a parameter called f which specifies the format of the response , so let's set it to json and use burp for the ease of illustrating and exploiting

Here we go ...

Now .... since we don't know any column name, what about entering a true value like 1=1 so the whole query is translated to where 1=1 :

Response of 1=1

Let's change the condition to a false one like 1=2 :

Response of 1=2

This is confirmation of Boolean based SQLi as the response changes with changing the condition.

I didn't want to report it this way as I wanted to extract actual data.

Exploiting The Parameter

Now we know that we are dealing with MSSQL and I'm not really good with it so I used PayloadsAllTheThings and Portswigger CheatSheat to conduct my payload.

I found that user_name() is quite good enough to be a POC , the main syntax is as follow:

SELECT user_name()

First I need to determine it's length, since we are dealing with boolean based we will depend on the response to know the length

Request

Response

After not so long tries I found that the length is 8.

Now to get the actual value of it, I used SUBSTRING() function as follow:

query?where=SUBSTRING((select+user_name()),1,1)='CHAR'

This will select the user_name() and then gets the first character of it and compares it with the provided character. To get the values I would send the request to the intruder and brute-force it 8 times BUT I'm kind of person that always wants to mess with things and break them down, so I thought of providing a digit instead of character to see what happens:

Response

Request

This was really surprising for me, The DBMS actually responded with the character value due to conversion error, so instead of brute-forcing the rest of the characters I changed the payload to be :

query?where=SUBSTRING((select+user_name()),1,8)=0

This will get the first 8 characters because it's the length of the username and the result was:

Got the username of the database, other things could be extracted like version , tables names , etc ... but I stopped here, I reported it as high severity but the triage team changed it to critical.

Final

shout out to @GodfatherOrwa for his tip about using bing dorking.

As a final tip from me, Don't always rely on tools. I've passed the request the first time to SQLMap and it said that the parameter wasn't exploitable.