Securing images folder against php

[FootstepsDesign]

Hi,

We have repeatedly had clients that have been hacked through the /images folder due to php script hacks.

These come in a multitude of guises with the latest one being a .gif file. They usually work by evaluating a specially crafted url. Some of the more clever ones will also zip the malicious code to generate a smaller url.

This can prove problematic if you try to limit scripting as it is not always the same file extenions within the folder so we looked in to a different solution and came up with the following:

This solution only works on 'nix distros

• Create a .htaccess file within the root images folder or amend it if it already exists
• Add the following line:

Code: Select all

php_flag engine off

Unfortunately due to the volatility of the naming conventions in IIS we don't have a blanket fix to remove the handlers for PHP in IIS but the following code shows the general principal for the web.config file assuming the handlers haven't been locked at a higher level.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <remove name="PHP 5" />
        </handlers>
    </system.webServer>
</configuration>

[sitesrus]

I'm intrigued by this, can you explain more?

So PHP files are or aren't being allowed to be uploaded and executed? Or this is all localized in a gif file that's the threat? Can you explain more in details and give an example?

I'd like to learn about this vulnaribility. We've done this in the past as a precaution but never allowed PHP scripts to be uploaded for client sites in case they accidentlly allowed something like that to take place. But you're saying a user uploads a gif and compromises the site?

Thanks.

[FootstepsDesign]

Hi Sitesrus,

This code will allow any file to be uploaded to the images folder however it stops the PHP engine from attempting to execute any code and so the PHP will just get parsed to the browser instead, but then our sites would never have PHP in the images folder.

We used to just limit script extensions using the .htaccess file but this fails for other extensions. We haven't performed much testing to determine how many different file types can be used in this way and it will probably depend on how the hosting is set up as well. But having said that on our hosting this file did work:

file.gif:

Code: Select all

GIF89a<?php
// Do something here.
?><< Remaining picture data >>

When we tested this we used it to write a test file to the server so that nothing was outputted so it would then display the picture once it had finished. However when the line was added to the .htaccess file it just returns a 'bad image' icon.

The GIF89a header is just to please various antivirus programs whereas antimalware should look for specific lines of code within the file.

n.b. This does need further testing to confirm it on multiple systems but unfortunately we don't have the time or resources to do this so if anyone else can post their experiences this would be very useful.

[sitesrus]

I'm pretty sure you have to configure the php processor to work against file extensions. So it's odd it would run against anything. Check your configs.

[FootstepsDesign]

Hi Sitesrus,

Yes you are quite right and the usual hiccup comes in how the web servers are configured. However suffice to say that you do need a little bit more code elsewhere that instantiates the file.

Unfortunately we can't post the full method of exploiting this due to liability.

If you don't know how to use this sort of exploit then try googling for gif exploits as it is the most common method as you can have a valid gif file that displays and still have malicious code within it.

Until it is exploited correctly then the website and owner can be oblivious to it. We normally see the attack starting about a month or so after the file was uploaded.

[sitesrus]

If it's being uploaded client side there's processing you can do in PHP for "signature detection" of threats which can catch stuff like that. There's also cloudflare (CDN + security) that goes in between your site and the client and resolves your DNS, it too may (And I think does) catch exploits like this before they even reach your site. It has a lot of DDOS, XSS, SQL injection, etc. type protection.

Maybe worth looking into? effortless to setup, usually takes about 60 seconds or more.