Blog

Sentrigo and MS SQL Server Vulnerability

By Adrian Lane

We do not cover press releases. We are flooded with them and, quite frankly, most are not very interesting. You can only read “We’re the market leader in Mumblefoo” or “We’re the only vendor to offer revolutionary widget X” so many times without spitting up. Neither is true, and even if it was, I still wouldn’t care. This morning I am making an exception to the rule as I got a press release that caught my attention: it announces a database vulnerability, touches on issues of vulnerability disclosure, and was discovered by one of the DAM vendors who product is a little different than most. Most of the press releases I read this morning didn’t cover some of the areas I feel need to be discussed and analyzed, so think release gets a pass for.

First, the vulnerability: Sentrigo announced today that they had discovered a flaw in SQL Server (ref: CVE-2009-3039). From what I understand SQL Server is keeping unencrypted passwords in memory for a period of time. This means that anyone who has permission to run memory dumping tools would be able to sift through the database memory structures and find cleartext passwords. The prerequisites to exploit the vulnerability are that you need some subset of administrative privileges, a tool to examine memory, and the time & motivation to rummage around memory looking for passwords. While it is serious if exploited, given the hurdles you have to jump through to get the data, it’s not likely to occur. Still, being able to take a compromised OS admin account and parlay that into collecting database passwords is pretty serious cascade failure. I am making the assumption that encryption keys for transparent encryption were NOT discovered hanging around in memory, but if they were, I would appreciate someone from the Sentrigo team letting me know.

For those not familiar with Sentrigo’s Hedgehog technology, it’s a database activity monitoring tool. Hedgehog collects SQL statements by scanning database memory structures, one of the event collection methods I discussed last year. It works by scanning the memory location where the database stores queries prior to and during execution. As the database does not store the original query in memory, but instead a machine-readable variant, Hedgehog also performs cross reference checks to collect additional information and ‘bind variables’ (i.e., query parameters) so you get the original query. This type of technology has been around for a while, but the majority of DAM vendors do not provide this option, as it is expensive to build and difficult to maintain. The internal memory structures of the database change as database vendors alter their platforms or provide memory optimization packages, so such scanners need to be updated on a regular basis to stay current. The first tool I saw of use this strategy was produced by the BMC team many years ago as an admin tool for query analysis and tuning, but it is suitable for security as well.

There are a handful of database memory scanners out there, with two available commercially. One, used by IPLocks Japan, is a derivative of the original BMC technology; the other is Sentrigo’s. They differ in two significant ways. One, IPLocks gathers every statement to construct an audit trail, while Sentrigo is more focused on security monitoring, and only collects statements relevant to security policies. Two, Sentrigo performs policy analysis on the database platform which means additional platform overhead, coupled with faster turnaround on the analysis. Because the analysis is performed on the database, they have the potential to react in time to block malicious queries. There are pros and cons to blocking, and I want to push that philosophical debate to another time. If you have interest in this type of capability, you will need to thoroughly evaluate it in a production setting. I have not personally witnessed successful deployment at a customer site and would not make a recommendation until I see that. Other vendors have botched their implementations in the past, so this warrants careful inspection.

What’s good about this type of technology? This is one way to collect SQL statements when turning on native auditing is not an option. It can collect every query executed, including batch jobs that are not visible outside the database. This type of event collection is hard for a DBA or admin to intercept or alter to “cover their tracks” if they want to do something malicious. Finally, this is one of the DAM tools that can perform blocking, and that is an advantage for addressing some security threats.

What’s bad about this type of technology is that it can miss statements under heavy load. As the many ‘small’ or pre-compiled statements execute quickly, there is a possibility that some statements could executed and flushed from memory too quickly for the scanner to detect. Second, it needs to be tuned to omit statements that are irrelevant to avoid too much processing overhead. This type of technology is agent-based, which can be an advantage or disadvantage depending upon your IT setup and operational policies. For example, if you have a thousand databases, you are managing a thousand agents. And as Hedgehog code resides on the OS, it is accessible by IT admin staff with OS credentials, allowing admins to snoop inside the database. This is an issue for IT organizations which want strict separation of access between DBAs and platform administrators. The reality is a skilled and determined admin will get access to the database or the data if they really want to, and you have to draw the line on trust somewhere, but this concern is common to both enterprises and SMB customers.

On patching the vulnerability (and I am making a guess here), I am willing to bet that Microsoft’s cool response on this issue is due to memory scanning. As most firms don’t allow memory scanning or dumping tools to admins on production machines, and Sentrigo is a memory scanner, the perception is that you have to violate a best practice just to allow someone to exploit the vulnerability. I have to commend the way Sentrigo handled disclosure of the vulnerability by giving the vendor ample time to address, and for providing a workaround. Disclosure is a huge point of friction in the research community right now, due to issues exactly like this one. I agree with Sentrigo that if we don’t spotlight these issues in a very public way, the vendors will never be sufficiently motivated to clean up their sloppy coding practices. And make no mistake, this is a sloppy coding vulnerability. But I think Sentrigo showed professionalism in giving the SQL Server team ample time before public disclosure.

No Related Posts
Comments

Thanks, Rich!

By LonerVamp


@ Dan - Thanks for the clarification.  I appreciate the information as you raise several points I failed to mention, and one that I was unaware of. 

-Adrian

By Adrian


Loner-

It’s SQL passwords only (not domain or other types of credentials). The concern is more about admins being able to snag other admin passwords, or service accounts.

By Rich


Adrian - Many thanks for your coverage of this announcement. Please allow me to elaborate a little more about this vulnerability and our approach to memory based monitoring.

First about the vulnerability - to get access to the passwords, an administrator can easily use a simple debugger like ollydbg to attach to the memory and search for usernames. In fact, in SQL Server 2000/2005 it is even easier, as the DBCC Bytes command is fully supported, even remotely. For many hackers, this would be a typical early test to find a way into an application

By Dan Sarel


Since this issue only affects SQL instances running in mixed mode, I would suspect this is a disclosure of SQL user passwords rather than OS or domain-level accounts. That is just a guess, however, as I can’t seem to find that answer at the moment.

It’s been a while since I had my fingers in MS SQL interfaces, but I don’t think there is any mechanism to allow users to self-serve their own password changes. So, a DBA will at least temporarily know user passwords, making this issue slightly less important.

Of course, any admin other than a DBA could scan memory, and a DBA might want to target someone whose password he’s forgotten, and thus recover it this way…

That is if my assumptions are correct. :)  Thanks for mentioning this. Strangely, I didn’t read anything about it last month!

By LonerVamp


If you like to leave comments, and aren’t a spammer, register for the site and email us at info@securosis.com and we’ll turn off moderation for your account.