vBulletin hacked forums: Clean Up Time
Step 8. Replace all vB files on server with a fresh copy from vBulletin Members Area download. Download new zip for your vB version and upload a fresh set of files overwriting your existing files. Quickest way to do this with SSH and root user access on VPS and dedicated servers is outlined in steps 4 method #2 of my vBulletin 4 upgrade guide where you download from vBulletin Members Area fresh new vB zip for your forum version.
On local computer extract the zip file and find upload folder and zip that up i.e. upload.zip and upload that to directory above web root i.e. /home/username/upload so upload upload.zip to /home/username. Then use following commands to mass replace all vB files. Example assumes your live vB install path is at /home/username/public_html (change accordingly to your specific location). This method ensures 100% that all your fresh set of vB files overwrite all your existing older vB files. But it won’t solve the problem if you have additional malicious malware files that the hacker left behind. Read further below to find out how to use vB Suspect Files check and AVG Anti-virus and Linux Malware Detect tools to seek out such files.
cd /home/username unzip upload.zip cd /home/username/upload \cp -Rfp * /home/username/public_html
Then might be wise to check file permissions again from step 7.
After that is done, if you are using vBSEO addon and have MaxCDN or any other CDN hosted vB php/js/css files served externally, please flush and purge the CDN caches from your MaxCDN or CDN provider control panels to ensure you’re working with the uploaded new files and not cached CDN files.
As the vB adminlog is an important tool to rely on, you may want to disable the ability for any admin users from pruning the log within /includes/config.php removing the default userid 1 from listing.
define("DISABLE_HOOKS", true); |
becomes
// ****** USERS WITH ADMIN LOG PRUNING PERMISSIONS ****** // The users specified here will be allowed to remove ("prune") entries from the admin // log. See the above entry for more information on the format. $config['SpecialUsers']['canpruneadminlog'] = ''; |
While you’re at it, you can also add your administrator and moderator/super moderator’s userids to the undeletableusers in vB config.php too. Just in case an admin’s account is hijacked and they decide to delete other administrator and moderator accounts.
// ****** UNDELETABLE / UNALTERABLE USERS ****** // The users specified here will not be deletable or alterable from the control panel by any users. // To specify more than one user, separate userids with commas. $config['SpecialUsers']['undeletableusers'] = '1'; |
Then secure your /includes/config.php via /includes/.htaccess as per vB documentation with following:
<Files config.php> order deny,allow deny from all </Files> |
You could also rename your /admincp and /modcp directories and update vB includes/config.php with the new renamed directories. Note if you do this, I would recommend you create empty /admincp and /modcp directories as place holders and .htaccess password protect the empty dummy directories as well as the renamed real renamed directories. This way if you do future forum upgrades and upload the default /upload folder’s /admincp and /modcp forgetting to rename them first, the uploaded directories will already have been password protected.
// ****** PATH TO ADMIN & MODERATOR CONTROL PANELS ****** // This setting allows you to change the name of the folders that the admin and // moderator control panels reside in. You may wish to do this for security purposes. // Please note that if you change the name of the directory here, you will still need // to manually change the name of the directory on the server. $config['Misc']['admincpdir'] = 'newadmincpname'; $config['Misc']['modcpdir'] = 'newmodcpname'; |
vBulletin master style vbulletin-style.xml
Zachery’s guide is also helpful as well. Particularly Step 7 in reloading fresh vBulletin master style vbulletin-style.xml (found in a fresh vB download zip’s /install/vbulletin-style.xml folder (make sure /install directory is password protected first as outlined above if you’re uploading files from /install directory). AdminCP > Styles & Templates > Download / Upload Styles, browse and choose the master vbulletin-style.xml from your local vBulletin zip download’s /install directory and import it. You won’t have to do this if you’re upgrading your forums to a newer vB version and are uploading a fresh set of vB files (make sure /install directory is password protected first as outlined above if you’re uploading files from /install directory). I assume you already have done Step 0 and made a full MySQL database and files backup of your infected forums, so can revert any changes and try again if you made mistakes ? ;)
Ensure you properly overwrite all files
- It’s common also to be breached when not properly overwriting the script’s previous version files (php files etc) with the new updated files. This is common across many web scripts including vBulletin. Frequently, I find vBulletin sites which have a mix of php version files from more than one version of vBulletin. vB AdminCP -> Diagnostic Tools -> Suspect Files check for vB 3.x/4.x would provide a complete list of mismatches or unexpected content. vB 5.x version of the Suspect file check isn’t complete as it only checks /core/* files and not the presentation layer files outside of /core/* right now. So ensure when you upgrade your web scripts (including non-vBulletin scripts), you are properly overwriting all files with the updated version files.
- Some folks despite needing full upgrade.php runs have been applying patch updates which include vB version file through several updates so you see the updated version but checking upgradelog database table you still see that the database itself is an older version and/or they have a mix and match of different vB php files as they didn’t properly overwrite all vB php files.
- If you have other web/php/mysql using apps on your server, I would also take this opportunity to update those respective scripts with latest version files and/or refresh with new upload all those scripts’ files. Such scripts with common breaches include, WordPress, Joomla, Drupal, OpenX, and vBSEO plugin.
- Compromises in any of these scripts could allow hackers to leave nasty backdoor entry and malware on your server which could potentially open up your entire server or account to be breached if you have other system level exploits present on your server (i.e. kernel exploits hence need to keep system packages up to date). If you find backdoor malware or PHP shell command malware on your server, you will need to consult with your web host as a server complete reload/reinstall OS or account level reload/reinstall might be safest way to ensure no further breaches occur. If any of these scripts listed are installed on same server as your vBulletin forum, then they need to have the same amount of care in securing them and ensuring they are up to date as well.
