WordPress.org

Ready to get started?Download WordPress

Forums

Media Temple oeaou hack (72 posts)

  1. UseShots
    Member
    Posted 3 years ago #

    @entilza72: I'm not a MediaTemple customer and don't know details of their platform.
    http://weblog.mediatemple.net/weblog/2010/08/06/security-facts/
    In this post they say:

    Vulnerable customer software (blogs, CMS, PHP apps) give attackers access to view and steal database passwords from application configuration files...

    I'm not sure what they exactly mean so just trying to isolate the issue and check whether wp-config.php permissions are to blame. That's why I ask to share permissions of these files on hacked sites.

    By the way, 500 is not read/write. It is read/execute. Read/write is 600.

  2. libertyvid
    Member
    Posted 3 years ago #

    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=\"http://ae.awaue.com/7\"></script>', ''), '<script src=\"http://ue.oeaou.com/31\"></script>', ''), '<script src=\"http://ie.eracou.com3\"></script>', ''), '<script src=\"http://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;

  3. Ankantoiel
    Member
    Posted 3 years ago #

    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.

  4. dsomar
    Member
    Posted 3 years ago #

    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 http://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.

  5. xyclopsoft
    Member
    Posted 3 years ago #

    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.

  6. jakobud
    Member
    Posted 3 years ago #

    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:

    http://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.

  7. UseShots
    Member
    Posted 3 years ago #

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

  8. jakobud
    Member
    Posted 3 years ago #

    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:

    http://api.wordpress.org/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?

  9. xyclopsoft
    Member
    Posted 3 years ago #

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

  10. xyclopsoft
    Member
    Posted 3 years ago #

    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.

  11. mdhenshaw
    Member
    Posted 3 years ago #

    I ran this:

    UPDATE wp_posts SET post_content = replace( post_content, '<script src="http://ao.euuaw.com/9"></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:
    http://mdtm.pl/dtZoR2

    For security-related resources specific to this issue, please go here:
    http://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 (http://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:
    http://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:

    http://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.

  12. UseShots
    Member
    Posted 3 years ago #

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

  13. Joshua Martens
    Member
    Posted 3 years ago #

    I use Media Temple too and have been hacked with this code on the bottom of every post and page: <script src="http://ao.euuaw.com/9"></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?

  14. nmmt
    Member
    Posted 3 years ago #

    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:
    http://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:
    http://sucuri.net/malware/entry/MW:JS:222
    http://sucuri.net/malware/entry/MW:RKS:3
    http://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: http://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:
    http://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:
    http://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:
    http://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

  15. brmecham
    Member
    Posted 3 years ago #

    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.

  16. nmmt
    Member
    Posted 3 years ago #

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

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

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

    Hope this helps.

  17. Armando Duran
    Member
    Posted 3 years ago #

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

    I tried the script suggested by MT here: http://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.

  18. Mike Rouse
    Member
    Posted 3 years ago #

    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.

  19. Armando Duran
    Member
    Posted 3 years ago #

    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.

  20. UseShots
    Member
    Posted 3 years ago #

    @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:
    http://www.unmaskparasites.com/malware-warning-guide/

  21. nmmt
    Member
    Posted 3 years ago #

    @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:
    http://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 security@mediatemple.net.

  22. joeyk
    Member
    Posted 3 years ago #

    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.

  23. frescova
    Member
    Posted 3 years ago #

    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?

  24. frescova
    Member
    Posted 3 years ago #

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

  25. kegill
    Member
    Posted 3 years ago #

    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?

  26. UseShots
    Member
    Posted 3 years ago #

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

  27. Dean Kirkland
    Member
    Posted 3 years ago #

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

  28. nmmt
    Member
    Posted 3 years ago #

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

    http://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.

  29. parisvega
    Member
    Posted 3 years ago #

    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.

  30. xyclopsoft
    Member
    Posted 3 years ago #

    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.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.