Code dive Samples of booby-trapped image files that exploit ImageMagick to compromise servers and other computers are well and truly out in the open now.
On Tuesday, it emerged that ImageMagick – a popular software tool used by countless websites to process selfies and other submitted photos – has a bunch of critical security bugs. These programming blunders can be exploited to execute commands on vulnerable systems by uploading maliciously crafted images.
If you're using ImageMagick on your website to identify, crop, resize or tweak pictures provided by your users, you must make sure you've applied these mitigations, and tweaked your code to only accept valid image files. Sandboxing ImageMagick is also a good idea.
Patches that completely address the flaws are not yet available. New versions of ImageMagick with the bugs fixed are due to arrive before the end of the week.
After word spread of the security holes, it wasn't long before infosec bods worked out exactly where the weaknesses lay in ImageMagick's open-source code, and how to exploit them. Now that information is spreading through mailing lists and forums, so be warned if you're using ImageMagick to process user input.
To give you a taste of the software holes you're up against, here's an example file that will outfox ImageMagick:
push graphic-context viewbox 0 0 640 480 fill 'url(https://example.com/image.jpg"|ls "-la)' pop graphic-context
Save that .mvg file with any extension you want, such as exploit.jpg. Then run it through ImageMagick:
convert exploit.jpg out.png
And yes, ImageMagick will execute the ls -l command embedded in the file. Replace that command with something more malicious, throw it at a vulnerable web app, and, well, you've probably broken a few laws.
Here's another example. If you can figure out how a website's server-side code works, and where it stores uploaded files, you can move files from that upload folder to anywhere on the server's file system. So, upload a web shell, knowing it'll be saved in, say, /tmp/image.gif, then upload this file, knowing it'll be saved in /tmp/msl.txt:
<?xml version="1.0" encoding="UTF-8"?> <image> <read filename="/tmp/image.gif" /> <write filename="/var/www/shell.php" /> </image>
Then upload an image containing:
push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'msl:/tmp/msl.txt' popgraphic-context
This will move /tmp/image.gif to /var/www/shell.php, so visiting victimwebsite.com/shell.php will open the web shell, granting access to a control panel to the web server. It didn't take long for people to demonstrate this technique:
so um.— Dan Tentler (@Viss) May 3, 2016
I just did my first exploit PoC.
I have a working PoC for the imagemagic bug. pic.twitter.com/hyNgtZpsSL
Im getting SUPER SUPER CLOSE.— Dan Tentler (@Viss) May 3, 2016
I just need to find the right reverse shell pic.twitter.com/Sj8TyU3Lp5
Done.— Dan Tentler (@Viss) May 3, 2016
Weaponized exploit. pic.twitter.com/PtrY6wf7DT
All this is possible because ImageMagick passes images to backend tools via shell commands, and does not fully sanitize filenames and paths, thus allowing pictures to reach into the file system and ruin someone's day. Top tip: don't screw up code that parses filenames and paths – there's more developer-level discussion on the topic over here. ®