[Plugin: BulletProof Security] BPS File Targeted and Hacked

Hate to tell you this, but there is nothing that can protect your websites if someone has stolen or hacked your passwords. BPS and other website security plugins are designed to protect against external attacks like RFI, Code injection, SQL Injection, XSS, etc. by blocking the hackers code from being successful. WordPress protects your website with authentication. If authentication is compromised then you don’t have any security at all and there is nothing that can protect your sites. And i really hate to tell you this. There is no point in trying to salvage a website that a hacker has been able to log into. If the hacker is smart he put in 100’s of backdoor scripts to allow access anytime they want without having to log in via WordPress, which also brings up another point. If you have an unpatched version of Timthumb then a hacker can upload his own login shell and does not need to use the WordPress login to login into your website.

A good analogy is if you have a top of the line car alarm, but you left the keys to your car in the ignition with the doors unlocked then the car alarm cannot protect your car and will benefit the criminals by boosting up the selling price of your stolen car to a chop shop.

My sites get attacked by these 2 same groups on a daily basis as well as 100’s of other random hacking attempts per day. Creating a website security plugin obviously makes you a target. 😉 I don’t mind at all because i now have a huge collection of hacker scripts to play around with. BPS Pro logs and tracks them so i just follow the yellow brick road back to the hackers websites and the originating script path and download the hackers scripts to play around with. I have collected many timthumb exploit scripts that allow hackers to upload files, modify files, login via shells and do anything else that they want to do with your website.

Ok back to the point. You need to isolate how they got in. The first thing to check is for timthumb exploits. This is the most common hacking attempt i am seeing on my sites on a massive scale. Then they could have hacked into your web host’s server and stolen your password, they could have stolen your passwords from a file that is stored pubicly, they could have intercepted an email that contained your passwords, etc etc etc. You need to notify your web host in any case. If they have a vulnerability on their servers that can be exploited then they need to be informed about it so they can fix it. They can also assist you in finding the entry point on your sites. Thanks.

Note: BPS Pro 5.0 does not have logging and tracking. BPS Pro 5.1 will be released in 4-10 days and does have logging and tracking.

It seems to me that hacking the bulletproof-security.php file was done to intentionally send you a message like “gotcha”. I have never had a hacker specifically targeting the bulletproof-security.php file on any of my sites. There is nothing of any real importance happening in that file and to hack it would give the hacker away so at least you are not dealing with high level hackers. The low level hackers want to show off. The high level hackers do not want you to know your site has been hacked – they are professionals focused on making money.

The timthumb exploit thing has been going on for at least a few months now. I estimate that a minimum of 100,000 websites have been hacked that did not patch or download the new timthumb.php script. When you Google this you will find lots of info on it. BPS is currently allowing thumbnailer scripts to display images. This unfortunately allows an unpatched or older version of timthumb.php to be hacked. For testing purposes i have several testing sites that do have the old timthumb.php script on them. On a testing site that BPS is blocking the old script – 2 things occur – the thumbnail images do not display and the hackers are unable to exploit the timthumb script. On a testing site where BPS is not blocking the old script – 2 things occur – the thumbnail images are displayed and the site is successfully hacked on an average of about once per hour. I am sent a notification each time that that site is successfully hacked so that i can restore it to an unhacked state – reset the trap again. 😉
Obviously if you want thumbnail images to be displayed then the solution is to get the new patched version of timthumb.php. I have tested it extensively and have not found any exploits in the new timthumb.php script.

Not all of your sites on the Server were hacked. This is a very good thing because it means that the Host server was not hacked / compromised.
Not all of your sites with BPS installed have been hacked so it is not an issue or vulnerability in BPS itself.
It appears that the hackers have not compromised your WordPress Database and only have the capability to upload, modify, create, edit and / or inject code into files – this is a classic timthumb.php exploit pattern capability and typically indicates that the hackers have successfully uploaded a Shell script to your website using RFI. A shell script allows them to do anything they want on your website. It is basically a WP Dashboard on steroids and allows them to do even more than you can do with your WP Dashboard. Google “AluCar Shell”.

