SANS says it has reports indicating that the recent dramatic increase in port 1433 scans is due to an automated worm attack rather than manual probes on the port. The SQLSnake worm (sqlexec.js is the name of the wrapper) is also known as the Spida worm, SQLSpida, and Digispid.B.Worm. It builds an ActiveX object containing the commands to run via the xp_cmdshell and uses a brute-force password attack on the sa SQL Server administrator's account. When successful, the worm logs on with administrator access, giving the attacker the ability to read, write, and modify data, as well as run executable code. SQL Server expands its power by calling stored procedures, functions in dynamic link libraries, outside the database. This is done through port 1433, so the port can't be disabled for most installations (and, in any case, that's not the real problem). Risk level: Severe
This attack is often successful simply because many admins don't bother setting a password for the administrator account, making an attack through this vector almost trivial. According to a report from SecurityFocus, this attack appears to be specifically targeting the SQL databases that still have the default, null, password. Because the administrator has the highest level of privileges, a successful attack can be very serious. Microsoft Support has information on the use of port 1433 by SQL to access applications through a firewall. Although SQL listens for incoming connections via port 1433 by default, it can be configured to use another port. If this has been changed on a system, it's not vulnerable to this particular attack. Applicability
SQL Server version 7.0 is probably the last version vulnerable to this attack. By default, SQL Server 2000 requires that the installer create a password for the sa account. TCP port 1433 is commonly used by Microsoft SQL Database to accept queries. This threat probably affects all SQL installations older than SQL Server version 7.0 that are also connected to the Internet. It would be incorrect to label this a flaw in the software, nor is it a vulnerability in the usual sense. Rather, this attack is possible due to poorly configured default settings and weak installation and administration practices. Mitigating factors
If you have set a strong password, there is not likely to be a successful system penetration, and certainly this version of the worm won't be a threat. Since Microsoft warned users earlier in the year that port 1433 scans were being conducted by the Voyager Force Alfa worm, more administrators than usual may have secured their systems. But there are still reports of a number of infected systems. Fix: Set a password
Configure your SQL database's administrator account with a strong password. The sa account cannot simply be disabled because, according to Microsoft, it's required for backward compatibility. To see whether your SQL Server systems have been exploited or are vulnerable to this attack, download this free scanner from eEye Digital Security. Microsoft's White Paper on SQL Server 7 security might also prove useful, although it isn't needed to explain this simple problem. However, if you still have the sa account password set to null, you definitely need to download and study the white paper to see what other SQL Server security issues you may be unaware of.