Building on our first article in the series, we continue to analyze the Google Safe Browsing List. In this part, we present more detailed statistics about the hashes seen on the blacklist and try to provide insight into what we observe.

Motivation
Understanding the behavior of infected websites is very important. This provides security researchers with strategies to help deal a blow to the bad guys and at the same time, provide website owners and administrators an idea of the current state of website security.

Since the publication of our last article in this series, we have received good feedback from our colleagues in security. We will attempt to incorporate their comments and concerns in this part of the series.

Methodology
We discussed the aim of this experiment and methodology in the last part of this series. We won’t repeat them here, but we encourage you to take a look at our first article in this series if you haven’t already read it!

Analysis
Below we present some graphs which provide more information about the analysis.

• Websites have a high probability of getting hacked on a Wednesday!

Websites have a high probability of getting hacked on a Wednesday!

• Websites have a high probability of getting hacked between 7-8 PM PDT.

Websites have a high probability of getting hacked between 7-8 PM PDT.

• On Monday websites get hacked most between 11 AM to 12 Noon, PDT
• On Tuesday websites get hacked most between 9 AM to 10 AM, PDT
• On Wednesday websites get hacked most between 7 PM to 8 PM, PDT
• On Thursday websites get hacked most between 10 PM to 11 PM, PDT
• On Friday websites get hacked most between 11 AM to 12 Noon, PDT
• On Saturday websites get hacked most between 1 PM to 2 PM, PDT
• On Sunday websites get hacked most between 11 AM to 12 Noon, PDT

Note: Most hashes which stay on the blacklist (over the 113 day period) seem to get added to the blacklist on Wednesday.

Conclusions
We have presented more interesting statistics regarding the appearance of website hashes on the Google Safe Browsing List. These statistics provide information which website administrators and owners can use better arm themselves with against attackers. We will continue analyzing the dataset to provide more interesting information. If you have any questions please add a comment.

At stopthehacker.com, we work hard to help you combat malicious hackers. If you would like to work with us, please drop us an email. You can also visit our services page to find out how we can help you, in fact you can even sign up for free services!

Till next time…

News, Report, Security analysis, blacklisting, google, malware, monitoring

Google’s efforts to clean up the Internet and provide a useful advisory to Internet users has been very successful. Nearly every modern browser now incorporates Google’s Safe Browsing List information, to prevent users from inadvertently visiting malware infested websites and phishing websites.

Motivation
In this article we will be analyzing the Google malware hash lists that have been published over the past few months in order to answer these important questions:

• How many websites get blacklisted each day?
• How many websites manage to get off the blacklist?
• How soon do websites get off the blacklist?
• How many never get off the blacklist?

These are practical questions which are often posed by frustrated, sometimes confused and angry website owners, time and time again at help forums, and via our contact page.

Resources
Google has done a good job creating detailed help content describing the process of blacklisting, as well as a group where website owners can ask for help. Additionally there are excellent resources like BadwareBusters where users can find volunteers to help them. We also participate in these groups.

Yet, there is still a demand for getting clear cut answers to some basic questions like the ones detailed above. In this vein we want to provide scientifically sound and statistically significant analysis of freely available information to provide clear answers to these questions. A small FAQ is also available on our site to answer questions from website owners and admins.

Goals
This series of experiments is split into multiple parts. This article presents a first look (part 1) at openly available data. The goal of the experiment is to understand:

• How many websites get blacklisted each day?
• How many websites manage to get off the blacklist?
• How soon do websites get off the blacklist?
• How many never get off the blacklist?
• How many websites fall back onto the blacklist?
• How much time elapses before a website falls back into the blacklist?

Methodology
For the purposes of this experiment, Google malware hash lists were collected from March 3, 2010 to June 1, 2010 (113 days). Malware hash lists were collected every 30 minutes. Each malware hash list contains the information in the Google malware hash specification. All hash lists were parsed and unique hashes were extracted and time stamped, and correlated with the malware hash list version.