My gut is telling me that since you were not aware of the timthumb.php exploit, i log about 200-250 timthumb exploit attack attempts per day on my main and blog sites and my “hackable” testing site that uses the old exploitable timthumb.php script with BPS allowing this hack gets hacked about once per hour then most likely this is how your sites were hacked.

Search all your sites for these files – timthumb.php, thumb.php, thumbs.php and phpthumb.php. If you find this file on any of your sites then make sure it is the new patched version of the script.

If you are not sure if the timthumb.php file / script is the new patched version then replace this code in the root .htaccess file until you find out for sure…

# TimThumb and all other Thumbnailer Images not displaying – Red X instead of Images
# If your theme uses an image thumbnailer script file this fix will work to display images correctly
# as long as thumb is part of the file name like timthumb.php, thumb.php, thumbs.php or phpthumb.php
RewriteCond %{REQUEST_FILENAME} ^(.*)thumb(.*)$ [NC]
RewriteRule ^(.*)$ – [S=30]

…with this code. This code is a snippet of the new root .htaccess code that will be releasd in BPS .46.5 – expected release date is 11-20.

# ALLOW THUMBNAILER SCRIPTS TO DISPLAY IMAGES
# To forbid allowing requests for these file names replace [S=1] with [F,L]
# If you delete or remove the RewriteRule below you will need to change the above skip rules
# Example: RewriteRule S=2 above will need to be changed to S=1, change S=3 to S=2, etc.
# If you forbid requesting of these files your thumbnail images will not be displayed if you are
# using the timthumb.php or one of the other image thumbnailer scripts listed below.
# It is fine to allow these files to be requested as long as they are the security patched versions.
RewriteCond %{REQUEST_FILENAME} thumb.php [NC,OR]
RewriteCond %{REQUEST_FILENAME} thumbs.php [NC,OR]
RewriteCond %{REQUEST_FILENAME} timthumb.php [NC,OR]
RewriteCond %{REQUEST_FILENAME} phpthumb.php [NC]
RewriteRule . – [F,L]

Let me know how it all turns out. If this is something new then i would be very interested in collecting the data / method, but most likely it is just a standard timthumb.php hack.

Thanks.

Very good input Mickey. 🙂

Major changes have been made in the upcoming release of BPS .46.5. One of those changes is dealing with thumbnailer scripts. Yep the old timthumb is rule is way too general. The new rules specify the exact thumbnailer script filename and gives people the option to allow or deny thumbnailer script requests on their site. I have gone through the new timthumb script and it looks safe to use. Personally i would never use a thumbnailer script on any of my sites because of the potentially dangerous actions that it performs. It is throwing hackers a bone and i don’t like giving them an inch. 😉

Regarding fingerprinting. Currently if you try to access or request bulletproof-security.php on my sites you get a 500 Internal Server Error. I’ve got BPS Pro 5.1 installed though. I am pretty sure that .46.5 will also generate a 500 error, but i am not currently working in that area yet.

I have done all kinds of testing with fingerprinting and here is what i ended up with. You can’t make the page return a 403 because that tells a hacker that BPS exists. if someone is allowing php errors to display then it will display a php error message and show that BPS exists. The ideal solution is to make the page die quietly i guess, but that also fingerprints that BPS exists. To make a long story short i found that trying to add fingerprinting blockers or prevention always ended up at the same place. The best solution is a 500 Internal Server error because their is no point in trying to hide the BPS fingerprint. I was also looking at adding fingerprinting WP version protection, but i came to the same conclusion. A hiding approach in general is not really a good or effective security approach. Besides surface HTTP stuff going on there is a lot of Perl, Python, etc recon going on so hiding does not really work. Displaying PHP errors to the world is of course different because it gives away the exact folder path for your site making the target pinpointed. So people need to create their own custom php.ini files as a standard security measure. Most hacking is automated, but if someone wanted to manually go after a particular site then the Document root path is not a good thing to expose. That is a php.ini thing so it does not relate to BPS Free only Pro.

Any way the new root .htaccess file for .46.5 is a beast! 🙂
thanks for the great input! 😉

