110

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

  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?

Improve this question
1
  • 2
    You should keep the blog up to date. :)
    – fuxia ♦
    Commented Jul 20, 2014 at 19:49

12 Answers 12

Reset to default
84

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
Improve this answer
9
  • 1
    sorry, neglected to mention -- I changed WordPress passwords of course. Updated post and checked off on the list here! I can't think of any way they could have my hosting password, or the FTP password, just by getting into WordPress; that information is nowhere in the filesystem or database.
    – Jeff Atwood
    Commented Jun 10, 2011 at 16:18
  • 9
    You have the probable exploit vector backwards; it's not likely WordPress -> hosting account, but rather hosting account (via server or FTP) -> WordPress.
    – Chip Bennett
    Commented Jun 10, 2011 at 16:20
  • 2
    @Jeff some server-level exploits you have no control over (aside from finding a better host). But just because you haven't used host/FTP credentials doesn't mean that someone hasn't stolen them, by gaining access to your hosting account.
    – Chip Bennett
    Commented Jun 10, 2011 at 16:36
  • 7
    There is a very common exploit making the rounds where malware infects your workstation (or the workstation of a contractor), digs through your saved passwords in your favorite FTP (or FTP-enabled) program, and sends those to the attacker, who then compromises your site and uses it to spread the same malware to other webmasters. That is one common way in which your FTP password gets stolen. What's particularly insidious is that its spread through normal sites like yours, not the seedy ones where you're likely to be careful.
    – tylerl
    Commented Jun 10, 2011 at 17:09
  • 3
    FYI, if you have access to the command line, WP-CLI has a verify checksums command that will check each file against wordpress.org
    – William Turrell
    Commented Apr 4, 2015 at 11:58
26

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!

Improve this answer
3
  • 4
    I would add SELECT * FROM wp_* WHERE comment_content LIKE '%<?%' and SELECT * FROM wp_* WHERE comment_content LIKE '%<?php%' just to be sure...
    – SeanJA
    Commented Jun 10, 2011 at 16:04
  • 4
    Oh, one final note. I'm assuming you have Google Webmaster tools tied in to this domain. Once you get things cleaned up you can submit a request from your webmaster tools account to have Google rescan the site and remove the warning message. They process requests from webmaster tools typically within a day. Otherwise you get on the "naughty list" for a good 90 days.
    – Dillie-O
    Commented Jun 10, 2011 at 16:06
  • Found a bunch of results but it's because of embedded iframes for Vimeo.
    – tooshel
    Commented Jun 10, 2011 at 16:19
20

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.

Improve this answer
6
  • wouldn't the Exploit Scanner find any hidden user accounts?
    – Jeff Atwood
    Commented Jun 10, 2011 at 15:52
  • @Jeff Atwood I wouldn’t rely on that. Your user table is not that big. You can easily read it without any plugin.
    – fuxia ♦
    Commented Jun 10, 2011 at 15:55
  • I checked the wp_users table and only 2 rows, both expected.. nothing in the /upload folder unusual (just gifs and pngs and jpegs)
    – Jeff Atwood
    Commented Jun 10, 2011 at 16:00
  • @Jeff Atwood Did you look into the files or just at the extensions? Are all those files listed in the media library?
    – fuxia ♦
    Commented Jun 10, 2011 at 16:02
  • 4
    Image files are a fairly common payload delivery method. See here, and the Theme Review Team has also run into Themes using a similar TIFF exploit.) So, yeah: I'd check each one, to ensure it's part of the Media Library. (Easy high-level scan: check for images that don't have thumbnail-sizes defined.)
    – Chip Bennett
    Commented Jun 10, 2011 at 16:16
13

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

Improve this answer
1
  • definitely a good idea to run a MySQL query on the users table to ensure nothing unexpected is there, and I did that. Good tip!
    – Jeff Atwood
    Commented Jul 6, 2011 at 7:10
8

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

Improve this answer
1
  • yeah I definitely resubmitted the site via Google Webmaster Tools, and it seems "cleared" now.
    – Jeff Atwood
    Commented Jun 11, 2011 at 0:38
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

Improve this answer
5

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

Improve this answer
1
  • 5
    I doubt it had to do with not updating WordPress (although it is possible, it's just not probable). WordPress itself is almost never the exploit vector. The usual vectors are insecure host configuration, and stolen FTP credentials.
    – Chip Bennett
    Commented Jun 10, 2011 at 16:03
4

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!

Improve this answer
4

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. :)

Improve this answer
3

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/

Improve this answer
2

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

Improve this answer
2

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.