As you may know from our previous posts, we’ve been watching the willysy.com infection of millions of e-commerce websites over the past few weeks.

Now, it appears that many of these are still infected and the hackers have now changed the infection to:

hxxp://tiasissi. com .br/revendedores/jquery

What’s really frustrating from our perspective, is that these are so easy to prevent. To date, we’ve cleaned 1,179 of these infections and no repeat infections – our methods work!

With the willysy infections we’ve seen many entries in the admin section of the osCommerce database which shows that the hackers have taken total control of these websites and this is just the infectious code they prefer to use for now.

There are many different backdoor shell scripts the hackers are installing on these websites and code inserted into the payment processing files that allow the hackers to steal the credit card information as it gets processed.

This is all cleanable and prevention is quite easy.

Contact us to have your website cleaned or email me at: traef@wewatchyourwebsite.com

If you have questions about this, please leave a comment. We’ll respond promptly.

Thank you.

I realize we’re not the first to write about this, but my intention is not to be a ground-breaking news source, but for our readers, I hope to be at least educational.

We’ve been seeing more log files, ever since we’ve been beta testing our new log analyzer, with probes for fckeditor and also editormonkey. This has led us on a journey to see why.

What we found was that many people are using editormonkey, even though it’s been “shelved” for some time. This means, no updates, nobody to fix bugs or more importantly – no security patches.

Here is a screenshot from the Editormonkey website:

Screen shot from editormonkey website

For those of you unfamiliar with FCKeditor and Editormonkey, they work with various programs like WordPress, Joomla and other Content Management Systems (CMS), to provide a more robust writing platform.

These programs were designed to bring more text editing features to web based programs.

According to the CKEditor website:

The problem with any plugin, component, module, etc. is that they often times provide a file manager. A file manager for an editor is key so you can upload graphic files without leaving the editor. For instance, if you wanted to add a picture to something you’re writing about, you would upload it to your website and then insert into your text. A good editor will enable you to perform that task, without ever leaving the editor.

When you have multiple ways of uploading files to your website, you also introduce multiple exploits for hackers to abuse and infect your website.

Let’s see what is so bad about this.

First, let me begin by saying that if you follow our security principles, you’ll know that all software should be kept up-to-date.

ALL SOFTWARE!!!

Yes, that means even web based editors.

For older versions of FCKeditor, like 2.0 -> 2.2, this string is dangerous:

http://[target]/[path]/editor/filemanager/browser/default/connectors/php/connector.php

This allows an attacker to upload a file, like a backdoor shell script to the vulnerable website without any real “hacking” skills.

How would a hacker know you have this installed on your website?

Google is a hacker’s best friend. They can search using:

inurl:/editor/filemanager/browser/default/connectors/php/connector.php

And find websites that Google has indexed and found that string.

What can you do to prevent this?

I’m glad you asked.

First, you can update your software. As posted above, FCKeditor has been renamed CKEditor. Update immediately.

Next, you can also use “security by obscurity”. In your robots.txt file you specify what the search engines index on your website. Does the world need to know what plugins you’re using in your WordPress blog?

Probably not.

You can use something like this in your robots.txt file:

# Hide certain folders from spiders
User-agent: *
Disallow: /(path to your editor folder)

We’re not big fans of relying on security by obscurity so you should also locate the config.php file. It’s usually located here:

editor/filemanager/connectors/php/config.php

Open it with a text editor and search for the line that looks like:

$Config['Enabled'] = true ;

And change “true” to “false” (no quotes). That will disable that connector.

Other safety precautions you can take is to password protect the editor folder. Usually your hosting provider will have that option in their Control Panel for your account.

You could also delete the filemanager folder altogether. This eliminates the vulnerability completely.

If you absolutely have to upload files to your website via the editor, then I suggest you pick some area of your website to designate as an upload folder, but you should know that the permissions on that upload folder have to be set to 777 (world readable/writable). Again, you are warned not to do this.

In review, always use a multi-layered strategy for website security.

1. Keep all software updated – even editors
2. Hide folders from search engines
3. Hide folders by using password protection
4. Disable potentially vulnerable functions
5. Hire a good security company (like us!)

It’s rare for me to post twice in the same day, but I thought this one needed your attention.

In some infected osCommerce and WordPress sites we’ve been seeing this line of code:

< scr ipt snc=hxxp: // www. google-analytics.com/urchin.js id=googleanalytics>var emob = googleanalytics;var emsk = 126853 * 4;var emsp = googleanalytics.id.substr(1,0);var k = 1;var t = emob.innerHTML.split…(removed)< /scr ipt >

In the osCommerce sites it was in:

/catalog/includes/languages/english/define_mainpage.php

In the WordPress sites it was in:

wp-load.php

Usually at the end of a div tag in the body of the page code. This has been noticed more and more. It used to be that the malicious code was somewhere either in the beginning or near the end of the page code.

This code works by looking like legitimate google-analytics code, but notice that in the opening script tag, that’s not a src variable. It’s snc. Which looks at first like src, but it’s not.

What the code does is replace use the id variable and replace it with a different URL and then the code at the end of the malscript sets the source for the script src with:

emob.src = emsp.substr(15)

Of the ones we’ve cleaned, so far, they’ve all pointed to:

hxxp:// chadon.nl/js/jquery.js

We’ve gathered the log files for these sites and processed them through our log analyzer and found that the hackers are using file inclusion strings in already vulnerable sites to infect them.

We can remove this from your site and help protect it or, if you have your files downloaded to your PC and have already installed grepWin, you can use this regex to find and remove these strings from your website files:

Please post back here with any comments, other URLs that this script is directing to or any other pertinent information.

Thank you.