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

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.

Tagged , | Comments Off

Observations from StopBadware’s first foray into reporting

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.
Tagged , , | Comments Off

Seeking comments on best practices for reporting

As we worked on our Best Practices for Web Hosting Providers, a common refrain we heard was, “What about best practices for reporting badware URLs?” So, we pulled together another great working group and started figuring out what elements make a report of a badware URL most likely to get the URL cleaned up or taken down. After several virtual meetings, we have a draft to share with you for your feedback.

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

We welcome any feedback you have on this draft. In particular, we’re interested in thoughts on the following:

  1. Are there better ways to identify the proper targets of the reports than those outlined in Practice 2?
  2. Are there other critical pieces of information that could be included in the list in Practice 3?
  3. Do you have suggestions for other escalation parties and/or guidance in Practice 5?
  4. Are the sample notifications in the appendix easy enough to follow? Is there anything you would change about the format?
  5. Should we also recommend an XML data format for reporting? If so, should it be based on an existing standard like IODEF, the Malware Metadata Exchange Format, the Mail Abuse Reporting Format, or something similar? Which one, and how would you recommend simplifying otherwise complex formats for the relatively simple job of reporting malware URLs for takedown/cleanup?

We would appreciate your feedback here in the comments or via email to contact\at\stopbadware\dot\org by Friday, September 16.

Comments Off

StopBadware introduces We Stop Badware™ program for web hosting providers

For some time now, StopBadware has advocated for increased focus on web hosting providers’ role in protecting customers, Internet users, and the Web as a whole from badware. Last week at HostingCon, StopBadware launched the We Stop Badware™ Web Host program for web hosting providers who pledge to follow policies and procedures consistent with our Best Practices for Web Hosting Providers.



The mechanics of the program are simple. To participate, web hosting providers should:

  • Compare their policies and procedures with the guidelines set out by the Practices to ensure compliance.

  • Sign up.
  • Display the We Stop Badwareâ„¢ Web Host seal to demonstrate commitment to protecting customers and strengthening the Web’s resistance to badware.

One of our goals in creating the program was to give web hosting providers a way to advertise to customers and Internet users their commitment to security and their support for a stronger, safer Internet. At StopBadware, we believe that hosting providers’ unique position in the architecture of the Web carries with it a responsibility to proactively protect users and create a more secure online experience for everyone. The We Stop Badware™ Web Host program offers security-conscious web hosting providers a chance to fulfill this responsibility and actively participate in the badware solution.

To assist web hosting providers who are in compliance with the best practices, StopBadware also recently released a legal white paper titled Web Hosting Provider Liability for Malicious Content. Developed in conjunction with the Cyberlaw Clinic at Harvard’s Berkman Center for Internet & Society, the white paper is available as an additional resource for web hosting providers seeking information about badware liability. Finally, to complement the Best Practices for Web Hosting Providers, StopBadware is currently in the final stages of developing an inaugural set of Best Practices for Badware Reporting. A public draft of these new best practices is expected later this month.

Tagged , , , , , , , | Comments Off

Summer reading

For those looking for some quality summer reading about badware, I recommend the following recent articles:

Tagged , | Comments Off

New insights on hosting provider badware liability

When we at StopBadware released our best practices for web hosting providers back in March, we wanted to lay out a framework that helps providers address badware reports responsively and comprehensively while retaining the flexibility they need to function as businesses in a competitive market. Legal liability is a major concern for any business, and since addressing badware issues is often a tense and trying process, we wanted to determine the state of the law governing providers’ liability for hosting malicious content on their networks. How would adopting the Best Practices affect a provider’s legal risk? We consulted the Cyberlaw Clinic at the Berkman Center for Internet & Society for guidance.

We’re pleased to shed some light on the issue in our new white paper, Web Hosting Provider Liability for Malicious Content, which we are releasing today as a complement to our Best Practices. The paper confronts three major issues:

  • Are providers generally liable for hosting badware?
  • Do providers become liable for hosting badware when they receive a badware report?
  • Can providers become liable when responding to a badware report?

The white paper is based on general principles of U.S. federal case law and is, of course, offered as an informational resource only. You can read the paper here (PDF).

Comments Off

Upcoming StopBadware events: HostingCon, Online Trust Forum 2011

Happy middle-of-July, everyone: we hope the season is treating you kindly. The next few months are going to be pretty eventful for usliterally. We have several events coming up in various cities (all stateside for now), and we’d love to see some of you there. StopBadware will be at HostingCon in San Diego, CA, August 8-10; we’ll be exhibiting at the conference and promoting our Best Practices for Web Hosting Providers, so if you’re a rock star in the web hosting industry, be sure to stop by, say hello, and learn how you can demonstrate your commitment to protecting the online ecosystem!

