Mar 3, 2010

[h-online.com] Fakeinit scareware with Alureon root kit

[Google Webmaster Central] New Message Center notifications for hacking and abuse – now include comment spam and ugc

Mar 5, 2010

[computerworld.com] 22 different patch mechanisms for 75 updates every year. Secunia promotes more universal solution

[h-online.com] known IE vulnerabilities will remain unpatched in March

Mar 7, 2010

Interesting reddit discussion about a malicious PHP code found on one site

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Joshua’s list was a good starting point. I saw multiple rogue blogspot blogs that followed the same pattern and multiple compromised sites where those blogs redirected to. For some reason, most of the functionality of the malicious pages on the hacked sites is implemented as a client-side JavaScript, so I could easily retrieve and analyze those scripts. They provided me with very interesting details about the internals of the attack: sites it expected as referrers and usage of infected PCs. As a result I came up to the following scheme:

Flow of the attack

Most people first meet the Koobface when they receive a message with a link to some video from someone they know. It’s either a message from a friend in Facebook or some other social network, or a DM in Twitter. To make the link less suspicious criminals use URL shorteners like bit.ly, tinyurl.com, etc. This is a normal practice on Twitter where messages are limited to 140 characters. For not-Twitter users such links will also be less suspicious than something like “hxxp://www.sfighters .yoyo .pl/ freevideo/?go”, especially when the link is received from a friend.

Another vector is poisoned search results that lead to rogue blogspot blogs that, in turn, redirect visitors to a hacked third party site that coordinates the malicious action.

That site can choose either choose the infection path or the direct monetization path.

Infection path

In case of the infection path, the user is redirected to a specifically crafted web page on one of already infected computers. This page takes into account the site where the user clicked on the malicious link (it may look like YouTube or Facebook). Generally it’s a web page with a “video” that requires additional download (player/codec update). This download is a trojan that seems to be used to download the rest malicious files and turn the use computer into a zombie. Among other bad things, infected PCs help the Koobface propagation:

• they send out message with malicious links to users’ contacts in social networks
• they host fake video pages
• they steal FTP credentials from users’ websites (if they happen to be webmasters) and then create rogue web pages there.

It shouldn’t be a surprise that after such a download the video won’t play. And when disappointed users close the page, they see another window saying that their computer is infected (this time it doesn’t lie) and they should download a security program (that is just another trojan) that will “fix” the problem. This happens because the fake video pages have an “onunload” even handler that opens a scareware site when people leave that page. This helps increase the infection rate and monetize the traffic via affiliate relationships with fake AV vendors.

Monetization path

Sometimes the sites that coordinate the attack flow decide to choose the monetization path right away and redirect users to a proxy site (when I checked it was 61 .235 .117 .83) that selects a proper affiliate link: adult dating sites, pirated video download sites, etc.

Rogue blogs

An interesting part of this attack scheme is rogue blogspot blogs. They all look the same and definitely auto-generated.

Here are their distinguishing features:

1. A single post that consists of a news headline (presumably from Google News), for example: “Two journalists released in Somalia – CNN International” or “Obamas’ affection for Hawaii means better times for state – USA Today“. This headline is both the blog title and the title of the only post. The post itself is empty.

2. The addresses of such blogs are composed of several words that resemble names (probably parts of stolen user credentials). E.g. demontlucavincenzo .blogspot.com, jacekjacekroys .blogspot.com, jamaldboeding .blogspot.com, britnymccarville .blogspot.com.

3. The blogs are the only blogspot blogs of their users (One Blogger user -> one blog -> one blogpost). They don’t create multiple blogs under the same account (otherwise they can all be easily detected and shut down).

4. They use different default languages for each blog. You can see blogs with user interface in English, Dutch, Chinese, Arabic, Russian, Greek, Hebrew, Turkish, etc. At the same time blog titles (news headlines) are always in English.

5. And the key feature is the script in the <head> section of their HTML that redirects visitors with enabled JavaScript to an intermediary attack site. The script usually starts with something like this:

c3f7db='do';d2beef91="canuqnkmfji".replace(/[anqkfji]+/g,"");eb79c7d9='ent.r'; ...

