The Coreflood takedown: building a better, broader botnet response

Posted on April 15, 2011 by imeister

Wednesday’s court-sanctioned takedown of the Coreflood botnet by the Department of Justice and the FBI has made big headlines in badware news. This is the second high-profile takedown to make it through the U.S. court system in as many months; Microsoft persuaded a court to allow them to take down the Rustock botnet only a month ago. But there are some key differences in the legal posture and tactics used in Coreflood that should inform future efforts to take down botnets — and invite further questions.

  1. Government in the driver’s seat. The biggest procedural departure in the Coreflood action is the party bringing it: a government attorney, not a private corporation, is asking the court system for relief. When Microsoft filed suit in a federal court in Washington to shut down the Rustock botnet, it was not enough simply to present the court with strong evidence that illegal activity was taking place and that its proposed takedown tactics would stop it — it had to carry the burden of showing how Microsoft itself was harmed by the botnet’s activities. It took Microsoft an entire month to obtain the restraining order it required. The U.S. Attorney in the Coreflood action, by contrast, benefited from the legal presumption that the government has standing to act to stop Coreflood’s illegal activity (wire fraud, bank fraud, and illegal wiretapping): within two days of filing its complaint, the necessary restraining order was issued.
  2. Disabling the botnet, not just its heads. When Microsoft took down the Rustock botnet, it did so by seizing the U.S.-based command and control servers it had identified and disabling the domain names and DNS records Rustock used to route bot traffic to the servers. This left the Rustock botmasters unable to issue further orders to the compromised computers and eliminated the immediate threat Rustock posed; however, it left no obvious path for identifying and targeting individual bots for cleaning. In the Coreflood action, the court’s restraining order directed registrars and DNS providers to point the seized domains to two specially designed servers set up at the Internet Systems Consortium. The servers transmit a ‘kill’ signal to botnet members and log their IP addresses for followup. This approach transfers, rather than destroys, control of the botnet to law enforcement, and in so doing preserves the ability to identify botnet members as they ‘check in’ with the new command and control servers.
  3. Working with partners to clean affected computers. In addition to partnering with the Internet Systems Consortium, the government also coordinated the Coreflood shutdown with Microsoft. In a security bulletin released yesterday, Microsoft provided full disclosure of the workings of the Coreflood badware and updated its free Malicious Software Removal tool to allow affected users to clean their computers. According to Wired's Threat Level blog, the government intends to provide lists of affected U.S. IP addresses (which the government claims make up 1.8 million of the 2.3 million Coreflood botnet members) to ISPs so that users with compromised computers can be notified.

At this point, the Coreflood takedown seems like a valuable re-imagining of the legal and logistical processes used in past takedowns. While some, including the EFF, have expressed concerns about the government issuing commands to U.S. computers via a specialized command and control server, the question begs: is there a more appropriate party to request relief when U.S. law is violated? The takedown order and planned government response bear many of the hallmarks of the sort of collaboration StopBadware believes is critical to fighting badware. The government has enlisted registrars, registries, and DNS providers to wrest control of a botnet; Microsoft, to provide a freely available cure for infected computers; and is about to enlist ISPs to encourage users to rid themselves of badware.

It’s an object lesson in the need to coordinate among stakeholders in the Internet ecosystem, and it acknowledges that infected users and computers are important participants in that ecosystem. While the criminal activity enabled by botnets like Coreflood is the most obvious target for remediation, every member of a botnet is, by definition, a computer with unpatched and exploitable software vulnerabilities that can enable future badware infection.

Will ISPs succeed in notifying their users about Coreflood infections? Will users be able to clean their computers effectively? The success — or failure — of this initiative should reveal a lot about the effectiveness of holistic approaches like this one.

Tagged , , , | Comments Off

StopBadware and Qualys team up to fight badware

Posted on March 29, 2011 by ccondon

