test.php.file uploaded in attachment-directory of vB gets executed as PHP

[firewire]

In the aftermath of a hacking attempt, I detected a file called "css.php.file" being uploaded to the vBulletin attachments folder. The attacker used another software to upload this file, so it's not vB's fault.

I am wondering though: even though it's ending is not .php (but .php.file), that file gets executed as PHP when requested over the web. In other locations than the attachments folder, only it's source is shown.

My only AddTypes for Apache are:
AddType application/x-httpd-php .php
AddType application/x-httpd-php .php3
AddType application/x-httpd-php .php4
AddType application/x-httpd-php-source .phps

Anyone with a suggestion, why a file with ending .file is considered a php file?
Thanks.

[Mike Sullivan]

I really can't comment on this specific issue. I seem to recall seeing it years ago when I was doing some Apache1-PHP as a CGI tests on Windows, but I never saw it in a proper LAM+mod_php setup.

I just wanted to mention a few things about security.

First, while some options in vB require that the directory be writable by the Apache user, none of those directories need to allow PHP code to be executed at all. (Well, there's the datastore in a file, but that's a specific case...)

For that reason, I recommend in your attachments/avatars/vbulletin_css folders to simply put this in an .htaccess. Or, perhaps even better, in the <VirtualHost> entry (obviously use a <Location> tag! :)).
php_flag engine off
You could take it a step further and disable CGIs from executing.

Another thing you can do for your attachments folder (and only the attachments folder) is not allow any direct request to it. I'd actually recommend putting it above the webroot, but if that hasn't/can't happen, this will help:
Deny from all

[firewire]

Hello Mike,

that is some excellent advice, thank you very much.