StopBadware Blog

StopBadware welcomes new developer

Wed, 14 Jul 2010 16:18:00 -0400

StopBadware is pleased to welcome Matthew Shanley, our new lead developer! As we mentioned previously, our current lead developer, Brandon, will be heading off soon to tortue himself for three years as a law student.

Matt joins us from Constant Contact, where he worked on their web development team. He holds a Master’s of Fine Arts in Interrelated Media from Massachusetts College of Art and Design, a Bachelor’s of Science in Electronic Media, Art, and Communication from Rensselaer Polytechnic Institute, and also attended Cornell University. He's also an all-around cool guy, and we're glad to have him on the team!

Establishing expectations for AV vendors

Wed, 07 Jul 2010 11:02:00 -0400

At StopBadware, we're currently revising our guidelines for badware applications. The goal of these guidelines is to distinguish between applications that are badware (defined as "software that fundamentally disregards a user's choice about how his or her computer or network connection is used") and those that aren't. One major reason for distinguishing badware from non-badware applications is to help people make informed choices before installing software that may compromise their privacy or security.

It is in this context that we ask a question that has been troubling us: if a "legitimate" anti-virus or security product has to send data about your computer use (e.g., your web search or browsing history) back to the vendor's servers to protect you as promised, how clearly should that data usage be disclosed?

Historically, we have thought of surreptitious collection of this type of data as a badware behavior. But what if the data isn't really being collected or used in any nefarious way, and the transmission of the data is necessary to make the product work as intended?

Consider a product like McAfee SiteAdvisor, a free browser plug-in that informs you of the safety of websites as you visit them or while browsing through search results. SiteAdvisor has to query a McAfee server with the URL (or the hash of the URL) of every site you visit or find during a search. This means that, if McAfee wanted to (or if a rogue employee gained access), a profile of your browsing history could be compiled and tied back to your IP address. Yet this is never disclosed in any visible way prior to or during installation. In fact, it's not even in the Privacy Policy. (It could be considered covered by a vague provision in the EULA about the collection of personal information from your computer necessary to the function of McAfee's security products.)

This is not unique to SiteAdvisor. Many AV products now query a centralized database about URLs and/or executables to ensure users are protected. In our experience, most of these products fail to disclose this potential threat to a user's privacy in any meaningful way.

So, back to the question. Is this a badware behavior, one that in this case is being perpetuated by several well-respected software companies? Or is it reasonable to expect that users either know or wouldn't care that their security comes at the price of a company having access to some private data? Is it dependent on the trustworthiness of the vendor or the stated use of the data once it's been received? What should we expect as a minimum bar from AV vendors whose products behave in this way?

Please let us know your thoughts in the comments!

What We Learned at ThePlanet (AS21844)

Tue, 06 Jul 2010 12:03:00 -0400

After months of looking into the infections of AS21844 (ThePlanet) we've decided to wrap up our investigations for now. We have learned quite a bit from our communications with customers at ThePlanet. While no one from ThePlanet has spoken with us officially we have learned that they possess a direct feed of infected URLs from Google. This means that large customers of ThePlanet, such as HostGator, should have the ability to learn of infections directly from their provider. Also partners such as Skenzo should be able to use the same list to purge previously infected, and now abandoned, domains from their monetization framework.

For those of you that look at our Top 50 Infected Networks you'll notice that ThePlanet is still at the top. There really should be an asterisk up there since some of those infections shouldn't be counted. In particular the Skenzo related infections aren't actually a threat but are still listed due to a policy decision by the Safe Browsing team (which you can read about in a previous blog post). The best solution for now is to get this list to Skenzo so they can remove it from their framework. I am preparing this list for Skenzo right now but eventually, I hope, ThePlanet will provide it for them. To add some transparency to our research I'll paste the top infected org names as reported by ThePlanet's RWhois server:

WebsiteWelcome	7909
Skenzo FZE	2838
Unidentified	683
Site5 LLC	430
Bahram Boutorabi	192
SiteGround.com Inc.	171
webserver-a-rackshack.directi.com	166
Mochanin Corp	136
maktoob.com	119
server sea	115
Payam Torkian	115
Our Internet_ Inc	112

Don't forget that some of the 7,909 infections listed as HostGator (WebsiteWelcome is the org name used by HostGator) are duplicates. Our hosting providers tend to include multiple pages (and/or directories) per website host so these numbers require additional explanation. If one were to sort the infections by unique domains alone the count would be noticeably less. Applying some command line fu to one of the data files shows us the repetition is not nearly as high as it used to be. Only four domains are repeated more than 10 times.

count	domain
10	vadakarapally.org
12	attorney2traffic.org
16	e-sense.tv
17	niftysensex.com

