FYI, it is now our opinion that there will likely be no Internet effect as a result of the DDoS component of the LovSAN worm. Here's an analysis from our folks in the labs;
The worm is programmed to execute a 64byte X 50pps SYN flood attack on port 80 directed at "windowsupdate.com." The worm determines the address for that host name by GETHOSTBYNAME, the
IP is not hard-coded into the worm as it was in the original Code Red worm. That host is *not* the site used by Windows to check for updates; that site is windowsupdate.MICROSOFT.com.
Mitigations:
User Logons:
ICSA Labs testing indicates a Windows 2000 host logged in as a normal user will not launch a DOS attack, but one with the Admin logged in will launch the attack. Unfortunately, testing also indicates a Windows XP host with any user logged in will launch the attack.
DNS Magic:
Yesterday morning, a DNS lookup for that name yielded two
IP addresses in Microsoft's network address block. Later, they lowered the TTL for windowsupdate.com to 10-15 min. and moved the
IP's into their own ASN as if they were preparing to stop announcing for it. Now those
IP's no longer resolve via GETHOSTBYNAME nor by rDNS.
This direction *appears* to be headed towards causing local DNS to return a NXDOMAIN to the infected client's GETHOSTBYNAME request. Multiple sources indicate worm will not fire if it gets NXDOMAIN response.
In testing strategies which were proposed for mitigating the effect of this worm we noted that infected systems
query DNS for "windowsupdate.com" in order to obtain an
IP address which will later be used in a flooding attack on that
IP address. It is important to note that this
query occurs when the malcode first executes and that infected systems *may* have an
IP address cached for use in the attack, and that subsequent alterations to DNS as described here will not redirect their attack UNLESS the systems are rebooted or if they happen to be infected after the DNS changes are applied.
Since the worm queries DNS "by name" for the
IP address to attack, it is possible to insert 'bogus' master zones into DNS which supply an arbitrary
IP address as the destination of the attack. One of the safest
IP addresses to use for this is the 'loopback'
IP address which is present on every system-- so the system will then flood a local pseudo interface and the flood traffic will not appear on the network. Supplying an external target
IP address is also possible, however it is less useful than might be thought as the malcode spoofs source addresses which renders the traffic non-useful for tracking infected systems.
TruSecure has observed from research and privileged sources that a number of mitigations are being employed at the infrastructure level which will reduce the impact of flooding on the greater Internet and the target sites. These protections do not eliminate the impact of infected systems upon enterprise networks and their ISP connections, although the flood traffic will be managed by routing protocols once it reaches ISP infrastructure. The impact of flooding on ISP connections should not be underestimated, in that relatively small number of systems in flooding mode can significantly burden a T1 connection.
Modifying DNS as described below allows an enterprise to provide a harmless address as the target for infected systems in flooding mode. It is important to ensure that the change is made to a DNS which lies between infected systems and the public Internet. It is also critical that *other* DNS systems in the environment are rebooted or flushed in order to eliminate cached
IP address records for windowsupdate.com.
In testing TruSecure found that supplying the loopback address prevented the flood attack traffic from occurring on the network, in that it was 'contained' within the infected systems. A later test in which we specified 'none' instead of 'any' in the zone
access "allow-
query" verb was also effective, in that the DNS server "though authoritiative" refuses to provide the
IP address, depriving the malcode of its target.
While it is possible that Microsoft *may* update its DNS to provide loopback as a target, or remove the relevant address records entirely-- we have no definitive information as to whether they will do so. By implementing these controls at the enterprise level, sites can avoid the consumption of local and ISP connectivity bandwidth caused by the flooding. Please note that none of these measures reduce the scan/attack/infect behavior of the worm.
#
# Fake zone entry for the named.conf file to claim authoritative # for
windowsupdate.com # # Be sure to alter the "file" spec to include the actual
path to # the fake windowsupdate.com zone file # # As described, the
allow-
query setting may be set to "any" or "none" # depending upon the
effect desired # zone "windowsupdate.com" {
type master;
file "<path.to.fix.db>/fix.db";
allow-
query{ any; };
};
;
; Doctored DNS zone to make LovSan nodes flood their own loopback address ;
instead of windowsupdate.com. ; ; An odd side effect is that it spoofs the
source address of some scanning ; traffic as windowsupdate.com... which in
this case is 127.0.0.1 ; so scanned nodes send ICMP UNREACH to themselves..
or ignore as their ; stack/firewall rules dictate. Not entirely a bad
thing. ; ; Be sure to insert REAL nameserver and domain name entries where ;
indicated in < > brackets below ; ; Timeouts may be tuned as desired to suit
the environment ;
; It is preferable to kill and restart BIND after inserting these ; changes
to ensure that the zone is loaded - be sure to verify that ; no errors occur
as the zone is loaded, and to verify that
; nslookup for 'windowsupdate.com' returns the
IP 127.0.0.1
;
$TTL 3600
@ IN SOA <realnameserver.com>. root.<realdomainname.com>. (
20030502 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS <realnameserver.realdomain.com>.
* IN A 127.0.0.1
windowsupdate.com. IN A 127.0.0.1
Cheers,
Russ - NTBugtraq Editor