The good news is piling up at StopBadware, and today we’re happy to announce that Qualys will be joining the StopBadware roster as our newest partner. Qualys, a leading provider of software-as-a-service IT security risk and compliance management solutions, will be working with us to reduce the spread of malware and find innovative new ways to protect the Internet ecosystem. They join an ever-growing list of industry leaders who support StopBadware, including our current partners Google, Mozilla, PayPal, Nominum, and Verizon. 

Qualys’ products are used by companies worldwide, and they share our keen interest in malware detection, analysis, and prevention. The company is especially supportive of StopBadware’s stance that fighting malware requires collective action and shared intelligence; to this end, they’ll be giving us access to Qualys’ automated malware detection service in addition to providing financial support. We’ll use Qualys’ tools and data to expand our reporting capabilities, and Qualys will draw upon StopBadware’s experience educating key constituencies to build a stronger anti-malware community. StopBadware and Qualys have similar philosophies about how to best protect the health of the Internet, and we expect this new partnership to yield great results. 

We’re equally excited to announce that Philippe Courtot, Qualys’ Chairman and CEO, has accepted our invitation to join the StopBadware Board of Directors. Philippe is a highly respected member of the security community, and we’re glad to have him as part of our board. We very much appreciate the level of commitment Philippe has demonstrated to StopBadware’s mission, and we’re confident the community will benefit from the work we’ll be doing together.  Welcome, Qualys and Philippe!

The full press release is available at http://stopbadware.org/home/pr_03292011. 

Comments Off

Public release of StopBadware’s Best Practices for Web Hosting Providers: Responding to Malware Reports

Posted on March 15, 2011 by ccondon

After several eventful months of writing, ruminating, revising, and listening to feedback from the security industry and our web hosting working group, we are proud to announce the public release of StopBadware’s Best Practices for Web Hosting Providers: Responding to Malware Reports. We had some pretty lofty goals in starting this project: we wanted to address the hosting industry’s lack of consensus about how to respond to malware reports; we wanted to enable transparent, productive discussion among hosting providers, security researchers, and policymakers; and we wanted to come out of it all with a realistic, complete set of best practices that could be implemented effectively, whether by a small reseller or a large operator. Through a lot of hard work, and with invaluable insight from our working group and the community, we’re confident that our final best practices document achieves every one of those goals.

It’s unfortunately commonplace for malicious actors to create websites that seem legitimate, but that actually contain or link to malware. Oftentimes, the goal of these malicious actors is to spread malware by compromising other websites and infecting those sites’ visitors. Security researchers or concerned users routinely report these malicious sites to web hosting providers, but there can be a slew of questions and concerns surrounding response to malware reports, even when hosting providers have every intention of protecting their customers. Is the malicious URL in the report definitively within the provider’s zone of control? Does acknowledging a report carry legal implications for a hosting provider? What if the security researcher obtains new information and needs to follow up on the original report? StopBadware’s best practices provide a high-level framework for hosting providers who are committed to protecting their customers and acting as good Internet citizens; the Practices set universal guidelines for what steps hosting providers can—and should—take upon receiving a malware report.

We received a lot of enthusiastic participation while we were developing the Practices; likewise, we’ve received a great deal of support leading up to this public release, including and especially from some of the hosting providers who participated in our working group. We’re optimistic about the Practices’ potential to highlight the positive impact hosting providers can have when they commit to protecting users responsibly. And we’re extremely excited about the focus this project has brought to the fight against badware. We’d like to extend our most sincere gratitude to both our sensational working group and the community for the time, thought, and openness they dedicated to this project.

In addition to the best practices, we’ve created some extra materials to help web hosting companies understand and more effectively implement the Practices–all of which are freely available for your perusal.  We also have physical best practices packages for purchase; to support StopBadware’s Practices, check out a technician’s kit or  a larger team kit! StopBadware’s Best Practices for Web Hosting Providers: Responding to Malware Reports is available in full at http://stopbadware.org/home/webhost. You can read the full press release here.

