@axelf78 I haven’t found anything anywhere yet either.
@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.
@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.
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.
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/
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
I’m a little late in responding, but as you may have guessed, I am also on The Rackspace Cloud.
What a nightmare. 🙁
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…
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/
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.
@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.
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.
I’ve about 8 of sites (AFAIK) with this issue on RackspaceCloud, I’m digging on it right now.
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.
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”!
