StopBadware Blog

Twitter unveils a stick, but where's the carrot?

2010-03-15T14:13:45-04:00

SC Magazine reported on this blog post by the Twitter team about the microblogging service’s plan to “detect, intercept, and prevent the spread of bad links across all of Twitter.”

From what I understand, links included in direct messages and e-mail notifications will automatically be shortened using Twitter’s own twt.tl link-shortening service. Users who click the links will be redirected through Twitter to the original links, unless the links are known to be bad (e.g., phishing), in which case the user will be… well, I’m not sure what will happen, as that’s not explained. I’m assuming the user will receive some sort of interstitial warning telling him/her that the requested site was a known scam and s/he shouldn’t visit it.

StopBadware generally supports efforts to warn users about known badware sites, though in this case I’ll leave it to others to debate the trade-off between the security benefits and the privacy implications of redirecting users through Twitter’s servers to visit links. I’m more interested in what users and website owners are able to learn from the new system.

If I click on a link to a blocked site, do I see a warning message? If so, do I see the original URL so that I can choose to ignore the warning and visit the site at my own risk, or at least learn what site was trying to scam me? Does the warning message take advantage of this great teachable moment to educate me about the dangers of phishing and badware websites and how to protect myself? What if it’s my site that’s being blocked, because my site has been hacked wtihout my knowledge? Is there any information to help me understand what’s happening and what I can do about it?

The Twitter blog post doesn’t provide any details or screenshots of its new system, so I don’t know the answer to these questions. Do you? If so, please share in the comments.

New feature: report a badware site!

2010-03-10T15:01:26-05:00

Today, StopBadware announces a new feature that brings us a step closer to the kind of open, collaborative intelligence about badware websites that we strive to build. Through our online community site, BadwareBusters.org, individuals can now report suspected badware sites to our Badware Website Clearinghouse.

Community reports will appear in our searchable Clearinghouse (listed separately from our corporate data providers’ reports), allowing researchers, site owners, and other interested parties to get a consolidated view of all badware reported on a given site. Community reports will also be shared with our data providers and made available to other organizations and researchers that we believe will use the data to help make the Internet safer. This means that anyone can submit a URL once and have confidence that it will reach a broad audience.

In the future, we might try scanning submitted URLs with third-party tools and services to verify reported badware. We might also offer a notification service for website owners to learn if their site has been reported. Do you have other ideas for how we might maximize the use of publicly reported URLs? Let us know in the comments!

Quick poll: How do you prefer to follow StopBadware?

2010-03-10T10:01:53-05:00

Google Blogspot Infections

2010-03-02T15:26:55-05:00

It is unusual to see Google’s AS block listed on our Top Infected Networks page for so long. Generally the infections are not the result of blogs being attacked and successfully infected but rather mass fake accounts being setup on the free blogging service and filled with links to malware. The cycle we are used to seeing is a surge of attacks followed by some tweak of the registration system to prevent attackers from setting up fake accounts.
It is also worth noting that the detection of infected blogs on the Google owned service is particularly high since the scanning takes place at a higher frequency. I started to dig into these infections a little deeper and started comparing lists of URLs from different dates going back to December of last year. In each case the intersection (or overlap) was nearly zero. That is to say the list of infected urls are almost entirely new urls for each sample. This would suggest that attackers have figured out how to continue to bypass the registration system and are registering new blogs as fast as Google can take them down. Maybe a little faster.
If you look at the curve of the infections it is pretty obvious the attackers have been gaining a lot of ground. From only 1,000 infections in November 2009 to nearly 8,500 by years end. There was a short reprieve followed by a sudden and non stop surge since the start of 2010. I hope to do some content analysis in the future and determine what the attackers are uploading to these blogs. This is a developing story so stay tuned.

[DISCLAIMER: Google is a data partner and generous sponsor of StopBadware. I am doing my best not to sugar coat this story and treat Google the same as I would any other victim of attackers on the Internet]

The Krypt Story

2010-02-23T07:32:26-05:00

About two weeks ago we noticed a huge spike of activity on AS 35908 which belongs to Krypt Technologies. If you click on the AS link you will see the actual numbers we recorded at StopBadware. 15,000 infections came out of no where and spiked to 20,000 in the matter of 48 hours. I tried contacting them via email but I imagine the abuse inbox had been lighting up due to complaints. As I was researching the network for other avenues of communication I got lucky and noticed they had recently set up a Twitter account! I fired off a polite tweet describing the situation (not entirely easy to do in 140 characters). I had to tweet publicly since they hadn’t auto-followed me when I started following them. I received an immediate response both publicly and privately stating they would ping their abuse team. I also tried a few hidden channels (mostly private mailing lists) to try and raise communications.

Very soon after I received an email from the manager of the abuse team. I explained our intentions and the types of information we could deliver to them. Immediately I sent a list of the infected URLs and a distribution analysis of the list as IP addresses. It showed that only a few server contained the majority of the infections (this is called a long tail distribution).

Servers were quickly disabled. It was honestly one of the faster responses I’ve seen from a service provider. So far over 100 servers have been disabled by the abuse team at Krypt! The attacks don’t seem to have subsided but they are clearly winning the war right now. During a follow up email I ran the infection numbers on their AS again and noticed that 5,000 infections had suddenly appeared on another IP address. That server is also getting shut down. All told I’m really happy with the response time and understanding from the abuse team at Krypt. I wish more providers would react as quickly as they did. One interesting detail about the urls we noticed was that a number of them resolved to IP addresses at Krypt and at Softlayer. Softlayer is also under an immense attack. I think there is something more to this and I’ll continue investigating this week.

New IP address reports

2010-02-18T11:04:36-05:00