HostGator has roughly 7,563 unique infected domains according to our last count and ThePlanet has 20,298 unique infected domains with their true number likely around 17,000 (adjusting for Skenzo). Where does that put ThePlanet in the context of our top 50 infected networks? Exactly where they are now actually. The next closest network is GoDaddy's AS26496 with 11,576 infections.

AV vendors say most badware sites are compromised

Fri, 02 Jul 2010 09:02:00 -0400

A recent report from Symantec reinforces the idea that most web-based malware is distributed via compromised, legitimate sites:

In 2010 so far, using the same approach, the proportion of malicious domains that are legitimate [i.e., set up for reasons other than distributing malware] has increased dramatically compared to last year – it’s now about 90%.

On a related note, Avast reports that, despite popular belief, adult sites are not carrying the load of malicious content:

...the statistics are clear - for every infected adult domain we identify there are 99 others with perfectly legitimate content that are also infected.

Everyday Internet users who are hearing this for the first time should take this as a wake-up call. Protect your computer. Protect your website. And recognize that, while making smart decisions about your Internet use is always a critical part of security, deciding which type of website you visit isn't as important as it once was.

Hat tip: H-Online via UnmaskParasites (Twitter)

WEIS Recap: Review of "Might Governments Clean Up Malware?"

Fri, 25 Jun 2010 15:01:00 -0400

Richard Clayton wrote on the more interesting papers presented at WEIS. In his paper “Might Government Clean Up Malware” [pdf] he suggests some possible goverment intervention to aid consumers in cleaning up their computers. His paper explains the reasons as follows.

1) ISPs do not have an incentive to act

2) The problem has public dimensions very similar to public health issues

3) The math behind this issue requires someone (the government) to seed the funding for experts to act

I agree with the contention that ISPs do not have incentives to act. Of the web hosts that I have communicated with not a single one has found it financially rewarding to deal with the problems I highlight. This really isn’t how it is supposed to work either. As Clayton points out “in principle the market should deal with ISPs who skimp on abuse activity.” Which put another way means that those ISPs who do actively clean up infections in their consumer base should have a better image and thus more business. The market should reward those ISPs who go out of their way to make sure that its customers remain protected. But as pointed out in many of the papers who grace WEIS and other conferences like it the margins are extremely slim.

Clayton’s paper even references another paper which makes the claim that a single interaction with a customer by an ISP will eat up all of the profit generated by that customer for the entire year. (In a footnote he mentions that this may be exaggerated but not greatly so)

The one issue I have with this paper is that it doesn’t quite cover the issue I’m most concerned about. And obviously that isn’t a valid criticism of the paper so much as a want from my side. The paper deals with helping out web “surfers” instead of web masters. Often the problem that I’m studying involves both levels. Web sites are infected because the web master’s personal computer was infected and the attacker gathered the login details from there. So fixing one may in fact help fix the other. But there is a major difference worth noting. The paper made a good point in writing about the hesitation of an ISP in engaging with its customers this way. When margins are thin profit is only acceptable through volume. So any actions which drive customers away in any number are dangerous. Accusing customers of infections isn’t always rewarded with gratitude. Customers can feel angry, ashamed, alienated or all three at once. It is difficult to find new options for bandwidth provision for many people. In Cambridge I have my choice between one cable company and two DSL (one who just resells the others at a mark up). And the change from cable to DSL (or vice versa) comes with considerable costs as well. But for web hosting providers there isn’t that much cost and there are a lot of choices. So the dangers of customer alienation for web hosting firms are very very high.

Australian ISPs on the right track

Thu, 17 Jun 2010 10:17:00 -0400

In early June, the Australian Internet Industry Association, an ISP industry trade group, published icode [PDF], a voluntary code of conduct for ISPs to follow to better fight bots on their networks. Like the previously-mentioned IETF draft, this document lays out a rationale for, and recommendations on how to implement, an ISP-level response to bots. Unlike the IETF draft, icode is a reflection of a coordinated effort by a large number of ISPs to buy in to a common framework for how to respond.

The icode framework has four parts:

Education. ISPs that adopt icode are expected to educate their customers about keeping their computers from becoming compromised.
Detection. ISPs can implement their own detection methods and/or get data from trusted third parties. Even better, they can get data from the Australian Internet Security Initiative, a government-led effort to centralize bot reporting by collecting bot reports from trusted providers and then distributing ISP-specific data daily to participating ISPs. (Wouldn’t it be great if we had something like this for infected URLs and hosting companies?)
Action. ISPs are encouraged to act on the information about bots, through whatever combination of customer notification, password resets, bandwidth throttling, walled garden quarantining, smtp blocking, or other measures they consider appropriate.
Reporting. ISPs are expected to report “significant cyber security incidents” to governments.

icode also recommends, though doesn’t require, that participating ISPs share threat data with each other, facilitated by the Australian CERT.

One could quibble over some of the details, but it’s clear that the Australian ISPs that created and will be adopting icode are light years ahead of most ISPs (and web hosting providers) globally in tackling the spread of malware.

