Update on Global Spam Volume

In this blog published in January, we followed-up on the spam volume saga as the Rustock botnet returned to action on January 10. At the time, it looked like the holidays were over for spammers. Did the prediction hold up?
Yes, as it turns out. Over th…

In this blog published in January, we followed-up on the spam volume saga as the Rustock botnet returned to action on January 10. At the time, it looked like the holidays were over for spammers. Did the prediction hold up?

Yes, as it turns out. Over the following six weeks, the global spam volume has remained more or less flat. Towards the end of February however, it is showing a bit of a decline.

A similar pattern can be seen for the global spam percentage:

Even though the spam volume has somewhat recovered, it is nowhere near what it was one year ago. This chart shows the global spam volume in the month of February in 2010 and 2011:

Spambot Tried to Play Cupid Ahead of Valentine’s Day

Spammers often use a variety of obfuscation methods in an attempt to bypass anti-spam filters. We did some follow up analysis on a recent dating spam attack in which the spammers made use of URLs in the message body with spaces inserted in between char…

Spammers often use a variety of obfuscation methods in an attempt to bypass anti-spam filters. We did some follow up analysis on a recent dating spam attack in which the spammers made use of URLs in the message body with spaces inserted in between characters in the URL. Although this obfuscation technique has been much used in the past, it has not been as prevalent in recent times. This particular spam attack was active during the last week of January and lasted until the first week of February, 2011. Approximately 12,000 spam messages were observed in this attack.

The subject and message body in this spam attack were randomized in addition to the URL obfuscation.

Sample subject line variations observed in this attack are:

Subject: Svetlana Martyushova appeared in the chat

Subject: Tatyana Zhivkova - waiting on you

Subject: Kazak Avrora thinks about you

Subject: Alina Lebedkova wants to see you

Subject: Dobrolyubova Liudmila appeared online

Subject: Nataliya Kostyuka wants you to come

Subject: Alesja Durchenko appeared in a video chat

Sample URLs observed in this attack are:

hxxp://kleopatraoefi.blog spot.com

hxxp://barkovaeminevy.blog spot.com

hxxp://fin pr ep online.com

hxxp://backfin group. com

hxxp://back fing roup.com

hxxp://egorichevkiripo.blogspot.com

hxxp://finp reponline.com

hxxp://bluef   inkids.com

hxxp://finpr eponline.com

hxxp://kleopatraoefi.blog spot.com

hxxp://fi nprep    online.c om

hxxp://barkovaeminevy.blog spot.com

hxxp://backfin group.com

The domains used in some of the URLs were registered in United States to the same person, and on the same day in August last year. As seen in several URLs in this attack, the spammers also made use of blogspot.com to re-direct the Web pages.

The email implies you are a registered user at a dating website and includes a link (broken) that claims to be either an application form or a questionnaire a Russian girl. However, most of the links ultimately redirected to roma.animoney.net - a Russian dating Web site, associated with Anastasia’s Affiliate Program. Moreover, as expected, redirection to the Russian dating site occurs only if the unbroken link is opened in a Web browser  by removing the spaces inserted in between characters. Through such spam emails, spammers attempt to instill a sense of curiosity amongst users who might be interested in interacting and/or meeting these Russian girls, from whom the email appears to come from. All above links are now inactive.

We found that these messages were originating from diverse geographical locations, suggesting that this is most likely a botnet attack. Further examination of specific IPs confirmed that they are indeed infected machines, and are part of multiple botnets. Although some IPs involved in the spam attack were identified as part of the Cutwail botnet, there were also traces of infection from the Lethic botnet in other IPs in the attack.

Thanks to Paresh Joshi for the spam samples contributed to this blog.

Using Trusted Software to do the Dirty Work

We recently discovered an interesting Trojan horse that changes the home page of Internet Explorer and redirects traffic from certain domains to this page.
Normally this wouldn’t be out of the ordinary, but rather than use their own Trojan code, …

We recently discovered an interesting Trojan horse that changes the home page of Internet Explorer and redirects traffic from certain domains to this page.

Normally this wouldn’t be out of the ordinary, but rather than use their own Trojan code, the malware authors have chosen a different way to build their malicious package. Utilizing a component of KingSoft Internet Security, they have built a package consisting of the KingSoft WebShield browser protection software. The package contains configuration files that are crafted in such a way that allows KingSoft WebShield to perform correctly, but also allows the malware authors to use a real browser protection package instead of customized Trojan code.

The Trojan is packed in an AutoIT package. Specifically, this package consists of the following Kingsoft WebShield and support components:

  • kswbc.dll
  • kswebshield.dll
  • KSWebShield.exe
  • kwssp.dll
  • kwsui.dll

All of these files are intact and are digitally signed by "Zhuhai Kingsoft Software Co. Ltd". They are normally distributed as part of a previous version of the Kingsoft Internet Security package, which is designed as an anti-phising/browser protection software application.

However, the interesting part of this package is in its configuration, which allows an opportunity for malicious intent. Kingsoft WebShield has the ability to lock the home page to a specific domain as well as to redirect URLs based entirely on plain text configuration files. This means that a person with malicious intent can repackage it using malicious configuration files and use this as a home-made Trojan package.

When the AutoIT package runs, it unpacks the executable and .dll files; puts them in the appropriate folders; and sets up the program service, imitating a normal installation. It then creates the following two configuration files:

  • kws.ini
  • spitesp.dat

The above configuration files control the home page and redirection domain list, respectively.

