# 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

### 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

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` :

Let's change the condition to a false one like `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](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/SQL%20Injection/MSSQL%20Injection.md) and [Portswigger CheatSheat](https://portswigger.net/web-security/sql-injection/cheat-sheet) 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

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:

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](https://twitter.com/GodfatherOrwa?t=Vv7isnHeC7jJ4ZFmi1OAug\&s=09) 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. ###