Media Temple oeaou hack

I have the same issue on most of my WP sites.

I tried the script suggested by MT here: https://wiki.mediatemple.net/w/WordPress_Redirect_Exploit but that didn’t work, the one address that the script was pointing to was a.auoo.info/in1.php?n=508101 but even though I tried searching and replacing for that one didn’t work.

What I then realized is that there was some code added in the footer of all pages, I commented wp_footer(); on footer.php and that seemed to remove it, yet still would like to know where else in my WP files the script is injected.

Media Temple has been good in responding to my Support submissions but I think this is an issue that I’d like to know the cause of it very soon.

I am with MediaTemple and have suffered with this problem too. They are right, however, that CHMOD permission was the weak link for my sites. I thought they were locked down but must have overlooked them. It’s a pain in the neck, but I’ve had similar issues with other providers too.

Doing a find and replace SQL script on the affect sites has taken out the malicious code. Changed passwords, double-checked CHMOD permissions. Hopefully that will keep us going until the next exploit.

I just found this post:

WordPress exploit: we been hit by hidden spam link injection

If the script was injected on your footer or header (as in my case), the quick fix so that at least your site doesn’t redirect is this:

How to solve this?

Once you realized your site been exploit, what you must have in your mind is upgrade your WordPress, and removes the infected files. There is a fastest way to temporary stop the spam injection. Removes wp_footer() and wp_head() hook from your themes. The hook should be store in footer.php and header.php.

Removes footer and header hooks does not really clean the affected files, but the spam links will disappear if you check with curl again. This doesn’t really solve the problems.

@nicholas and MediaTemple webmasters:

mdhenshaw has quoted MT response about how they cleaned compromised websites. This response contains incorrect information about removing Google’s malware warnings.

I’d like to correct this misconception.

1.) Patiently wait for the removal of the Google alert. The Google warning will subside once Google re-crawls/re-indexes your site.

In reality, site crawling/indexing is not connected with malware warnings. There are malware scanners with their own schedule. If you don’t request a malware review via Webmaster Tools, your site may remain blacklisted for weeks. So request a malware review ASAP!

https://www.google.com/webmasters/tools/reconsideration?pli=1

This link is also incorrect. This reconsideration review has nothing to do with malware review. Using this links is a way to delay site unblocking.

The malware review link is in your Google Webmaster Tools account on the “Malware” page of the “Diagnostics” section. If you use this link and your is really clean, it will be unblocked within a day (usually).

@nicholas: I hope you can correct your support staff so that they don’t misguide your clients.

You can read more about dealing with Google’s malware warnings here:
https://www.unmaskparasites.com/malware-warning-guide/

@useshots: Thank you for the feedback. I think that our statement regarding the Google warnings and your perspective are actually similar, but perhaps there are one or more semantic distinctions. We certainly apologize for any confusion.

Regarding the first point, the “number 1” that you have placed in the box above, we did not mean that simple web crawling/indexing is identical to a re-analysis of site content for malware. We were trying to put that into general terms. Regardless, if a site is cleaned up, the malware/suspicious site warning from Google should go away on its own in time.

Thank you for clarifying the difference between a “reconsideration review” and a malware review. Ultimately, we are suggesting to any affected clients that they utilize Google’s Webmaster Tools to request a de-listing once sites are cleaned up.

Lastly, we have also made reference to the unmaskparasites.com article on several occasions and have linked to the site here:
https://wiki.mediatemple.net/w/%28mt%29_Security_Resources

As you can imagine, anything that is helpful to our customers is of interest to us.

For any customers who are interested in discussing security at (mt) Media Temple, you are welcome to submit a support request, to call 877-578-4000, or to email our security team directly at [email protected].

I manage around 100 WordPress sites across numerous hosting companies: GoDaddy, HostGator, 1&1, Dreamhost, you name it. The installations stay up to date and run all kinds of plugins and theme variants.

Out out all these sites the only times they’ve been hacked is with Media Temple’s Grid Service (on two accounts to boot!). First a few months ago and now this.

Try searching Twitter, Google, and these forums for this hack and you’ll find one thing in common: Media Temple.

How could any reasonable person buy their argument of it having nothing to do with their services? At the very least hackers are specifically targeting Grid Service accounts.

It’s worth noting on one of my GS accounts none of the sites are indexed in search engines. I use robots.txt and just use the WP installations for testing and showing sample work to clients.

Yes their customer service is excellent – they’ll even clean up your sites for you. Even their Dedicated Virtual service is fine – I’ve never had and problems there!

However for their Grid Service I just want to pay my monthly fee, not worry about sites getting hacked all the time, and leave it at that.

They need to do better than pointing the blame at us and trying to upsell us on their Sucuri affiliate program.

I’m on MediaTemple as well and just discovered this exploit on one of my sites – trying to fix it, but the sql query provided is doing nothing – always get a 0 rows affected result – I know the code is there because when I go to edit random posts I see it.

Any other fix?

Operator error – sql query fixed it – all of the 20+ sites I manage were affected – all on MediaTemple GS servers…

I have four WordPress installations on MediaTemple.

I ran the MT SQL script for wp_posts and the MT SSH script (which is missing one of the four URLs, btw).

According to the SSH script, only two sites needed disinfecting — but one of the sites “disinfected” is still viral, according to Sucuri.net, and one of the sites that the SSH script skipped is also still viral. Both “clean” sites are .orgs. Both “dirty” sites are .coms. Probably no coincidence.

I remain POed that the first form letter response that I got from MT (21 hours after filing the ticket, btw) made it sound like I was all alone with this problem.