The ‘kws.ini’ file is responsible for settings pertaining to locking the current home page and the desired home page URLs. The following is a list of home pages known to be associated with the threat, which are advertisement link farms:

  • hxxp://www.91xiaz.com/cn/?
  • hxxp://www.ww2221.com
  • hxxp://wvw.86819.com/

 

The ‘spitesp.dat’ file contains configuration details for a list of domains, which get redirected to the URL in the ‘kws.ini’ file in the event that a user tries to access them.

The following is a list of domains known to be redirected by the threat:

  • 1188.com
  • 360.com
  • 365j.com
  • 7f7f.com
  • bbs.360.cn
  • go2000.com
  • qq.com
  • qq5.com

Users are prevented from accessing these Web sites, which are all quite popular in China, as the threat redirects the browser to the pre-determined advertisement home page. Certain Web sites offering help with computer problems are also blocked and redirected (e.g. 360.cn).

Additionally, the threat deletes all Quick Launch icons except Internet Explorer. If Internet Explorer is not present in Quick Launch, a shortcut is created for it. This is possibly an attempt to ensure that a user must use Internet Explorer to browse the Internet as the Kingsoft WebShield package only works in the desired manner for Internet Explorer.

The Trojan also installs itself as an automatic service. Furthermore, as there is no uninstaller for this particular package, removal can prove to be quite challenging.

The Kingsoft WebShield otherwise behaves exactly as it is designed to, which may possibly prevent a user from recognizing that this particular WebShield package has been reconfigured.

These samples are currently detected by Symantec as Trojan Horse.

Hiding the WordPress Version Number Will Not Make Your Website More Secure

One of the most mentioned measures that is supposed to make a WordPress installation more secure is hiding the WordPress version number, but the truth is that it will not make your installation any more secure. If it has any … Continue reading

One of the most mentioned measures that is supposed to make a WordPress installation more secure is hiding the WordPress version number, but the truth is that it will not make your installation any more secure. If it has any effect, this measure is making WordPress installations less secure. The idea certainly sounds good if don’t have an understanding of what the actual threats are and the methods someone could use to determine what version is being used. The biggest thing to understand is that hackers are not checking what version of WordPress is being run when trying to hack a website. In fact in most cases they don’t even check if WordPress is installed, they just try to exploit known vulnerabilities in older version of WordPress at locations that WordPress might be installed (they also attempt to exploit other software that might be located on a website as well). So no matter how hard you try to hide the WordPress version number, you will still get hacked if you are running an outdated version of WordPress. This is why keeping WordPress updated is the only measure you really need to do to keep WordPress secure.

If the WordPress version number is hidden someone who wants to check what WordPress version is running, as we often do with for potential clients or we are alerting websites we have found to have been hacked, will not be able easily determine what version is running and therefore not be able to give the webmaster a reminder that they need to upgrade it.

Furthermore, these attempts to hide version number would not be successful in preventing some who wants to determine the WordPress version number from actually doing it. There are multiple ways to check pages and files to determine the version is running and we have listed a number of them below. Someone who really wanted to know the version could also use the more advanced method of testing capabilities to determine the version as well. So if there was a real risk that came from the WordPress version number being known the attempts to hide the version would fail to protect the website.

Meta Generator Tag

The most well known way of checking what version of WordPress is being used is to check generator that is included in the source code of the website’s pages:

<meta name=”generator” content=”WordPress 3.1″ />

There are multiple methods of removing this from the pages.

Readme.html File

The other well known method is to check readme.html file that is placed in the root directory of the WordPress installation. From our experience this is not always reliable for determining what version is running as people don’t always copy the new readme.html when the perform an upgrade. So this could only be relied on to tell that the website is only running at least a certain version of WordPress. This can be removed by just deleting the files, but it will need to be done each time if you use the automatic update feature.

RSS/Atom Generator Element

If the website provides a RSS or Atom feed generated by WordPress it will include a generator element similar to the one placed on the website’s pages:

<generator>http://wordpress.org/?v=3.1</generator>

Like the generator tag this can removed, but we have found that this occurs much less often.

Login Page CSS File

The next two methods will only allow the major version of the WordPress to be determined. That is they could tell if you are running 3.0 or 3.1, but not it you were running 3.0.1, 3.0.2, 3.0.4, or 3.0.5. This information would be enough to narrow down the possible vulnerabilities that the hacker could use making the task of finding one they could use much simpler.

In the source code of the WordPress login page a version number is attached to the login.css style sheet:

<link rel=’stylesheet’ href=’http://localhost/wordpress/wp-admin/css/login.css?ver=20081210′ type=’text/css’ media=’all’ />

These are version numbers for the last five major releases:
2.7: 20081210
2.8: 20090514
2.9: 20091010
3.0: 20100601
3.1: 20110121

Limiting access to the wp-login.php could prevent this from being checked.

New Files

The final method involves checking for a file that has been added to a given version. These are files that were introduced in the latest version for the last five major releases:
2.7: /wp-includes/js/comment-reply.js
2.8: /wp-includes/js/autosave.dev.js
2.9: /wp-includes/js/json2.dev.js
3.0: /wp-includes/js/wp-list-revisions.dev.js
3.1: /wp-includes/js/admin-bar.dev.js

It impossible to have a file that has not yet been created already on your website and blocking access to these files is not something that you could realistically do, so this is something that could not be prevented from being able to be used to determine the version.

If you see someone promoting hiding the WordPress version number as a security measure we would appreciate if you point them to this post to help stop it from being promoted..