Blog

What's in a name?

Posted on September 28, 2011 - 15:31 by mweinstein

One of the most interesting aspects of yesterday's announcement of another botnet takedown engineered by Microsoft was the naming of the owners of the .cz.cc domain in their lawsuit.

...this case highlights an industry-wide problem pertaining to the use of subdomains. Under U.S. law, even pawn brokers are more effectively regulated to prevent the resale of stolen property than domain owners are to prevent the use of their digital properties for cybercrime. For example, pawn shop operators must require a name, address and proper identification from customers, while by contrast there are currently no requirements necessitating domain hosts to know anything about the people using their subdomains –making it easy for domain owners to look the other way.

Through this case, we hope to demonstrate that if domain owners don’t hold themselves accountable for knowing their customers, they will be held accountable for what is happening on their infrastructure. Our goal is for this case to spur an industry-wide discussion for more public and accountable subdomain registration practices to enable a safer, more secure Internet for all users.

Microsoft should be applauded for its effort, as well as for raising awareness of intermediary service providers' roles in perpetuating badware. I don't understand, though, their heavy handed focus on customer identification. True domain registrars, at least those accredited by ICANN, are already required to collect and publish valid contact information for domain registrants, yet this hasn't seemed to help a lot in preventing malicious registrations or tracking down the criminals. There are lots of reasons for that, such as privacy proxies that shield the identities of the registrants, weak enforcement by ICANN, use of stolen credentials, and the difficulty of verifying the validity of customer information.

I also wonder about dotFREE, the operator of the .cz.cc subdomain service. After the entire .cz.cc domain was pulled from Google Search results due to the high malware and low quality rates of cz.cc subdomains, dotFREE claimed to be implementing a number of reasonable security precautions, from hiring more abuse staff to suspending accounts that appeared on popular badware blacklists. All talk, no action? Could be. Too little, too late? Maybe. But what if they were doing all these things and making a good faith effort to prevent continued abuse of their domain? Was the fact that they didn't verify and publish contact information for their customers enough to make them liable for the malicious use of their subdomains? Perhaps the fact that they were marketing their service like a registrar, but not behaving like an accredited registrar, is enough to do them in?

It will be up to the courts to decide on whether dotFREE is liable under U.S. law. I'd push back against Microsoft, though, and say the industry discussion shouldn't be about "public and accountable subdomain registration practices," but rather about identifying more broadly the philosophical and perhaps legal expectations for how such providers should contribute to the safety of the Internet.

Tags: 
botnets, microsoft, subdomains, takedowns

Last chance to submit feedback on new best practices for reporting badware URLs

Posted on September 12, 2011 - 10:08 by ccondon

Several weeks ago, we put out a request for comments to anyone who might have feedback on our newly developed best practices for reporting badware URLs. As a reminder, we’ll be accepting comments on the new best practices until  this Friday, September 16.

As we mentioned previously, one of the catalysts for our developing these best practices for reporting was feedback we received while creating the first installment of our Best Practices for Web Hosting Providers. We’re extremely interested in any comments web hosting providers may have on these new best practices. Please see our previous blog post on this topic for a list of specific questions about which we’d like feedback.

You can see for yourself the results of our first shot at reporting badware URLs according to these best practices. Given the success of these initial attempts, we’re excited to hear comments on the reporting best practices and integrate them so as to make the final document as complete and effective as possible. Comments can be submitted here or sent to contact/at/stopbadware/dot/org.
 

Download the draft as a Word doc (.docx) or as a PDF.

Tags: 
reporting, stopbadware

Observations from StopBadware's first foray into reporting

Posted on September 2, 2011 - 10:22 by ccondon

As we mentioned last week, we have a full and public draft of a new best practices document for reporting badware URLs. You may also be aware that StopBadware receives a feed of badware URLs reported by members of our BadwareBusters community, via this form. The community feed is represented in our Clearinghouse, but it’s discrete from any data we receive from our data providers (Google, GFI-Sunbelt, and NSFocus).

For the past six weeks, our testing team has been reporting the URLs from our community feed in accordance with the current draft of our Best Practices for Badware Reporting. This inaugural effort at reporting is only a pilot project, and we have not yet decided whether to continue or expand the work. That said, the reporting we’ve done these past couple of months has given us a much better feel for the reporting landscape and the needs of both hosting providers and reporters endeavoring to take down badware and protect users.

Naturally, our immediate goal when we started reporting URLs from our community feed was to put our new best practices to a practical test. A side effect of this test, however, was that we have begun to witness firsthand the variation in hosting provider responses to reports of badware on their networks. We’ve made some intriguing discoveries in the course of our reporting efforts; in the spirit of our commitment to transparency and improving the Internet ecosystem’s collective resiliency to badware, we’d like to share some of our results.

Our team’s reporting steps were as follows:

  1. They manually investigated the reported badware URL to determine whether badware was, in fact, present.
  2. If badware was observed, our testers used their considerable experience to determine (as much as possible) whether the URL was inherently malicious or a compromised, legitimate site.
  3. They contacted the appropriate entities as laid out by our Best Practices for Badware Reporting. In most—though not all—cases, our team simultaneously contacted the site owner and the hosting provider; please see the current draft of StopBadware’s Best Practices for Badware Reporting for an explanation of appropriate points of contact for various reporting scenarios.

Notable observations:

  • A full 67% of the URLs we reported were cleaned up, many within a short time.
  • Dropbox, who qualifies as a web hosting provider by the definitions set out in our Best Practices for Web Hosting Providers, was particularly responsive to badware reports. Every report sent their way was acknowledged and addressed quickly, many reports were met with personal responses, and some badware URLs on their network were taken down in as little as 45 minutes.
  • Dreamhost, Bluehost, Brazil’s Universo Online S.A., German host Hetzner Online, and Chicago-based WiredTree were also among the most responsive: frequently our team received personal responses from these hosting providers, and badware URLs we reported to them were, without exception, cleaned up or taken down.
  • Though two thirds of the URLs we reported were cleaned up, only 26% of the reports were acknowledged. (Note: Our Best Practices for Web Hosting Providers specify that providers should acknowledge receipt of badware reports within one business day and should follow up with information about action taken.)
  • Of the reports that did receive acknowledgments, 81% were cleaned up. When the acknowledgment was a personal response, that number rose to 95%.

Several conclusions seem clear to us from our experience thus far. Open communication channels are key to both reporting and responding to reports.  The framework provided by our reporting best practices held up, though implementation inevitably varied based on proactive replies from individual hosting providers; unsurprisingly, open communication was instrumental in those minute changes, too—for instance, when a hosting provider preferred the reporter to submit abuse complaints via a web form. Finally, size is not an impediment to responsible communication and follow-up, as evidenced by the varying sizes of the providers listed above.

Of course, the list of hosting providers we’re recognizing for exemplary responses is preliminary and not meant to be exhaustive. Undoubtedly, there are a great many responsive and proactive hosting providers to whom we haven’t yet reported badware URLs. (If you’re a hosting provider whose policies and procedures are in compliance with our Best Practices for Web Hosting Providers, you can sign up for our We Stop Badware™ Web Host program to show potential customers your commitment to fighting badware.)
 

We’re actively soliciting comments on our Best Practices for Badware Reporting until September 16, 2011. We welcome feedback from hosting providers, reporters, and other members of the security community, as well as from concerned users and members of our community. Feedback can be posted to our blog or sent to contact<at>stopbadware.org.

Tags: 
hosting, reporting, stopbadware

Pages