SQL Slammer Clean-up: Contacting CERTs

Published: 2010-10-29
Last Updated: 2010-10-29 17:53:59 UTC
by Kevin Liston (Version: 1)
2 comment(s)

As you go through the process of individually-contacting abuse-contacts (http://isc.sans.edu/diary.html?storyid=9664) and work your way up the stream (http://isc.sans.edu/diary.html?storyid=9712) you may eventually end up the state/nation-level. This should only occur in cases where the ISP is unresponsive, or actually complicit in behavior. For something like slammer this shouldn't be the case, but for completeness I'd like to cover how to engage CERTs.

Each CERT is unique. They have varying levels of funding and organization, their missions are not consistent from one country to another, but they do have a couple of things in common. Most are clearing-houses for abuse-reporting. If your research into the owner and up-stream provider of an infected IP address isn't turning up working contacts, they can usually help identify the correct contacts and forward the report on for you. Also, they are each responsible to a specific constituency.

Before contacting a CERT it's important to study their mission and their constituency. You will not get good results if you report an IP address or an organization that is outside of their scope. Some CERTs do not actually accept abuse reports from individuals or organizations and only service other CERTs (e.g. Asia Pacific Computer Emergency Response Team-- apcert.org)

As an individual or organization directly reporting an incident to a CERT it's best to use their online reporting form. This assures that your report enters their work-flow and contains the information that they require. Sending an email in your own format runs the risk that it may be ignored. If you shotgun your report as an email to multiple organizations and CERTs it's almost guaranteed to be ignored by most or all of the recipients on your list. However, if what you have to report doesn't fit with their reporting-form and you think an email is necessary, they are quite fond of digital signatures.

Let's look at a couple of examples. For reporting slammer, your two most common countries are China and the United States. CNCERT has an easy web-form to report infections: http://www.cert.org.cn/english_web/ir.htm. There's a little captcha to prove that you're a human, you fill out a few fields, select "Virus, worm or trojan infection" from the incident type, paste your logs/packet dump in the description field, and ask that they system be taken off-line or cleaned. Be sure to record when you sent the report in your tracking spread-sheet and what kind of response you get.

US-CERT (http://www.us-cert.gov) has their own reporting forms, they break them down into: incident, phishing, and vulnerability. For something like slammer, you'd use the "Report an Incident" link: https://forms.us-cert.gov/report/ They collect some contact information, as well as more details about how the incident is impacting you (none to minimal in the case of slammer attacks,) what type of followup you require (none, contact or forward-- probably forward in this case.) They ask for the current status of the incident, since the slammer infection is still ongoing, you could use the "Occurring" status. They have a couple of fields to use to describe the incident, one of them is specifically for pasting logs-- use that.

Reporting to an organization such as a CERT is often an act of faith. You're not likely to get a quick, human response (not like when you submit something to us: http://isc.sans.edu/contact.html) but your efforts do have an impact. The attention that an IP address gets grows more and more reports come in from multiple organizations. This is why I've been soliciting you to make your own reports individually as opposed to a request of "send me all of your known SQL slammer infections."

we're quickly approaching the end of this exercise, so next week I'll post the results and go into more of the background of why I chose Slammer and how I organized the drill.

Keywords: slammercleanup
2 comment(s)
Diary Archives