mchriston

Thanks @madjax…

Just wondering:
Are you staying with Rackspace or are you going elsewhere? If so, where?

That question is open to everyone by the way!

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

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

Quick question: My Link Order does not seem to do the re-ordering on WP 2.8.6?

(but My Page Order works fine)

Is there still a fix? I’m using Version 2.8.7

Thanks,

Michael