and is generally well detected by Unmask Parasites.

It is clear that the blogs are automatically generated. Probably the CAPTCHA-breaking function of Koobface trojans is used to automatically create multiple Blogger accounts.

The nature of the blogs’ content makes me think that their primary purpose is search results poisoning. Publishing headlines of breaking news when there’s not much relevant legitimate content exists, they expect their blogs will be ranked high enough (at least for a short time) for the news related searches. Given how many people use search engines to find details about hot news topics, this may be a working approach.

However only people from Blogger can says how successful for hackers this approach is. I tried to search for headlines that appear on Google News but couldn’t find the infected blogs (is this vector still active?). On the other hand I’ve easily found a couple a big farms of spammy blogspot blogs that used the same trick.

Anyway, I was able to identify several hundred Koobface rogue blogs (and the hacked sites they redirect to) using Google’s Safe Browsing Diagnostic pages. For example if you check the diagnostic page for any known infected blog (e.g. britnymccarville .blogspot .com ) and then click on the links for sites reported as hosting malware (the IP addresses belong to infected PC and domain names to hacked legitimate sites), you will see more infected blogspot blogs on subsequent pages.

Checking the blacklisted blogs that still exist, I found the earliest dates they have (the dates of blogposts) are in the second half of November 2009 and the most recent are in this February. Maybe it’s just a coincidence, but this period almost exactly matches the sharp increase in number of reported malicious URLs on Google’s network (blogspot.com blogs are a part of that network).

StopBadware report: Number of Reported URLs on AS 15169 – GOOGLE – Google Inc.

If it’s not a coincidence, then Koobface is responsible for about 80% of reported malicious URLs on Google’s network.

(Thinking aloud: November dates may have something to do with the fact that Safe Browsing data is limited to the last 90 days, so I just can’t see rogue blogs that had been blacklisted before November. On the other hand, Google’s malware scanners revisit infected sites once in a while and update their status, so I still expect to see some records for sites that had been first blacklisted before the last November. If they exist.)

Some of the blogs I checked have already been shut down. I wonder why Blogger doesn’t shut down them all if they can easily obtain a list of the rogue blogs from Google’s own Safe Browsing database. (I could manually retrieve more than 300 unique Koobface blogs using only Safe Browsing diagnostic pages that provide very limited and incomplete information). These blogs are not infected legitimate blogs – they are 100% malicious and created by non-existing users. And they can be easily distinguished from any other legitimate blogs (even by a pretty simple automated scanner). Blogger, you can safely delete all those blogs and users! Why wait?

Hacked legitimate sites

Now let’s talk about the compromised legitimated sites that work as intermediaries in this attack.

Hackers create a new directory where they place their files. The malicious URL have the following structure: http://www.hacked-site.com/rogue_dir/?go

Here are some real examples (be careful):

www .uniquecreationbabies .co.za/supervids/?go
www .piratedb .net/index.htm/?go
ritmotours .com .tr/main/?go
www .sfighters .yoyo .pl/freevideo/?go

If you specify a URL without the ?go part you will see a page that contains a blurry thumbnail of a video page and a Flash file that redirects visitors to the ?go page (thanks Pob)

The ?go page consists only of one moderately obfuscated script:

The first thing you see is two lists at the very top of the script. The first is a list of expected referrers:

• facebook.com
• tagged.com
• friendster.com
• myspace.com
• msplinks.com
• lnk.ms
• myyearbook.com
• fubar.com
• twitter.com
• hi5.com
• bebo.com

No comments required. These are the primary places of Koobface distribution.

Infected PCs

The second list contain 20 IP addresses. This list is different on every hacked site. When I checked the IPs with DomainTools I discovered that they all belonged to different cable and broadband Internet service providers. In other words, they are IPs of regular home and office PCs.

This list is used to create 20 external scripts and load them on the fly. If a rogue web server on an infected computer is working at that moment it should respond with a URL of a fake video page that it hosts. Then, using a timer, the intermediary site checks when that URL is available and redirects people there.

Quick Q&A

