Have I been hacked? Username: “amin”

Just FYI:

For file permissions on RackSpaceCloud look to https://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.

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

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

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.

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

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

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,

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 https://onlinelinkscan.com/ or https://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

Update: Just removed a malicious code entry from a 404.php file and discovered the root directory of one of our websites (e.g. https://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.

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

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

Here’s my revised plugin for Rackspace customers:

https://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?

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

Also – forgot to ask – the permissions your plugin suggest, I presume they’re best practice as suggested in https://codex.www.ads-software.com/Hardening_WordPress ??

Thanks,

M

@mchriston

<p>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!</p>

These options remove all access to your files for everyone and optionally the group. Since PHP runs as the file owner on Cloud Sites, this allows the install to still function.

These permissions are more restrictive than those prescribed in the link you reference, which allow others and members of the same group to see your files.

Hope that helps.