[unisog] Windows Update

Jeff Bollinger 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.
> 
> Questions:
> 
> 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.
> 
> 
> 						Thanks,
> 							- 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:
> 
> 207.46.134.30
> 207.46.134.94
> 
> 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
> attack.
> 
> 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
> attacking
> 
> 30.134.46.207.in-addr.arpa
> 
> 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)
> SACK
> 
> The TCP port 80 SYN packets do not carry any TCP options.



More information about the unisog mailing list