Q: Why use infected PSc as malicious web servers?
A: Why not? They control thousands of infected zombie PCs that are powerful enough, have a decent Internet connection and many of them have static IPs.

Q: Why 20 IPs?
A: Remember that home PCs are not always turned on and connected to the Internet. Moreover, the malware can be removed from infected computers any time. So hackers try to connect to 20 different infected PCs at the same time to increase chances that at least one of them is ready to serve the fake video page.

Q: What happens if web servers on more than one IP will be available at the same time? Will people see more than one fake video page?
A: No. The intermediary sites wait for any redirect URL to be available. When they detect that some of the loaded (from infected PCs) scripts provided such a URL, visitors get redirected. All subsequent redirect URLs are simply discarded.

To webmasters

This post contains some important information for webmaster and I want to sum up it here.

Keep your PC clean

If you don’t want your sites to be hacked, you should keep your PCs clean from malware.

Per TrendMicro, among other bad things, Koobface installs a variant of the LDPinch trojan that steals email, IM and FTP credentials. Here is the list of the targeted FTP clients TrendMicro provides (PDF) in their Koobface review (compare it with the list I published here a few months ago):

• Total Commander
• cuteFTP
• Ipswitch
• SmartFTP
• Coffeecup Software
• FTP commander (Pro, Deluxe)
• FlashFXP
• FileZilla

So get a decent antivirus program and a Firewall that will block unauthorized network activity (e.g. trojans sending your FTP credentials to bad guys).

Try not to save passwords in FTP clients (especially in those listed above) if they don’t provide master key encryption.

If your hosting plan includes SFTP (or FTPS), switch to the secure protocol immediately and forget about FTP that sends everything (including your passwords) in plain text. Most popular FTP clients support secure protocols so this switch will be painless.

Although Koobface doesn’t use browser/plugin vulnerabilities, I still insist that you keep your whole system (OS, web browser, Java, Flash, Adobe Reader, etc.) up-to-date. There are many other web threats that exploit vulnerabilities of (even slightly) outdated software.

I recommend that you use Firefox with the NoScript extension. This plugin allows to execute only trusted scripts and active content, which makes web surfing more secure. As I showed above, Koobface actively uses JavaScript on both intermediary and fake video pages. With NoScript, you would hardly reach the pages that actually serve malicious files. Unfortunately, this extension is only available for Firefox at this time. If you know any alternatives, please leave a comment.

If your site is hacked…

If you were unlucky your site could have been hacked. Here is what you can do to detect this.

1. Scan your server for new suspicious files and directories.
2. Search for suspicious .swf files (especially if you don’t use Flash). In the rogue directories, hackers place a Flash file with a name like “n0ld7q.swf“
3. Search for files that contain this string: KROTEG. I see it at the top of the main script on every compromised (by Koobface) site.

Google’s malware warnings

