According to SANS Institute and other security sources, Microsoft SQL servers are under active attack from a new worm. 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.
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.
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.
The Incidentes.org (SANS Institute) report on this worm lists the following files as being enclosed in SQLSnake:
drivers/services.exe — Foundstone’s fscan.exe (UPX packed)
According to a CNET News Report, within two days of the worm’s appearance, 2,450 SQL servers had been infected and 74,000 had been targeted for attack.
The following sources also have advisories or reports on the SQLSnake worm:
Once again, IT pros will probably direct most of the blame for this attack at Microsoft for configuring poor defaults on earlier versions of SQL Server. But in this instance, the company’s big mistake was relying on administrators to install its software with a minimum of common sense by altering the default installation password.
Even if only a small percentage of users have failed to properly secure their systems, this will still be a dangerous worm because Microsoft SQL database has a large market share, especially in small to midsize businesses.
To make matters worse, this isn’t some newly discovered problem. Several previous warnings have been issued, including at least one directly from Microsoft, telling SQL Server admins that they need to set passwords on the sa account. For those who have missed or ignored earlier warnings, it’s definitely time to get around to fixing this problem.