McAfee > Theat Center > Virus Detail Page

Overview

This is a virus detection. Viruses are programs that self-replicate recursively, meaning that infected systems spread the virus to other systems, which then propagate the virus further. While many viruses contain a destructive payload, it's quite common for viruses to do nothing more than spread from one system to another.

Aliases

• DDOS_SQLP1434.A (Trend)

• Sapphire (F-Secure, eEye)

• W32.SQLExp.Worm (Symantec)

• Worm.SQL.Helkern (Kaspersky)

Characteristics

-- Update March 11, 2004 --
The risk assessment of this threat was lowered to Low-Profiled due to a decrease in prevalence.

-- Update March 4, 2003 --
The 4247 dat files, in conjunction with either the 4240 Command Line Scanner or the soon to be released VirusScan 7.0 Enterprise (4240 engine) are able to detect this worm in memory via an On-Demand scan.

-- Update January 30, 2003 --
Due to a decrease in prevalence of this worm, as a result of the number of vulnerable systems being patched, and firewalls being configured to block UDP Port 1434, the risk assessment has been lowered to Medium.

This threat has a special Risk Assessment - it is "High" only for unpatched systems (only affects SQL servers not running SP3 for MS SQL/MSDE):

* Microsoft SQL Server 2000
* Microsoft Desktop Engine (MSDE) 2000

* Microsoft SQL Server 2000
* Microsoft Desktop Engine (MSDE) 2000

* Microsoft SQL Server 2000
* Microsoft Desktop Engine (MSDE) 2000

For a complete list of which patches must be applied to SQL Servers that are not running SP3, visit Microsoft Technet .

This virus exists only in memory of unpatched Microsoft SQL servers. Its purpose is simply to spread from one system to another and it does not carry a destructive payload.

This worm causes increased traffic on UDP port 1434 and spreads between SQL servers. Heavy network traffic, associated with this threat, can effect network performance on all systems on the network.

It uses a buffer overflow in "Server Resolution" service (read about CVE-CAN-2002-0649 vulnerability in MS02-39 and CVE list ) to gain control on a target server. SQL Servers running Service Pack 3 are not affected.

The malformed packet is only 376 bytes long (which is the full worm!) and carries the following strings: "h.dllhel32hkernQhounthickChGetTf", "hws2", "Qhsockf" and "toQhsend".

The minimal risk for this worm has been set to Low-Profiled because of the media attention at CNN.

Symptoms

Unusually high outgoing traffic from an infected system to UDP 1434 as seen below in the Sniffer Matrix View. The Sniffer can be used as a network scanner to detect and identify infected computers.

This worm does not exist as a file on your system. No INI or registry keys are created by this worm.

The MD5 checksum of the worm (376 bytes) is A0AA4A74B70CBCA5A03960DF1A3DC878.

Method of Infection

The worm body starts with byte 04 (followed by a long series of 01s) which when received by the SQL Monitor generates a long registry key name (HKLM\Software\Microsoft\Microsoft SQL Server\.....\MSSQLServer\CurrentVersion) overflowing the buffer (dots in this key denote the Registry key branch SQL Monitor tries to access - for SQLSlammer.worm these bytes are are a long series of unprintable 01 symbols following 04 which is a type of request). That overwrites the return address on stack and the worm code recieves control with the privileges of the SQL Monitor. The vulnerability that this worm uses lays in the SSNETLIB.DLL in the routine that handles requests of type 04 to 1434/udp port.

Once the worm gets control on the target computer it loads WS2_32.DLL and starts to continually send itself to port 1434/udp of randomly selected IP targets in an infinite loop.The IP of a victim is constructed using 'GetTickCount' API and is purely random (no skew towards the local subnet, for example). This propagation strategy consumes a lot of network bandwith because the vast majority of requests go to the Internet.

The worm does no error checking whatsoever - its operation may cause crashes of SQL servers it was not designed for. The worm exists only in memory and does not modify any local files.

