vBulletin hacked forums: Clean Up Time
Step 1. Close forums temporarily. Then pay attention to the following suggestions:
- Change all your login and passwords for your entire server and forums – FTP, SFTP, SSH, cPanel, WHM, MySQL, email passwords (if you were using SMTP for vBulletin).
- If you use same username and logins for other 3rd party services such as domain registrar, 3rd party DNS management or other web services, you will need to change those as well.
- If you have other administrators or partners who have similar level of access to all mentioned logins and services, you will also need for them to change their log in and passwords.
- Human breaches. More common than you think. Weak, common dictionary worded and/or re-used passwords being set on user accounts on forums and other web scripts you may have installed. This applies to all web scripts on your server and not just vBulletin itself as already mentioned above. You can use http://strongpasswordgenerator.com to generate much stronger password combinations with a minimum of 15 characters. I personally use 16-18 character passwords generated from Lastpass.com program (similar to keepass).
- You would be surprised how common it is for the security breach to come from an insecure or easily guessed password or even from local computers infected with key loggers or spyware. So don’t forget to scan your local computers for viruses and malware infections too. For passwords, use http://strongpasswordgenerator.com to generate minimum 16-18 character passwords.
- Hackers eavesdropping on unsecure home or public Wi-Fi connections – securing Wi-FI isn’t part of this article but Google search ‘how to secure Wi-Fi‘ should bring up alot of results. Nice article on what evesdroppers actually see on an unsecured Wi-Fi hotspot. Eavesdroppers have the ability to capture login information and hijack accounts on unsecure Wi-Fi connections!
- If you are using a web hosting control of some sort, i.e. WHM/Cpanel, DirectAdmin, Plesk etc, take note of the current version installed and then check to see what is the latest stable release for your control panel. Outdated web hosting control panels with older vulnerable security flaws are yet another possible way of compromising your server. Keeping your web hosting control panel up to date is highly recommended. If unsure or on shared hosting, consult with your web host.
- Ensure your Linux distros’ package software are up to date i.e. your server Kernel, Apache, Nginx, PHP and MySQL server versions etc. For CentOS/Red Hat/Fedora that would be done via YUM package manager. For Ubuntu and Debian that would be via APT package manager. For vBulletin 3.8.7+ ensure PHP 5.3.27, for vBulletin 3.8.8 beta ensure PHP 5.3.27 or 5.4.19. For vB 4.2.x prior to vB 4.2.2, ensure PHP 5.3.27. For vB 4.2.2+ and higher ensure PHP 5.3.27 or 5.4.19. For Apache at least 2.2.25. If unsure or on shared hosting, consult with your web host.
- Ensure your PHP has been configured with register_globals disabled (off) for both local and master values listed if on PHP versions less than AdminCP > Maintenance > View PHP Info. Use CTRL+F on the page and find register_globals. You can also check via SSH telnet as root user type the below command – if it exists it will return a value, if it doesn’t then it will come back empty:
Command:
php -i | grep 'register_globals'
On PHP 5.3.27 server it returns for local and master values the following:
register_globals => Off => Off
If register_globals is enabled (On), then you need to disable it via PHP config file php.ini at server level. Hence, why you need web host provider involvement if you’re on shared hosting as they would be only ones who have privileges to make such changes. If unsure, consult your web host provider.
If you have SSH root access, you can edit your php.ini and find the register_globals variable and change it from On to Off and then restart Apache or PHP process (depending on how server is configured i.e. php-fpm). To find your correct php.ini file (as their could be multiple ones on server), check the PHP info page for Configuration File line. Or via SSH type (below example shows it’s located at /usr/local/lib/php.ini:
php -i | grep 'Configuration File'
php -i | grep 'Configuration File' Configuration File (php.ini) Path => /usr/local/lib Loaded Configuration File => /usr/local/lib/php.ini
