By

Fake google-analytics code

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.

By

What to do if your site is showing “Cannot redeclare corelibrarieshandler” error

We’ve been seeing more infected websites that when viewed with a browser show the following:

Fatal error: Cannot redeclare corelibrarieshandler() (previously declared in /home/content/(all changed)/index.php:4) in /home/content/(all changed)/includes/defines.php on line 11

The error always appears to show the error on line 11. As of this writing google shows 3,570 results for this error message. Some of these have already been flagged with Google’s warning: “This site may harm your computer”. Some haven’t. We’ve also seen where some of the websites showing for this search term have already been cleaned.

The code that is causing this error is:

The above code is inserted into many, if not all, .php files which makes clean up a little difficult.

For this clean-up, if you don’t want us to clean it for you, you can use grepWin.

First you’ll have to download all your website files to your local computer.

Then, if you’re on Windows, you can use grepWin along with this regex search string:

<\?php\s*\/\*\*\s*\*\s*Gets some core libraries and displays a top message if required.\s*\/\*\s*\*\/\s*function CoreLibrariesHandler\(\).*?\?>

Then set grepWin to scan all files, create a backup and to scan the folder with your downloaded files in it and hit replace.

Then you can copy the new files up to your website.

You’re not finished. If you don’t close the point of entry, the hackers will be back. Many of the infections we’ve seen are either the result of stolen FTP passwords or out dated software. Some have been WordPress, Joomla, or osCommerce that have not been properly secured.

I think this will be growing more over the next few days. Update your sites now.

Please post back with a comment if you have anything to add to this or have further questions.

Thank you.

By

What Hackers Won’t Do for SEO

First an announcement: The number of websites we’ve cleaned just passed 75,000!

In reviewing our recent activity, I noticed a number of sites that have a certain similar characteristic – a large number of infected websites have a folder added to the named .log or .logs

The dot (.) in front of a folder name causes it to be hidden by default so many FTP programs wouldn’t show that folder.

In addition to the “hidden” folder, we also found .htaccess files with the following:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /31.php?q=$1 [L]

The part that would be different is the 31.php. Often times this was any random 2 digits, but we’ve also seen some files that were a random name:

rhau.php
roseanne.php

The contents of the those randonly named .php files was always about the same:
eval(gzuncompress(base64_decode('eNqVWG2P4kYM...

This file was used by the hackers as the “backdoor” to the website for future infections, etc.

Inside the .log or .logs folder was another folder named the same as the infected website. Inside that folder was a file:

xmlrpc.txt

in the case of the folder named .log, the contents of which lead to a website that the backdoor can request new instructions or other malicious code from. In the cases where we found a .logs folder, we found the same structure, another folder named with the infected website, then a file:

ref.xmlrpc.php

The contents of which were similar to the xmlrpc.txt file, a website where the 2 digit file could get further malicious code or additional files.

Some of the websites we’ve seen listed in this xmlrpc.txt/re.xmlrpc.php are:
love-adamnet.net
boolin.in
love-adambiz.net
love-adaminfo.net
love-adamorg.net
bestorgblog.net
and many others...

This line of code is inserted somewhere in a .htm/.html/.php file:
img heigth="1" width="1" border="0" src="hxxp: //imgaaa. net/t.php?id=8021025">

usually at the very end of the file, after the closing html tag.

The hackers are using different domains in this img tag, but most of them are similar to:

imgccc.net
imgddd.net
( you get the idea )

and obviously the id at the end is different.

This begs the question: Why?

What’s the purpose of all of this? What are the hackers gaining by this and how are they getting in?

First, the why.

Inside many of the .log folders we’re seeing many, many hundreds of .html files for various products/services. For instance:

  • WHIPPLE GRID
  • WESTERN EYES
  • SPANISH JAZZ
  • SHARK DRAW
  • OSSA MOTORCYCLE

One common thread with these files is that they all start with h1 tags, the above text, or some other topic, all in upper case, a variety of links to more files on that same infected website and content all optimized for search engine results.

So the hackers are using this scenario to drive traffic to various websites – mostly images. What’s at those websites? Mostly we found the fake anti-virus websites waiting for the unsuspecting visitor.

Now the how.

How does this happen?

In most cases, after our log analyzers finished their work, we found that this resulted from stolen FTP credentials. In other words, a virus is on a PC. That PC has been used to FTP files to the infected website. The virus can either “sniff” the FTP traffic, and since FTP transmits all data in plain text, it’s easy for the virus to see and steal the the username and password from the traffic, or the virus steals the FTP login credentials from a file saved on the PC.

Many free FTP programs store their saved login credentials in a plain text file on the local PC. When a virus infects a computer it looks for these files and steals the information.

After the virus steals this information, it sends it to a server which then carries out the infection.

What can you do?

You can make sure that you’re running a good anti-virus program on your PC. Then make certain that it stays updated and runs full system scans everyday. I know it takes time and I know it’s a hassle, but so is cleaning up your website.

Also, if your hosting provider supports FTPS or SFTP, switch to that instead of FTP. The reason is that FTPS and SFTP send their traffic encrypted, not in plain text. This makes it much more difficult (not impossible) to sniff and steal.

To clean this up, find and remove the entire .log or .logs folder. If you have an account with many sub-domains, you’ll have to check each sub-domain or add-on domain folder as well.

  1. Using either the file manager from your hosting provider account or your
    FTP program, delete the entire .log or .logs folder.
  2. If you can download all the files from your website to your local computer, search all files for:

    eval(gzuncompress(base64_decode

    and remove those files.

  3. Check all .htaccess files for the code listed above in the .htaccess content I provided.
  4. Change all FTP passwords.
  5. Update your anti-virus signatures and run a full system scan. Insist that anyone else with FTP access do the same and do not give them new passwords until they have run a full system scan with an updated anti-virus program. Ask them for the report at the end.

We recommend that each person with FTP access have their own FTP account. Also, check with your hosting provider to be sure that FTP and access logging is enabled. That way, if your site is ever infected again, you can search through the logs, or we can do it for you as part of our service, and determine who’s PC was infected, or at least how the code was inserted into your website.

If you need help cleaning up your website, please send me an email: traef@wewatchyourwebsite.com – we’ll clean it up for you.

If you have any further comments about this infection, or questions, please post a comment.

Thank you.