Subsequently an analysis was conducted to answer the questions posed above. At no point was an attempt identify a website name from the hashes. Also, note that a single website can have more than one unique hash. For example: “www.abcd.com”, “abcd.com”, and “www.abcd.com/infected/” can all generate different hashes.

Brief Highlights

• Total number of unique hashes tracked: 688,602.
• Average number of unique hashes per day (over 113 day period): 6093.
• 25.8% of hashes never got off the Google blacklist.
  Each one of these unique hashes was deemed infected for over 3 months (greater than 113 days).
• 43% of hashes were listed exactly once as infected and managed to get off the Google blacklist.
  The average time each of these hashes was blacklisted was 13 days (89 days max).
• 2% of hashes were blacklisted exactly twice.
  Each one of these hashes was blacklisted, was then removed from the blacklist and then fell back in (the sites were hacked again). These sites remained infected for an average of 19 days (89 days max), and remained clean for an average of 17 days before being hacked again.

Analysis
It is clear from these initial results that a very large number of websites, nearly one quarter of the 6000 hashes added per day never make it off the Google blacklist. There are a number of reasons for this. One being that most webmasters, who may be good at website design and layouts, may not have the technical skills which are required to clean websites infected by malware and code injection attacks. We have also met website owners who are extremely business savvy, but lack the technical expertise to recover from a blacklisting event. The income lost due to business interruption in these cases is considerable.

We see that 43% of websites which get blacklisted manage to make it off the blacklist, but these websites suffer for an average period of 13 days.

Some websites manage to get off the blacklist and then fall in again. The average time for these “repeat offenders” on the blacklist is larger than the previous case. The time for which these “repeat offenders” stay clean is not very high, an average of just 17 days.

Conclusion
These numbers clearly show the current sorry state of website security. It is unfortunate that thousands of websites are affected every day. At stopthehacker.com, we strive to help combat this trend.  These issues need to be addressed specifically by services that currently are not readily available to the masses. To address this vacuum in the service space, and disrupt the security market stopthehacker.com provides its advanced Health Monitoring and Vulnerability assessment services for website owners. Our services take away the anguish which business owners face when their websites are attacked. Please visit our services page to find out how we can help you. In fact, you can even sign up for free services.

Further detailed analysis will be presented in the second part of this series. We will show detailed analysis of the data and will provide more insight on the implications of these observations.

Stay tuned for Part 2!

News, Report, Security analysis, blacklist, google, malware, monitoring

Hackers have been trying new tricks to obfuscate their malicious code and sneak it surreptitiously into benign websites. This trend is ever increasing as websites are now the weakest link in the entire malware chain. Hackers discover vulnerabilities in websites, exploit them to inject malicious bad code and voila – you have at your disposal a “trusted” website – lots of web surfers will drop by, and in turn get infected with the hacker’s malicious code. This vicious cycle of malware has become a very attractive modus operandi for the dark figures of the Internet.

Overview

This post will show an example of a trend about which we first blogged a few months ago. We will concentrate on the way hackers use “backup-sources” to infect visitors to a compromised website. If this does not make sense yet, hold on for just a few seconds more.

Quite recently we blogged about how hackers are using benign and useful JavaScript hosted locally on accounts managed by the website owner/admin to spread malware. Hackers have injected malicious code right into useful snippets of JavaScript which do everything from displaying menu buttons, drop down choices and much much more. Take a look at our previous findings: here.

An Example

Everyday we find websites which are infected with malicious code which follows the same principles. In fact, we now monitor over 1 million websites!

Website name: ipac-bd.org
Time of latest scan: 15:33:10 PDT on 2010/05/03

In this example, the website was hosting JavaScript which had been compromised by a hacker. The hacker had inserted various script elements at the very end of the benign JavaScript being used by the website. It’s likely that the website owner never saw this coming, and probably did not realize what was going on until he was blacklisted.

The “Backup” Strategy

Take a look at the example below: clearly the hacker used multiple websites which he has compromised as the “loading point” for the malicious payload injected as part of the benign JavaScript. It’s almost funny when one realizes the number of websites this hacker has used as backups for his malicious code.

