January 2006 - Test - lists.nanog.org

Urgent Alert: Possible BlackWorm DDay February 3rd (Snort signatures included)
by Gadi Evron 24 Jan '06

24 Jan '06

Hello. This is an urgent alert released by the cooperative efforts of the MWP / DA groups that also worked on the hurricane Rita scams. This task force is now known as the TISF BlackWorm task force. This task force involves many in the security (anti spam, CERTs, anti virus, academia, ISP's, etc.) community and industry, working together to combat threats to the security of the Internet in cooperation with law enforcement globally. Anti Viruses companies each have a chosen name for this, but for operational reasons as well as simplicity we choose BlackWorm. This is what we submit for CME. A CME entry should hopefully be created shortly. Buttom line: 1. Update anti viruses urgently. 2. See Snort signatures below. A special SANS Diary page should be setup soon to process information for Snort signatures for this as we refine them: http://isc.sans.org/blackworm (Current Snort sigs are at the footer of this email message) General information and updates will be found also at: http://blogs.securiteam.com Actual information and background: This worm will destroy certain data files on an infected user's machine. So far about 700K users have been infected. We know this because of a counter which the malware author made use of. That machine is nothing but a counter and there is no reason at this time to blackhole it, as it would harm our attempts to respond to this incident. We are however coordinating a possible action of this sort with the right people if that becomes necessary. We believe the counter to be real and the number of infected users to be mostly accurate. We are working with law enforcement and the ISP to get a list of infected IP's so that we can inform the respected ISP's of the possibly infected users in their net-space. DDay is February 3rd (i.e. that is when the worm becomes destructive). However effective or ineffective this may be, we urge users to update their anti viruses as soon as possible and scan their computers and/or networks. This risk may turn out to be nothing and whatever happens, the Internet is NOT going to die. We would however rather attempt to prevent this DDay on February 3rd regardless. Further, Joe Stewart (jstewart(a)lurhq.com) has come up with the Snort signatures below to help detect infected users in your net-space. False positives should be reported to him. It should be noted that the worm connects to the counter only once on connection, however it keeps trying to DDoS Microsoft. Both these methods can be used to track down the infected users at risk. These signatures and this alert should soon also be on BleedingSnort and the SANS Diary, as well as come from different CERTs. Snort SIgnatures: 1. This sig alerts if someone visits any counter at webstats.web.rcn.net without a Referrer: header in their URL. Could be an infected user, could be one of us checking out the counter stats: alert tcp any any -> any 80 (msg:"webstats.web.rcn.net count.cgi request without referrer (possible BlackWorm infection)"; content:"GET /cgi-bin/Count.cgi|3f|"; depth:23; content:"df|3d|"; content:"Host|3a 20|webstats.web.rcn.net"; content:!"Referer|3a|"; classtype:misc-activity; sid:1000376; rev:1;) 2. This sig alerts on the specific pattern BlackWorm uses to test connectivity to www.microsoft.com. It's unique in that the request doesn't have a User-agent: header. So this will catch BlackWorm and possibly other automated requests to microsoft (which could happen if someone codes a sloppy app that uses the exact same pattern - but they should probably be flogged anyway) alert tcp any any -> any 80 (msg:"Agentless HTTP request to www.microsoft.com (possible BlackWorm infection)"; dsize:92; content:"GET / HTTP/1.1|0d0a|Host|3a20|www.microsoft.com|0d0a| Connection|3a20|Keep-Alive|0d0a|Cache-Control|3a20|no-cache|0d0a0d0a|"; classtype:misc-activity; sid:1000377; rev:1;) Thanks, we will update further as information becomes available, if necessary. Good luck, Gadi.

1 0

urgent request for a contact at rcn.com/.net
by Gadi Evron 24 Jan '06

24 Jan '06

Hi guys, this is rather urgent, we would appreciate any help. I will make sure and update as things progress, but right now I believe public attention would only hinder our (DA/MWP/etc. > TISF) incident response attempts. Thanks, Gadi.

1 0

preventing future situations like panix
by Josh Karlin 24 Jan '06

24 Jan '06

Short of perfect filters, or perfect IRRs combined with PKI, it's a difficult problem to stop prefix hijacks such as we've seen this weekend. Myself, Jennifer Rexford, and Stephanie Forrest have been looking at feasible and incrementally deployable solutions to the problem and we would really like to have operator input on our proposed solution. The idea is simply to consider 'suspicious' looking routes as a last resort in the decision process (~1 day). Thus if no alternative route for a prefix exists, the suspicious route is used regardless, no harm done. Of course, relationship preference must be preserved when possible so very few routes should be considered suspicious if possible. Suspicious routes are those that originate at an AS that has not originated the prefix in the last few days and those that introduce sub-prefixes. Sub-prefixes are always considered suspicious (~1 day) and traffic will be routed to the super-prefix for the suspicious period. We have not yet addressed man-in-the-middle style of attacks where an AS announces a false route and places itself in the middle. We also realize that nobody likes to have announcements delayed, and we explain in detail how few routes will actually be delayed by our mechanism in the linked paper. http://www.cs.princeton.edu/~jrex/papers/pgbgp.pdf Your input is most welcome. Thanks, Josh Karlin

4 5

Re: Domain name hijack?
by Wil Schultz 24 Jan '06

24 Jan '06

The domain in question is a .com I've spoken with our current registrar and they cannot assist since it isn't in their database, so I'm dealing with the registrar that the domain shows at this point. I've asked her to make sure that no changes would be made until this is resolved, she seemed a bit overwhelmed and unsure but agreed. I really would love to know that the change was on July 25th, I suspect that it would have been the admin/tech contacts. I have our billing department digging up any financial records that we have on the domain as well. -Wil Mark Borchers wrote: >My take is that this last point you make is very pivotal. If >your registrar has surrendered your claim to the domain using >dispute procedures between registries, then I think your situation >becomes much harder. On the other had, if the two registries >contain conflicting information, then your prior claim to the >domain is intact and should work to your favor in the dispute. > > > >>I've got calls into the current registrar to see what is >>going on, they >>were contacted at the same time I was and need some time to >>see what's >>going on. Anyone have any advice? Should I call ICANN? How can I find >>out what that change was on July 25th? >> >> >> > > > > >

2 1

Re: preventing future situations like panix
by Josh Karlin 24 Jan '06

24 Jan '06

> > It seems like most of the routers which would need to make this decision > > wouldn't have adequate information upon which to do so... > > not necessarily. the decision could be made in "near real time" by > building prefix filters based on the algorithms that josh and co have > worked on and leaving a 'default deny' in place. this moves the > routing decision off of the router (which i agree does not have the > history or resources to take these additional vectors of information > into account) and over to a server with more storage and computational > capacity. The 'core' routers are definitely the best informed, though other ASs which are multi-homed also come across a substantial bit of information through updates. Yet if only the core ASs were to run such a solution, it would be sufficient to suppress most attacks for at least a day. The paper has more detail on that situation.

1 0

Domain name hijack?
by Wil Schultz 24 Jan '06

24 Jan '06

Hey all, probably not the best place to ask this but thought that I would give it a shot. At my company I manage 30 or so domain names through various registrars, they existed before I came on board. Today I received an email from a person claiming ownership of one of our valuable ones, valuable to us anyway since we have an ASP product sitting behind it. Whois database says that is clearly belongs to him and the ICANN registrar is not one that is being used here, last updated 6 months ago. If this would have been changed 6 months ago I would have been the one to change it, and I didn't change anything. <snip> Created on..............: 2001-May-20. Expires on..............: 2010-May-20. Record last updated on..: 2005-Jul-25 21:29:10. </snip> The domain is still pointing to our DNS servers, we haven't had any outages to this point, looks like the admin and tech contacts were the only thing changed, and now 6 months later they want the domain. I've got calls into the current registrar to see what is going on, they were contacted at the same time I was and need some time to see what's going on. Anyone have any advice? Should I call ICANN? How can I find out what that change was on July 25th?

2 1

Re: preventing future situations like panix
by Todd Underwood 23 Jan '06

23 Jan '06

bill,all, On Mon, Jan 23, 2006 at 12:08:11PM -0800, Bill Woodcock wrote: > > On Mon, 23 Jan 2006, Josh Karlin wrote: > > The idea is simply to consider 'suspicious' looking routes as a last > > resort in the decision process (~1 day). Thus if no alternative route > > for a prefix exists, the suspicious route is used regardless, no harm > > done. > > It seems like most of the routers which would need to make this decision > wouldn't have adequate information upon which to do so... not necessarily. the decision could be made in "near real time" by building prefix filters based on the algorithms that josh and co have worked on and leaving a 'default deny' in place. this moves the routing decision off of the router (which i agree does not have the history or resources to take these additional vectors of information into account) and over to a server with more storage and computational capacity. it has the side effect of denying announcements of valid prefixes from customers that are not in the prefix list until the list is next updated, but we already pay that price now; well, networks that maintain prefix filter lists on customer-facing ports pay that price now. this just describes a different way of building and maintaining those lists. the idea of incorporating history into the validation process for routing tremendously useful and worth considering seriously. at least until we get all signed updates. how is that whole thing going? :-) t. -- _____________________________________________________________________ todd underwood chief of operations & security renesys - internet intelligence todd(a)renesys.com www.renesys.com

1 0

Re: preventing future situations like panix
by Bill Woodcock 23 Jan '06

23 Jan '06

On Mon, 23 Jan 2006, Todd Underwood wrote: > > It seems like most of the routers which would need to make this decision > > wouldn't have adequate information upon which to do so... > not necessarily. the decision could be made in "near real time" by > building prefix filters based on the algorithms that josh and co have > worked on and leaving a 'default deny' in place. this moves the > routing decision off of the router (which i agree does not have the > history or resources to take these additional vectors of information > into account) and over to a server with more storage and computational > capacity. Agreed, if you're willing to suppose that routing decisions will be centralized, and static RIBs pushed down into things that look more like switches, many many many problems go away, to be replaced by the other problem: out-of-band control plane and detection of forwarding plane failures. I did a bunch of work with the Agilent guys on that five years ago or so, and found it really fascinating, in a what-if alternate-universe sort of way. -Bill

1 0

cctld server traffic
by Randy Bush 23 Jan '06

23 Jan '06

any cctld ops seeing unusual traffic in the last hours? randy

5 4

Re: oof. panix sidelined by incompetence... again.
by Fergie 23 Jan '06

23 Jan '06

Out of curiousity, why must these be in .pdf format? I mean, what's wrong with .html? Just curious, - ferg -- Manish Karir <mkarir(a)merit.edu> wrote: in case some people want to look at routeviews data for themselves, I have archived a couple of pdf file at: http://bgpinspect.merit.edu/reports.php -manish [snip] -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1