[unisog] Windows Update
jeff01 at email.unc.edu
Thu Aug 14 19:50:43 GMT 2003
Anderson Johnston wrote:
> I took this idea to out network boss. He suggested that he modify the DNS
> to redirect packets to an IP where I can monitor the sources for later
> identification. That way we can catch some of the ones we haven't found
> so far - especially the dial-ins.
> 1.) Just to confirm, the DoS attack is targeted by name
> ("windowsupdate.com"), right?
> 2.) Is the DoS attack on port 80 only?
> 3.) SYN flooding? TCP connect attempts?
> 4.) Has anybody reverse-engineered the worm yet to see
> what it really does? I looked at it with Process
> Explorer and it looked like it might be using cookie files, but
> that hasn't been mentioned in any write-up I've seen.
> - Andy
I'm pasting this message from the Incidents list which I think is a
pretty good analysis so far.
Jeff Bollinger, CISSP
University of North Carolina
IT Security Analyst
105 Abernethy Hall
mailto: jeff @unc dot edu
> -------- Original Message --------
> Subject: RE: rpc dcom worm and windowsupdate
> Date: Wed, 13 Aug 2003 10:02:27 -0500
> From: Flowers, Katie <Katie.Flowers at savvis.net>
> To: <Oliver.Gruskovnjak at BIT.admin.ch>, <incidents at securityfocus.com>
> hope the below helps you out oliver
> <source elided>
> Hi Team,
> Just tinkering w/ the "wurm" a little and thought I'd make a couple of
> observations on the AUG 16 date.
> At some time on or after Aug 16, the worm will issue a DNS request for
> the A record of windowsupdate.com to the locally configured DNS server
> with the +recusion option set. When the clock strikes Aug 16, it does
> NOT appear to immediately attack windowsupdate.com. My guess is that
> the loop iterating the /16 scan needs to complete before the code checks
> the clock again for attacking Microsoft.
> Assuming the query succeeds, the two current A records will be returned:
> The worm will then begin to send 60 byte (20 bytes ethernet padding) TCP
> SYN packets to windowsupdate.com port 80.
> The source IP will be spoofed out of the /16 of the local LAN subnet,
> the source port will be in the range of 1000-2000, IP TTL of 128, and IP
> ID 256.
> Note the very consistent parameters in the IP packets. A combination of
> source ports and/or IP ID checking may be another way to fingerprint the
> The worm appears to select the first IP of the two returned in the DNS
> reply consistently, so it may be possible to simply block access to the
> first IP if necessary as a mitigation method.
> While sending TCP floods it will issue a PTR Lookup for the IP it is
> The rate of packets sent may vary based on hardware platform, CPU, and
> bandwidth, but I've noticed a rate of approximately 50pps for the SYN
> attack. Packets appear to be spaced about 20ms apart.
> The TCP 135 scans appear to run at about 12pps. At this rate it would
> take approximately 93.29 minutes to scan an entire /16.
> As Rob suggested, there appears to be approximately a 1.5-2 second delay
> between each 20 socket connects(). The TCP port 80 SYN Flood does not
> appear to exhibit the same behavior.
> The TCP port 135 scans carry the following TCP options:
> MSS (1460)
> The TCP port 80 SYN packets do not carry any TCP options.
More information about the unisog