The Strange Tale of the Frog Images

If you have been maintaining a Magento 1.X store for the last year or so you may well recognise this image.


If you do a reverse image search and include the path to Magento’s media folder you get some interesting results.

Screen Shot 2017-06-12 at 12.50.29
A google image search for the pepe the frog image with the string “Index of /media/catalog/category”

You can see this image appearing under different names in the /media/catalog/category folder of dozens of Magento 1.X sites. What is more it has been uploaded without the knowledge of the site owners. But why is it a case of simple vandalism?

If take a closer look at the image on one of these sites you can see PHP code appended to the binary image data.

Screen Shot 2017-06-12 at 12.55.42

The file is an attempt to execute malicious code on the web server hosting the sites. In this case it seems to be trying to write a backdoor PHP script to a file located at /skin/skins.php and another to skin/test1.php but the images contain a variety of payloads.

Loading the image for display as we just did will not execute the PHP code. Instead it outputs the uninterpreted code which is how we were able to see it.

How are such files executed by the attacker?

There is a clue in the code in the image. It searches for index.php in the SCRIPT_FILENAME global variable to find the scripts path. It therefore looks like the script is being executed via a request to the frontend or admin side of the store and not through any other path. It is almost as if the image is being included as a PHP source file.

I have found one method that is a likely one used to execute the code through the admin site. This means an attacker must already have a valid login for your admin site. If you are wondering how this could happen See this earlier post. Using an admin user the attacker is first able to save the image as the header image to one the existing categories. This will transfer the file to the location media/catalog/category on the target server.

The method will no longer work on up to date Magento installs since it makes use of vulnerabilities fixed by the latest security patch for Magento SUPEE-9767.

I believe that the image is being included by the attacker as part of a newsletter template. In an un-patched version of Magento you can indeed achieve execution of PHP code in images via this method. You simply use the image name as a template file when adding content to a newsletter template.

{{block type="core/template" name="test" template="../../../../../../media/catalog/category/evil.jpg"}}
Screen Shot 2017-06-13 at 11.58.56
Including an evil image as a template in a newsletter template

You then need to preview your newsletter template and hey presto your PHP code is executed!

Screen Shot 2017-06-12 at 13.35.11
Binary image data outputted to the screen with the output of PHP code at the end

In order for the path used above to work in the template there needs to be an non-default setting for the configuration setting:


When set to 1 this negates a check in the code that only allows templates from the template directory to be included. The check uses PHP’s realpath function and hence breaks if the template path is a symbolic link.

Without the patch SUPEE-9767 the altering of this setting was available to an attacker who had successful gained access to the admin site.

Screen Shot 2017-06-13 at 11.57.18
The “Allow Symlinks” setting has been removed from the admin site now and is now configured in config.xml

This attack has been used in the wild on stores for several months. The solution which has been implemented in SUPEE-9767 was several fold. Firstly a filter was implemented that will strip PHP code from images uploaded. This uses tried and tested methods and should be reliable.

The second part of the fix was to remove the ability to skip the path check based on a setting in the admin in panel. Instead if you need templates to be included that contain symbolic links this setting is now in config.xml

Screen Shot 2017-06-13 at 12.24.45

This means that having gained access to the admin site an attacker can no longer update the setting and must have access to the filesystem.

So patch, patch, patch as soon as possible.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s