Site infected by variant of osCommerce vulnerability attack

[Pond]

I have a client's site running Website Baker 2.8.1 which I have found out by accident appears to have an extensive malware infection.

• http://sucuri.net/malware/malware-entry-mwjs1240
• http://malware.im/blackhole-defs_colors-and-createcss-injections/
• http://www.google.co.uk/search?num=20&hl=en&safe=off&client=safari&rls=en&q=div_pick_colors&aq=f&aqi=&aql=&oq=

It seems to be a variant of an osCommerce hack which, as far as I can make out from the poor quality information online, uses a vulnerability in osCommerce to infect sites. The Website Baker site in question is running on 1&1's shared services and have correct '644' permissions with files owned by the web server - even an FTP session cannot overwrite or modify files written by the Website Baker web server process. This means that an external FTP hack is almost impossible. There are two possibilities I can see:

• Someone found an admin password but rather than commandeer the site, just decided to infect some of its pages (unlikely!)
• There is a live, unpatched, exploited vulnerability in Website Baker or one of its modules

The server side infections consist of additions to the PHP files in the 'pages' folder which Website Baker writes. If I create a new page, the infection is absent and date stamps on infected files are very similar (there are two distinct dates so it looks like infections occurred in batches on those two dates).

This is clearly an extremely serious situation. I don't know much about the malware, I don't know where I should be looking to find out more, I'm not sure how to clean up the site and, most seriously, I don't know what the attack vector is but given the osCommerce attack similarity it looks like it might possibly be a vulnerability within the PHP code itself. In any event, even if I cleaned up all the files on the site, it would be a matter of time before it got infected again if the underlying vulnerability - whatever it might be! - is not patched.

Anyone have any ideas? Anyone else seen this? Anyone dealt with it on other sites not necessarily using Website Baker?

Thanks!

[Pond]

Further information: It looks like it's simpler than I thought. A couple of subdirectories in the 'media' folder have 777 permissions - world writeable. And that's that - a malicious file called "msl.php" contains all the infection code and this has been uploaded into that folder (along with a bunch of other crud). Presumably all that needs to be done is to then visit the PHP file in a web browser to have the server run it & (re-)infect pages.

Directories created from within the media browser do have the correct '755' permissions so the incorrect permissions must have been introduced in some other way.

I've attached the malicious "msl.php" in a Zip file (DO NOT RUN THIS!) for anyone who's interested in studying how it works.

[kweitzel]

OK ... is it clear already how this file was "put" onto the infected Webspace? Are there maybe osCommerce sites on the same server which could have spread the infection onto that webspace? At the end this can only be investigated by 1&1 if it happened via a different Webspace.

cheers

Klaus

[Pond]

Yeah. Unless the 777 permissions are a red herring and there was actually a different attack vector used, then as you say, someone had to already be elsewhere on the filesystem to get those files there.

Oh and I made a mistake - this particular client is on XCalibre, not 1&1. The complication there is that their FTP and Web server processes use different UNIX user names. I asked support to sort that out when the site was first installed; you upload website baker by FTP and the Web server can read things, but not write anything, so nothing works - files can't be created in the 'pages' folder etc. etc. because they're all owned by the FTP server user not the Web server user. It's a right mess. Their solution, it seems, was to set world writeable permissions (!) - so here we are.

I have opened up a technical support ticket with them. I hope they are more aware of security now than they were last time and that I manage to get a competent support person dealing with the request!