Removal

AVERT's recommendations are:

1. Block incoming UDP 1434 at your firewall (it is advisable to turn off logging on that port at the same time)

2. Download and apply Service Pack 3 from Microsoft, and restart the server. This will clear the virus from memory and prevent reinfection. The corrected SSNETLIB.DLL will have version 2000.80.760.0 (you can inspect it by right clicking on the DLL icon and selecting 'Properties' and then 'Version' tab).

Installing SQL SP3 without significant testing may create problems for some admins. In the event that SP3 can not be installed immediately, the MS02-061 patch should be applied.

Alternatively, we have made available a new version of Stinger designed to locate the worm in memory on infected SQL servers, and shut down the SQL processes. Stinger must be run with Administrator privileges to shut down SQL Server, and will NOT prevent future infections, unless you also install the above-mentioned Service Pack.

SNIFFER USERS: A Sniffer filter to detect W32/SQLSlammer.worm traffic is available for Sniffer Distributed 4.2 and Sniffer Portable 4.7.

• Instructions to install the filter for Sniffer Distributed
• Instructions to install the filter for Sniffer Portable

McAfee ThreatScan Users: A ThreatScan signature update has been posted to locate unpatched Microsoft SQL 2000 servers. To update ThreatScan, first run the console auto update utility on the ePO server (not an ePO console). Next, push out update tasks to all your ThreatScan agents. After successfully updating your ThreatScan installation create a new ThreatScan task of type "Threat Scan". Select the "Remote Vulnerability Detection" category and the "SQL Slammer Worm Vulnerability Check" on the scan options tab. When this task is executed, all computers that are running Microsoft SQL Server 2000 that do not have service pack 3 will be reported.

McAfee Desktop Firewall Users: If you are running the McAfee Desktop Firewall on your SQL servers you simply need to create a rule that blocks incoming UDP port 1434.

Variants

Variants

N/A

All Information

Overview -

This is a virus detection. Viruses are programs that self-replicate recursively, meaning that infected systems spread the virus to other systems, which then propagate the virus further. While many viruses contain a destructive payload, it's quite common for viruses to do nothing more than spread from one system to another.

Aliases

• DDOS_SQLP1434.A (Trend)

• Sapphire (F-Secure, eEye)

• W32.SQLExp.Worm (Symantec)

• Worm.SQL.Helkern (Kaspersky)

Characteristics

Characteristics -

-- Update March 11, 2004 --
The risk assessment of this threat was lowered to Low-Profiled due to a decrease in prevalence.

-- Update March 4, 2003 --
The 4247 dat files, in conjunction with either the 4240 Command Line Scanner or the soon to be released VirusScan 7.0 Enterprise (4240 engine) are able to detect this worm in memory via an On-Demand scan.

-- Update January 30, 2003 --
Due to a decrease in prevalence of this worm, as a result of the number of vulnerable systems being patched, and firewalls being configured to block UDP Port 1434, the risk assessment has been lowered to Medium.

This threat has a special Risk Assessment - it is "High" only for unpatched systems (only affects SQL servers not running SP3 for MS SQL/MSDE):

* Microsoft SQL Server 2000
* Microsoft Desktop Engine (MSDE) 2000

* Microsoft SQL Server 2000
* Microsoft Desktop Engine (MSDE) 2000

* Microsoft SQL Server 2000
* Microsoft Desktop Engine (MSDE) 2000

For a complete list of which patches must be applied to SQL Servers that are not running SP3, visit Microsoft Technet .

This virus exists only in memory of unpatched Microsoft SQL servers. Its purpose is simply to spread from one system to another and it does not carry a destructive payload.

This worm causes increased traffic on UDP port 1434 and spreads between SQL servers. Heavy network traffic, associated with this threat, can effect network performance on all systems on the network.