If your site is blacklisted by Google and you don’t know why (you can’t find anything wrong in your web pages), check the Safe Browsing diagnostic page ( http://www.google.com/safebrowsing/diagnostic?site=your-site-domain.com ). If this page mention several blogspot blogs that your site have infected (example), the chances are your site is exploited by Koobface and you should search for a rogue directory on your server.

When you identify and remove the cause of the problem, don’t forget to request a malware review via Google Webmaster Tools to have your site removed from the blacklist.

To learn more about Google’s malware warnings and how to deal with them, you might want to read my practical guide.

Summary

This was the first time I worked with Koobface. It’s such a complex multi-tier heterogeneous malware attack so I don’t expect that I managed to cover everything correctly at the first try. Even the visible (web) part of the Koobface iceberg is very impressive:

• Social Networks
• Search Engines
• Rogue blogs
• Hacked legitimate sites
• Web servers on infected PCs
• Scareware and other “grey/black” affiliate sites.
• and I don’t mention here exploit files hosted on image-sharing sites as .JPG files (per TrendMicro)

And the hidden part (malware on infected PCs and botnet coordination) that I don’t even try to research myself is monstrous (Check this visualization and explanation (PDF) by TrendMicro).

Have your say

So if you find any mistakes in this post or want to share some missing details, please leave your comment here.

I would also be interested in hearing from webmasters of the hacked exploited used by Koobface. I’d like to take a look at file they upload (I still don’t know if they use server-side scripts or just add some .htaccess logic for different types of requests).

Thanks for reading.

Related posts:

• 10 FTP Clients Malware Steals Credentials From
• Quicksilver Malware Network
• Rogue blogs redirect search traffic to bogus AV sites. Part 1.
• Rogue blogs redirect search traffic to bogus AV sites. Part 2.

Feb 15, 2010

WeWatchYourWebs explains the recent attack – stolen FTP credentials and eval(base64_decode

RT @wordpress: WordPress 2.9.2 has been released, addressing a security concern w/trash.

Feb 17, 2010

Updated my list of Gumblar zombies – 500 items at this point and the attack is still active

Feb 20, 2010

[ocaoimh.ie] New version of WordPress Exploit Scanner plugin

Comment from a Servage user who had rogue blogs created under his account

RT @stopbadware: New data reporting tools on StopBadware.org

Top 50 IPs that host reported malicious URLs – SoftLayer network hosts the leader. Google hosts #2 .

Top 50 networks by number of reported malicious URLs.  Leaders: SoftLayer, ThePlanet & ChineNet-Backbone

Feb 21, 2010

[krebsonsecurity.com] what happens when security news make it to major media – take them with a grain of salt

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Feb 8, 2010

Investigating an attack that seems to be exploiting vulnerability of phpMyAdmin. Make sure your phpMyAdmin is up-to-date.

[h-online] Tomorrow Microsoft releases fixes to 26 sec. vulnerabilities.  Some known vulnerabilities will stay unpatched

Feb 10, 2010

The ex-”GNU-GPL” script constantly mutates. You can learn a lot about JS following the changes ;-)

Feb 11, 2010

[thecpaneladmin.com] Securing FTP Access on a cPanel Server

Feb 12, 2010

[h-online] SpyEye botnet toolkit – bots grab web froms, email and FTP traffic

RT @briankrebs: Critical Security Update for Adobe Flash Player. Also, another Adobe Reader patch coming

RT @kdawson: Breaking: BSoD after Windows security update happens only on machines with pre-existing rootkit infection.  (Comments are also worth reading)

[minor update] Unmask Parasites v0.5.197 – added more malware detection rules

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Feb 1, 2010

New revision of the ex-”GNU GPL” malicious script.

Feb 3, 2010

Answers to Google’s webmaster quiz

RT @gcluley: The world’s top 10 dirtiest web-hosting countries revealed

Feb 4, 2010

Seems like a new attack against PHP sites – it uses “iss9w8s89xx .org” and “ssdfsdfwefwefwe .com”

[slashdot] Image Searchers Snared By Malware – malicious redirects for Image search results (Google & Yahoo). (Attack description similar to the ones I post here. It includes my comments.)

Another insightful story about .htaccess hack in slashdot comments.  – media cloaking?

[h-online] Microsoft confirms new vulnerability in Internet Explorer – IE5-IE8 are reportedly affected

Feb 7, 2010

[mozilla] malicious Firefox add-ons: Sothink Web Video Downloader and Master Filer

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

Jan 26, 2010

RT @gcluley: RT @mikkohypponen: Some notes about using Twitter as a tool for people interested in computer security.

New revision of the “GNU GPL” malicious script – now without comments and with less obfuscation. (Jan 29, plus more recent revision)

Jan 27, 2010

[h-online] Scareware becomes ransomware again – encrypted files, unbootable Windows, malicious IQ tests

Another bunch of hacked sites poison search results for Haiti disaster keywords (using the bety-like hack)

RT @briankrebs A peek inside one of the more popular browser exploit kits. the stats might surprise you.

Jan 28, 2010

[sophos] Troj/JSRedir-AK morphs into Troj/JSRedir-AR

[stopbadware.org] Tips for Cleaning & Securing Your Website

FTP Lock – hosting providers come up with solutions that can minimize threats from stolen FTP credentials

Jan 29, 2010

[google] Request visitors’ permission before installing software if you don’t want your site to be labeled as malicious

Jan 30, 2010

[minor update] Unmask Parasites v0.5.196 – should work slightly faster.

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

The main goal is to demystify hackers and encourage webmasters to explore their own sites. The more you know about hackers, the better you’ll be at protecting your site against their attacks.

This post is based on the files and access logs of three compromised sites that I received from a webmaster who contacted me a couple of weeks ago.

Quick facts

1. The attack uses unpatched vulnerability in osCommerce 2.2 that allows an attacker to upload arbitrary files to compromised servers using a security hole in file_manager.php.
2. Only one of the three sites actually uses osCommerse (site-1).The rest two sites had been hacked using access gained via the hacked site-1.

Chronicle of the attack

In logs of site-1, I found several POST requests to “/admin/file_manager.php/login.php?a=1&action=save” (on December 9, 10, 16, 17, 18) from several different IPs. Right after those attacks I saw POST requests to newly created files called fly.php (the file that is used in the disclosed exploit — it executes arbitrary PHP code passed as a POST parameter) and flop.php. Apperantly those files provided full access to the site (to directories with write permission). One of such attacks created a file called mm.php (it provides a simple interface to upload files from a local computer to server).

December 21, 2009

12:13 – Hacker with IP 84.52.73.161 uses mm.php to upload an sh1.php file to the /images directory. sh1.php is a web shell. It equips hackers with a sophisticated graphical interface that provides almost full access to compromised sites. It allows hackers to browse directories, create and modify files, execute arbitrary PHP code, work with databases etc.

12:14 – 12:28 – the hacker uses the web shell to explore internals of the site-1.

12:14 – he discovers site-2 under the same account

12:23 – he discovers site-3 under the same account and decides to start the malware campaign there. He uploads sh1.php and bety.php there.

21:05 – The hacker submitted three site-3/bety.php?q=keywords pages to page2rss.com (Page2Rss helps monitor web sites that do not publish feeds).

21:06 – The hacker clicks on the created links on page2rss.com and visits site-3 to check that everything works as intended.

Links on page2rss.com are “nofollowed” but maybe this service somehow pings Google about new feeds, which makes the discovery faster?

21:31 – Googlebot comes to site-3 directly to bety.php pages and starts to index them. Apparently hackers somehow submitted a big batch of bety.php URLs to Google since it’s clear that it didn’t use site-wide discovery (didn’t follow links found in just indexed bety pages).

22:50 - Googlebot finishes indexing bety.php pages. 1976 malicious pages have been indexed.

The indexed pages become immediately available in search results. The first visitor from Google Search comes at 21:47. It is just in 16 minute after Google first discovered the bety pages and started indexing them and in 5 minutes after that visited page had been indexed. And at that time the initial indexing was still underway with more than an hour to go. 10 web surfers had visited the bety pages by the time googlebot left the site.

Some stats on visits from Google:

42 visits on December 21.
129 visits by December 31.

But wait, it’s just the beginning.

Bety on site-2

December 22

08:18 – The hacker with IP 84.52.73.161 returns to site-1 and works with it for about 6(!) hours using the sh1.php web shell. This time he wants to start the “bety” campaigns on site-1 and site-2.

08:22 – he uploads sh1.php and bety.php to site-2.

08:51 – the hacker has someone open the site-2/bety.php?q=so-you-think-you-can-dance-phone-number page using Microsoft Translator service.

09:32 – Googlebot comes to site-2 and starts to index the bety.php pages.

09:58 – first visitor clickes on the bety search result. As you can see, the indexed pages become searchable almost immediately.

10:36 – The first batch of 1592 bety.php pages is indexed. By this time 25 more visitors came to site-2 bety pages via Google search results.

18:38 – One of the bety links somehow makes it to twitter. The same minute Googlebot follows this link.

21:39 – Googlebot visits site-2 again and starts to index another batch of 5150 bety pages. This session lasts till 03:24 – of the next day (almost 6 hours).

Then Googlebot regularly visits site-2 and by the end of month it has indexed 8415 bety pages. As a result, there had been 1353 visits of malicious bety pages from Google search results on December 22, 1878 visits on December 23, and 5734 visits by the end of December.

Bety on Site-1

When Google picked up bety pages on site-2, the attacker switched back to site-1 and triggered the bety campaign there.

December 22, 2009

10:53 – a spammy comment with 438 links to site-1/bety.php?q=keywords pages has been published on my.mail.ru. 11:02 – Someone clickes on those links and opens a couple of bety pages.

12:35 – Googlebot comes to site-1 and starts to index the bety.php pages. It indexes 4887 malicious pages by 16:44.

12:59 – the first visitor from Google search.

466 – visits from Google search results on December 22.
1500 – visits from Goolge on December 23.
3136 – visits from Google by the end of December.

Sumarry

During the last 10 days of December, 2009, this hacker managed to drive 9019 visits from Google to malicious bety pages. (Google was the only source of traffic for those pages.) 7768 times the script that redirects visitors to malicious sites was loaded by web surfers from 4781 unique IPs. Quite impressive, given it only took a few hours of the hacker’s time.

The secret of bety.php

OK. So what does this bety.php do an how it manages to provide Google with so many different variants of pages that it considers worthwhile to show on first pages of search results?

Bety.php handles two types of request q and red.

Red requests

bety.php?red=keywords requests are used to retrieve the content of lname.php, which is a redirect script, like this:

window.location = "hxxp://basicallyantispyware .net/hitin .php?land=20&affid=33220";

Every 20 minutes, bety.php updates the content of the lname.php file pulling the domain name of the currently active malicious site from
hxxp://92.48.127.76/domain.php?password=d0cd05bf619266a045dfb4a016753a39

To hide the malicious redirect from search engines, red request handler checks IP addresses of visitors and doesn’t return anything if detects requests from known IP-ranges used by search engine crawlers.

Q requests

q requests return web pages specially crafted for Google.

When bety.php is opened for the first time, it creates a special directory called .cache (in new version .pages). It is the place where the bety script stores generated web pages.

When processing bety.php?q=keywords requests, the script checks if there is a pages called keywords.html in the cache directory. If it is, this page will be displayed. E.g. for /bety.php?q=2010-nfl-mock-draft request it checks for file .cache/2010-nfl-mock-draft.html.

If the cached file is missing (and initially there are no cached files at all) it is generated on the fly. Here is the structure of the generated files:

1. Keywords go to the title tag. (dashes replaced with spaces)
2. Background and text colors are random value (to make all pages look a bit different)
3. Capitalized keywords go to the h3 tag at the top of the page.
4. Below goes the current date (as a hint that the content is fresh)
5. Then there is a bullet-list of up to four links:
   1. The first is a link to .cache/map.html – (every generated web pages is added here)
   2. The next three items link to bety.php?q=keywords1, bety.php?q=keywords2, bety.php?q=keywords3, where keywordsN are top keywords returned by Google’s AJAX requests that are normally used for keywords suggestions in Google’s search forms.
6. Malicious redirect script<script src=”?red=keywords”></script>
7. 50 random descriptions from top 100 Google’s search results for keywords.
8. In new versions, they also add a buggy link to “hxxp://www.megaupload .com/ ?d=YQ3C29N6“
9. And finally, for tracking purpose, each bety page contains a script of a hit.ua counter. So you can check how successful this particular malware campaign is: http://c.hit.ua/hit?i=25418

Pretty straight forward, isn’t it? Those pages contain many relevant keywords and while they are fresh (first couple of days) Google temporarily boosts their ranking. And for multi-keywords searches this is enough to make it to the first page of results.

What is not clear to me is

1. How hackers submit thousands of new pages to Google so that it immediately (well, almost) starts to index them?
2. How does Google permit this many (thousands) automated requests from compromised servers? In the logs, is see periods of more that an hour of consecutive requests at a rate of about 25 requests/second (and each time both “search” and “complete” services are requested). When I try to automate (sorry Google) searches from my home computer with comparable request rate (sometimes I need to analyze large volumes of search results for my researches), my IP inevitably gets block within a few minutes.
3. If Google readily indexes thousands (on just one site) of junk pages every day, what is the share of such junk in its main index? More than 90% 50%? ;-)

