May 2000 - Test - lists.nanog.org

Alert timeline for Love Bug
by Sean Donelan 07 May '00

07 May '00

Senator Bennet from Utah wants to know where the FBI was when the "Love Bug" began circulating through e-mail systems in the USA. I thought I would try to figure out when various different alerts first reached the public from various sources. Although there may be some "private" alerts earlier, I don't have a good way to find out their timestamps. I've tried to normalize all times to UTC. 4-May-2000 10:17 UTC NANOG posting 4-May-2000 12:54 UTC AP (Hong Kong) 4-May-2000 13:17 UTC Reuters(London) 4-May-2000 13:30 UTC ZDNet News 4-May-2000 13:31 UTC F-Secure press release 4-May-2000 14:30 UTC Financial Services Information Sharing Alert 4-May-2000 14:30 UTC CERT/CC Alert 4-May-2000 14:38 UTC Symantec press release 4-May-2000 15:00 UTC FBI/NIPC Alert 4-May-2000 15:05 UTC Computer Associates press release 4-May-2000 16:19 UTC Trend Micro press release I think the FBI did pretty well. In context, the FBI alert came out approximately the same time as most commercial virus vendor press releases. I'm not surprised NANOG beat the FBI or CERT by 4 to 5 hours. But I think I missed some news reports. Does anyone know of any verifiable public alerts or news stories about the "Love Bug" before 1017 UTC?

2 2

Re: tcp port 8311?
by Dean Robb 06 May '00

06 May '00

At 12:06 PM 5/3/00 -0700, K. Graham wrote: > >What is the name of the log file that is generated from this program? >Where is the log file placed in the system? Did you check to see if >there is any residual traces of the programs in the registry? If so >where? Do you know the name(s) of the *.vbs you have encountered? Only one gave me solidly useful clues: All the traces were n.*...the * being various VisualBasic-related extensions. The one that gave me useful info was n.log - showed the modem log and dialout times, etc, but not a list of what was transmitted. The number the modem dialed was XXX'd out; and the transmission stats showed the 10megs. The end user confirmed that, although he was doing some VB6 programming for a class, it wasn't his script and that no one was home at the time the dialout occured. Unfortunately, the system was unstable as hell and I was lucky to get this data before it crashed completely; W98 wouldn't load at all because of (suspected) corrupted files. Before it crashed completely (and the reason the end user called me) was that upon W98 boot, a system error would be displayed saying RPCSS.dll had caused a GP fault in OLE32 and then a VB debug session would start and freeze. The other encounter showed similar symptoms but left no clues that I could find. >Virus_Research(a)NAI.com, samples(a)f-secure.com, and support(a)sophos.com >all are addresses where suspect files can be sent. They prefer them in >a zip format before accepting them. If I'd been able to get samples, I'd surely forward them. Bet these clients keep their McAfee updated and running from now on :). "Microsoft is not a monopoly!" - Bill Gates "HA!" - Judge Jackson Dean Robb Owner, PC-EASY (757) 495-EASY [3279] On-site computer services Member, ICANN @Large

1 0

RE: DomainSiren.com Whois records alert service
by Roeland Meyer (E-mail) 06 May '00

06 May '00

Cute dude. OTOH, this probably has enough operational content to merit posting to NANOG. Now all we need is for some script-kiddee to figure it out <groan>. > Behalf Of domainiac > Sent: Saturday, May 06, 2000 4:08 PM > > I figured out a way to completely hijack a domain in less > than week under > the new shared system. And by hijack I do not mean simply > redirect the DNS, > etc. I mean completely change the whois record to a new > owner. I won't post > specific directions but I am sure others could do the same > trick as it is > not that complicated. I passed the specific directions onto > ICANN but who > knows if they are likely to do anything. The vulnerability > only applies to > NSI domains with MAIL-FROM (or when their CRYPT-PW system screws up). > > I set up an automated system that reads both the registry and > registrar > records, compares it the stored records, and automatically > e-mails contacts > with the changed info. It also can be used to track domains > about to be > released. > > http://DomainSiren.com > > Russ Smith > http://ChangeYourDomain.com

1 0

Re: DACS blamed for MCI / CSX train problems last week
by Joe Abley 06 May '00

06 May '00

