View Full Version : HowTo "UnHack" Yourself and Hacker Prevention

15 Dec 2009, 09:35
Recently, one of my vBulletin powered sites was under a hacking spout, I'd fix it, and it got hacked the next day, fixed it, hacked again, fixed, hacked again.

Fortunately, he was doing the same thing each time. Up until the last time, I was just restoring a DB backup, which he hacked several times. I found this is the lazy way out

I was scratching my head over and over, "how is he getting in". I'd followed the standard safety measures and such, renamed admincp/modcp, 128bit passwords, etc.

Here's what I did, and it seems to have worked:

Firstly I did a recursive CHMOD of 0644 on every single file and folder, this will make your vBulletin bring up a "Forbidden" Message, while you work on it. Then I CHMOD the AdminCP Dir (renamed) to 0755, which gives you access to your acp. So you have access to the site, the hacker doesnt. You could also achieve this by putting an index.html in your root directory, or specifying a 301 redirect in a .htaccess.

I then fixed the bugs, using the vBulletin AdminCP, and PHPMYADMIN, I find it's more effective to remove these things at a database level (this time it was sql insertion and malicious javascript) I then went ahead and changed all my staffs passwords, sure, they'll moan, but if it protects the site, then they have to live with it.

I then went and created 128bit passwords and put .htaccess and .htpasswd's in the following directories:

admincp/ (renamed)
modcp/ (renamed)

If you have SSH access to your server, ask your host to remove it also (even if just for like, a week or two), as this is another way the hacker can get in.

I then changed my Database NAME, and Database user name and password, and changed those in the config.php, I then renamed the admincp/modcp/ dirs, again, they now aren't even under /forum/, you can do that by adding your full path to any instance of "global.php". (see attachment)

Then I went and did a recursive CHMOD on all the DIRECTORIES to 0755, so all files are now sitting at 0644 and directories (folders) are at 0755. So this should be secure, vBSEO users should remember to chmod your config_vbseo.php back to 777, and if you have any mods like vbimghost, chmod 777 the image upload directory.. - this isn't needed if you used the .htaccess method.

Finally, I reviewed my raw access logs and control panel logs, and error logs, determined the IP of the hacker, and IPtabled them, they now can't access any part of the server. This is a b*tch to do, and gives you a headache and takes a long time. If you dont have the access to block them from the server, again, you can use a .htaccess to block thier IP or thier IP range.

Alot of what I've said is in all the official stuff, but eh, Hope this helps anyone.

Black Tiger
20 Dec 2009, 16:51
Nice howto, but I've got some comments:
I was just restoring a DB backup, which he hacked several times. I found this is the lazy way out
Not it's in fact totaly no way out at all, not even a lazy one. It just plain and stupid giving the same possibility's back to the hacker. As you experienced.

You can do a lot of chmodding, but these things should be already automatically fine when installing and later upgrading vBulletin.
However, always take care with 777 directory's and files which are always a risk.

Then I CHMOD the AdminCP Dir (renamed) to 0755, which gives you access to your acp. So you have access to the site, the hacker doesnt.
That's a common mistake made by many people. If you make something 755 its not writable to the world, but it is still readable to the world. So also the hacker can read. That's why the first thing to do is to put up a .htaccess file in there.

This is a b*tch to do, and gives you a headache and takes a long time.
That depends on the knowledge of the person who is doing this. You can chmod recursive, also with an ftp program, and this can save you lots of time.
Als don't just start chmodding everything, have a look first if maybe most things not already -are- oke. A hacker can also gain access via mods which are not safe. Thats where vbulletin.org comes in, which sends security messages if it gets know a mod is not secure. Not a lot of mod sites are doing such nice things, so take care from where you download and install mods/hacks.

Most important thing to do is to get to know how the hacker gain access.

For the rest it's a very nice manual for people who take security very serious.

25 Dec 2009, 15:45
Thanks for this! I've had my board hacked 6 times within a week and recovered it each time. However, you don't have to restore the whole database each time. Once you recover your board again, and get it back to good working order again. Back it up, and run the "Template" table query. Drop / Create. Done. Then do the password protection of those directories/ rename of admincp and modcp. It worked for me, and took less time.

Or, go into phpMyAdmin, drop the tables of ONLY the template that was in use at the time of the hacking. If "Sam" coded my template, and I was using his template at the time of the hacking. I would only drop the tables of that template that had his name beside it. Then, go to "options" table in the database... switch the style id back to the default id. You'll get a blank page, then just run "domain.com/install/upgrade.php" or whatever.

27 Dec 2009, 21:28
Well, well

... I did a recursive CHMOD of 0644....

0440 or 0400 can be enough. Depends on how your Webserver is configured but in my opinion the PHP user should never be able to write anywhere inside the Webroot.
You can configure VB to use the uploads directory somewhere outside the Webroot which is much better.


Well - if that thing is installed one will for sure have other problems than securing VB - best way - remove phpMyAdmin completely specially if you

If you have SSH access to your server, ask your host to remove it

can use SSH to forward Database connections through a tunnel to your local host. And instead of removing SSH - ask the host if they can switch to Public Key authentication and for Gods sake keep it running.
Instead try to use SFTP and remove FTP giving you the ability to tighten up the file permissions even more.

Problem is that if you remove SSH which can be configured secure but keep phpMyAdmin running and have 0644 permissions you secure at the wrong side of the server.
General recommendation - if possible never let the PHP user write anywhere inside the Webroot if possible, mod_sec / suhosin are good if configured right to prevent RFI's / LFI's and Injections and try to remove FTP completely and rely on the much more secure SSH / SFTP with (and only with) Public Key auth.

Then you can easily configure your Webserver that admincp / modcp Logins are SSL based - maybe with a Client Cert authentication.

Please - don't misunderstand me - just phpMyAdmin as example is a thing that should be removed completely. Unsafe software won't get more secure if you make the door entry smaller - as long as it's there, it's a risk.
Same applies to FTP when SFTP is available as option and finally the problem that PHP should never write anywhere in the Webroot.
If you still decide to keep CSS related Style changes on the Webroot you can set the directory where these files are kept with:

<directory "/where_ever_it_is/clientscript/">
php_admin_flag Engine off

Or removing the handlers when using FastCGI. The same applies to all other folders where no PHP files are running (images, js and so on) and it should specially apply to every folder where PHP is able to do write operations such as the uploads directory.


21 Apr 2010, 11:22
Very nice article for people who are new at security

19 May 2010, 19:51
How do you remove phpMyAdmin completely?

19 May 2010, 20:23
HowTo "UnHack" Yourself
I'm seeing a lot of suggestions on prevention, but couldn't find one thing that talked about how you actually Unhacked yourself.

You mention 'fixing bugs'. Which?

01 Jun 2010, 16:07
How come when you're setting up memcache file storing you're advised to CHMOD to 777 but every bit of security advice says not to?