You've probably heard by now about the Spida worm, also known as digispid.b.worm and SQLSnake. Spida, first identified in May, is a worm that attacks SQL Server instances that have a null sa password. Worms and viruses are always dangerous, but Spida is particularly spine-chilling because careless SQL Server users contributed to its spread.
Spida scans port 1433 on SQL Server machines, looking for a null sa password. The worm connects to SQL Server and uses the xp_cmdshell procedure to add the Windows Guest account to the local and domain administrators' groups. Spida then propagates by copying files that it uses to attack other machines. Spida also collects various diagnostic and SAM information about the server and sends this information to a defunct email address outside of the United States. You'll find a detailed technical description of Spida at http://www.eeye.com/html/research/advisories/al20020522.html . This page tells you exactly what Spida does to your machine and includes information about removing the virus. You'll also find a free scanner that will quickly determine whether the virus has infected your machine.
Why do I call the Spida worm spine-chilling? This worm infected more than 10,000 machines in May, according to reports, but had SQL Server administrators followed basic security practices, the worm couldn’t have spread. This particular worm doesn't use a dictionary attack to find passwords that are common words. For example, it doesn't look for weak passwords—ones that don't contain a mix of difficult-to-guess alpha and numeric characters. Spida attacks machines that have a null sa password. SQL Server 2000 administrators must make a conscious decision to create a null password because the Setup program prompts you with an "Are you sure?" message. You've received the same explicit warning about SQL Server 7.0 if you've applied Service Pack 3 (SP3) or later.
Spida didn't spread because busy administrators couldn't keep up with the latest security hotfixes and vulnerability warnings from Microsoft. Spida spread because administrators and developers were too lazy and inattentive to bother using a password for the sa account. I bet these same people wouldn't write their PIN on the back of their ATM card, then leave the card on a busy street.
Why do people make silly mistakes like allowing a null sa password? I confess that I'm one of the careless people I just described. I'm ashamed to admit that I've worked on projects that have a null sa password to ease the workflow for developers. I've never used a null sa password on a production box, but I have on development boxes where the data wasn't considered important. But the Spida epidemic illustrates how dangerous sloppy password administration can be. Spida didn't do much damage, but imagine the consequences if it had used xp_cmdshell to delete all files from every hard disk it could find on the network. People were very lucky this time.
Please create a strong password for your sa account if you don't have one already. Please block port 1433 from the Internet and create a secure demilitarized zone (DMZ) for people to use to access your SQL Server. We can yell all we want at Microsoft and other vendors for not adequately addressing security. But people who live in glass houses shouldn't throw stones. Have you taken reasonable and appropriate steps to secure your SQL Server?
