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.

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.

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.

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.

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.