Stacked based MSSQL blind injection bypass methodology

If you have a blind SQL injection you are already in a good position. Exploitation however, depending on the type of the blind SQL injection, can take time.

This post is part of a methodology used for obtaining output from a stacked based blind SQL injection.

Requirements:

  1. Stacked based Blind SQL injection
  2. Local MSSQL database server (MSSQL server express was used in this example)
  3. Improper remote firewall configuration (allows outbound connections)
  4. #include < brain.h >

If all of the requirements above are met then the following technique can be used:

This instructs the remote database server to connect to the local database and write the result of SELECT @@version command. If SELECT * from output_db..output returns any results then you are in luck otherwise continue using sqlmap

Now we can change the “SELECT @@version” part to run any command we want and the results are going to get saved our database.

NOTE: OPENROWSET needs the destination table to have the same columns as the ones returned by the remote command and *similar* types to avoid any errors

Copying Databases:

Advancing:

Advancing more:

NOTE: because of the fmtonly off instruction the issued command is going to be run twice. This makes echo-ing to script files a bit harder.

$ chmod -x attack //Protecting the web server (for the non pen-testers)

What went wrong – Recommendations:

First off all, the SQL injection, (*obviously*) sanitizing the input would be the first step. However this is only part of the problem, other factors contributed into making this attack vector possible. At least this would not lead to complete compromise of the server if a layered approach was taken and the perimeter was adequately protected.

For example if the outbound connections were firewalled (eg. deny all outbound and only allow incoming connections to the webserver), it would not be possible to make a remote connection to our own server in order to get the SQL results.

Secondly, hash AND SALT all database passwords. Many reasons for that just accept the fact that this is how it must/should be done.

Lastly, make the sa password hard to guess and do not reuse passwords, specifically administrative passwords.

If all of the above were implemented, then the attack would take significantly more time and the attacker would get at most an administrative password (for the web application) which hopefully would take years to crack. Instead of the attack taking a couple of hours and leading to complete compromisation of the host.

Last note: all of the above scenarios are based on vague assumptions about the configuration or typical configurations.