It uses a buffer overflow in "Server Resolution" service (read about CVE-CAN-2002-0649 vulnerability in MS02-39 and CVE list ) to gain control on a target server. SQL Servers running Service Pack 3 are not affected.

The malformed packet is only 376 bytes long (which is the full worm!) and carries the following strings: "h.dllhel32hkernQhounthickChGetTf", "hws2", "Qhsockf" and "toQhsend".

The minimal risk for this worm has been set to Low-Profiled because of the media attention at CNN.

Symptoms

Symptoms -

Unusually high outgoing traffic from an infected system to UDP 1434 as seen below in the Sniffer Matrix View. The Sniffer can be used as a network scanner to detect and identify infected computers.

This worm does not exist as a file on your system. No INI or registry keys are created by this worm.

The MD5 checksum of the worm (376 bytes) is A0AA4A74B70CBCA5A03960DF1A3DC878.

Method of Infection

Method of Infection -

The worm body starts with byte 04 (followed by a long series of 01s) which when received by the SQL Monitor generates a long registry key name (HKLM\Software\Microsoft\Microsoft SQL Server\.....\MSSQLServer\CurrentVersion) overflowing the buffer (dots in this key denote the Registry key branch SQL Monitor tries to access - for SQLSlammer.worm these bytes are are a long series of unprintable 01 symbols following 04 which is a type of request). That overwrites the return address on stack and the worm code recieves control with the privileges of the SQL Monitor. The vulnerability that this worm uses lays in the SSNETLIB.DLL in the routine that handles requests of type 04 to 1434/udp port.

Once the worm gets control on the target computer it loads WS2_32.DLL and starts to continually send itself to port 1434/udp of randomly selected IP targets in an infinite loop.The IP of a victim is constructed using 'GetTickCount' API and is purely random (no skew towards the local subnet, for example). This propagation strategy consumes a lot of network bandwith because the vast majority of requests go to the Internet.

The worm does no error checking whatsoever - its operation may cause crashes of SQL servers it was not designed for. The worm exists only in memory and does not modify any local files.

Removal -

Removal -

AVERT's recommendations are:

1. Block incoming UDP 1434 at your firewall (it is advisable to turn off logging on that port at the same time)

2. Download and apply Service Pack 3 from Microsoft, and restart the server. This will clear the virus from memory and prevent reinfection. The corrected SSNETLIB.DLL will have version 2000.80.760.0 (you can inspect it by right clicking on the DLL icon and selecting 'Properties' and then 'Version' tab).

Installing SQL SP3 without significant testing may create problems for some admins. In the event that SP3 can not be installed immediately, the MS02-061 patch should be applied.

Alternatively, we have made available a new version of Stinger designed to locate the worm in memory on infected SQL servers, and shut down the SQL processes. Stinger must be run with Administrator privileges to shut down SQL Server, and will NOT prevent future infections, unless you also install the above-mentioned Service Pack.

SNIFFER USERS: A Sniffer filter to detect W32/SQLSlammer.worm traffic is available for Sniffer Distributed 4.2 and Sniffer Portable 4.7.

• Instructions to install the filter for Sniffer Distributed
• Instructions to install the filter for Sniffer Portable

McAfee ThreatScan Users: A ThreatScan signature update has been posted to locate unpatched Microsoft SQL 2000 servers. To update ThreatScan, first run the console auto update utility on the ePO server (not an ePO console). Next, push out update tasks to all your ThreatScan agents. After successfully updating your ThreatScan installation create a new ThreatScan task of type "Threat Scan". Select the "Remote Vulnerability Detection" category and the "SQL Slammer Worm Vulnerability Check" on the scan options tab. When this task is executed, all computers that are running Microsoft SQL Server 2000 that do not have service pack 3 will be reported.

McAfee Desktop Firewall Users: If you are running the McAfee Desktop Firewall on your SQL servers you simply need to create a rule that blocks incoming UDP port 1434.

Variants

Variants -

N/A