W32.Blaster.B.Worm

When W32.Blaster.Worm is executed, it does the following:

1. Checks to see whether a computer is already infected and whether the worm is running. If so, the worm will not infect the computer a second time.
   
   
2. Adds the value:
   
   "windows auto update"="penis32.exe"
   
   to the registry key:
   
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
   
   so that the worm runs when you start Windows.
   
   
3. Generates an IP address and attempts to infect the computer that has that address. The IP address is generated according to the following algorithms:
   
   • For 40% of the time, the generated IP address is of the form A.B.C.0, where A and B are equal to the first two parts of the infected computer's IP address.
     
     C is also calculated by the third part of the infected system's IP address; however, for 40% of the time the worm checks whether C is greater than 20. If so, a random value less than 20 is subtracted from C. Once the IP address is calculated, the worm will attempt to find and exploit a computer with the IP address A.B.C.0.
     
     The worm will then increment the 0 part of the IP address by 1, attempting to find and exploit other computers based on the new IP address, until it reaches 254.
     
     
   • With a probability of 60%, the generated IP address is completely random.
     
     
4. Sends data on TCP port 135, which may exploit the DCOM RPC vulnerability. The worm sends one of two types of data: either to exploit Windows XP or Windows 2000. For 80% of the time, Windows XP data will be sent; and for 20% of the time the Windows 2000 data will be sent.
   
   Notes:
   • The local subnet will become saturated with port 135 requests.
   • While W32.Blaster.Worm cannot spread to the Windows NT or Windows Server 2003, unpatched computers running these operating systems may crash as a result of the worm's attempts to exploit them. However, if the worm is manually placed and executed on a computer running these operating systems, it can run and spread.
   • Due to the random nature of how the worm constructs the exploit data, this may cause the RPC service to crash if it receives incorrect data. This may manifest as svchost.exe, generating errors as a result of the incorrect data.
   • If the RPC service crashes, the default procedure under Windows XP and Windows Server 2003 is to restart the computer. To disable this feature, see step one of the Removal Instructions below.
     
     
5. Uses Cmd.exe to create a hidden remote shell process that will listen on TCP port 4444, allowing an attacker to issue remote commands on an infected system.
   
   
6. Listens on UDP port 69. When the worm receives a request from a computer to which it was able to connect using the DCOM RPC exploit, it will send Penis32.exe to that computer and tell it to execute the worm.
   
   
7. If the current date is the 16th through the end of the month for the months of January to August, or if the current month is September through December, the worm will attempt to perform a DoS on Windows Update. However, the attempt to perform the DoS will succeed only if one the following conditions is true:
   • The worm runs on a Windows XP computer that was either infected or restarted during the payload period.
   • The worm runs on a Windows 2000 computer that was infected during the payload period and has not been restarted since it was infected.
   • The worm runs on a Windows 2000 computer that has been restarted since it was infected, during the payload period, and the currently logged in user is Administrator.
     
     
8. The DoS traffic has the following characteristics:
   • Is a SYN flood on port 80 of windowsupdate.com.
   • Tries to send 50 HTTP packets every second.
   • Each packet is 40 bytes in length.
   • If the worm cannot find a DNS entry for windowsupdate.com, it uses a destination address of 255.255.255.255.
     

Some fixed characteristics of the TCP and IP headers are:
• IP identification = 256
• Time to Live = 128
• Source IP address = a.b.x.y, where a.b are from the host ip and x.y are random. In some cases, a.b are random.
• Destination IP address = dns resolution of "windowsupdate.com"
• TCP Source port is between 1000 and 1999
• TCP Destination port = 80
• TCP Sequence number always has the two low bytes set to 0; the 2 high bytes are random.
• TCP Window size = 16384

Symantec ManHunt

• Symantec ManHunt Protocol Anomaly Detection technology detects the activity associated with this exploit as "Portsweep." Although ManHunt can detect activity associated with this exploit with the Protocol Anomaly Detection technology, you can use the "Microsoft DCOM RPC Buffer Overflow" custom signature, released in Security Update 5, to precisely identify the exploit being sent.
• Symantec ManHunt Protocol Anomaly Detection technology detects the activity associated with the Denial of Service (DoS) SYN flood. Security Response has created a custom signature for ManHunt 3.0, released in Security Update 6, to detect this attack specifically as a Blaster DDoS Request.

Symantec Enterprise Firewall
Symantec's full application inspection firewall technology protects against the W32.Blaster.B.Worm, blocking all the above listed TCP ports by default.

Norton Internet Security, Norton Personal Firewall
By default, these Symantec products have the EPMAP rule to block TCP port 135.

Recommendations

Symantec Security Response encourages all users and administrators to adhere to the following basic security "best practices":

• Use a firewall to block all incoming connections from the Internet to services that should not be publicly available. By default, you should deny all incoming connections and only allow services you explicitly want to offer to the outside world.
• Enforce a password policy. Complex passwords make it difficult to crack password files on compromised computers. This helps to prevent or limit damage when a computer is compromised.
• Ensure that programs and users of the computer use the lowest level of privileges necessary to complete a task. When prompted for a root or UAC password, ensure that the program asking for administration-level access is a legitimate application.
• Disable AutoPlay to prevent the automatic launching of executable files on network and removable drives, and disconnect the drives when not required. If write access is not required, enable read-only mode if the option is available.
• Turn off file sharing if not needed. If file sharing is required, use ACLs and password protection to limit access. Disable anonymous access to shared folders. Grant access only to user accounts with strong passwords to folders that must be shared.
• Turn off and remove unnecessary services. By default, many operating systems install auxiliary services that are not critical. These services are avenues of attack. If they are removed, threats have less avenues of attack.
• If a threat exploits one or more network services, disable, or block access to, those services until a patch is applied.
• Always keep your patch levels up-to-date, especially on computers that host public services and are accessible through the firewall, such as HTTP, FTP, mail, and DNS services.
• Configure your email server to block or remove email that contains file attachments that are commonly used to spread threats, such as .vbs, .bat, .exe, .pif and .scr files.
• Isolate compromised computers quickly to prevent threats from spreading further. Perform a forensic analysis and restore the computers using trusted media.
• Train employees not to open attachments unless they are expecting them. Also, do not execute software that is downloaded from the Internet unless it has been scanned for viruses. Simply visiting a compromised Web site can cause infection if certain browser vulnerabilities are not patched.
• If Bluetooth is not required for mobile devices, it should be turned off. If you require its use, ensure that the device's visibility is set to "Hidden" so that it cannot be scanned by other Bluetooth devices. If device pairing must be used, ensure that all devices are set to "Unauthorized", requiring authorization for each connection request. Do not accept applications that are unsigned or sent from unknown sources.
• For further information on the terms used in this document, please refer to the Security Response glossary.

Summary