This vulnerability can be exploited remotely with no authentication and no user interaction necessary. If exploited, the attacker may perform remote code execution with the privileges of System or may create a Denial of Service. The attack vector is through TCP ports 139 and 445. This vulnerability is designated by CVE ID 2006-3439.

This document contains information to assist Cisco customers in mitigating attempts to exploit the Microsoft Server Service Buffer Overflow Vulnerability. There is a remote code execution vulnerability in Server Service that could allow an attacker who successfully exploited this vulnerability to take complete control of the affected system.

Cisco devices provide several countermeasures for the MS06-040 vulnerability. The most preventative control is provided by Cisco Security Agent (CSA) at the end host level. The CSA default enabled rule set provides threat mitigation from all known attack vectors. Detective controls can be performed by the Cisco IPS product suite, which provides identification and protection starting with signature pack S243 using signatures 5799/0-5799/7. Access Lists applied on Cisco IOS® software, PIX, and ASA along with Access controls applied to VPN connections provide deterrents, thus reducing threat exposure.

The effectiveness of any mitigation technique is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround is the most appropriate for use in the intended network before it is deployed.

Caution: As with any configuration change in a network, evaluate the impact of this configuration prior to applying the change.

The access list entries shown below include an example for one of the worm variants now being tracked. New variants using different ports are possible and should be filtered using the information below as examples.

The following access-list can be applied to a PIX Firewall running 6.x software to prevent/contain the spread of the MS06-040 exploit on customer networks.

Caution: As with any configuration change in a network, evaluate the impact of this configuration prior to applying the change.

The access list entries shown below include an example for one of the worm variants now being tracked. New variants using different ports are possible and should be filtered using the information below as examples.

The following access-list can be applied inbound to a PIX/ASA Firewall running 7.x software to prevent/contain the spread of the MS06-040 exploit on customer networks:

The Cisco Intrusion Prevention System (IPS) can provide detection of the MS06-040 vulnerability starting with signature pack S243 for 5.x devices.

Signature Pack S243

Added signatures 5799/0 - 5799/6

Signature Pack S244

Added meta signature 5799/7

Modified signature 5799/2

Retired signatures 5799/0 and 5799/3

Signature Pack S245

Added signature 6013/0 for detection of DNS requests for the C&C channel of the WORM_IRCBOT.JK botnet network

Modified signatures 5799/4 and 5799/7

The Cisco Intrusion Detection System (IDS) can provide detection of the MS06-040 vulnerability starting with signature pack S245 for 4.x devices.

Signature Pack S245

Added signature 5799/0 (disabled by default)

Added signature 6013/0 for detection of DNS requests for the C&C channel of the WORM_IRCBOT.JK botnet network

In order to trigger preventative controls, the IPS 5.x signatures 5799/4 and 5799/7 or the IDS 4.x signature 5799/0 will need to be configured to perform a response action. The actions that provide this type of mitigation are more effective when using an IPS device that is deployed in inline mode. This threat is TCP based so attacks are unlikely to be spoofed.

IPS meta signatures 5799/4 and 5799/7 trigger a High severity alarm on potential exploits of the Windows Server Service vulnerability which may indicate a remote code execution attack. Supporting component signatures are used to detect the intermediate steps of the attack.

The following event was triggered by signature 5799/7 after a potential exploit of the Windows Server Service was attempted on the target victim at IP address 192.0.2.157.

A number of signatures were defined in signature packs S243, S244 and S245. Of these signatures, IPS 5.x customers should monitor for signatures 5799/4, 5799/7 and 6013/0 and IDS 4.x customers should monitor for 5799/0 and 6013/0. The rest of the IPS 5.x 5799/x signatures are components to identify individual steps in the attack. Signatures 5799/0 and 5799/3 are retired as of Signature Pack S244.

In addition, signature 11203/0 (Severity: MEDIUM, Enabled by default) can be modified to detect potential IRC bot activity on TCP port 18067 and 22522. Adding TCP 18067 and 22522 to the service-ports (TCP ports 6666, 6667, 6668 are already configured by default) used by Signature 11203/0 can be done as follows:

Signature pack S245 adds signature 5799/0 for Cisco Intrusion Detection (IDS) 4.X devices. However, the detection algorithm for this signature differs between the IDS 4.x and IPS 5.x platforms due to enhanced features available in IPS 5.x. The 5799/0 signature is disabled by default in IDS 4.x devices because it is more prone to false positives. Depending on traffic flows, signature 5799/0 may degrade performance on lower end 4.x IDS devices.

Cisco Security Agent (CSA) provides mitigation through buffer overflow protection mechanisms that prevent the exploit from doing damage. These mechanisms are a part of the default rule set and are enabled by default. CSA versions 4.0.3.X and later provide prevention capabilities.

The CSA agents must be set in "Protect Mode" (not "Test Mode") mode for successful prevention of this exploit. No updates are required. The specific rules that stop the exploit are:

Buffer overflow protection found in:

System API control rule - which is in Rule Module "General Application Permissions - all Security Levels". The description for this rule is: "Network applications, access system functions from a buffer"

Site-to-site VPNs should have access control applied on a need-to-know basis instead of an implicit trust model. Therefore, applying an ACL to block TCP/139 and TCP/445 as part of standard VPN configurations is recommended unless business use dictates otherwise. Below is a sample IOS ACL that could be applied to the decrypted VPN traffic as it exits the VPN termination device or to another screening device that is located at the next hop from the VPN termination device.

Caution: As with any configuration change in a network, evaluate the impact of this configuration prior to applying the change.

The access list entries shown below include an example for one of the worm variants now being tracked. New variants using different ports are possible and should be filtered using the information below as examples.

Any added access list entries should be implemented as part of a Transit Access Control List that filters transit and edge traffic at network ingress points.

Note: If you are trying to track source addresses, use Sampled NetFlow, rather than "log" statements in access lists as the high traffic in combination with the log statement can overwhelm the router. The command show access-list can be used to determine the hit count against individual access list entries. This data can be used in conjunction with Sampled NetFlow to determine which specific worm variants are attacking the network.

With Transit Access-lists, Cisco IOS routers can be configured with interface access-lists to drop packets that could potentially be used to exploit (and contain the spread of) this issue.

Caution: As with any configuration change in a network, evaluate the impact of this configuration prior to applying the change.

The access list entries shown below include an example for one of the worm variants now being tracked. New variants using different ports are possible and should be filtered using the information below as examples.

Any added access list entries should be implemented as part of a Transit Access Control List that filters transit and edge traffic at network ingress points.

Note: If you are trying to track source addresses, use Sampled NetFlow, rather than "log" statements in access lists as the high traffic in combination with the log statement can overwhelm the router. The command show access-list can be used to determine the hit count against individual access list entries. This data can be used in conjunction with Sampled NetFlow to determine which specific worm variants are attacking the network.

Please note that filtering traffic with an interface access list will elicit the transmission of ICMP unreachable messages back to the source of the filtered traffic. This could have the undesired side effect of high CPU utilization since the device needs to generate these ICMP unreachable messages. In Cisco IOS software, ICMP unreachable generation is limited to one packet per 500 ms. ICMP unreachable generation can be disabled using the interface configuration command no ip unreachables. ICMP unreachable rate-limiting can be changed from the default 1 per 500 ms using the global configuration command ip icmp rate-limit unreachable <1-4294967295 millisecond> .

With a Transit Access-list, once the interface access-list is deployed, the command show access-list 101 can be used to identify the number of packets being dropped. Dropped packets should be investigated to determine if they are attempts to exploit the issue.

In the above example there are a very high number of flows on TCP/139 (Hex 008B) and TCP/445 (Hex 01BD) from a single IP address to multiple destination IP addresses. On internet edge routers and potentially on VPN termination routers, this may be indicative of an attempt to exploit this vulnerability and should be compared to baseline utilization of these ports on the monitoring devices.

To only view flows on TCP/139 (Hex 008B) and TCP/445 (Hex 01BD), the command show ip cache flow | inc SrcIf|008B|01BD may be used as shown here:

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.