WordPress.org

Ready to get started?Download WordPress

Forums

Have I been hacked? Username: "amin" (64 posts)

  1. Axelf78
    Member
    Posted 4 years ago #

    I just found 'AMIN' user with admin privileges in my WP as well. I also host with Rackspace Cloud. Luckily I can not find any code anywhere yet. So it's possible I caught it early.

  2. w8lifter2000
    Member
    Posted 4 years ago #

    @axelf78 I haven't found anything anywhere yet either.

  3. Axelf78
    Member
    Posted 4 years ago #

    @w8lifter2000
    What steps have you taken to lock down your WordPress? I just changed all passwords and installed WP Firewall.

    Have you posted in the Rackspace Cloud forums yet? If you haven't, please consider doing so.

  4. w8lifter2000
    Member
    Posted 4 years ago #

    @axelf78 I have installed wp-security scan, secure-wp, askapache password protect, locked down wp-admin with htaccess, installed secret key, copy the db table over to a new db with WP Table Rename and I reset all the permissions on the root folders to 755. I am as well researching additional methods. I found a site for a commercial plugin called wpsecurity.net which claims to offer tons of various protection. I am on the forums as well with RS.

  5. w8lifter2000
    Member
    Posted 4 years ago #

    I as well changed the ftp, mysql and wp admin passwords. I will probably go a step further and replace all wp core files. I honestly can't find anything in the dbs though. I started working on catching this though about 5 days ago when I first mentioned it to RS. So I stayed up all night applying security measures.

  6. UseShots
    Member
    Posted 4 years ago #

    Hi guys,

    I spent a week end investigating this issue and have gathered quite a few information about it (this thread was very helpful).

    I checked many RackSpace IPs and majority of WordPress blogs on those IPs were affected by this problem. (I only checked for injected scripts in the recent blogposts).

    You can clean up your sites but hackers will reinfect them unless RackSpace indentify and close the security hole. That phpMyAdmin vulneravility could be an initial vector of the attack. RackSpace had upgraded their phpMyAdmin nodes yesterday. However the question is: did hackers create enough backdoor scripts and rogue users in RackSpace databases to continue the attack. I guess will find it out soon.

    You can read more about my investigation here:
    http://blog.unmaskparasites.com/2010/06/14/attack-on-wordpress-blogs-on-rackspace/

  7. Axelf78
    Member
    Posted 4 years ago #

    The status blog shows they did a phpadmin update. Hopefully that fixed the issue. Only time will tell now.

    http://status.mosso.com/2010/06/emergency-phpmyadmin-maintenance-ongoing.html

  8. Cartman
    Member
    Posted 4 years ago #

    I'm a little late in responding, but as you may have guessed, I am also on The Rackspace Cloud.

    What a nightmare. :(

  9. w8lifter2000
    Member
    Posted 4 years ago #

    So I don't know if anyone noticed this. The /www.yoursite.com and /www.yoursite.com/web and /www.yoursite.com/web/content were all chmod 777 by default. I know this because wp security scanner made suggestions to change these permissions before all the blog postings started. I know because I started this a few days ago. Now all of a sudden as I'm applying fixes to sites now that were not so critical...the content directory is now 755 on every site I go to work on. Interesting...

  10. thors1982
    Member
    Posted 4 years ago #

    Our wordpress sites on Rackspace Cloud were also compromised. All our wordpress blogs had a "amin" user. Also noticed by looking through the database none of those users had a user_registered date, I also found one user called "WordPress" that didn't have a user_registered date either. Which was weird... so I just deleted that user. Some of you may want to check for that as well.

    I haven't found any modified files or scripts in my posts however. If anyone else finds something let us know so we can all look.

    This link may help a few of you as well, because he is saying they put an option in wordpress that auto loads itself every page load.
    http://smackdown.blogsblogsblogs.com/2010/06/14/rackspace-hacked-clients-check-your-databases-wordpress-wp_optimize-backdoor-in-wp_options-table/

  11. pkchrisjohnson
    Member
    Posted 4 years ago #

    After going back through our weekly backups on a WordPress site I maintain, I found that the Amin user was present as far back as May. Our backup that went through on the 17th was the first that did not contain that user account.

    After calling Rackspace, they seemed to think that it was a plugin vulnerability but I didn't have that many plugins. Here is what I had installed, though (btw, these plugin names come from the folder name on the server, and may differ from the "actual" plugin name):
    Akismet (disabled)
    Calendar
    Disqus Comment System
    Google Analyticator
    Google Sitemap generator
    Optimize-db
    Share-This
    WP-Db-Backup
    WP-no-category-base
    WP-Print
    WP-Security Scan
    wptuner
    hello dolly (disabled)

    I did not see any bad code on the site but the "amin" user has been present for about a month.

  12. thors1982
    Member
    Posted 4 years ago #

    @pkchrisjohnson
    From what I have gathered the user amin was added to all our sites on May 20th. Also if it helps the only plugins we have in common are

    Akismet (also disabled)
    Google Analyticator

    Not that I think it will help at all its clearly a vulnerability in phpmyadmin that rackspace just won't fess up to.

  13. Jackson
    Member
    Posted 4 years ago #

    If you're dealing with this, you may want to scan your wp_options [1] and wp_posts table:

    SELECT * FROM XX_options WHERE (option_id LIKE '%base64_decode%' OR blog_id LIKE '%base64_decode%' OR option_name LIKE '%base64_decode%' OR option_value LIKE '%base64_decode%' OR autoload LIKE '%base64_decode%' OR option_id LIKE '%edoced_46esab%' OR blog_id LIKE '%edoced_46esab%' OR option_name LIKE '%edoced_46esab%' OR option_value LIKE '%edoced_46esab%' OR autoload LIKE '%edoced_46esab%' OR option_name LIKE 'wp_check_hash' OR option_name LIKE 'class_generic_support' OR option_name LIKE 'widget_generic_support' OR option_name LIKE 'ftp_credentials' OR option_name LIKE 'fwp' OR option_name LIKE 'rss_%') order by option_id

    SELECT * FROM wp_posts WHERE (post_content LIKE '%base64_decode%' OR post_content LIKE '%<script%' OR post_content LIKE '%edoced_46esab%' OR post_content LIKE '%visibility:%' OR post_content LIKE '%display:%' OR post_content LIKE '%<iframe%'
    )

    You may also want to look at wp-malwatch and exploit-scanner to locate leftover hack files from the pharma attack - http://www.pearsonified.com/2010/04/wordpress-pharma-hack.php

    If you're on CloudSites, you can ask support to generate a list of all files and folders with world writable permissions. Study that list and evaluate every file. The .bak, .cache, .old crap etc files hide randomly, not always in the first plugin. Sometimes buried deep.

    At the end of the day nothing beats a fresh install and re-uploading your wp-content items from a known safe copy.

    [1] http://smackdown.blogsblogsblogs.com/2010/06/14/rackspace-hacked-clients-check-your-databases-wordpress-wp_optimize-backdoor-in-wp_options-table/

    Good luck to anyone dealing with this, I wouldn't wish it upon my worst enemies.

  14. sfranchi
    Member
    Posted 4 years ago #

    I've about 8 of sites (AFAIK) with this issue on RackspaceCloud, I'm digging on it right now.

  15. WraithKenny
    Member
    Posted 4 years ago #

    the hack alters (writes to) plugins and themes. Blaming it on a plugin or theme at this point is crazy, since after infection any plugin could have the code. default was hacked in one install, and in another a completely custom theme that I wrote. Akismet was hacked in one install, a zip written to a theme's image folder, the main index.php was hacked on one... Database entries including the firstname field of cloned users, post entries, and options meta have been affected. This thing is all over the place.

  16. mchriston
    Member
    Posted 4 years ago #

    Having received a support email from Rackspace last night, I've spent the whole day working through my sites and chatting with RS.

    Yes, I'm a CloudSite customer. In fact we have a bunch of WP sites on CS.

    The RS email told me they had removed "Amin" from about 12 of our sites and suggested I take steps to make sites more secure. Naturally I contacted them and asked "What's *actually* going on?"

    They claim the situation has NOTHING to do with them and that the only commonality they are finding between hacked sites are files and directories with 777 permissions...

    However, my own situation proves this wrong. Yes, there were some files/directories like that BUT not *all* of the hacked sites were 777 examples... and neither were all the 777 examples hacked (according to this list RS gave me in their email)! In other words, RS's supposed common link is not a link at all!!

    They said they are working on a support article to explain what to do and will be released soon - but admitted they haven't done this yet as they are not entirely sure what is going on!

    Also - I now have even less faith in their abilities as having read this forum I see that the "Amin" problem has been around for a couple of weeks and RS only alerted customers like myself in the last 24hrs!

    Like others on this forum, I am going through all accounts changing passwords etc. And I have been scanning the DB tables as well... finding only one instance so far in wp_options. The random nature of this attack is proving a HUGE headache!

    But here's my question: When chatting with RS they suggested that if a hacker could get in via a 777 open file/directory they could not only get access to that site but also ALL sites on that CloudSite account. Now please tell me it's not that easy?! ...because that has to be the mother of all security "glitches"!

  17. WraithKenny
    Member
    Posted 4 years ago #

    Just FYI:

    For file permissions on RackSpaceCloud look to http://cloudsites.rackspacecloud.com/index.php/File_Permissions

    Note that permissions are different then the default WP install permissions, where in XYZ, Z should almost always be 0.

  18. Jackson
    Member
    Posted 4 years ago #

    Here's a dirty little plugin for WordPress users on CloudSites.

    Use at your own risk. Upload, activate, and visit new menu item. Can remove all world and group permissions. Search options table for backdoors, and posts table for spam links. Also looks for *.bak.php, *.old.php, and *.cache.php files and displays a listing of all files for review.

    Far from perfect, but maybe it helps someone?

    Download jw-wp-scanner 2.0

  19. Jackson
    Member
    Posted 4 years ago #

    Here's an interesting report from the CloudSites trenches:

    One of my databases that had wordpress in it got popped. The weird part is I don't even have wordpress installed on that site any more.. like the directory does not exist. I just sort of forgot the database being there. That means there were no files that contained the database password hosted anywhere. Can someone from RS please tell me how my non-existent wordpress frontend was compromised to modify my old database?

    Whaaaaaat????

  20. UseShots
    Member
    Posted 4 years ago #

    Good point madjax.

    Let's think about how hackers could write into WP tables.

    1. The could steal database credentials from wp-config.php files if they are world readable. What are the permissions of the wp-config.php files on your compromised sites? (they should be 600)

    2. Hackers could built backdoor code into WP files (including themes and plugins). When executed in WP context they have access to WP database. But in this case hackers need write permissions for your files. (Could you check the permissions of compromised files?)

    3. Hackers could have "root" access to the whole mySql database (e.g. attacking some RS tech via that myPhpAdmin vulnerability, or some via some other attack). This way they can do whatever they want with every WP database on the compromised server. This can explain how that old WP database without a real WP front end (so no wp-config.php to steal passwords from and no WP files to build backdoor code into) was compromised.

    Any other ideas?

    P.S. Please post your wp-config.php permissions. I wonder if at least some of them are not world readable.

  21. Jackson
    Member
    Posted 4 years ago #

    My wp-config files are set at 600, with sites organized into client folders and permissions for the web/content folders at 700.

    The whole situation really rots, and puts Rackspace in an uncomfortable space with their customers.

    "These attacks are exclusive to accounts with WordPress ONLY; accounts that do not have WordPress installs were left untouched. Until we discover an attack vector that was due to our environment, this will be handled as a WordPress exploit."

    I'm really, really interested to hear Rackspace's answer as to how a abandoned WP database with no front end or wp-config.php file could be compromised. I can hear the answer now... 'scan your workstation with anti-virus software'... which is not bad advice - but something is clearly fishy here - no?

    People have been miserable with this all week and so far Rackspace has ducked and dodged the issue - at the same time, they have taken it upon themselves to scan databases for the 'amin' user and notify the account holders - which was very nice of them and all, but why would they do that if this was a WordPress exploit and outside their scope of responsibility?

    And, if this was indeed a permissions issue - why wouldn't code be injected into static HTML files as we've seen done previously?

    I really just want to get back to my life. Woke up this morning to a new Sucuri alert of spam links inserted into a footer.php file. So sick of this!

    At this point it seems Rackspace + WordPress = Misery : (

  22. UseShots
    Member
    Posted 4 years ago #

    >These attacks are exclusive to accounts with WordPress ONLY

    I guess that hackers know WordPress well enough to make it their target. Moreover, it can be compromised via DB

    1. They know where in database to insert a malicious code so that it is executed when visitors view web pages.
    2. They know how to create a WordPress account via direct database writes.
    3. They know how to use that account to modify WordPress theme files (WP built-in theme editor can modify files with 600 permissions because PHP scripts are executed with their owner permissions)

    Summary:

    • The attack vector is mySql database. It looks like hackers don't steal individual DB passwords - they just have a "root" (or similar) access.
    • Change your theme files' permissions to 400 (I guess, you don't modify them yourself every day)
  23. affiliatedoctor
    Member
    Posted 4 years ago #

    When chatting with RS they suggested that if a hacker could get in via a 777 open file/directory they could not only get access to that site but also ALL sites on that CloudSite account. Now please tell me it's not that easy?! ...because that has to be the mother of all security "glitches"!

    We have had over 20 WP sites hacked on RackSpace and over 15 non WP sites have been deleted, there was even a domain bought through RS on our account as well on the 16th.

    RS denies the incidents are related, saying that our password on the CP was compromised. We said BS, how coincidental all occred in the same timeframe. We have a major headache on our hands and am wondering if anyone else in the community has had non WP sites hacked or deleted?

    Thanks,

  24. mchriston
    Member
    Posted 4 years ago #

    Hey all,

    This is a long post designed to help people suffering with the WP/RS fiasco!!

    Well on Thursday we worked for 16 hours on this and discovered several key things, but we still don't know if this is everything. All of this information has been passed to Rackspace:

    Observations:

    1 - The attack exploited 777 permissions to drop hidden php files into directories. This was done in pairs, so each site attacked has two files hidden in the directories, which can be *any* directories.

    <Quick friendly disclaimer: Please remember this is what we have found so far... so it may be there is more to this hack/exploit than we found>

    2 - Also, 'dormant' code (will explain this in next point) inserted into wp_options table in WP database of that site. On all cases found it was the last entry on the table and had option_name rss_f541b3abd05e7962fcab37737f40fad8 and option_value was a string of code including Base64 starting with s:65065:"O:9:"MagpieRSS":19:{s:6.... etc

    3 - The two hidden files then work with the dormant code in the table. The first decodes and triggers the dormant code to run, end result is a shell created at what looks like root level on your server (i.e. once created hacker can do whatever he/she wants!) The second file seems to create a file listing all server details, though it might have more functionality as decoding it proved very tricky.

    4 - Best guess is the combination of files is setting up a larger attack which would be some kind of denial of service

    5 - The most worrying thing is of course... Once files are removed (see below) is the shell still there? For our sites, at the moment we don't know!

    Solution for above:

    This is what we did....

    First get your websites scanned for 777 directory "holes", if you find one you will find another (but more than likely only two... which I'll come back to in a minute). In EACH of those two directories and with "show hidden files" on, you will find a .php file hidden. Delete these.

    Second, goto database of same website with 777 holes and run query on wp_options table

    SELECT * FROM wp_options WHERE (option_id LIKE '%base64_decode%' OR blog_id LIKE '%base64_decode%' OR option_name LIKE '%base64_decode%' OR option_value LIKE '%base64_decode%' OR autoload LIKE '%base64_decode%' OR option_id LIKE '%edoced_46esab%' OR blog_id LIKE '%edoced_46esab%' OR option_name LIKE '%edoced_46esab%' OR option_value LIKE '%edoced_46esab%' OR autoload LIKE '%edoced_46esab%' OR option_name LIKE 'wp_check_hash' OR option_name LIKE 'class_generic_support' OR option_name LIKE 'widget_generic_support' OR option_name LIKE 'ftp_credentials' OR option_name LIKE 'fwp' OR option_name LIKE 'rss_%') order by option_id

    If you have the 777 holes then you are going to find the entry mentioned before which begins "rss_f541b3..."! This was same in every instance on our sites. Delete this row of the table.

    Thirdly, and just to be safe, change passwords etc for database.

    Of course, if you have several sites on your RS CloudSite... then check all. RS will give you a list of 777 holes on request via their LiveChat support.

    Once complete and again just to be sure ask RS for another 777 report and run something like http://onlinelinkscan.com/ or http://www.unmaskparasites.com/ on your site(s). Any sites we were more concerned about or simply were unable to change (e.g. one of our sites did not allow us into the WP dashboard) we deleted entirely.

    Just so you know, a senior RS techie in their security team has since confirmed that we had done a good job of minimising the risk to our sites and clearing up the hack.

    Now let's talk about Rackspace...

    I have been kicking ass with RS as we believe this cannot be purely a user WP issue. My reasoning is simple and logical, and I think it beats any nonsense 'techie' or 'human error' argument RS had suggested:

    1 - I like to make sure I don't leave 777 holes on our sites! But hey, let's call it human error just in case, so........

    2 - Human error is naturally random. So if you were going to have the occasional 777 hole through human error, then you would expect random distribution across sites. In other words, some sites have one hole, some have two, others may have three...... What you don't expect is exact and even distribution where each affected site has exactly two 777 holes and all other non-affected sites have no 777 holes whatsoever. That is not human, that is 'mechanical' - it is just like you'd expect from a program DESIGNED to create the 777 holes.

    <This is not conspiracy, this is just logic!>

    3 - The 777 holes were on plugin folders and sub-folders. But, at my company we keep an up-to-date backup of the standard plugins we always use. And everytime we load a site we ftp these plugins into the new site. So why is it that one site has a 777 hole in the directory of one of these plugins, but the same directory (from the same source) does NOT have the same hole? Again, the conclusion would be that the 777 holes must have been created by

    something other than the user (and not human error)

    So in conclusion...

    So following the logic - The 777 holes which are required in order to create this exploit must have been CREATED rather than accidental. Now if they were created then it is fair to ask did it happen from the inside?

    Guys, hope this helps. But please remember, I'm not claiming this is everything or that we are experts on what happened. This post is just what we found, what we did and what believe is likely behind the attack.

    As it stands at this very point in time, we are still waiting for confirmation from RS that all is well - for example, the malicious shell which is created by the hack, has it been removed? ...because as a CloudSite user you don't have enough server access see whether it has or it hasn't.

    Again, hope this helps.

    Michael

  25. mchriston
    Member
    Posted 4 years ago #

    Update: Just removed a malicious code entry from a 404.php file and discovered the root directory of one of our websites (e.g. http://www.abc.com) was not configured for 770 permissions (again this must be because of the hack).

    So, this is indeed STILL ongoing despite everything above!

    BUT... RS have helped with the above. It was they who spotted these two extra problems ...So it would seem pushing them hard does work.

  26. UseShots
    Member
    Posted 4 years ago #

    @mchriston: Please monitor your sites for at least a couple of days. This is the hack that returns.

    If it returns, check your file and directory permissions again.

    P.S. I hope you've changed passwords anyway.

  27. KatePhiz
    Member
    Posted 4 years ago #

    I have the same problem on a different host but it's possible they are a reseller for the RS cloud.

  28. Jackson
    Member
    Posted 4 years ago #

    Here's my revised plugin for Rackspace customers:

    http://jacksonwhelan.com/2010/06/cloudsites-wordpress-scanner/

    The newest version will look for and allow you to delete hidden files directly, as well as any offending options from the table.

    It will also allow you to change your permissions with one click recursively.

    It does not look for the 404.php file, but does provide a complete listing of all your files to peruse for rogue entries.

    Hope it helps.

    @mchriston - can you post the code from your 404.php file?

  29. mchriston
    Member
    Posted 4 years ago #

    Hi Madjax - Sorry mate, it was deleted without taking a copy of the code. From what I remember (and was told by Rackspace) it was set to allow re-entry into site whenever required by Hacker. The only code snippet I remember was references to cookies.

    Quick question on your plugin - It all looks great, but wondering why you have the following...

    The Others: Click here to remove rwx for other (chmod -R o-rwx) from all files and directories. This cannot be undone!
    The Group: Take it to the next level? Click here to remove rwx for group (chmod -R g-rwx) from all files and directories. This cannot be undone!

    What's this about?

    Thanks,

    Michael

  30. mchriston
    Member
    Posted 4 years ago #

    Also - forgot to ask - the permissions your plugin suggest, I presume they're best practice as suggested in http://codex.wordpress.org/Hardening_WordPress ??

    Thanks,

    M

Topic Closed

This topic has been closed to new replies.

About this Topic