Last week Sentrigo brought a security hole in SQL Server to my attention. The issue is simply that SQL Server stores passwords in clear text in memory, so it’s quite possible to sniff the memory to retrieve passwords of other users. That in itself doesn’t sound dangerous at first glance because you have to have system admin rights in the database to do this. However, there are two basic situations where this could be horrendous.
Because most users have the same password, once you gain access to this password, you’ve gained access to all the boxes that account is on. This works on only native SQL passwords, not on Windows passwords. This is because when you use a Windows account to log into SQL, you don’t give it a password; you only pass in your security token, and there’s no password to steal. With SQL passwords, however, you pass in the SQL username and password, and this combination is stored in clear text in memory.
The point of Sentrigo’s press release isn’t as much about the security hole as it's about Microsoft’s refusal to do anything about it. I contacted Microsoft myself and here’s what the company had to say:
Microsoft has thoroughly investigated claims of vulnerabilities in SQL Server and found that these are not product vulnerabilities requiring Microsoft to issue a security update. As mentioned by the security researchers, in the scenario in question, an attacker would need administrative rights on the target system.
An attacker who has administrative rights already has complete control of the system and can install programs; view, change, or delete data; or create new accounts with full user rights.
Sentrigo says this is an important issue, but Microsoft says it’s not. In my opinion, Sentrigo has the right idea, and Microsoft is putting blinders on. I’m not sure why it's so resistant to seeing the real issue, but even when I talked to Microsoft, the spokesperson seemed quite determined that the above was the company's final word.
Here’s why I think Sentrigo is right about this; it’s an issue of perspective. Consider these two scenarios.
Scenario No. 1
You’re the sys admin of a company and you have rights on all your SQL boxes. You also have an auditing solution in place to ensure that nobody, including yourself, does anything they’re not supposed to. And for some reason you get a wild hair to be nefarious. However, you have a pesky auditing solution keeping you honest.
Then you read Sentrigo’s story. You figure out how to read SQL’s memory, then obtain the username and password of the guy you’re mad at. You start doing your bidding in the database under his name. Now he’s under the microscope because his login is responsible for all of the malicious things transpiring. He’s likely to get fired, though he didn’t do anything. This could go on forever before anyone figures it out. Though you’re a sys admin with wide-ranging rights, this is the very reason you shouldn’t be able to access someone else’s password.
Gaining permission to decrypt sensitive data is another part of this scenario. You could have a third-party encryption app in place that keeps the database administrators from seeing the data. Remember, it’s not necessarily as much about gaining more access as much as it’s about impersonating someone else -- which you should never be allowed to do. Also, maybe you’re sys admin on certain boxes only, but this would allow you to gain that same level of rights on other boxes.
Scenario No. 2
This one is even worse because it’s far more likely and more dangerous to cause an unintended privilege violation.
Let’s say you’re a developer, and like many devs, you have sys admin on your dev box. You ask the database administrator to look at something on your box because you are having trouble with a query, would like him to take a backup -- or some other ruse of your creation. Once the database administrator logs on, you’re able to retrieve his password. Now, you not only have sys admin privilegs on all the SQL boxes, you have his log-in, so no one can trace it back to you. If nothing else, you could steal information and nobody would know anything about it. A security audit afterward wouldn’t show anything at all because everyone has the correct rights.
But it gets worse. You don’t have to pose as the database administrator or coax him into coming onto your box to steal his credentials. There are plenty of other credentials you can steal. Let’s say you have a product like Ecora that takes full inventory of your SQL boxes. It’s likely taking inventory of your dev box too, so you can steal that account. What about monitoring packages like SCOM, Spotlight, or OpenView? Or how about any scripts that might be running across your LAN to do one thing or another? There are so many moving parts in a big organization, it’s impossible to track them all.
There are some good ways around this problem. First, use Windows accounts instead of SQL accounts. Windows accounts don’t pass passwords between boxes; they only pass their token, so there’s nothing to steal. My devs get tired of me turning down their requests for SQL accounts. I hand out SQL accts when there’s no other option, and I severely limit the access.
Also, don’t create generic SQL accounts. Should you have a password that gets stolen in the manner I’m going to show you, you have someone to go to. You can interrogate this person and try to ascertain their activities at the time of the activity. If you’re able to clear the end-user, it’s easier to determine whether you’ve been compromised. But if you have a generic account, it’s much harder to diagnose the situation as a security compromise. You’re far less likely to come to the right conclusion -- at least for a very long time.
You can use this to get SQL passwords that have been lost and can’t be retrieved or changed any other way. I currently have such a situation. I inherited a SQL account that’s used all over the LAN and by so many processes there’s just no way I could change it without breaking hundreds of settings. If you have a situation like this, you’re screwed if someone comes in and changes the password in the DB by mistake.
Another good example of this is with linked servers. You can’t get linked server passwords back out once you create the linked server, so if you lose the password you’re screwed. Again, I'm in this exact situation myself. I have several linked servers that hit boxes in other groups or divisions and nobody on the other side knows the password. We can’t change it because they have no idea how many groups are using it.
Whatever your reason, you need to get a password out of SQL Server’s memory. Go to my video on MidnightDBA.com to see me walk you through the process painlessly. In fact, it’s so easy it’s actually scary.
I hope a lot of you found this useful and I hope it finally puts to rest whether this is something Microsoft should change -- because they should.