Zero Day Exploit and Suspect File Versions

[NumNum]

Will running the Suspect File Versions be an effective way to identify the rogue files for removal?

[chriske]

Only in the core folder if I am right.

They will probably add files in other folders to.

[NumNum]

That is my thinking. Other files outside the core that are not identified I have renamed and watching for any negative impact.

[twistsol]

On our site, the offending .php files were in the attachments directory as well as in the directories of each of the admins listed in the core/includes/config.php file as well as the attachments/1 directory which would usually be the first user and therefore the admin. The suspect file versions check did not identify any of them. We restored to the prior day's backup and deleted any files in the site directory created on or after 9/24.

[Blackhorse]

On our site, the offending .php files were in the attachments directory as well as in the directories of each of the admins listed in the core/includes/config.php file as well as the attachments/1 directory which would usually be the first user and therefore the admin. The suspect file versions check did not identify any of them. We restored to the prior day's backup and deleted any files in the site directory created on or after 9/24.

Hello,

I think restoration is not a solution!

I have deleted more than 15 php files and many folders

i have deleted all files from 18 September, but unfortunately i found out that they are able to inject files with very old dates, i had to check folder by folder regardless of sate for any strange file.

I have updated forum to the latest vbulletin and patch

Is there any important step to do?

[In Omnibus]

Restoration does not terminate any malicious processes.

Here is the official solution:

1. Create a new directory.
2. Upload the files from a new patched vBulletin Package to this directory.
3. Point the /core/includes/config.php to your database.
4. Make sure there are no PHP or Javascript files in the attachment or customavatar directories.
5. Copy over your attachment and customavatar directories.
6. Run /core/install/upgrade.php
7. Revert any template customizations that you have not documented as creating

[LBS]

Step:
8. Inform all your users that your server and their accounts have been compromised.
9. Perform a complete reinstall of your server.
10. Verify every record of the database to make sure that no malicious entries exist.
11. Reduce the operating system permissions of vBulletin as much as you can.
12. Monitor #vBulletin at Twitter, so that when the next exploit is released, you can immediately shutdown your forum to minimize damage. Don't rely on the swift manner of the official announcements.

[Gene THF]

LBS what do you feel is the risk by not performing a complete re-install of the server?

[LBS]

That depends on the security of the system. For example, if the system is running on outdated software, then this exploit increases the attack surface a lot by providing shell access from which privilege escalation may be performed. So if you want reduce the likelihood that things are left, then re-install the server.

[alfreema]

Folks, there has never been a better example of the security principle: "don't run your web server as root"

The damage caused by this exploit is reduced by MAGNITUDES if you aren't "that guy". Make sure you never run your web server software as root. Just don't. If you are, educate yourself on how to change that.

Make sure your vb5 folder owner is a non-root user and make sure your web server is running as a non-root user. If you do that, then the worst part of this issue is the database being compromised (which still sucks but it's fairly straight forward to recover from with a good backup).