This is my first “hack” and I am less than thrilled with MTs trying to blame this problem on ME. My passwords are secure. My sites are up-to-date. I have minimal plugins. And I’ve not touched the DB permissions, passwords, etc. or the wp-config.php files (until today). If the DB security is “weak” it’s because MT made it that way with the one-click install.

My adventures: I’ve Been Hacked. I guess this makes me an adult now?

@nicholas: When dealing with malware warning even Google’s own documentation is not clear enough and many webmaster make false assumptions about how Google unblocks sites. As a result many clean sites remain blacklisted for weeks!

The most usual mistakes are:
1. waiting for warning to automatically go away (even if Google’s malware scanners find a site clean during a next scheduled scan, without explicit review request from a webmaster, they’ll leave it in their blacklist for at least one more round to make sure the change is permanent)
2. Using incorrect requests. Many people know that they should request Google to re-check their sites and for some reason find the “site reconsideration request” mentioned in (mt) response. This request deals with SEO problems (e.g. site removed from google’s index or penalized for black-hat tricks). Sometimes it takes several weeks before people realize they should have requested another review in another place.

That’s why it is important to provide as clear and detailed instructions as possible.

@kegill: What exactly sucuri reports for your “still viral” sites? The chances are they only report that your sites are still blacklisted by Google. In this case you should just request malware reviews via Google Webmaster Tools (Diagnostics -> Malware)

@nmmt thank you for getting in here and helping us out.

@useshots: Your feedback on the Google topic is much appreciated. After our earlier interchange, I did some additional research, and also made sure that clarification was shared both internally and externally. I found this URL to be helpful:

https://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=168328

@kegill: I believe that UseShots may be correct regarding some cases where sites are showing as “still viral” via Sucuri despite cleanup efforts. I believe that this is related to:

1) The Sucuri results will not auto-refresh instantly. There may be cache involved.
2) The Google warning, if still on your site, may play a role.

We will be looking into that more closely. Thank you for bringing it up. You can also reach Sucuri directly for clarification via Twitter (@sucuri_security) and they tend to be very helpful.

UseShots is also correct in that you will want to have Google do a malware review for your site as soon as possible (once it has been cleaned up).

@ Dean Kirkland: You are welcome. We are doing our best to provide quick and accurate assistance to any affected customers. This is of the highest priority to (mt) Media Temple.

After cleaning my database I was having a problem with the visual editors of all the sites that were affected by this hack. To fix the problem I put this

define('CONCATENATE_SCRIPTS', false );

at the bottom right before

require_once(ABSPATH . 'wp-settings.php');

and now everything works fine.

Thanks to this post for the fix.

This is my first “hack” and I am less than thrilled with MTs trying to blame this problem on ME. My passwords are secure. My sites are up-to-date. I have minimal plugins. And I’ve not touched the DB permissions, passwords, etc. or the wp-config.php files (until today). If the DB security is “weak” it’s because MT made it that way with the one-click install.

Even if your wp-config.php files were readable, they would have to be read inside the server somehow, not from a webserver.

Either:

MT failed somehow in making a bunch of FTP/MySQL passwords available
MT failed somehow in allowing php to be shut off, allowing the config files to be read via a browser
MT failed somehow in making the MySQL database available/writable
MT failed in some other way

This is absolutely not the fault of file permissions alone, and if MT don’t know this, they are incompetent, and if they do know it, they are shameful. Trying to upsell is even worse.

This particular vulnerability only affected MT users on GS accounts. I haven’t seen one other example with a different host, or even a different account with MT.

Blaming customers when it is very clear it could not possibly be the customers who are at fault is shabby and if I were the one who chose where these sites were hosted, it would quite literally be anywhere else.

@xyclopsoft:

I understand your concerns. Please know that (mt) Media Temple is doing everything we can to assist any and all affected clients. I would like to try to respond to your comments in more detail…

We did not make any passwords “available”, but we used to allow customers to see FTP/DB passwords in the AccountCenter in plaintext. FTP passwords were taken out of the AccountCenter at the end of 2009 and DB passwords were removed in early Spring of this year. Those were originally put there as a convenience and based on customer feedback. We have removed them and addressed all of that publicly. Also, as you probably know, passwords that are weak can be “brute-forced”, and that happens all the time, on all kinds of systems.

Exploits of this type are indeed happening on other hosts, and these types of redirects/includes/etc. are not unique to (mt) or our (gs) Grid-Service. In fact, php/javascript injections are incredibly common, and often go undetected. Here are some indicators:

https://sucuri.net/malware/entry/MW:JS:222
https://sucuri.net/malware/entry/MW:RKS:3
https://sucuri.net/malware/entry/MW:RKS:2

Other companies are mentioned if you look through the links above. Please see this post for detailed information on these exploits and where (mt) Media Temple is coming from:
https://weblog.mediatemple.net/weblog/2010/08/06/security-facts/

We are not blaming customers, and to be clear, we are not blaming WordPress either. Also, we have done much analysis on our end and have yet to find any indication that there is a vulnerability in our infrastructure.

On the other hand, via Sucuri.net and other means, we have found that out-of-date software is being used on the exploited customer services and is a source of site vulnerability. Take a look at this list of security advisories for older versions of WP:
https://secunia.com/advisories/product/6745/?task=statistics

Also, this was written by Matt Mullenweg (founding developer of WP):
https://www.ads-software.com/news/2009/09/keep-wordpress-secure/

This article was created to give users detailed steps on fixing an infected site:
https://wiki.mediatemple.net/w/Fixing_an_infected_website_-_(detailed_steps)

If you are an (mt) customer, please open a support request and we can look at the specifics of your account/services.