In this example the hacker has used 30 different infected websites to try and load his malicious code. The frequency distribution of the infectious websites which the hacker has used to distribute his malware is present below. It seems that hackers understand the concept of a “backup-strategy” well. An interesting point to probe further would be to understand why the frequency distribution of the infected sites is the way it is.

Frequency distribution of infected websites used in the transmission of malware.

Read more…

Report, Security document.write, hackers, injection, malware, script

Search engines, like Google, Yahoo and Bing offer users the ability to scour the plethora of information on the Internet. These search engines index content on websites and often maintain cached copies of these sites so that, in the event that the site is unavailable, visitors can still view the contents of the website.

Unfortunately, the idea of page caching has not been implemented well. In fact, page caching has opened up new opportunities for malware. The primary problem being that, from a security perspective, when search engines cache copies of websites, they are storing any malware that is present on the site on their own infrastructure as well.

Hackers Exploit Search Engine Page Caches

Most large search engines use some kind of malware analysis to determine if a website is compromised or not. Google for example, has a well tuned system with high accuracy. In our meeting with the Google malware team, some months ago, we were glad to find that they were already aware of this problem. In the weeks following our interaction, cached copies of infected websites were no longer easily available via searches.

Not so long ago, we wrote an article about our efforts to alert Yahoo of the presence of malware in the cached versions of various web pages served up by their search engine. Our efforts were not successful, although the occurrence of malware in Yahoo cached pages seems to have gone down significantly. Perhaps our messages were not entirely ignored.

Recently, an article came up on ISC SANS discussing this very same issue.

Recently, we have found instances of Bing serving up malware in their cached pages. It seems that Bing’s malware detection methods are not able to reliably detect malware on cached web pages. This keeps Bing from securing cached pages which contain malware for its users. We have provided screen shots below as an example of the issue. In this particular case, the strain of malware found in Bing cached pages has been around since 2009.

Search Engines Ignore the Problem

Consider the case where a malicious individual deliberately infects a website with malware and Bing (or another search engine) indexes it. The malicious individual can then send out hyperlinks pointing to the cached web pages hosted by Bing. Any kind of “reputation-checking” for the cached link will confirm that the page is hosted by a reputable company, in this case, Bing (Microsoft). However, the malware will still be able to deliver its payload. Just in case you’re thinking, “my antivirus will protect me from the malware on the cached page,” you may like to read this article.

It is surprising to see that search engines like Bing, which claim to implement malware detection, cannot correctly determine if a cached copy of a web page hosts malware! In these cases, Bing ends up an excellent attack vector for malicious individual.

It remains to be seen if search engine companies will continue to serve up cached pages laced with malware at the same time as they are touting active scan and detection mechanisms. Let’s hope this article can get attention in the upper echelons of management at these large search giants and they start to pay attention to this problem.

Screen shots follow below:

Report, Security bing, cache, engine, google, malware, pages, search, yahoo

“Spain Busts Hackers for Infecting 13 Million PCs”

• Reuters via Threat Level | Wired.com

Users were targeted via a vulnerability in Internet Explorer when they visited websites infected with the malware. Spanish authorities shutdown the Mariposa bot-net on December 23, 2009 although the details of what is being called the “largest cyber-raid to date” are just being released.

Infection Statistics:

• 190 countries
• 40 of the largest financial institutions
• 50% of 1,000 largest companies

News, Security bot-net, credit card, Internet Explorer, malicious websites, malware, Mariposa, raid, Security

URL shortening services have become all the rage on the Internet. These services take a long URL as input and produce a short, easy to use, URL as an output. Simple! By virtue of their ease of use, millions of Internet surfers use them to post messages on twitter. In fact, URL Shortening services like bit.ly have garnered so much attention that even giants like Google and Microsoft have jumped onto the URL shortening bandwagon.

Case in point:

• Google: goo.gl
• Microsoft: binged.it

These URL shortening services are godsend for Internet surfers tired of copying and pasting long, ugly looking, URLs. But hold on a minute! All is not hunky dory in URL Shortening Land.