We have several other significant projects in the works right now; you can expect to see much more from us in the coming months. Thanks for your continuing support!

 
 
**Update: We were remiss in not thanking Tucows for their support throughout this process and their help with publicity. Our apologies to Tucows–of course, you have our gratitude for everything you've provided during this project!
Tagged , , , | Comments Off

Spend the summer fighting badware!

Posted on March 10, 2011 by Maxim Weinstein

We are now accepting applications for a summer internship here at StopBadware. Would you like to:

  • learn how to spot badware in a website?
  • contribute to the security community’s knowledge of badware trends?
  • hang out with cool geeks (and Caitlin, who is cool, but more of a nerd than a geek) here in Harvard Square?

If you answered yes to one or more of the questions above, then check out the full internship description here. We’re hoping to have someone lined up by April 15, so get that application in quickly if you’re interested!

Tagged , , | Comments Off

StopBadware announces partnership with Verizon

Posted on March 4, 2011 by ccondon

StopBadware is delighted to announce today a new collaborator in our fight against badware: we enthusiastically welcome Verizon as our newest partner! Verizon joins a growing group of industry leaders who support StopBadware, including Google, Mozilla, PayPal, and Nominum.  Verizon has committed to a three-year partnership with StopBadware, during which we’ll work together to protect small businesses, expand educational resources for users, and develop new security strategies for the mobile space.

Verizon is a global provider of broadband and other communications services for mass market, business, government, and wholesale customers. The company has voiced its commitment to both securing its own network and helping to ward off security threats for others in the Internet ecosystem, and we at StopBadware are eager to combine our own expertise with Verizon’s  to better defend Internet users. We’re particularly excited about drawing on Verizon’s resources and knowledge to bolster conversation surrounding the mobile malware threat and innovative ways to combat it, like identifying new approaches to securing mobile handsets. Verizon, in turn, will take advantage of StopBadware’s experience creating tools and educational resources for users and setting standards for the security industry.

We’re pretty excited about this new partnership. Our relationship with Verizon brings unique opportunities to spread our badware-busting message to an even wider audience and to expand our work in the mobile field, among others. We’re looking forward to working closely with their team, so look this way in the coming months (and years!) to see what our collaboration yields.

The full press release is available at http://stopbadware.org/home/pr_03042011.

Comments Off

A different story about Android malware

Posted on March 3, 2011 by Maxim Weinstein

The security world is abuzz about the recent malware apps discovered in—and removed from—the Android Market earlier this week. Ars Technica published an article with a headline that captures the general tone of the industry: “Malware in Android Market highlights Google’s vulnerability.” The gist is that because Android is generative (i.e., open to people installing or programming whatever they want) and the Android Market is less centrally controlled than, say, the Apple App Store, it’s inevitable that malware will become a big problem.

Yet this story could—and probably should—be told very differently. Here’s an alternate headline: “Android community, Google respond quickly to limit damage from new malware.” There are tens of millions of Android smartphones out there, yet reports indicate that only around 50,000 users downloaded the malware apps in question before they got pulled from the Market. That’s a pretty small number, and it’s not clear how many of those were susceptible to the malicious aspects of the malware.

I’m in no way suggesting that malware isn’t a threat to Android users. Rather, I’m pointing out that there are mechanisms, both formal and informal, for limiting the spread and impact of malware in the ecosystem. Some, such as the centrality of the Market to many users’ smartphone experience, combined with Google’s willingness to pull the plug quickly if malware is discovered in the Market, position Android differently from the oft-targeted Windows.

That said, the ecosystem needs to develop more mechanisms to protect users from bad apps. The early ideas from John Palfrey and Jonathan Zittrain that led to the formation of StopBadware five years ago might provide some clues. Perhaps there’s a way to generate some sort of collective reputation or automated telemetry system that can help users make more informed decisions about their apps. Or perhaps there are other tools, systems, or policies that will help. The time is now, before we replicate too many of the problems that have plagued open systems in the past, to identify solutions that keep users safe while preserving the generativity of platforms like Android.