A few months ago, we announced new data reports showing our aggregate numbers of reported badware sites by Autonomous System Number (ASN). Today, we are pleased to announce similar reports showing data based on IP address.

The Top 50 report shows the 50 IP addresses with the largest number of reported badware sites, updated daily. Individual reports, which can be found by clicking an IP address in the top 50 or by searching our Clearinghouse, provide a graph (and downloadable .csv) of an IP address’s infection numbers over time.

Here’s a sample report:

We hope these new reports will be helpful to the community. Please share any feedback you have in the comments or at contact@stopbadware.org.

Lessons from the auto-update web chat

2010-02-10T14:36:52-05:00

This afternoon, we hosted a productive web chat about automatic updates and their impact on user security and control. A few interesting themes emerged during the conversation:

There is an important distinction to be made between updates that fix vulnerabilities and those that add or change product features. The former can/should be treated as a public health issue, especially when one user’s issue can lead to other users being hurt (e.g., a browser vulnerability that could allow a computer to become a spambot). The consensus of the participants seemed to be that automatic updates to fix bugs or vulnerabilities should be pushed more aggressively and should require a lower level of disclosure and user interaction than feature updates.
Enterprises and other managed computing environments (e.g., university computer labs, government netowrks, etc.) experience automatic updates very differently than end users. In these environments, IT staff may need to control bandwidth usage and to test applications for compatibility with internal systems prior to pushing updates. Software vendors can help IT staff by providing tools and configuration options that facilitate centralized update management. In addition, there was a call for a standardized cross-vendor protocol to make this easier.
Users in areas with low bandwidth (rural areas, developing countries, etc.) often disable auto-update features to conserve bandwidth and, as a result, use insecure product versions longer than users with ready access to high-speed broadband. Software vendors can help by minimizing the bandwidth necessary for patches (e.g., distributing differential updates instead of full new product versions), clearly distinguishing between security fixes and feature updates, and providing options for bandwidth throttling. Educating users about these bandwidth-saving features when they are available would increase user participation.
In the case of applications targeted at individual (non-enterprise) users, there was little concern about disclosure of automatic updates as they relate to bug and security fixes. On the other hand, participants felt that feature updates should be clearly distinguished as such and that an auto-update system that plans to include feature updates should disclose this behaivor.
There was consensus that, for a variety of reasons, including those alluded to above regarding enterprise and low-bandwidth environments, users should have the ability to disable auto-update features. That said, it was pointed out that the option to opt out of security updates might be better hidden in a configuration menu than presented as a choice at installation, which might lead to people opting out too frequently.
Consensus was clear that automatic security update mechanisms should not be used to enforce software licensing, as these create a barrier to people fixing security vulnerabilities that may affect not only them, but also others on the network/Internet.
It was also agreed that automatic updaters should not be used to push other products on users, as this can decrease trust in the update system.

A transcript of the text-based portion of the chat can be found here. Unfortunately, I neglected to record the audio portion, so the transcript is missing some of the great comments that people made, but the text transcript does capture many important points. Speaking of comments, please share your additional thoughts on this topic here in the blog comments, or feel free to e-mail us at contact@stopbadware.org.

Reminder: register now for Wednesday's web chat

2010-02-08T16:13:43-05:00

Don’t forget to register for Wednesday’s web chat about automatic update mechanisms and their effect on end user security and control. More information about the topic and how to register can be found in the original blog post.

Prevalence in web infections

2010-02-01T23:42:21-05:00

I’ve been very interested in applying epidemiology to the world of malware lately. Prevalence is quite simply the number of infected in a given population at a specific time. More specifically it is a ratio of infected over the number of people susceptible. When you look at the data we provide publicly we show you the number of infections for IP addresses and AS blocks. What we don’t show you however is the size of the networks that are infected.
This is something that is likely to change soon. I’m proposing that we start displaying the size of the network by summing up the total number of IP addresses under control of the AS derived from CIDR blocks. This would be fairly trivial for us to do but has some drawbacks. Firstly, CIDR blocks show the size of the network in terms of how many IP addresses are grouped together. It says nothing of how many web servers exist in that range or even how many of the IP addresses are active. This would be similar to saying there are 100,000 houses in zip code 02138 but not saying how many people live in those houses (if any at all). However I’m convinced that knowing the number of IP addresses under the control of an AS block is important.
For instance our page reporting on the top 50 AS block currently shows ThePlanet and Chinanet-Backbone in the number 1 and 2 positions. They have ~16,000 and ~15,000 respectively. However AS4134 (Chinanet) controls 70M IP addresses compared to only 1.5M for ThePlanet. The difference in those two numbers is staggering and it tells me that the number of infections sustained at ThePlanet is abnormally high.

Join us for a web chat about auto-update mechanisms

2010-01-28T10:50:17-05:00

In the past couple of years, auto-update mechanisms that allow software applications to check for and install patches or new versions have become far more prevalent. Some software vendors have looked to push auto-updaters beyond the traditional “an update is available, do you want to install it?” format. Last year, Apple began using its updater to push additional software applications. Google’s Chrome browser silently installs updates, including new major versions, with no user interaction or notice. A new updater for Adobe Reader appears to be a hybrid of Chrome’s silent installer and more tradiitonal updaters.

On Wednesday, Feburary, 10, at 1pm EST, we will be hosting a public web chat to discuss auto-update mechanisms from the standpoint of balancing their security benefits with questions about appropriate disclosure and user control. Brad Arkin of Adobe will be participating, and the Google Chrome team has been invited to join, as well. The chat will incorporate VoIP audio (requires headset or microphone/speaker on your computer) as well as text, using dimdim’s Flash-based web conference system. Pre-registration is free and recommended. Just enter your e-mail address in the widget below. Feel free, as well, to help publicize this chat by clicking the “Share Widget” link.