Support » Fixing WordPress » Media Temple oeaou hack

  • Hi,
    I looked in one of my pages today and now all of a sudden all my pages and posts have <script src=”″></script> when you view the page in the HTML.

    Was my site hacked or was this put in here by a plugin?

Viewing 15 replies - 31 through 45 (of 71 total)
  • 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 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}’ -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}’ -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=\"\"></script>', ''), '<script src=\"\"></script>', ''), '<script src=\"http://ie.eracou.com3\"></script>', ''), '<script src=\"\"></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 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:
    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:

    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:

    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=”″></script>’, ‘ ‘)

    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:

    For security-related resources specific to this issue, please go here:

    (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 (

    You may visit this link for additional information on recovering from a site compromise, as our actions may not have resolved all cases:

    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:

    If you require the assistance of a support agent please update this support request through the AccountCenter at

    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=”″></script> 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:

    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:

    If you look to the right of those pages, you can see a wide variety of exploits that 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:

    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:

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

    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:

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

    Hope this helps.

Viewing 15 replies - 31 through 45 (of 71 total)
  • The topic ‘Media Temple oeaou hack’ is closed to new replies.