What do you think?

To webmasters

Hackers are always on the look out for vulnerable websites that they can use for their malicious activities. As a site owner or webmaster you should be ready to deal with hacker attacks.

1. If you use third-party scripts on your site, make sure they are secured. Find instructions on how to harden default installations. Then regularly check for security advisories (e.g. in Secunia). And always upgrade whenever security patches are available.
2. Monitor your server for changes (new files and directories). This can help you detect suspicious unauthorized activity early on. The sooner you detect the problem and clean up your site, the less the damage (think dropped search engine ranking, malware warnings, etc.) BTW, can anyone suggest tools suitable for file system monitoring on shared hosting plans?
3. Although Google Analytics and similar statistics scripts may provide you with almost everything you need to know about your site, don’t forget about raw access logs. Hackers don’t add your tracking code in their files and requests to them will only be reflected in access logs (tools like Webalizer work with raw logs so they can also help if requests to illicit files are popular enough to make it to Webalizer reports.) Pay special attention to POST requests – they may help you identify security holes.
4. Google Webmaster Tools can also help reveal illicit content, reporting top searches and search keywords for your whole site, not limiting to pages that contain your tracking code. Irrelevant keywords in GWT reports is a strong sign of security problems.

Any comments?

Related posts:

• Bety.php – osCommerce Hack. Part 1
• Black Hat SEO for Virus Dissemination
• Rogue blogs redirect search traffic to bogus AV sites. Part 1.
• Rogue blogs redirect search traffic to bogus AV sites. Part 2.
• Stats Anomaly Reveals Website Security Issues

