Verifying that I have fully removed a WordPress hack?

0 Views

My for-fun WordPress blog at http://fakeplasticrock.com (running WordPress 3.1.1) got hacked — it was showing an <iframe> on every page like so: 

<iframe src="http://evilsite.com/go/1"></iframe>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

I did the following

Read More
  1. Upgraded to 3.1.3 via the built-in WordPress upgrade system
  2. Installed the Exploit Scanner (lots of critical warnings on unusual files) and AntiVirus (this showed all green and clean, so I uninstalled and removed it after running)
  3. Changed MySQL password.
  4. Changed all WordPress user passwords.
  5. Connected via FTP and downloaded the whole filesystem (not large, this is a WordPress-only Linux shared host)
  6. Diffed the filesystem against an official ZIP of WordPress 3.1.3 and removed or overwrote anything that did not match.

I am quite sure that

  • all the files on disk are official WordPress 3.1.3 files
  • there are no “extra” files on disk other than my one /theme, the Exploit Scanner plugin (which I just downloaded), the /uploads folder, and a tiny handful of other expected files. My other plugin, wp-recaptcha, matches the current official downloaded version.
  • I also checked the .htaccess file and nothing looks wrong there

wordpress 3.1.3 file compare in Beyond Compare

I did not touch the database, but I am struggling to think how anything in the database could be malicious without special PHP code to make it work?

My WordPress blog appears OK and hack-free now (I think), but is there anything else I should check?

Post Views: 0

Related posts

Leave a Reply

12 comments

  1. Have you identified the exploit vector? If not, you may be leaving yourself open to future exploit.

    Other things to consider:

    1. Change WordPress admin user passwords – done
    2. Change Hosting account user password
    3. Change FTP passwords
    4. Change MySQL db user password – done
    5. Change the db table prefix
    6. Update your wp-config nonces/salt
    7. Check your directory/file permissions
    8. Block directory-browsing access, via .htaccess
    9. Go through everything in the Hardening WordPress Codex entry
    10. Go through everything in the FAQ My Site Was Hacked Codex entry

  2. Looking at the Google Chrome “safe browsing” message, you’re getting the “.cc iFrame hack” that seems to be going around a LOT lately. I think 3.1.3 will fix this, but check your index.php file in the root if your site, that’s where it kept hitting me until I got EVERYTHING updated and passwords changed.

    There is some VERY tricky stuff folks can do with post and comment injections. You can run the following queries against your database to help find some of them I blogged the rest of my “tracking” here.

    SELECT * FROM wp_posts WHERE post_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%display:%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?%'
UNION
SELECT * FROM wp_posts WHERE post_content LIKE '%<?php%'

    SELECT * FROM wp_comments WHERE comment_content LIKE '%<iframe%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<noscript%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%display:%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?%'
UNION
SELECT * FROM wp_comments WHERE comment_content LIKE '%<?php%'

    Hope this helps!

  3. The database can contain malicious code too: hidden user accounts or values that are printed unescaped somewhere. Also, check your upload directory for files which don’t belong there.

    Oh, and try to understand how the attacker found his way into your site. On shared accounts it is often the whole server. Check the other sites on the server for hacked blogs or other pages too. Read your FTP log. If you don’t know how it happened you cannot prevent the next break.

  4. Sorry to hear you got hacked – looks like you’ve done a fine recovery job though!

    Your filesystem sounds golden, I wouldn’t say there’s anything else you could do here.

    I would think Exploit Scanner would throw a warning if it found any scripts, iframes, PHP (though only dangerous if eval’d), or other unusual code in your database.

    I’m not sure if it checks tables other than posts & comments, might be worth checking out /wp-admin/options.php for a quick glance and see if you spot anything odd.

    I’d also check your users table in a MySQL client (users may be in the database but not visible in the admin).

  5. Check Google Webmaster tools for two things:

    • verify that your site hasn’t been flagged as compromised, and request reconsideration if it has
    • check your site as Googlebot and verify that there’s no spam being inserted which is only visible to Googlebot – example of this is the WP Pharma hack

    Also, I’d re-implement the theme, or check it extremely carefully. A few lines of PHP can redefine core PHP functions so that they extract malicious code from the database, especially the wp_options key / value store tables

  6. Search the database via phpmyadmin for “iframe” or dump the database and search the text.

    And check for invisible users in the users table; I’ve seen users in the tables that didn’t show up in WP Admin>>Users.

    Clean Options « WordPress Plugins will show what junk from old and possibly vulnerable plugins is left in the database.

    Your theme is also missing the <head> tag, so I’d check that in case you edited the theme to remove bad links.

    And the usual: and How to find a backdoor in a hacked WordPress and Hardening WordPress « WordPress Codex

  7. “is there anything else I should check?”
    You need to examine your process, and find out how you were hacked (almost certainly because you didn’t patch in time, or correctly) and fix that too, not just the symptoms.

  8. That happend to me once, through a leak on mediatemple. I had to write a plugin to check the database for injected links. You can grab it here as a github gist.

    It’s pretty user friendly, has several steps that deliver feedback and re-checks your database after you’re finished.

    Good luck!

  9. I had a very similar hack I had to fix on one of my client sites.

    There was malicious scripts in the filesystem (php base64_decode stuff). However, the database ‘posts’ & ‘comments’ tables had been compromised and the iframe code was scattered through that data as well.

    I’d at least run a few searches on the DB, just to be safe. 🙂

  10. Check your plugins !, so far this year there have been 60 exploit releases from .org plugins, I would suspect the real number to be much higher since no one is really doing this full time.

    You listed that you only have one plugin, well it had a security hole (not sure how long it was out, and it might not be the vector).

    wp-recaptcha-plugin
    The exploit was released: 2011-03-18
    Exploit version: 2.9.8

    The author stated he rewrote with version 3.0, but there is no mention of the security patch.

    http://www.wpsecure.net/2011/03/wp-recaptcha-plugin/

    Change log: http://wordpress.org/extend/plugins/wp-recaptcha/changelog/

  11. I use a cloud server and have random wacky ssh port numbers no ftp at all. Passwords are extremely difficult to hack. All root access is completely denied. I agree that WordPress is not going to be your culprit. Another thing to check for is ftp sessions not closing, virus on your personal computer(remember you can up load a file to your site and who ever loads that file can get the same virus), also dont keep your passwords on public sites or private sites always right them down on paper never on a word document or notepad.

    Lastly ask your host if they recently had a breach as they should have a firewall setup

  12. Check the date of your files. No file should have a change data newer than your last edit/install!

    But also this can be faked. The onliest way of being sure would be to compare (eg. hash compare) all files with the original installation files.