Due to processes inherent to “URL Shortening,” the original URL an Internet surfer might like to shorten is, for all purposes, being obfuscated. Is this a problem? Yes. Why, you ask? Consider the fact that people, not even necessarily tech-savvy ones, have learned to double check the links present in their emails and on websites. They even have help from various browser plugins, but in general, users are smartening up. When these same people see “shortened” links, they have no way to make a judgment call on whether visiting the link is safe, or not. For example, you may recognize www.stopthehacker.com as being a benign, safe to visit link, but what about bit.ly/oJMrP or bit.ly/dc38ze?

Articles published from credible sources, like ISC SANS, show that URL shortening services, when compromised, can provide an excellent mechanism for malicious hackers to infect unsuspecting visitors. Criminals use these services to bypass Google’s Safe Browsing service, which is used by popular browsers.

To combat this growing menace, URL shortening services have partnered with security companies to identify malicious URLs and websites. Some of them even use the SURBL blacklists to identify if someone has tried to link to a malicious website.

This article attempts to identify the effectiveness of security measures put in place by the various URL shortening services.

This experiment answers the following questions:

• Do URL shortening services have any kind of security measures in place?
• How effective are these security measures?

The 25 URL shortening services evaluated in this article are listed below:

We compare 25 URL shortening services listed below. Each URL shortening service is analyzed to measure the effectiveness of their security measures. We use a two stage process to evaluate the security implemented by each service.

snipr.com
budurl.com
bit.ly
short.to
twurl.nl
chilp.it
fon.gs
ub0.cc
snurl.com
fwd4.me
short.ie
a.gd
hurl.ws
kl.am
to.ly
hex.io
tr.im
cli.gs
urlborg.com
is.gd
sn.im
ur1.ca
tweetburner.com
tinyurl.com
snipurl.com

Experiment methodology:

An initial corpus of 932 websites was obtained from Malware Patrol a well respected source of information about malware infected websites, which receives nearly 3,500,000 hits/month. This experiment was conducted between February 2nd and February 4th, 2010.

For each URL obtained from Malware Patrol, we attempt to create shortened URLs for each site domain and full URL using each of the 25 services.