Jan 18, 2009

[h-online] Typo3 updates patch holes

[milestone] 400,000 web pages checked by Unmask Parasites

Jan 19, 2009

Some nice Unmask Parasites testimonials. Please consider writing a testimonial if you like Unmask Parasites too.

Google’s quiz for webmasters – 40 questions. I only knew answers to about 80% of them.

Jan 21, 2010

bety.php from my latest blogpost is renamed to opa.php in today’s attacks

RT @gcluley: Here it is folks…. well done to MS on releasing the IE Patch

Jan 22, 2010

GNU GPL / CODE1 / LGPL malicious scripts now identify themselves as “Exception”

Firefox 3.6 released with protection from out-of-date plugins to keep users safer as they browse.

Jan 23, 2010

[h-online] 1 year free SSL certificate from a registered Certificate Authority (StartSSL) – with instruction

Jan 24, 2010

[sophos.com] Continued Sinowal activity.  And my domain generator for this attack 

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks

With Jim’s permission, I publish this email here:

Around Dec 22 an attacker with a Russian IP deposited some files on my
webserver. My hosting provider said access was gained through a since
updated version of Wordpress, although my view of the logs indicates it was
through an unsecured version of OSCommerce.

The attacker left 3 files on my server. No other files were changed. The
main domain that was attacked is http://wanlesstennis.com