Tagged , , , | Comments Off

Imageshack protects, educates users

Posted on March 1, 2011 by Maxim Weinstein

A couple weeks ago, intrepid security reporter Brian Krebs blogged about Imageshack, a site that hosts images for free, taking a proactive approach to protect users from spammers. It seems that spam messages would reference images hosted at Imageshack, presumably making the messages smaller and reducing the badness detected by anti-spam tools (because the images were hosted by a legit site).

Tipped off to the problem, the folks at Imageshack didn’t just take the offending images down. Instead, they replaced the images with a warning not to click on anything in the spam message. This had the effect of creating a “teachable moment” for users who might otherwise have fallen for the scam. This approach is similar to the one used by the Anti-Phishing Working Group and participating hosting providers, which replace phishing pages with this educational page.

Any time we, as an industry, take the opportunity to simultaneously protect and educate users, we make progress in the fight against badware. Imageshack should be commended for its work here. StopBadware, meanwhile, has been talking with some folks about doing something similar for malware sites that are taken down.

Tagged , , | Comments Off

Building upon Scott Charney’s “public health” proposal

Posted on February 18, 2011 by Maxim Weinstein

At the RSA security conference this week, Microsoft’s Scott Charney continued advocating a "public health model" for fighting malware and other security threats. I missed Charney’s keynote, but I spoke to a couple members of his Trustworthy Computing team on Monday, and I read Charney’s blog post and some third party accounts of his presentation.

The public health metaphor is an interesting one, and one which folks like Joe St. Sauver at the University of Oregon have talked a bit about over the years. It’s not a perfect metaphor, to be sure. As Scott acknowledges in his blog post, malware and related threats are a result of deliberate, malicious human action; diseases, in contrast, evolve naturally. Disease also spreads physically, not virtually, which changes a lot of the dynamics. The impact, and thus society’s response, differs, too. There’s a big difference between the death of a person and the death of a computer (or the theft of a person’s account number).

Still, with all these critiques, public health is a decent model to turn to for lessons. Malware does, in many cases, follow patterns similar to an infectious disease, and epidemiologists have spent a lot of time developing strategies for tracking and interrupting the spread of such diseases. Many of the same techniques that work for protecting human health—immunization, reducing exposure, educating people, treating disease—have (or could have) clear analogues in computer security. Similarly, though we now lack on the security side many of the institutions and social structures that have developed over the past couple hundred years to address public health, there’s no reason these couldn’t be developed.

Therein lie the questions that are most interesting to me in this discussion. What institutions have to develop, and what new approaches do we need to adopt, to adequately protect a couple billion Internet users? Charney proposes, by way of example, a completely voluntary, private approach to enhancing security: a bank offering an option that checks for updated AV software before allowing a PC to log in. Within that idea are several related questions. Since a single bank adopting that strategy won't have that large an effect, is there a way to get all (or most) banks to adopt the same strategy? Can some organization develop a common framework for how this can be done effectively, consistently (to avoid consumer confusion when they switch banks), and responsibly? Is this something that can be entrusted to, and achieved by, industry, or does it require a third party to get involved? Is there a public policy requirement, or are there market incentives that can encourage banks to do their part?

There are a number of other questions that come to mind along similar lines. Can we learn anything from the community health model that has been successful in addressing certain diseases that target specific populations? What kinds of communities are relevant on the Internet, and how do they differ from those in physical space? How do we ensure that the most extreme (but potentially effective) interventions, such as quarantining an infected computer or network, are done with oversight, due process, and within clearly prescribed guidelines? Do we need to start mandating data reporting, much as we do with disease reporting, to ensure that those who need it have full access to the information they need to intervene? And who are those that will intervene? Industry players? Non-profits like StopBadware? Government agencies akin to the Centers for Disease Control and Prevention?