We denote a service as Stage 1 Compliant if it appears to use a security service or blacklist to identify malicious domains and does not allow a user to create a shortened link to any infected domain. Does the URL shortening service allow a user to create a URL pointing to a malicious domain (e.g. http://www.badsite.dom)?

We denote a service as Stage 2 Compliant if it uses a security service or blacklist to identify malicious domains and does not allow a user to create a shortened link to any infected domain or malicious full URL hosted on that domain. Does the URL shortening service allow a user to create a URL pointing to a malicious link hosted on a malicious domain (e.g. http://www.badsite.dom/badfolder/badfile)?

We present the most interesting results in brief:

• Approximately 68% of URL shortening services were Stage 1 Compliant.
• Approximately 56% of URL shortening services were exclusively Stage 2 Compliant.
• Approximately 52% of URL shortening services were both Stage 1 Compliant and Stage 2 Compliant (see graph below).

Observations on specific URL shortening services:

• bit.ly seems to favor blocking malicious domains rather than specific links.
• fwd4.me, hurl.ws and urlborg.com seem to favor blocking malicious links rather than specific domains.
• bit.ly failed to qualify as Stage 2 Compliant due to 0.5% of tested URLs.
• fwd4.me failed to qualify as Stage 1 Compliant due to 9.8% of tested URLs.
• hurl.ws failed to qualify as Stage 1 Compliant due to 0.3% of tested URLs.
• urlborg.com failed to qualify as Stage 1 Compliant due to 0.3% of tested URLs.

Venn Diagram depicting URL filtering capabilities of URL shortening services. Only about half of the most popular URL shortening services are effective at blocking malicious URLs.

Stage 1 Compliant and Stage 2 Compliant services:

budurl.com
cli.gs
fon.gs
hex.io
is.gd
kl.am
sn.im
snipr.com
snipurl.com
snurl.com
to.ly
tr.im
ub0.cc

Deeper security issues remain:

It seems that popular services like bit.ly, which do try to use blacklists in order to prevent malicious hackers from using their services and pointing to bad websites, can still be easily fooled by chaining together shortened URLs created by another service. We have found that if a malicious user can create a shortened URL using a service that does not implement blacklist checks or is not effective, then a service like bit.ly can be tricked into redirecting the visitor via the malicious shortened URL to a malicious domain. Effectively, users can be redirected to a malicious site regardless of bit.ly performing all its checks. See the appendix for an example below (wget log).

Conclusion:

This limited experiment shows that URL shortening services have a long way to go before Internet users can trust them to deliver safe links. About half of the most popular URL shortening services seem to be somewhat effective at blocking access to well known malicious URLs that can be found on blacklists. It remains to be seen if these URL shortening services can improve and provide a safer web experience for their users.

Read more…

News, Report, Security bit.ly, malware, ow.ly, tinyurl, url shorteners

Malicious hackers have, for many years, been offering services to unscrupulous individuals and companies for monetary compensation. With the growth of Email Spam advertising everything from medical supplements to cars and lottery tickets, email scrubbers and filters have taken the game up a notch by implementing ever increasing layers of complexity to cut down on such spam. In turn, hackers have started to focus on advertising spam, such as medication and fraudulent scams by compromising web-based message boards and forums.

Hackers employ two basic techniques:

• Creating large numbers of users on forums. These accounts are then used to post spam on the message boards.
• Exploiting Web Application vulnerabilities in the software used to run the forum.

Approximately two weeks ago, Lenny Zeltser, from ISC SANS, posted an informative article about online pharmacy ads popping up on message boards. In this vein we have conducted a limited experiment with about 14,000 websites which contain spam announcing online pharmacies.

The aim of the experiment:

• What percentage of websites which advertise online pharmacies are message boards and Internet forums?
• What Web Applications, e.g. CMS packages, are used on the message boards that are compromised?

We believe this will provide us with a rough estimate of how focused are hackers toward using message boards and forums on the Internet to advertise spam. From another perspective, it will provide us some idea of how vulnerable websites are if it hosts a message board or forum from being abused by hackers.

Testing methodology:

We have used Google to mine the websites which contain certain keyword patterns such as “buy zocor online”, or “buy brand kamagra online” etc. Once the links suggested by Google were mined, each of the websites was tested against Google’s Safe Browsing List to determine if they had hosted malware (according to Google). Next, an analysis was done to determine if the link(s) mined from Google pointed to a forum or message board. This was done by identifying the presence of multiple strings inside a link. For example, if a link has the keywords “topic”, “view”, “thread” or similar keywords, including characters associated with dynamic page generation, it is probably hosting a message board or forum.

The test was conducted between January 21st and January 23rd, 2010.

Popular software packages installed on compromised forums and message boards.

We present the most interesting results below:

• 47.9% of websites displaying “online pharmacy” spam are message boards and forums.
• None of the websites advertising “online pharmacy” spam were listed on Google Safe Browsing List.
• 20.28% of forums displaying “online pharmacy” spam were using Jquery.
• 15.73% of forums displaying “online pharmacy” spam were using phpBB.
• 11.54% of forums displaying “online pharmacy” spam were using WordPress.
• 10.84 % of forums displaying “online pharmacy” spam were using Mootools.

These results and other software packages, helper-scripts, tracking-code are depicted in the graph presented above.

This small experiment shows that a high percentage of websites displaying online spam campaigns are message boards or forums. This indicates that there are many unsecured software installations and older software packages still in use which are often exploited by malicious individuals to post spam. Further, it seems that most sites which were hacked are using jQuery. This supports our previous observations regarding jQuery scripts being used to push malware to unsuspecting visitors.

Read more…

Company, News, Report google, malware, online pharmacy spam, safebrowsing, spam

Yahoo’s cached pages can be distributing malware.

Yahoo, has allowed users, for several years, to use the “cached pages” options displayed along with its search results on Yahoo-Search. Yahoo has partnered with McAfee’s SearchScan to provide safer searches since about May 2008. This is all good. The intention of providing safer searches to visitors is very noble. Google too, has led the pack in this direction by opening up its SafeBrowsing API and by providing visual warnings in search results boldly claiming “Warning visiting this website may harm your computer”.

Stopthehacker.com  has tried to communicate with executives at Yahoo since April 2009 about the potential problems that we have been observing in their cached pages. This has not been met with any real response.

The problem is simple, but very important. Cached versions of web pages displayed on Yahoo Search often contain malware code embedded in them. This is a phenomenon that we have observed repeatedly.

Consider one of our many attempts at communicating this issue to Yahoo (message shortened for brevity).

We have found that Yahoo’s cache results, even with SearchScan on, do not detect the presence of malware on its cached copies of webpages. I have attached some screen shots which prove the point.

Our scanners flagged the code in the cached copies right away. The site in question, for which I looked up Yahoo’s cache is http://www.xxxxxxxx.com

More info on our response to this site is available at http://xxxxxxxxxx.xxx/**stripped**

The screen shots attached with this post show an example of a website which was scraped by Yahoo’s spider, indexed and cached and then when accessed via its search results, pops up the malware code. There does not seem to be any kind of sanitization/scrubbing process going on in the background.

Worryingly, this problem gives rise to a very effective attack vector, where a malicious individual can compromise a site or even simply create a site that contains malicious code. Once the site is crawled by Yahoo’s spider, and is loaded in the cache, the link to this cached page becomes an excellent attack vector to use for social engineering, as it carries the sense of security that comes with Yahoo’s brand name. No need to exploit XSS/CSRF, no back-breaking hours of toil and sweat need to be put in discovering flaws in a site. Just get the infected pages cached in Yahoo! and voila, you have a live exploit launched from official Yahoo property.

Consider the fact that Yahoo search has 18% of the search market in October 2009, the number of visitors to the site is non-trivial! Moreover, Yahoo’s brand image can suffer, if this phenomenon becomes more wide spread or well-known.

Given my failed efforts to discuss this with Yahoo, at this point, I can only hope that this does not become more popular.

I cannot understand how Yahoo is employing SearchScan technology to provide safer search results to visitors, yet fails at the back-end to identify cached pages loaded with malware.

Till next time.

News, Security cache, injection, malware, yahoo

It has been a busy day. Lots of interesting things have happened over the course of the last few hours. One interesting issue which we faced today was when trying to help out on badwarebusters.org today. It seems that one of our scans popped up a script hosted by Site Meter as potentially malicious. This gets interesting because this kind of code acts as a tracker to measure how many hits a site gets, where the users are coming from, how much time they spend on a page etc. The important point being this code is deployed on tons of websites. Some of the interesting websites I visit also have this code. I was intrigued to see why this popularly used counter was popping up as suspicious.

We had a look at our logs, local dumps and analysis and saw that the Site Meter script was pushing in an iFrame pointing to dg.specificclick.net using a body-onload event to trigger the event. Interestingly, dg.spe cificclick.net, has been associated with multiple cases of Internet misdemeanor. [0] [1] [2] [3] [4]

It is surprising to see companies that have widely established customer bases to link to questionable content.

The code from the Site Meter script is presented below, the offending part is clearly visible.

// Copyright (c)2006 Site Meter, Inc.
// <![CDATA[
var SiteMeter =
{
 init:function( sCodeName, sServerName, sSecurityCode )
 ** code removed for brevity **
 onPageLoad:function()
 { 

 var newIFrame = document.createElement("iframe");
 newIFrame.frameBorder = 0;
 newIFrame.width = 0;
 newIFrame.height = 0;
 newIFrame.src = "http://dg.specif icclick.net/?u=" + encodeURIComponent(document.location) + "&r=" + encodeURIComponent(SiteMeter.getReferralURL()); 

** code removed for brevity **

SiteMeter.init('s29rottweilers', 's29.sitemeter.com', ''); 

var g_sLastCodeName = 's29rottweilers';
// ]]>

The SafeBrowsing report from Google about this site follows:

• Google SafeBrowsing report – www.schwarzerwaldrottweilers.com

Read more…

News, Report, Security iframe, injection, malware, sitemeter, suspicious code