the files were-
bety.php – a script with the title GoogleF#cker v1
sh1.php – some kind of redirect
lname.php -

The purpose seems to be to fool Googlebot into seeing non-existent links
within my domain in the generic form
http://wanlesstennis.com/bety.php?=some-garbage-keywords-here

I first noticed this a few days after the attack when looking at Webmaster
Tools for this domain and seeing that the top keywords had all of a sudden
changed to tiger, woods, nordgren, nfl, etc., all words that don’t even exist
on any of my webpages. Also the top search queries list pages like
formville.com, holy days of obligation catholic church, weather network
vancouver, etc., again things that have nothing to do with my site.

Once I noticed this I removed the offending files.

From that point on the number of reported Not Found errors in WMTools
started increasing . . . it is over 500 currently as all of these garbage
links are no longer accessible since the php files have been removed.

While researching some of the broken links I found a few pages in community
forums in russia that had posts that contained thousands of links to these
garbage links – once such page is here
http://my.mail.ru/community/abdul_and_asem/3F8D6B6BA0618DAB.html

Since then I have added a line in my robots.txt file to disallow /bety.php*
which of course is causing my URLS blocked by robots.txt to start
increasing in tandem with Not Found URLs.

The upside is that this has sent me scurrying to upgrade my security, the
downside is that it will take a while to have this garbage disappear from
WMTools.