Recent spikes in badware reports

Wed, 16 Jun 2010 16:12:00 -0400

We have generally seen an increase in the number of badware URLs reported by our data providers lately, but in the past few weeks, we’ve seen unusually big spikes on three autonomous systems (simplifying slightly, an AS is a set of networks operated by a single entity):

AS16276 (OVH) graph
AS9809 (Nova Network, China) graph
AS22489 (Castle Access) graph

We have attempted to notify all three network operators via abuse@domain_name. The report to abuse@nova.net.cn bounced, so if you know another contact address there, please let us know.

Most likely, these spikes in infection numbers are the result of either targeted attacks at these networks or opportunistic attacks that happened to find their way into large numbers of identically configured (or misconfigured) web servers.

StopBadware welcomes a new board member

Fri, 11 Jun 2010 11:21:00 -0400

StopBadware is pleased to announce that Paul Mockapetris will join our
board of directors.

Mockapetris created the Domain Name System (DNS), an essential part of
today’s Internet infrastructure, in the 1980s. He is now the Chief
Scientist and Chairman of the Board at Nominum, a global provider of DNS
and DHCP solutions to communication providers. He has previously served
as chair of the Internet Engineering Task Force (IETF) and as a program
manager at the Advanced Research Projects Agency (ARPA).

The board, chaired by PayPal CISO Michael Barrett, also includes Vint
Cerf, Esther Dyson, John Palfrey, Ari Schwartz, Mike Shaver, and
executive director Maxim Weinstein.

Press release: http://www.stopbadware.org/home/pr_06112010

Thoughts on WEIS 2010

Wed, 09 Jun 2010 10:58:00 -0400

Earlier this week I sat in on the Workshop on the Economics of Information Security. One of the more lively research papers presented was on insecurities in the online pornography industry. The paper ⁰ has also been written about by Threatpost ¹. As noted by Naraine’s article the team crawled just over 35,000 websites using an automated system. Interestingly the team discovered that about 3.23% of those sites were also infected with drive by downloads. One aspect of the research I was curious about was the degree to which those infected porn sites were popular. I spoke with Dr Wondracek after his talk to speak about the possibility of figuring this out. In my own thesis last semester I discovered that of the sampled sites we receive from our data partners less than 3% of the those were listed as popular by Alexa.

To determine this one simply downloads Alexa’s “Top 1,000,000 Websites” list ² and formats the list for comparison appropriately. (Alexa’s list uses canonical hostnames) Then simply take the intersection of that list (find which hostnames appear on list A and list B) and use that to create a percentage. This statistic should answer Pr(Popularity|Infection) or the probability of popularity given an infection.

[edit: moved links to bottom in footnote format for better readability]
⁰ http://weis2010.econinfosec.org/papers/session2/weis2010_wondracek.pdf
¹ http://threatpost.com/en_us/blogs/understanding-porn-malware-connections-060810
² http://s3.amazonaws.com/alexa-static/top-1m.csv.zip

A Detailed Look at ThePlanet's Infection Distribution

Tue, 25 May 2010 12:17:00 -0400

A reader asked a question in the comments of the previous blog post about ThePlanet regarding the distribution of infections. The reader wanted to know if the rest of the infections not attributed to Skenzo and HostGator were evenly distributed with less than 10% of the total infections. The type of distribution the reader was describing is called a Power Law distribution. A power law distributed population will look something like this:

courtesy of Wikipedia.org

For this blog post I'm using data pulled from early May 2010 on AS21844 (ThePlanet) and find the infection counts are roughly power law distributed. I've gone over the methodology to obtain this data in previous posts but it bears mentioning that I am using data distributed by RWhois organization names. Later in this post I will look at the same data distributed by only IP address so that it can be compared with other AS blocks. The raw infection counts look like this in graphical format:

The shape is precisely the same and it is obvious that there are a lot of organizations that have only single and double digit infections attributed to them. The area between 500 and 2500 is entirely barren with only a single entry beyond 2500. One of the issues when looking at data like this is the blur of data points below the 500 marker. One could simply strip away the outliers (those data points above 500) but in this particular case I don't think that is an effective way to view the data. In statistics people often "transform" the data to deal with this situation. This generally means they divide all the numbers by some constant which allows the data to retain the same shape but become easier to read. I generally favor the log/log method which means I take the log of each number and graph it that way. Log (or logarithm) is a mathematical function best explained by Wikipedia but best thought of as a number "reducer" that can be applied uniformly across data.

To get a sense of the scale the log of 2500 is 7.8, the log of 500 is 6.2, the log of 100 is 4.6 and the log of 1 is 0. Once the data is transformed we can see there is a little variance in the actual distribution but the fact that the line is sloping downward like that is another very good indicator of the power law distribution.