Well it’s kind of the same difference. The HTTP Status code is 410 instead of 403. The ideal scenario would be to mimic that the page does not exist at all. I will tinker with this down the road. Currently i get a fair amount of people trying to look at the bulletproof-security.php file on several of my sites, but they are not successful since it bounces them with a 500. Thanks.

Well I think that it is ok if hackers were to go after BPS files directly, but I am not seeing that many “hacking” attempts directed at BPS files directly on any of my lives sites, client sites or any test sites. I do occaisonally see some amateurish attempts at accessing the BPS files directly from a browser, but not very many and they appear to be just random exploration attempts. And no real professional hacking attempts so far. I think what happened in your case is the hacker just did a “in your face” to you. Hacking the bulletproof-security.php file only serves one purpose – to let you know that your site has been hacked. Like i said the pro hackers do not do this. They don’t want you to know that they own your website.

Your site has been fully compromised so unless you are a professional coder and security expert then there is no point in trying to salvage the current site. The learning curve on a website salvage mission is huge so do not even bother wasting your time trying. 😉

So…

The first thing you need to do is search your entire site for any and all .htaccess files. You should only find a root and wp-admin .htaccess file on your site. Check the BPS .htaccess files and make sure that no additional .htaccess code has not been added to them. If you find other .htaccess files then download them, take a look at them and if they are not .htaccess files that you created then delete them from your website.

Then put your site in Maintenance Mode – this allows only your current IP address to gain access to your site – PERIOD – Even if they have installed a Shell, which most likely they have. Maintenance Mode adds an .htaccess file in your website root folder that allows only your current IP address to access your site. If for some reason you cannot log back in via your WP login then you will have to manually FTP to this file or use your host CP to edit this file. Example: if your current IP address changes to a new IP address while you are doing what you need to do next.

Then change all of your passwords – Host account, FTP, WordPress DB (in your host control panel phpMyadmin and also in the wp-config.php file) and your WordPress Dashboard admin login passwords.

Make a zip backup of your entire site. Xcloner does this very nicely and quickly and backs up both your files and DB. Download the Xcloner zip backup file to your computer.

Now you will need to restore your site from a known good backup that has not been hacked. You will also need to restore your WP database from a known good backup that has not been hacked. Your restored site may or may not have any security yet so you should add security ASAP immediately after restoring the site. You could also just put the restored site in Maintenance Mode until you are sure it is locked down securely.

The only data that you want to import back into your restored WP DB is any newer post content that a backup does not have. Or you can always do a manual copy and paste directly from your existing site if you do not have much new content / posts to your restored site. And if you want to add any additional files back to your restored site then check the coding in them before uploading to your restored site.

Now you want to monitor your restored site very closely for at least a couple of weeks. If the site is hacked again then you need to know within a 1 hour window of exactly when the hack occurred. This will make checking your Server log or any intruder logs that you have in place very simple. You will see the Origin, Method and Destination.

Thanks,
Ed

The log file you sent me does not conclusively tell me the method of attack, but the IP address — 109.127.86.107 in your log files is a known bad IP address used in Dictionary Attacks >>> http://projecthoneypot.net/ip_109.127.86.107 and is also blacklisted on several other monitoring sites.

All the clues you have given me point to a brute force dictionary attack used to crack your WP admin password. If the default WordPress user account “admin” is in use a password can be cracked in anywhere from 3 minutes to 1 year. There are several free password cracking tools on the Internet that can do this.

You should not assume that this was how the hack was definitely done, but you need to make sure that this is not a possibility by deleting the default “admin” account and creating ONLY unique obscure usernames for any admin accounts and only very complex secure passwords using lots of random characters like !#@* etc. An example of a secure password that would take a very, very long time to crack would be this >>> pV!*b04#z!Rs@!Xp

I have clients that bitch and moan about having to use obscure and complex usernames and passwords. I do a live demonstration for them and show them how quickly i can crack the username and password that they wanted to use. Then they fully understand that convenience should never take priority over security. 😉

Thanks,
Ed