[apologies in advanced for the pitiful layout that Outlook Express will no doubt inflict on you after I click send] -----Original Message----- From: Sean Donelan <sean(a)donelan.com> To: nanog(a)merit.edu <nanog(a)merit.edu> Date: Saturday, May 06, 2000 3:04 PM Subject: DACS blamed for MCI / CSX train problems last week >This isn't the first DACS problem nor is MCI the only carrier affected >by DACS problems. Bell Atlantic had a multi-day DACS problems, I've >experienced 18+ hour MCI DACS problems in the past. What is it about >DACS systems which seem to lead to such catastrophic problems? I don't believe there is anything unherently unreliable in a DACS (we call them Digital Cross-Connects, or DCCs, down here). In fact, most DCCs I have seen are extrordinarily redundant and would probably quite happily continue to function at 100% after a good seeing-to with an axe. The problem lies elsewhere. "Modern" telecommunications equipment seems to come equipped with two configuration paradigms: [1] will usually be a vendor-supplied Unix solution, probably running on Sun or HP hardware, which provides a full database back-end and a simple point-and-click interface for end-to-end service management. This is what the engineering planning people see when the system is demonstrated to them, and this obvious money-saving wonder is what will justify the inflated budget required to purchase it. [2] will probably be 9600 bps terminal access to a protracted series of cryptic menus, about sixteen levels deep, through which the only practical way to navigate is to type ahead protracted strings such as "1,4,9,13-17,3,3,1" and then walk away for ten minutes to drink coffee. [1] will usually stop working properly about four weeks after the vendors disappear from site. Various technicians who have either a vague idea of the network technology, or a self-taught-at-home expertise in Linux, will attempt to fix the problem. The IT department will be called in, and will limp through a SunOS 4.1.3 install from QIC tape, and may even get as far as completing a successful reinstallation of the vendor's management system (at which point it will become clear that the back-end is an embedded version of Informix, for which the licence keys are either missing or have mysteriously transformed themselves into one-week demo licences for some completely unrelated product). Hence [1] will quickly cease to be a useful tool for provisioning services. Of course, the business doesn't stop just because one management system is broken; we always have [2]. [2] is extremely vulnerable to radical accidental reprogramming of the network due to caffeine-induced finger-shake, but quickly becomes a preferred tool for programming the network for a certain subset of the network provisioning technicians. Those who discover that they can script routine tasks using shareware terminal packages will also become able to perform radical accidental reprogramming of the network whilst standing on the keyboard, reaching back to tape laser-printed Dilbert cartoons or semi-pornographic calendars to cubicle walls. Any change using [2] will naturally never be reflected in the database of [1]. This fact will be recognised whenever someone manages to get [1] temporarily back on its feet, and will trigger a seemingly endless series of network audit projects, which will never succeed due to the underground popularity of [2] and the fact that anybody competent enough to perform a network audit does their very best to escape from the project at the earliest opportunity, leaving no indication whatsoever of what they have found out so far. The unreliability of any network records means that any troubleshooting is likely to involve far more random guesswork than is healthy, and the probability of a cascade of outages following routine maintenance on a minor issue is much higher than you would expect. On the other hand, it could be simply that marketing departments have observed that customers are happy with the phrase "DACS outage" and therefore use it as a generic term to describe any incident which might otherwise cause a customer to complain :)

1 0

What is wrong with COVAD?
by Dirk Harms-Merbitz 05 May '00

05 May '00

Right now a number of COVAD circuits in LA are down again. This is the 6th time this year that our COVAD customers are down. What is going on? Is anybody else using COVAD? Are you seeing a similar amount of problems? Dirk

2 1

Enough!
by Shawn McMahon 05 May '00

05 May '00

Can we stop sending copies of the worm and various cleaner scripts back and forth here in the list, please? Everyone here has the resources to go get either, and even if we didn't we wouldn't need 50 goddamn copies of it, OK? Besides, who in his right mind would run a VBS that says "Cleaner" that is received via unsolicited email attachment? Stop!

1 0

uuencoded Love Worm variant
by Eric Conrad 05 May '00

05 May '00

I caught one of these uuencoded 'in the wild'. It would have slipped through my filters if not for the standard Subject: line. ---<snip>--- kindly check the attached LOVELETTER coming from me. begin 666 LOVE-LETTER-FOR-YOU.TXT.vbs ---<snip>--- I've since updated my filters to catch uuencodes as well. On a lighter note, a clueless gateway forwarded 6 copies of the worm with the following helpful banner attached: ---<snip>--- kindly check the attached LOVELETTER coming from me. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by the latest virus scan software available for the presence of computer viruses. ********************************************************************** ------_=_NextPart_000_01BFB683.1FF56E54 Content-Type: application/octet-stream; name="LOVE-LETTER-FOR-YOU.TXT.vbs" --<snip>--- ...Eric

4 4

How long before NIPC decides we need one of these?
by Roland Dobbins 05 May '00

05 May '00

http://www.the-times.co.uk/news/pages/sti/2000/04/30/stinwenws01034.html -- ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

8 13

Major .au cw.net fiber cut.
by Roland Dobbins 05 May '00

05 May '00

FYI, there are reports of a major cw.net fiber cut in Australia, with multiple ISPs affected. Side-effects are said to include major degradation of the PSTN, Sydney stock-exchange slowdowns, and cash-machine issues. No precise details or ETR known at this time, nor data concerning North American/trans-Pacific second-order effects, if any. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

2 1

Re: Virus Update
by David Charlap 04 May '00

04 May '00

"Eric A. Hall" wrote: >> >> Many mail programs (including Netscape Communicator) have no VBS >> support in them, so they can not execute virusses like this one. > > Netscape relies on MIME type mappings. If there's a type defined > (which there is if you have Windows Scripting Host installed) then > it's an executable attachment. Right-click, "open in new window." I stand corrected. I just tested it by writing and mailing myself a VBS file. It opened, ran and was able to write my output file (after approving it in the "security warning" dialog.) I assumed that NS would treat VBS like executables. With an EXE attachment, you don't get the choice of launching it - the SaveAs dialog appears immediately. I think I'll inform NS that they've got a bug. They should be treating VBS like EXE and COM files. -- David

1 0