- NANOG - lists.nanog.org

RE: Password Security and Distribution
by McLean Pickett 24 Jan '06

24 Jan '06

Jeremy - I've not found a better solution than PGP. Perhaps more a formalized process for communicating password updates proactively is all you need. Ideally, distributing passwords at 3am is too late. In the past I've used small password database programs on a network share. You are then left with verbal or PGP encrypted communications to distribute a single new password to access the database versus distributing all of the changed passwords. If you're interested try http://www.anypassword.com There are others who read this list that prefer distributing passwords on paper. You can't hack into a piece of paper :) and if you have physical access to the paper then you most likely have physical access to the network equipment as well... McLean -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jeremy Stinson Sent: Tuesday, January 24, 2006 10:49 AM To: nanog(a)merit.edu Subject: Password Security and Distribution All, Our company is starting to grow rather quickly and we are starting to have growing pains. We are in the need for a better mechanism for sharing passwords between our engineers. Most of these passwords are for our client's systems where some of them are controlling the password schemes (aka requiring shared user accounts). We have a process in which we change passwords every X days but, distributing these passwords to everyone who needs them is starting to become a challenge. Also, handing off passwords to someone who is stepping in to help out at 3am securely is not easy. I have tried to do google searches but I have not been able to find a good way or process to do this. I am wondering if anyone has any ideas on how to handle this? In other companies we have used a PGP keyring to secure a text file that contained all of these passwords and then put them onto a shared customer portal. The problem with this strategy is what happens if you are not on your computer where PGP is installed? Any suggestions will be welcomed. Thanks in advance, Jeremy

3 2

BlackWorm technical information
by Gadi Evron 24 Jan '06

24 Jan '06

Technical information on the worm itself can be found here: http://www.f-secure.com/v-descs/nyxem_e.shtml and http://blogs.securiteam.com/index.php/archives/229 Gadi.

1 0

Re: BLS FastAccess internal tech needed
by Fergie 24 Jan '06

24 Jan '06

RFC2827/BCP38? - ferg -- Suresh Ramasubramanian <ops.lists(a)gmail.com> wrote: [snip] What they're *trying* to do is actually quite sensible, and beats spammers trying to do asymmetric routing / source address spoofing type stuff [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/

4 3

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 23 Jan '06

23 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 23 Jan '06

23 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