Local blogger friend Dr. Beth Snow‘s site was hit with a PHP injection attack. My blog was hacked using that mechanism last summer, but today I realized that I never wrote down the recipe for cleaning it out. So here goes.
Form of the attack
The attack is in the form of some extra PHP code that gets added onto existing files on the webserver as well as written into new files on the webserver that are likely to get called. The goal is to redirect visitors’ browsers to a thirdparty website where there’s bad stuff waiting to be downloaded.
Most likely the site got hacked by a bot that did a brute-force password guessing attack on the FTP account. Once the bot gets in, it will add the code to many files.
How to get rid of it
Step 1: Upgrade your FTP password!
Prevent future attacks by upgrading your FTP password. “Sammy32″ is NOT a strong password. “rU#9&Jup” is a strong (though quite short) password. If you need inspiration, there are many free strong password generators online.
Step 2: Upgrade the rest of your passwords on that webhost!
Somebody got access to some of your data, and you must assume that they’ve taken full advantage of their access, so change your other passwords too. Including:
- Database passwords (for a WordPress blog that’s the MySQL password)
- WordPress user accounts passwords
- Any password protected directories (whether you set them up manually in the .htaccess file or you used your webhost’s control panel tools to do the same)
Step 3: Check all browsable files on your website
The PHP insertion hack will attack browsable files such as .php, .htm, .html. Look for lines of code with width 1, height 1 hidden iframe (see the post describing the hack on my website).
Donncha O Caoimh, a respected WordPress community contributor had created a very handy WordPress exploit scanner plugin that will look through your WordPress installation and database. If you have more content on your website than just the WordPress files (e.g. a Wiki, a static website, a downloads directory, etc.) then the WordPress plugin won’t scan those directories. For that situation I recommend using an editor or another tool that can search all files in a directory tree for a particular string.
Step 4: What to do if you find the hack code
If the hack code is the only content in the file, delete the file.
If you find the hack in any part of the site that you didn’t create yourself (WordPress core files, theme files, extensions, etc.) delete the particular directory and re-upload a freshly downloaded replacement. For plugins, the settings are stored in the DB and will survive this procedure; for theme directories, you might want to first backup .css files, image files and any other files you’ve modified.
If the hack code is inserted after the ending HTML tag, just delete the hack code and save the file.
No related posts.
Leave a Reply