DISCLAIMER: I wrote this as a quick and dirty explanation for a friend without a background in computer science. I am sure that some of my explanations may not be completely correct. It has been a while since I gave much specific thought to computer architecture, since university, though I have the general concepts pretty well. I don’t think this is very well written, but I wrote it, so I might as well put it out there just in case it might help someone else. Explanation of the Recent MS SQL Worm Main text from http://www.nextgenss.com/advisories/mssql-udp.txt Other comments added inline. Microsoft's database server SQL Server 2000 exhibits two buffer overrun vulnerabilities that can be exploited by a remote attacker without ever having to authenticate to the server. This is the vulnerability that allowed a virus-like program to take over many thousands of machines on the Internet recently. It is called a worm because it moves and spreads itself, requiring no action from the user. A virus requires the user to perform some action such as opening a contaminated file. A buffer is the section of memory where programs code and variable values are stored. The processor essentially follows instructions from one section of memory to another, jumping around from one section to another, like following the logic of a program written without control loops, only conditionals and GoTo’s. - Brian “Buffer Overrun - An attack in which a malicious user exploits an unchecked buffer in a program and overwrites the program code with their own data. If the program code is overwritten with new executable code, the effect is to change the program's operation as dictated by the attacker. If overwritten with other data, the likely effect is to cause the program to crash. “ - http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/glossary.asp If a program does not check to make sure that a variable does not exceed its storage, the value can over run its assigned memory space and overwrite other memory space. If the processor hits a GoTo in the compromised space, the hacker has control of the processor. - Brian What further exacerbates these issues is that the attack is channeled over UDP. Whether the SQL Server process runs in the security context of a domain user or the local SYSTEM account, successful exploitation of these security holes will mean a total compromise of the target server and its data. “TCP uses a three-way handshake before it starts to transfer data. UDP just blasts away without any formal preliminaries." - http://www-net.cs.umass.edu/kurose/transport/UDP.html SQL Server can be configured to listen for incoming client connections in several different ways. It can be configured such that clients can use named pipes over a NetBIOS session (TCP port 139/445) or sockets with clients connecting to TCP port 1433 or both. Which ever method is used the SQL Server will always listen on UDP port 1434. This port is designated as the Microsoft SQL Monitor port and clients will send a message to this port to dynamically discover how the client should connect to the Server. This message is a single byte packet, the byte being 0x02. When SQL Server receives a packet on UDP port 1434 with the first byte set to 0x04, the SQL Monitor thread takes the remaining data in the packet and attempts to open a registry key using this user supplied information. For example, by sending \x04\x41\x41\x41\x41 (0x04 followed by 4 upper case 'A's) SQL Server attempts to open HKLM\Software\Microsoft\Microsoft SQL Server\AAAA\MSSQLServer\CurrentVersion By appending a large number of bytes to the end of this packet, whilst preparing the string for the registry key to open, a stack based buffer is overflowed and the saved return address is overwritten. This allows an attacker to gain complete control of the SQL Server process and its path of execution. By overwriting the saved return address on the stack with an address that contains a "jmp esp" or "call esp" instruction (a GoTo instruction - Brian), when the vulnerable procedure returns the processor will start executing code of the attacker's choice. At no stage does the attacker need to authenticate. Once the recent worm used this exploit to take control of the machine, it then started blasting other IP addresses searching for other SQL servers to continue spreading. All this traffic is what caused the net slowdown. – Brian