Don't Be SQL Server Slammed This Holiday

Remember SQL Server slammer, which struck nearly six years ago? IT administrators were lucky the worm spread a month after Christmas. The new SQL Server vulnerability could bring coal to your Christmas stocking, if left untended.

GOT A TIP OR RUMOR?

Late last night, I saw a blog post by Bill Sisk on the Microsoft Security Response Center Weblog about Security Advisory 961040. He writes:

We are aware that exploit code has been published on the Internet; however, we are not aware of any attacks attempting to use the reported vulnerability. To successfully exploit this vulnerability an attacker must be local, or remote, authenticated user on the system. However, if an attacker has already compromised a web server via SQL injection, they could exploit this vulnerability as an unauthenticated user.

"SQL injection" sends prickles down my spine. No IT manager would want the company's Web-facing SQL Server installation injected and infected for Christmas, right? Attackers must be "authenticated" to compromise a system, which could be done through SQL injection. Microsoft Security Vulnerability Research and Defense bloggers Jonathan Ness and Bruce Dang explain in a post:

If an attacker finds a SQL injection vulnerability in the web application connected to your database, he could combine the SQL injection vulnerability with this vulnerability and run code 'without authenticating.' Technically, the attacker did authenticate—he just used your compromised web application to authenticate for him. Of course, if an attacker does compromise your web application using SQL injection, he can take a number of actions anyway.

Companies with older software are in the riskiest position, particularly if they haven't updated to the newest service packs. Bill explains:

It's important to note that systems with Microsoft SQL Server 7.0 Service Pack 4, Microsoft SQL Server 2005 SP3 and Microsoft SQL Server 2008 are not affected by this issue. Also, because, by default, Microsoft SQL Server Desktop Engine 2000 (MSDE 2000) and SQL Server 2005 Express do not allow remote connections, attackers would have to already have local access to machines running MSDE 2000 and SQL Server 2005 Express to exploit this vulnerability.

Bill, please be absolutely right about MSDE 2000. That beast still fills me with fright. When SQL Server Slammer struck in early 2003, the surprising attack vector came through MSDE 2000. Many IT organizations, even Microsoft's, got whacked on the desktop rather than on the server. They had patched SQL Server installations long before Slammer released. But desktop applications running MSDE weren't patched, unexpectedly spreading Slammer.

There's still plenty of risk, as Jonathan and Bruce explain:

Remember our October advisory and blog post about service isolation? That vulnerability allowed an attacker to escalate from code running as NetworkService to LocalSystem. Unfortunately, this SQL vulnerability allows any user logged on to a machine running SQL Express to escalate to SYSTEM by leveraging the SQL vulnerability to get to NetworkService and then the service isolation vulnerability to get to SYSTEM.

Now you can worry. The major workaround is to "deny permissions on the sp_replwritetovarbin extended stored procedure," according to the security advisory. I won't repeat the workaround, which is simply done and explained in the security advisory.

What's the impact of using this workaround? According to the security advisory:

Disabling the sp_replwritetovarbin extended stored procedure prevents updates to subscription tables by all users. The impact of this workaround only affects customers that use transactional replication with updatable subscriptions. Customers using transactional replication with read-only subscriptions, bi-directional transactional replication, or peer-to-peer transactional replication are not impacted.

Way I see it, the bigger risk isn't the vulnerability but the timing. Many organizations will be shutting down for the holidays starting Wednesday. While I alluded to Slammer (to scare you), this exploit isn't like the one that unleashed in Jan. 2003 attacks. But there is risk, because many organizations won't be closely monitoring operations over the next few days.

Microsoft will be watching. It's standard procedure for security teams to be on call during the holidays, just in case there is a major vulnerability requiring investigation and creation of a patch.

[Please send your tips or rumors to watchtips at live.com].