[Plugin: BulletProof Security] BPS File Targeted and Hacked

Another site was hacked today by hackers calling themselves FBI.

They also hacked the bulletproof-security.php file in the plugin’s folder and added a text file called fbi.txt at the root level.

Help! Do I need to deactivate BPS everywhere now? This is really a problem.

thanks!

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.

Hi and thanks for getting back to me.

What threw me was that hacking incidents had been few and far between in the past few years (we keep our WP and plugin software up to date) but after installing BPS, we had two sites hacked in less than a couple days (about 2 weeks later) and in both cases, the hackers specifically hacked the bulletproof-security.php file and then left one other calling card.

In other words, they appeared to be targeting the BPS plugin.

I don’t see how the WordPress login could be compromised since I would never store that kind of information on the server. The sites hacked were so insignificant that I can’t believe any hacker would be interested in them. It isn’t every site on the server, just two out of maybe 20. Weird.

I’ll report this to our hosting people and see if they have any insights and look into “timthumb exploits” which I’ve never heard of. I’ll also keep an eye on the other 30 WP sites we maintain, which all have BPS on them now.

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.

First I’m not trying to hack this thread, but offer a suggestion(s). I’m pretty sure you’ll be able to improve on them, but just a suggestion.

# 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]

Make this a bit more specific as the above will cause the rules to skip ([S=30]) the thumbs.db hack:

RewriteCond %{REQUEST_FILENAME} ^(tim|php)?thumb(s)?\.php$ [NC]
RewriteRule ^(.*)$ – [S=30]

Instead if you want to really get deep into stopping (not skipping [S=30]) malicious fingerprinting of the timthumb and variants, how about this?

# Forbid fingerprinting variants of timthumb and thumbs.db
# (with or without tim or php prefixes, s (plural), various php and db extensions, or infected theme cache directory files)
RewriteCond %{REQUEST_FILENAME} ^(tim|php)?thumb(s)?\.(php[2-5]?|db)$ [NC,OR]
RewriteCond %{REQUEST_FILENAME} /wp-content/themes/.+/cache/[a-f0-9]+\.php[2-5]?$ [NC]
RewriteRule .* – [F]

—————————————————-
And what about doing something to stop people from fingerprinting your plugin?

How about adding a line like so:

RewriteCond %{REQUEST_FILENAME} ^bulletproof-security\.php$ [NC]
RewriteRule .* – [F]

Not sure if using a RewriteCond or just using a straight RewriteRule above would be better, you’d have to test.

Or better yet, putting some allow,deny directives in an .htaccess in the plugin directory itself.

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! ??

hmmm….

You can’t make the page return a 403 because that tells a hacker that BPS exists.

How about using [G] (Gone) instead of [F] (Forbidden)?

RewriteRule .* – [G]

Or just send them back to the home page:

RewriteCond %{REQUEST_FILENAME} ^bulletproof-security\.php$ [NC]
RewriteRule .* https://example.com [L]

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.

And actually I made a major bad statement to BrattDev. If the hackers are using a Shell like C99, r57 or AluCar then they have full access to your DB and stored data as well as full access to anything else stored in your folders.

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”.

Thanks for all the info. I did a complete search of the hacked sites and unfortunately, there is no timthumb.php script on either one (I searched all variant file names too). We do have a couple sites that use that script — one was hacked months ago after the client went crazy with dicey plugins. The other has not been hacked, and I’ll contact the plugin developer to make sure the timthumb.php script has been patched.

But that leaves me more or less where I was. I don’t know how they got in so I can’t plug the hole (yet). I have a positive feeling about BPS but I really hate that hackers are motivated to hack it.

Here’s what I think I’m going to do — see what you think. I will change the main server password again. I will check the logs on both sites and see if there’s any hints. Reading log files isn’t my strong suit but I should be able to see something will report back if I find anything fishy. My server people should be able to help with this too.

So we’ll see what we can find out and let you know. I won’t sleep until this is resolved, or at least, not well.

Ok, I found the hack in the access logs (or at least I’m pretty sure I did). The time corresponds to the time the bulletproof-security.php file was altered. I’m happy to send you a copy, AITPro, if you want to see it. They hit wp-admin/login.php a bunch of times, then got a bunch of plugin files including and esp BPS. I’m not qualified to judge how they managed to do this or what exactly they did but they left a lengthy trail over the 10 or 11 minutes it took them to hack the site.

Would you mind if I emailed the log excerpt to you for your expert opinion?

thanks again.

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

Yep sure send me the log file. edward[at]ait-pro[dot]com

They hit wp-admin/login.php a bunch of times, then got a bunch of plugin files including and esp BPS.

hmm going after login.php usually indicates a brute force attack to guess a password. If you are using the default WP “admin” user account then delete that account as well as changing your admin account passwords.

And like i said there is no point in trying to salvage the current site, but knowing how they got in is very helpful. ??
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 >>> https://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

Also i want to point this out >>> when you create an Admin account you want to make sure that “Display name publicly as” is not the same as the user account name. Otherwise the username is displayed publicly under comments, posts, etc and is the same thing as using the WP default username “admin”. You give the hackers a huge starting point and they can then just run their automated dictionary cracking program until the password is eventually cracked. ?? Passwords should be changed a minimum of every 30 days.

Thanks,
Ed