FFS Not Everything Is A SQL Server Vulnerability

The Dude

I get asked if I know anything about <newest SQL vulnerability as reported by random website>, quite often. Generally, my answer is that I don’t for two main reasons… the first being that none of them are actual vulnerabilities, and the second being that none of them are particularly new but merely items from the same bag of tricks everyone else uses and isn’t a buffer overrun/privilege escalation/etc. item. My normal response after taking a peek at whatever article is referenced is generally the same response as The Dude, “Yeah, well, you know, that’s just like uh, your opinion, man.”, as all of these items are purported to be vulnerabilities but yet none actually exploit any vulnerability.

Mulder and Scully

“I want to believe” should be the poster on all of these articles. Let’s break down the latest one which incurred my ire. According to article, this is malware – which is the correct categorization for this, but let’s see if it exploits any undisclosed or new vulnerabilities.

Its capabilities extend to brute-forcing administrator logins […]

Brute forcing isn’t new, it’s quite literally the oldest attack in the bag of tricks. How is that a vulnerability? It’s not.

Analysis of the malware revealed that it disguises as an Extended Stored Procedure DLL […]

Woah woah woah, time out. What the literal F. First, why use an extended stored procedure DLL, why not CLR based? XPs have been deprecated, may have issues with newer versions of SQL Server, and _at minimum_ requires it be added by someone with *sysadmin* permissions. If you have access to an account with sysadmin, you can pretty much own the server. Period. That’s an issue with your internal security (or exploiting a non-patched/new/undisclosed other method of gaining access to an account with sysadmin, such as a Windows account, which isn’t a SQL Server thing). Just to reiterate, the following needs to happen for this to *even* be loaded.

1. The DLL needs to be put onto the system.
2. The DLL needs to be in a place the SQL Server service account can access.
3. A SYSADMIN must execute sp_addextendedproc with the required information to load it into the SQL Server process.

All of these are failures of your security policies and infrastructure, none, unless root caused to be so, are SQL Server vulnerabilities. People load all sorts of horrible 3rd party DLLs in SQL Server process space (Carbon Black, McAfee, Symantec, IBM, FireEye, etc.), though these are added through other techniques (which the above referenced DLL _could_ get loaded by as well, which would mean the kernel is compromised [see mrbminer], which again isn’t a SQL Server vulnerability).

LUGGAGE

Let’s get back to another part of the amazing vulnerability. Brute forcing passwords, did you not notice 105 million failed login attempts in 10 minutes? Are you using an SA account with a weak password, or passwords at all (I’m not a fan of SQL logins, but hey they exist and are needed in specific situations)? Do you not use firewalls? I guess tried and true human stupidity is still the best way to gain access. Brute forcing a password isn’t even a vulnerability, if it is then every piece of software pretty much everyone has this vulnerability… wonder how it should be patched? I just can’t.

Salads are gross

Word salads, that is… although regular salads are too, to an extent. Anyway.

The researchers say that the command list also includes four “Exploit” commands, indicating that the attacker may rely on known vulnerabilities for some actions, such as adding a new user.

Excuse me? Adding a new user is a known vulnerability? Since when? That’s basic functionality of the system, especially given it has sysadmin rights.

Misery Likes Company

This is becoming a pattern, where anything that does anything is a vulnerability. Here’s a few more I weighed in on but never blogged about, which made their rounds across the globe touted as SQL Server vulnerabilities, that aren’t such as Vollgar and mrbminer. There are real vulnerabilities that do occur with SQL Server and those will have a specific GDR and CU-GDR release for in-market supported versions (Service Packs are gone, thankfully), so if you’re on a very old version you’ll want to upgrade.

Just because the server happened to be running SQL Server doesn’t mean it’s a vulnerability with SQL Server. When there are, there will be CVE details and there are many reputable sites which will collect these for viewing. Normally, MSRC will also put out their own details around the issue. Please stop “the sky is falling” panic, take a breath, and look at the facts before jumping to conclusions.