On May 3rd the ImageMagick security team posted on their blog a possible remote code execution vulnerability involving specially crafted images. For those that haven’t seen the news yet, ImageMagick is a widely used open source program for converting and managing images. You might use it, for example, if you were a website that lets users upload their own profile picture. Those users could upload a specially crafted image that would be executed by the ImageMagick application and potentially cause a remote code execution on the host.
Shortly after ImageMagick posted on their blog, the vulnerability was discussed in various online mailing lists and forums.
From the oss-security mailing list:
ImageMagick allows to process files with external libraries. This
feature is called ‘delegate’. It is implemented as a system() with
command string (‘command’) from the config file delegates.xml with
actual value for different params (input/output filenames etc). Due to
insufficient %M param filtering it is possible to conduct shell command
injection. One of the default delegate’s command is used to handle https
“wget” -q -O “%o” “https:%M”
where %M is the actual link from the input. It is possible to pass the
value like `https://example.com”|ls “-la` and execute unexpected ‘ls
-la’. (wget or curl should be installed)
$ convert 'https://example.com"|ls "-la' out.png
drwxr-xr-x 6 user group 204 Apr 29 23:08 .
drwxr-xr-x+ 232 user group 7888 Apr 30 10:37 ..
What this means is that you could potentially upload a malicious file to a website that, when ImageMagick processes that file, would execute the malicious code within. The example above shows how the process of converting a file would execute an unexpected
A CVE was issued to track this vulnerability (CVE-2016–3714), and even a branded website with a catchy title has popped up to raise awareness of this very critical vulnerability.
Having been in the Technical Operations world for over 15 years, I’ve seen this story played out countless times. This underscores yet again that prevention is a myth, and that given the modern day dependence on countless open source libraries, massive vulnerabilities can be lurking in all kinds of software we depend on.
One of the reasons I was most excited to join Threat Stack nearly two years ago was because I knew that it is impossible to prevent attacks on your systems with 100% certainty, and the best way to protect yourself is by continuous monitoring for system anomalies. At Threat Stack, whenever PoCs for vulnerable software are released into the wild, we like to exploit them on systems running our agent in order to see a full scope of a simulated attack. Most importantly, because we are able to capture system events from the kernel directly, we can see every process, and every network connection as the result from this simulated attack.
So, to see what actually happened when this vulnerability was exploited, I spun up an instance, installed the Threat Stack agent, and created an
.mvg file with the following payload:
viewbox 0 0 1 1 image over 0,0 0,0 'https://google.com" && cat /etc/passwd && echo "1'
You can find the additional examples of PoCs at the ImageTragick GIthub.
As we learned in the oss-security mailing list, due to the insufficient parameter filtering, everything after the URL is going to get executed on the host. Converting this file with a
convert <file>.mvg output.png will cause the
/etc/passwd file to get displayed to the terminal. It shouldn’t take long for you to see how easily it would be for an attacker to download malware payloads, execute a rootkit on your host, and take over your system.
Of course, when we ran an image conversion on a host with the Threat Stack agent, we saw alerts already begin to fire.
Right away we were seeing file transfer activity alerts for the user process that converted the file. This should raise a red flag because there is probably no legitimate reason why converting an image would require your application to execute the curl(1) command.
Let’s dive into this process and see if we can learn more about the context of the alert. In the event detail page, I can see the process tree for this process that fired. You can see how the ImageMagick convert command executed 2 child processes: one is the connection to google.com and the other where we access
Further diving into the event detail, I’m able to see the full TTY timeline for this process (as this test was executed inside an interactive session on a host).
Finally, diving into the file transfer that occured from the original file conversion, I can see a list of IP addresses that this host connected to. If this system connects to a known bad IP address, the Threat Stack Threat Intelligence feature will issue an additional alert on top of the previous alerts to let you know that something is amiss.
As an operations engineer, I no longer lose sleep at night over the unknown unknowns of potentially vulnerable software that is running on my stack. I know that with Threat Stack, I can easily see anomalies in my stack and use my tools (Slack, PagerDuty, etc.) to let me and my team know about it the minute it happens. The visibility that our agent provides in this example is yet another reason that I love running Threat Stack to protect the Threat Stack Platform.