Sentrigo and MS SQL Server Vulnerability
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
