Advisories
ANALYSIS: Blaster Worm
Release Date:
August 11, 2003
Severity:
High
Overview:
The Blaster worm uses a series of components to successfully infect a host. The first component is a publicly available RPC DCOM exploit that binds a system level shell to port 4444. This exploit is used to initiate a command channel between the infecting agent and the vulnerable target. Once the target is successfully compromised, the worm transmits the msblast.exe executable (the main body of the worm) via TFTP to infect the host. The payload used in the public DCOM exploit, as well as the TFTP functionality, are both encapsulated within msblast.exe.
Technical Details:
View eEye's detailed comments of the Blaster Worm assembly code
View eEye's comments of the Metasploit exploit assembly code
When a host is infected with the Blaster worm through the execution of msblast.exe, the registry value "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
CurrentVersion\Run\windows auto update" is created with a string value of "msblast.exe". The executable specified by the newly created registry value will be run automatically each time the machine is booted.
Once the "windows auto update" registry value is in place, the Blaster worm next creates a mutex named "BILLY." The existence of the mutex allows a new instance of the Blaster worm to recognize that a target has already been infected, preventing subsequent infection attempts from interfering with an already active instance of Blaster.
The worm then initializes Winsock and checks to see if the infected machine has network access. If an internet connection is available then propagation can proceed, so the worm then checks the date. The infected host will begin SYN flooding windowsupdate.com on port 80 using spoofed source addresses (each address consists of the first two octets of the local address, then two randomly-generated octets in the range 0-254) if the current day is the 16th or later, or on any day if the current month is September through December.
Regardless of the date, the worm will continue infecting hosts, even while carrying out a SYN flood attack against windowsupdate.com.
Infection vector:
The worm will begin infection at an address either based off the local machine's IP address, or a completely random address, and then attempt to infect sequential IP addresses endlessly. Each time a host is infected, there is a 40% chance that it will begin at the first address of its "Class C"-size subnet (x.x.x.0), and a 60% chance that it will start at a completely random IP address with the last octet set to 0 ([1-254].[0-253].[0-253].0). If the starting address is based off of the local address, and the third octet is greater than 20, it will be reduced by a random number between 0 and 19, inclusive.
Once a starting address is determined, the worm attempts to probe blocks of 20 sequential IP addresses at a time for hosts with TCP port 135 (Windows RPC service) open, by sending a connection attempt to each one simultaneously. After about two seconds, the worm will try to exploit each host with which a connection was established, one at a time. First, it transmits a payload over the wire to the designated RPC service listening on that port. 80% of the time the Blaster worm will assume the target environment is Windows XP, while 20% of the time it assumes Windows 2000, and the exploit is configured accordingly. The choice of which OS to target is decided when the worm executable begins running, and remains the same throughout all exploitation attempts. If the target host is running the correct version of Windows, and if its RPC service is vulnerable to the DCOM buffer overflow (Microsoft Security Bulletin MS03-026), the payload causes a command shell to be bound to port 4444 on the infected target. The shell only stays open for one connection, and will therefore be closed once the worm has finished issuing commands.
After sending the payload and waiting for a short interval, the worm assumes that a command shell is listening on the remote port 4444 and attempts to connect. If successful, it starts a TFTP server thread on the local (attacking) machine and sends a command that instructs the remote machine to download a copy of the "msblast.exe" worm executable via TFTP. Once the executable has been transferred, or after 20 seconds have elapsed, the TFTP server is shut down and the worm then issues further commands to the victim to execute msblast.exe. Assuming the executable was downloaded successfully, the propagation cycle then begins again from the newly infected host, while the infecting instance of the worm continues iterating through IP addresses.
Denial of Service:
Each infected host will begin to SYN flood windowsupdate.com (on port 80) starting on the 16th of the month in January through August, or on any day in September through December. Note that this behavior is independent of the current year, and can therefore persist indefinitely as long as instances of the worm remain active in the wild.
Detection:
Check for the existence of the registry key
"SOFTWARE\Microsoft\Windows\CurrentVersion\Run\windows auto update". Also check for the existence of the file "%systemroot%\system32\msblast.exe".
Retina Network Security Scanner has been updated to identify Blaster worm infections, as well as hosts vulnerable to the DCOM security hole that the Blaster uses to propagate.
http://www.eeye.com/html/Products/Retina/index.html
eEye has also released a free scanner to aid in the detection of vulnerable hosts:
http://www.eeye.com/html/Research/Tools/RPCDCOM.html
Removal:
Install the Microsoft patch available from:
http://www.microsoft.com/technet/security/bulletin/MS03-026.asp
Where feasible, disable DCOM and filter the following ports:
TCP: 135, 139, 445, 593
UDP: 135, 445, 593, possible tftp (69)
To manually enable (or disable) DCOM for a computer:
Analysis by:
Drew Copley, Riley Hassell, Barnaby Jack, Karl Lynn, Ryan Permeh, Derek Soeder
Related Links:
Last Stage of Delirium (original discoverers of the RPC DCOM vulnerability)
http://lsd-pl.net/special.html
CVE for the RPC DCOM Vulnerability
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0352
Copyright (c) 1998-2008 eEye Digital Security
Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please email alert@eEye.com for permission.
Disclaimer
The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.
August 11, 2003
Severity:
High
Overview:
The Blaster worm uses a series of components to successfully infect a host. The first component is a publicly available RPC DCOM exploit that binds a system level shell to port 4444. This exploit is used to initiate a command channel between the infecting agent and the vulnerable target. Once the target is successfully compromised, the worm transmits the msblast.exe executable (the main body of the worm) via TFTP to infect the host. The payload used in the public DCOM exploit, as well as the TFTP functionality, are both encapsulated within msblast.exe.
Technical Details:
View eEye's detailed comments of the Blaster Worm assembly code
View eEye's comments of the Metasploit exploit assembly code
When a host is infected with the Blaster worm through the execution of msblast.exe, the registry value "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
CurrentVersion\Run\windows auto update" is created with a string value of "msblast.exe". The executable specified by the newly created registry value will be run automatically each time the machine is booted.
Once the "windows auto update" registry value is in place, the Blaster worm next creates a mutex named "BILLY." The existence of the mutex allows a new instance of the Blaster worm to recognize that a target has already been infected, preventing subsequent infection attempts from interfering with an already active instance of Blaster.
The worm then initializes Winsock and checks to see if the infected machine has network access. If an internet connection is available then propagation can proceed, so the worm then checks the date. The infected host will begin SYN flooding windowsupdate.com on port 80 using spoofed source addresses (each address consists of the first two octets of the local address, then two randomly-generated octets in the range 0-254) if the current day is the 16th or later, or on any day if the current month is September through December.
Regardless of the date, the worm will continue infecting hosts, even while carrying out a SYN flood attack against windowsupdate.com.
Infection vector:
The worm will begin infection at an address either based off the local machine's IP address, or a completely random address, and then attempt to infect sequential IP addresses endlessly. Each time a host is infected, there is a 40% chance that it will begin at the first address of its "Class C"-size subnet (x.x.x.0), and a 60% chance that it will start at a completely random IP address with the last octet set to 0 ([1-254].[0-253].[0-253].0). If the starting address is based off of the local address, and the third octet is greater than 20, it will be reduced by a random number between 0 and 19, inclusive.
Once a starting address is determined, the worm attempts to probe blocks of 20 sequential IP addresses at a time for hosts with TCP port 135 (Windows RPC service) open, by sending a connection attempt to each one simultaneously. After about two seconds, the worm will try to exploit each host with which a connection was established, one at a time. First, it transmits a payload over the wire to the designated RPC service listening on that port. 80% of the time the Blaster worm will assume the target environment is Windows XP, while 20% of the time it assumes Windows 2000, and the exploit is configured accordingly. The choice of which OS to target is decided when the worm executable begins running, and remains the same throughout all exploitation attempts. If the target host is running the correct version of Windows, and if its RPC service is vulnerable to the DCOM buffer overflow (Microsoft Security Bulletin MS03-026), the payload causes a command shell to be bound to port 4444 on the infected target. The shell only stays open for one connection, and will therefore be closed once the worm has finished issuing commands.
After sending the payload and waiting for a short interval, the worm assumes that a command shell is listening on the remote port 4444 and attempts to connect. If successful, it starts a TFTP server thread on the local (attacking) machine and sends a command that instructs the remote machine to download a copy of the "msblast.exe" worm executable via TFTP. Once the executable has been transferred, or after 20 seconds have elapsed, the TFTP server is shut down and the worm then issues further commands to the victim to execute msblast.exe. Assuming the executable was downloaded successfully, the propagation cycle then begins again from the newly infected host, while the infecting instance of the worm continues iterating through IP addresses.
Denial of Service:
Each infected host will begin to SYN flood windowsupdate.com (on port 80) starting on the 16th of the month in January through August, or on any day in September through December. Note that this behavior is independent of the current year, and can therefore persist indefinitely as long as instances of the worm remain active in the wild.
Detection:
Check for the existence of the registry key
"SOFTWARE\Microsoft\Windows\CurrentVersion\Run\windows auto update". Also check for the existence of the file "%systemroot%\system32\msblast.exe".
Retina Network Security Scanner has been updated to identify Blaster worm infections, as well as hosts vulnerable to the DCOM security hole that the Blaster uses to propagate.
http://www.eeye.com/html/Products/Retina/index.html
eEye has also released a free scanner to aid in the detection of vulnerable hosts:
http://www.eeye.com/html/Research/Tools/RPCDCOM.html
Removal:
- Delete the following registry key:
"HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
Value: "windows auto update"
String: "msblast.exe" - Look for "msblast.exe" running in the task manager. If it is running, kill the process.
- Delete the file "%systemroot%\system32\msblast.exe"
Install the Microsoft patch available from:
http://www.microsoft.com/technet/security/bulletin/MS03-026.asp
Where feasible, disable DCOM and filter the following ports:
TCP: 135, 139, 445, 593
UDP: 135, 445, 593, possible tftp (69)
To manually enable (or disable) DCOM for a computer:
- Run dcomcnfg.exe. If you are running Windows XP or Windows Server 2003, perform these additional steps:
- Click on the Component Services node under Console Root.
- Open the Computers sub-folder.
- For the local computer, right click on My Computer and choose Properties.
- For a remote computer, right click on the Computers folder and choose New then Computer. Enter the computer name.
- Right click on that computer name and choose Properties.
- Choose the Default Properties tab.
- Select (or clear) the Enable Distributed COM on this Computer check box.
- If you will be setting more properties for the machine, click the Apply button to enable (or disable) DCOM. Otherwise, click OK to apply the changes and exit Dcomcnfg.exe.
- Reboot.
Analysis by:
Drew Copley, Riley Hassell, Barnaby Jack, Karl Lynn, Ryan Permeh, Derek Soeder
Related Links:
Last Stage of Delirium (original discoverers of the RPC DCOM vulnerability)
http://lsd-pl.net/special.html
CVE for the RPC DCOM Vulnerability
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0352
Copyright (c) 1998-2008 eEye Digital Security
Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of eEye. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please email alert@eEye.com for permission.
Disclaimer
The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are no warranties, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk.
