While doing a Web Application Penetration Testing exercise, we may find an SQL injection vulnerability which generally poses a high risk to the application. Exploiting an SQL injection vulnerability can sometimes be a little challenging as the organization might have implemented other mitigation measures. The blog post below explores one such situation and how another vulnerability was used to bypass the mitigation and then exploit SQL injection completely.
- Web Server: IIS 8.5
- Web Framework: Asp.net 4.0.30319
- SQL Server: Microsoft SQL Server
While doing the WAPT, I found error-based blind SQL injection vulnerability. By exploiting it I was able to enumerate users. The SQL Server administrator account ‘sa’ was also in the list.
I was also testing for LFI on the same application and to do so, I made a list and used brute force to access local files on the server. However, I concluded that it was not vulnerable to LFI, but I did note that for different file requests the application responded differently. I analyzed the errors and realized that it is searching for the name in the database tables and requires a ‘/’ before every keyword. I guessed that it might be trying to render the values that I am passing through the vulnerable URL.
As the backend database was clearly a Microsoft SQL server, it might be having XP_CMDSHELL package in it, if it’s not disabled. So, the first step was to try and enable it as its disabled by default on Microsoft SQL servers these days.
So, I typed in the following command through the other URL that took a filename:
parameter = EXEC sp_configure ‘xp_cmdshell’, 1 –+
parameter = RECONFIGURE –+
These inputs got executed without any errors.
Getting admin access
In order to further exploit it I required System Admin username and password. As I already enumerated the users, and user ‘sa’ was in the list. So now the task was to enumerate the passwords or at least their hashes. I used –os-shell option of sqlmap. SQLmap gave me xp_cmdshell access. I ran the whoami and dir commands in order to confirm that it was properly working.
This is how I was able to do remote code execution by combining SQL injection to another level. The mitigation measures for this are that the user input should be properly sanitized. Parameterised queries should be used to avoid command execution. If XP_CMDSHELL is not required, then the package should be deleted.
Latest posts by Jayant Sharma (see all)
- Advanced Exploitation of SQL Injection to get Remote Code Execution - February 26, 2018