At StopBadware, we have some thoughts that we’ll try to blog about over the next few months, and we’re excited to engage in the conversation. We also welcome input from the community; please post your comments here or share them with us via e-mail, Facebook, Twitter, or—if we happen to cross paths—in person.

Tagged , , | Comments Off

Request for comments on final draft of new best practices

Posted on February 4, 2011 by ccondon

About two weeks ago, we put out an initial request for comments on a public draft of our new best practices. This RFC was met with insightful, eminently practical advice from our expert working group and the security community. After incorporating some of the suggestions from these groups, we have a second draft of the Practices ready for review and comment. The second public draft of StopBadware’s Best Practices for Web Hosting Providers: Responding to Malware Reports is available here in doc and pdf format.

This is intended to be the last draft of the Practices; we’ll be accepting comments until Friday, February 11, 2011. The final best practices document will be publicly available within a few weeks.  Thanks to all those from our community and the security industry who have given us such dedicated thought and creativity during the course of this project!

You can join our mailing list here. 

Comments Off

The rise of digital collateral damage

Posted on January 25, 2011 by Maxim Weinstein

Stuxnet has been in the news a lot lately, as it appears to have been an effective case of cyberespionage against a high-profile and high-stakes target: Iran’s nuclear processing facilities. Much of the focus in articles such as this New York Times piece has been on who was behind the attack and/or how effective it was at handicapping the Iranian government. These are important and interesting questions, but no one seems to be talking about collateral damage.

Collateral damage? Yep. Here’s the definition from the U.S. Air Force:

Collateral damage is unintentional damage or incidental damage affecting facilities, equipment or personnel occurring as a result of military actions directed against targeted enemy forces or facilities.

Setting aside the question of whether Stuxnet was military in nature, the basic principle still applies. Though the malware is highly targeted at Uranium-spinning centrifuges, the designers needed a way to spread it around until Iranian nuclear facilities got hit. The solution was to use typical malware techniques: Stuxnet can travel across local networks and via infected USB flash drives. When first released, it exploited no fewer than three zero day vulnerabilities, making it an especially potent threat, even to those keeping their sotware patched.

The result of using Windows-based malware as a way of delivering the payload is that over a hundred thousand computers that were not in Iranian nuclear facilities became infected and helped to spread the worm. Many of these were in Iran, though tens of thousands were also in the U.S., Indonesia, and India, amongst other countries. In other words, ordinary computer users took collateral damage.

Some might argue that, because the malware only has a malicious payload when it discovers industrial control systems, that most “infected” users were not, in fact, damaged. People making this argument are wrong. Imagine if someone sends an envelope containing white powder to a government facility. The white powder turns out to be flour, not Anthrax. Was damage done? Of course! Although no injuries may occur, there is still a cost: time is wasted, money is spent, people panic, etc. The same is true with malware. Here are a few of the things that might happen if a typical user’s PC becomes infected with Stuxnet:

  • The user receives an anti-virus warning, leading to fear, confusion, and/or some of the actions below.
  • The user takes his computer to a repair shop and pays to have the malware removed and/or to check for damage.
  • The user loses valuable productivity time investigating the malware.
  • The worm slips by the user’s AV software, and the user’s ISP later warns the user or disconnects the user’s network connection for attempting to spread malware across the network.

Multiplied by large numbers of users, these effects could have a substantial impact. There are also systemic side effects. Criminals can study and learn from the malware, so they can use similar techniques to steal money from unsuspecting consumers and businesses.

As governments and private interests alike use ever-evolving digital means to undermine each other, it’s inevitable that such collateral damage will continue to grow. The institutions behind these attacks must, for their part, be cognizant of this new type of damage, which (at least to me) feels very different from wartime physical damage. The rest of us, meanwhile, must continue to help the Internet ecosystem evolve such that it is more resistant to, and resilient in the face of, malware generally, whatever the malware’s source.

Tagged , , | 1 Comment