I'm back with another blog post discussing an SQL injection vulnerability that I found during one of my engagements. While SQL injection vulnerabilities have become somewhat rare nowadays, the one I'm about to discuss in this post is quite unique due to its rarity. Despite their reduced occurrence, these vulnerabilities still emerge, and their potential outcomes can be extremely destructive. One of the most recent instances of an SQL injection vulnerability was discovered within the MOVEit file transfer software. This vulnerability affected thousands of companies and government agencies and had serious consequences.

Identifying the vulnerability

I was conducting a Black Box Penetration Test on a Web Application. Since I didn't have access to the application to test all the functionalities I was limited in what I could test for therefore I wasn't expecting to find a lot of vulnerabilities other than the usual misconfigurations we all report on as security best practice.

Accessing the application I was presented with a login page. Initially, I was testing for authentication vulnerabilities like user enumeration and brute-force protection. When user enumeration combined with the absence of brute-force protection, coupled with weak passwords and the lack of 2FA (2 Factor Authentication), it creates a direct path towards a potential disaster. I frequently see these issues in my penetration tests and happened several times when I gained access to the application because of the lack of these security measures.

After addressing the straightforward aspects of the testing, I proceeded to test other vulnerabilities such as XSS and SQLi. I started testing for XSS and quickly discovered that it was vulnerable. Interestingly a basic script tag was executed successfully. The execution of a basic script tag reveals significant insights into the application's security posture and when that happens I am expecting to find more severe vulnerabilities.

The next step was to test for SQL injection and tried the basic authentication bypass and characters that would break the SQL query in the hope of a useful error message coming back but this was not the case.

Moving forward I used this cheat sheet from Portswigger to try SQL time delay payloads and to my surprise, it was working. Initially, I was sceptical, thinking that the response delay was just the server's delayed response but after a few more attempts I was convinced that the login page had a time-based SQL injection vulnerability as the delay from the server matched the delay specified in the query.

SQL query: WAITFOR DELAY '0:0:10'

Burp request showcasing the injection point the payload and the time delay:

Exploiting the vulnerability

The next logical step was to use SQLMap to exploit this further so that's what I did. Running the tool quickly revealed the issue I already knew existed and used the tool to further exploit and demonstrate the impact of the vulnerability. While running SQLMap I proxied the traffic through Burp to see what SQL queries SQLMap is sending so I can understand better what the tool does and what the queries are rather than just firing up the tool and waiting for something to happen.

I tried to dump the database tables and I did get back a couple of table names but I decided to stop here take a screenshot so I can show it to the customer and move forward to see what else I can do as I didn't want to dump any sensitive information.

SQLMap has a really useful feature where an OS shell can be opened gaining further access to the server. Using this I was able to exploit the injection further and was able to run OS commands making use of the xp_cmdshell which if enabled is a very powerful functionality that allows to run OS commands. This however proved to be a slow process due to the nature of the injection type but once I was able to run commands on the host I could have used this to improve on it prompting an interactive reverse shell.

SQLMap Command:

sqlmap -u "https://example.com/" --data "txtUserID=*" --dbms "database type" --os-shell

Demonstrating the ability to run OS commands using SQLMap:

I decided to stop here as I had enough evidence and impact to show to the customer and reached out the them to let them know what was found. While there are a variety of ways to improve on this shell, I found that the easiest method would have been to use Hoaxshell, a Windows reverse shell payload generator that generates a Base64 encoded payload that can then be copied into the existing shell, prompting a fully functional reverse shell.

Closing thoughts

As shown in this example, a SQL injection vulnerability can be extremely dangerous, and if discovered by a cybercriminal could have devastating consequences for a business.

Hope you enjoyed this blog post and learned something new from it. Thanks for reading, stay curious and see you next time.