AusCERT - Business Impact Assessment - Possible Slammer hiatus

Business Impact Assessment - Possible Slammer hiatus

Date: 30 January 2003
Original URL: http://www.auscert.org.au/render.html?cid=1926&it=2730
References: ESB-2002.187 ESB-2002.280 ESB-2002.338 ESB-2002.339 ESB-2002.363 ESB-2002.364 ESB-2002.368 AU-2003.002

The effects of the Slammer worm were short-lived but if circumstances permit a resurgence of harmful network activity may easily occur. Slammer scanning started to be noticed in Australia at 1530 hours Australian Eastern Daylight Time (AEDT) (+11 UTC) on Saturday, 25 January 2003 and began dissipating around 0600, AEDT, Sunday 26 January 2003. Shortly after the worm commenced scanning, many tier two and three ISPs commenced blocking inbound and outbound 1434/UDP traffic.

While there is no doubt that some machines connected to the Internet remain vulnerable to the Slammer worm, many countries have reported that Slammer scanning has decreased to negligible rates. While there is a lull in Slammer activity, there are number of key issues that IT security managers should consider.

What machines were affected?

Slammer targeted vulnerable Microsoft SQL Server 2000 but also affected Microsoft Desktop Engine (MSDE) which is a stripped down version of SQL Server, primarily used for smaller databases on workstations. MSDE comes installed with applications such as Visual Studio and Office XP Developer Edition.

What it did

The worm did not include a DoS attack mechanism - in fact it didn’t include any malicious payload whatsoever, eg, Trojan, backdoor, format files etc. Rather its ability to rapidly and randomly spread using the User Datagram Protocol (UDP), a low-overhead, connectionless protocol, meant that once the worm compromised a vulnerable machine, it saturated all accessible network connections to the Internet in an attempt to propagate further. As networks typically have smaller bandwidth connections to the Internet than they do within their LANs, it was possible for a single infected machine to diminish the capacity of all machines on the LAN to access the Internet. For example, one Australian site reported that a single compromised SQL server saturated an 8Mbps Internet connection.

Slammer could have been worse

The fact that the worm did not include a harmful payload is fortunate but it could easily have done so. The nature of the vulnerability was such that it enabled an attacker to execute arbitrary code with system privileges, ie, higher than the Administrator account. In summary, while Slammer diminished system and network availability, had it included a malicious payload it could have significantly compromised the confidentiality and integrity of all data accessible by the compromised host. Furthermore, the time and effort involved in clean-up and recovery would have been considerably more resource-intensive.

Slammer virility

The fact that the worm was able to spread so quickly is the result of three primary factors:

The presence of vulnerable versions of (unpatched) MS SQL Server and MSDE;
The failure to configure firewalls to only explicitly allow authorised and necessary traffic, while having a default deny rule; and
The worm exploit was a mere 400 bytes in size and was well suited to the fast and connectionless nature of UDP. Being connectionless meant that compromised scanning machines were able to send out scanning packets at a faster rate than had it relied on the connection-oriented Transmission Control Protocol (TCP). In comparison, Code Red machines scanned for vulnerable Microsoft IIS web servers using port 80/TCP.

Prevention

Notably, the patch for the vulnerability that the worm exploited has been publicly available for the last six months. Microsoft publicly released Microsoft Security Bulletin MS02-039, “Buffer Overruns in SQL Server 2000 Resolution Service Could Enable Code Execution” on 25 July 2002.

As databases are typically back-end applications there is little reason why they should have unrestricted access from the Internet. Where remote access to the database is required, it should occur via an appropriately restricted firewall or a Virtual Private Network (VPN).

Recovery

As this worm was memory based, it did not write any information to disk and thus allowed users to quickly and easily recover by applying the relevant MS patch and rebooting the machine. Although the worm propagated rapidly within a short time, it was also easier to protect against than some other worms and viruses (eg, Nimda, Code Red II, Bugbear).

Future malicious activity

Observations with the Code Red lineage showed that despite wide publicity associated with rapid propagations, many system administrators were surprisingly slow to patch their vulnerable systems. AusCERT is aware of ISPs which have already commenced removing or are planning to remove filters on port 1434/UDP. If hosts remain vulnerable and their firewalls continue to permit 1434/UDP, networks will again be exposed to incoming malicious connections. This may lead to a resurgence in Slammer activity or other new attacks containing payloads with more harmful effects. The fact that the source code for Slammer is publicly available is likely to facilitate the creation of these new attacks.

Conclusion

If you haven’t already done so, now is the time to identify and review your organisation’s change management policies and procedures for security-related patches/service packs and apply outstanding patches.

As part of a defence-in-depth approach to security, organisations should also consider blocking all non-essential services at hosts and network gateways. For some organisations, an analysis of the services and applications available on the network may be required before it is possible to determine what are essential and non-essential services.