After our summer conference debut, join us at the Online Trust Forum 2011 in Washington DC, October 17-19.  Hosted by the Online Trust Alliance, the Forum will address marketing, technical and regulatory challenges impacting trust and confidence in online services and communications. Now in its 7th year, the Forum brings together an international audience of business, industry, marketing, security, and government leaders to learn and collaborate on best practices to protect consumers and develop trust.

If you need another reason to come witness the all-star lineup at the 2011 Online Trust Forum, we’ll give you one: our intrepid leader, Executive Director Maxim Weinstein, will be participating in a panel called Evolving Cybercrime – How to keep from being a statistic along with leaders from the APWG, InfraGard, and Internet Identity. 

Early bird registration (register by August 12): https://otalliance.org/dc.html. You can save $100 by using the code PTRORG.

In addition, the Forum will include the 2011 Online Trust Leadership Awards. If your company promotes online trust and protects online safety and identity, let everyone know by nominating yourself for an Online Trust Leadership award. (And of course, if you’re so inclined, feel free to nominate StopBadware for the NGO award!) More>

To learn about other events around the world geared toward protecting the Internet and stopping badware, check out StopBadware’s Badware Events Calendar. If you know of a great badware-busting event that should be included on our calendar, let us know at calendar<at>stopbadware<dot>org.

Tagged , , , , , | Comments Off

Graphic design wanted!

In preparation for a new StopBadware intiative that we'll be launching in August, we're looking to get a professional looking seal/logo designed within the next couple weeks. If you're a designer and want to put in a proposal for the job, take a look at the RFP. Note that the proposal deadline is this Thursday, and the design will have to be finished by July 15, so get those proposals in quickly!

Tagged , | 2 Comments

A new form of script injection

The good people at Armorize recently discovered and analyzed a new form of script injection, which they have dubbed "Mass Meshing Injection." The unique characteristic of this new attack is that each compromised site loads a malicious script from a different compromised site, thus the "mesh" effect. According to Armorize, many of the compromised sites had not yet been picked up by major blacklists, including Google's, as of the date of the blog post.

According to Armorize, the telltale signs that a site has been compromised are the presence of a <script> tag pointing to somedomain/sidename.js within the website's contents, and two files injected in the site's root folder: sidename.js and wpcomplate.php.

Based on what we've read, it seems that sites that remove the above-mentioned files and tags often find themselves reinfected shortly thereafter, and there may be a backdoor in play.

We're asking the StopBadware community to help us become a resource for tracking this attack and helping site owners clean their sites of it. If you know more about this attack or new variations about it, please share them with the community. You can do so by posting to BadwareBusters.org or adding a comment here. If you have a lot to say, you may propose a guest blog post by emailing us at contact<at>stopbadware<dot>org. (Note: no guest blog posts containing product or service promotions will be accepted.)

Tagged , , | Comments Off

Innocent sites caught in a dragnet

A New York Times blog reported last night that entire racks full of web hosting servers were seized by the FBI in an effort, presumably, to get at some evidence living on one of the servers:

The F.B.I. seized Web servers in a raid on a data center early Tuesday, causing several Web sites, including those run by the New York publisher Curbed Network, to go offline.

The raid happened at 1:15 a.m. at a hosting facility in Reston, Va., used by DigitalOne, which is based in Switzerland, the company said. The F.B.I. did not immediately respond to a request for comment on the raid.

[snip]

DigitalOne provided all necessary information to pinpoint the servers for a specific I.P. address, Mr. Ostroumow said. However, the agents took entire server racks, perhaps because they mistakenly thought that “one enclosure is = to one server,” he said in an e-mail.

Other sites that were using those servers reportedly include popular services Pinboard and Instapaper.

If the reported information is accurate, it appears the FBI really messed up here, harming several legitimate sites that didn't have to be harmed, and potentially damaging the reputation of the web hosting provider (presumably an innocent intermediary).

This also raises questions about how to apply the concept of property seizures to the cyber world. If I'm suspected of a crime, law enforcement can—with a court's permission—seize my computer and search it for evidence. In this case, though, it seems the servers seized didn't belong to the party under investigation. Rather, that party was renting space on a shared server, which in turn was part of a server farm. The FBI's actions seem equivalent to seizing an entire lot full of rental cars because one of the rental agency's customers was suspected to have committed a crime using one specific car on the lot.

Courts and law enforcement organizations are going to have to put some effort into figuring out  a better way to execute seizures against shared digital resources. This might, for example, mean temporarily taking the server in question (and only that server) offline to create a forensically-valid clone of the contents, rather than seizing the physical equipment.

In any case, I hope that we won't see many repeats of this apparent over-reaching.

Tagged , | Comments Off