emptymind604
Forum Replies Created
-
Ran across this on a clients site today.
The files are spoofed gif images. So the mime-type will detect as gif. But then have php embedded in them. When pushed through the php processor the gif parts are passed through to the browser just like html in the file would be and showing up as garbage on the screen, and then the php is executed behind the scenes once it is encountered.
These are usually file uploader, or php shell scripts, (I have not decoded these ones personally) which allow the hacker to upload more files and effectively at that point have complete control over your accounts content. That includes ‘addon domains’ that may also be running under the same user.
While it doesn’t solve the problem of the code being uploaded, the standard security step of disabling php processing in the uploads directory preemptively defangs the attack and stops the hackers from actually running the uploaded code.
This particular attack, as it’s based on random tempdir names and filenames, is also co-dependent on ‘Indexes’ being enabled on the server. As the temp dir is a known location, without any index file, if indexes are enabled, and you go to that url, you will be happily presented with a list of the randomly named temporary directories that you can click on and then get a list of the ‘temp’ files in that directory that you can then click on to run. Since the temp file is named ‘.php’, if PHP is not disabled, you’ve just been hacked.
Adding the following to an .htaccess file in the uploads folder will help to protect your site from this and future similar attacks as well.
`
<Files *.php>
deny from all
</Files>
`Luckily in my case this was already in place, so no further infection was found.
I’d recommend to the programmers in this case, if they are hell bent on using the ‘uploads’ folder as a ‘temp’ directory to ensure that they have an empty index.html file in the temp directory to help stop this attack vector.
And I would recommend to all wordpress users to disable/block php from running in the uploads folder(as above), because it’s not only these programmers that have decided that the uploads folder is a great place to use for general plugin data storage.
I’d go further and propose to all plugin coders that they stop this practice and instead create/support a non-web-accessible directory for such purposes which completely removes the attack vector in its entirety.