In this installation of Malware Minute, I decided to take it back a little old school and research and discuss a worm that infected over 75,000 computers and took out a major portion of the internet in 8.5 seconds in 2003 called SQL Slammer. This is not the first malware to attack SQL servers, nor was it the first work ever discovered, but it was a type of malware that transformed the way that vulnerabilities are reported, as well as, how Microsoft handled system patching.
Before getting into the details of this specific malware, it is very important to explain what a SQL Server is if there is anyone out there that does not know. Most applications run off of databases, which are large storage facilities for data. These databases are of a few varieties, some use a language called SQL, and these are considered SQL databases, the most common of these is Microsoft SQL Server, MySQL, and Oracle. Then there are others that do not use the SQL language but instead use another type of scripting language. These databases are called NoSQL databases. When a website or application retrieves, such as a username and password, it must connect to a server that is hosting a database and retrieve this information. As you can imagine, most of the internet is connected to a database.
SQL slammer was derived from an exploit that Security Researcher David Litchfield developed ethically in 2002 on an assignment. Litchfield developed the exploit from a tool called SQLPing that would inject a single byte packet with a value of 0x02 into UDP port 1434 on a SQL Server (Litchfield, 2010). Litchfield, like most security researchers, became interested in what would happen if he changed the byte and incremented the values. He wrote a short program and tested it out on a SQL server 2000 testing environment; this was when he discovered the exploit initially. He noticed that value 0x08 in the SQL Server had crashed the server, and became interested in what was happening, so he broke down the code and began exploring (Litchfield, 2010).
Essentially through reverse engineering and analyzing the exploit, Litchfield finds a way to own the SQL servers by finding a buffer overflow vulnerability. A buffer overflow is a condition in which a program attempts to put more data in a buffer (section of allocated memory) than it can hold, which can corrupt the data or create an area to execute malicious code. Litchfield reported this information to Microsoft, they released a patch, then allowed Litchfield to present his proof of concept at a security conference the following month (Litchfield, 2010).
While Litchfield is technically the writer of the exploit, he is not the author of the malware. Litchfield’s purpose was to alert the security community about the need to apply the patch. However, someone took his proof of concept code and developed it into a worm that would replicate itself on multiple computers. Even though a patch was created to secure the system, it was not effective when many systems had not been patched to fix the vulnerability. This created a new code of ethics per se in the security world. Exploits are now handled more responsibly, and vendors have changed how they release patches. The malware was stored in memory (RAM) and was able to be wiped off of a system through a restart. However, the malware could replicate itself and find its way back in the SQL Server system if it were not patched.
This malware shows how security researchers must be responsibly presenting their proof of concepts at security conferences as well as the importance of vendors to get patches to build, distributed, and alert their user’s when bugs are found.
Works Cited:
Litchfied, D. (2010). The Inside Story of SQL Slammer. Retrieved on April 10, 2019, from https://threatpost.com/inside-story-sql-slammer-102010/74589/