Jim sent me the rogue .php files and access logs for his sites. They helped me investigate the hack and now I can share the details here.

1. His sites were not the only sites hit by this attack. I could easily find similarly hacked sites using the following Google Search: http://www.google.com/search?q=inurl%3Abety.php

2. Most of the affected sites run osCommerce. Moreover, Jim’s logs proved that a known vulnerability in osCommerce 2.2 RC2a (Secunia advisory) was used to upload rogue files to his sites.

The purpose of the attack is to drive traffic from Google to these intermediary bety.php?q=keywords pages that in turn, redirect unsuspecting web surfers to scareware (fake AV) sites. Here’s a description of the trojan downloaded from one of those sites (when I downloaded it, only 4 out of 40 anti-virus tools detected it).

Affected directories

Hackers upload their files into directories that are writable for webserver processes. This usually means directories with 777 permissions. However on certain host that use suPHP, all user directories are writable for PHP scripts since they run with the user’s permissions and 755 cannot stop them. Moreover, if a webmaster have multiple sites (domains) under the same account, not only will they create malicious files in the site running vulnerable version of osCommerce but also in every other website with writable directories.

Detection

To detect this particular hack, scan all your server directories for the following files:

• mm.php – uploads files to a webserver
• sh1.php – web shell
• betty.php – manages malicious landing pages
• lname.php – redirect to malicious sites
• .cache/ – directory with loads (sometimes thousands) of .html files (landing pages) it usually contains file called .cache/map.html

In addition to the above files, I noticed the following files created after successful attack exploiting the same osCommerce vulnerability: flop.php and fly.php (the latter executes arbitrary PHP code passed to it in a POST request)

You can also analyze your server logs (Google Analytics won’t do since rogue files don’t include the Analytics’ code). Check them for the above files. Take special attention to POST requests. You can notice attacks trying to exploit the osCommerce vulneravilities if you search for POST request to /admin/file_manager.php/login.php?a=1&action=save. (actual URL depends on the location of the osCommerse admin directory)

Finally, as Jim mentioned in his email, Google Webmaster Tools can help you detect this attack. Their “search queries” report has also proven to reveal many other security problems, so it’s a good idea to use GWT at least once a week.

Cleaning up

1. Remove all the rogue files.
2. Write-protect your site directories. Their permissions should be 755. (This is especially important on shared servers)
3. Restrict access to the admin directory. You can make it password-protected. Or you can allow only requests from known IP addresses. (Ask your hosting provider about the best way to do it)
4. If you store any passwords on your site (password to DB, to osCommerce admin, etc. ), you must promptly change them.

You can find many more osCommerce security best practices in this thread. Among other things, the post suggests that your rename the admin directory and remove the file-manager.php file and shows how to properly do it (these two steps can save you from this file_manager.php vulnerability). Must read for osCommerce users.

If your know any other good osCommerce security resources, please share them here in comments.

In the second part, I will provide more interesting details (incuding some black hat SEO tricks) about this attack. Stay tuned.

Related posts:

• Bety.php Hack. Part 2. Black Hats in Action.
• Rogue blogs redirect search traffic to bogus AV sites. Part 1.
• Rogue blogs redirect search traffic to bogus AV sites. Part 2.
• Black Hat SEO for Virus Dissemination
• Stats Anomaly Reveals Website Security Issues

Jan 11, 2009

[blog] update of the post about GNU GPL script. Added example of the new LGPL modification

Jan 13, 2009

[h-online.com] Update time: security patches for Windows and Adobe Reader (Acrobat)

[viruslist.com] The botnet ecosystem – “business” around botnets

Jan 14, 2010

RT @gcluley: Windows XP users: Have you updated Flash?

[milestone] According to Feedburner, there are 500+ subscribers to my blog. Wow!

Investigating an attack that uses osCommerce vulnerability. Will be blogging about it soon.

[minor update] Unmask Parasites v0.5.193 – better redirect detection

If you want more real-time experience, you can follow @UnmaskParasites on Twitter.

Related posts:

• Previous Tweet Weeks