Wednesday, September 2, 2009

Sentrigo Passwordizer

I haven't posted for quite some time as my recent fun project failed to produce any worthwhile results. I hope to find the time to polish it, to be able to publish something.

Meanwhile some interesting stuff has happened at my work which is worth writing about.
I have found some security flaw in the all mighty SQL Server database, all versions included.
My company, Sentrigo, has asked me to write a Proof Of Concept which later we decided to make into a tool which mitigates the problem. We published the tool for free download on our web site
The tool created some buzz (We call it buzzwordizer), so I decided to write down what exactly stands behind it.

It appears that SQL Server is saving in memory all plain text passwords of any user that is currently logged in with a specific kind of authentication called native SQL authentication (enabled only in mixed mode). The passwords are saved intentionally in an internal data structure containing log-in information. That data structure is kept allocated in memory, it's not just some memory left-overs wandering around the free blocks in the heap. I know this for sure, because I have succeeded in writing a tool to jump through some pointers in constant offsets in memory, to get from the global sessions table to all passwords. Needless to say, I have never seen these passwords vanish from memory for as long as the user is still logged in.

There are only two ways to log in to SQL Server. One is this method and the other is Windows authentication, which lets Windows perform the entire process of logging in. The latter method is not flawed. Microsoft suggest that you use the Windows authentication method, and even refers to the other one as deprecated in some cases. Despite that, Sentrigo has learned that many users still use the less recommended method, because it is easier to configure.

Now, one may ask what is so wrong in saving plain passwords in memory? Every trained Ninja knows that a highly privileged log-in is required to gain access to process memory. And once such log-in is obtained, the sky is the limit for what the user can do with it. On the other hand, up until SQL Server 2008 there had been a SQL command called DBCC BYTES that allowed a privileged user to read the local process memory remotely. Notice that being a database privileged user does not necessary mean being a local machine administrator, on the contrary - some organizations separate the two for security reasons, which is violated by this flaw.
Furthermore, the flaw could be combined with some other flaw which provides only memory leaking, to create a remote passwords dumper, although I'm not familiar with any such flaws at the moment.

To summarize it I would like to quote my CTO Slavik Markovich, from one of the posts published about this bug:
"Developers go to great lengths to ensure passwords are not even transmitted in clear text (for example at the time of login), let alone stored in a readable form. Users have come to expect that their personal passwords, are exactly that –personal – and that not even administrators can see them. Exploiting this vulnerability, an administrator will be able to see the passwords of users and applications that have connected to SQL Server, all the way back to the last restart. We respectfully disagree with Microsoft’s view that since it requires administrative privileges, the risk is mitigated. Even if you trust your admins, there are plenty of hackers capable of gaining escalated privileges, who could now easily access other systems across the network using these passwords."

After all, I would not consider this as major security problem as remote code exploitation, but it does indicates low security considerations, and could lead to bigger problems.

The thing I have found the most amazing about it is the way the Microsoft Security Response Team downplayed it. I have met more than one guy from the team in the past, and I must say that the team includes some well trained Ninjas that really should be adored for their good understanding of technical and low level details. They are all well familiar with every security aspects, and they have done some miraculous work in the past. On the other hand, from my point of view, they got a big fail on bureaucracy. They were quoting stuff from their books about how you should always trust your Administrators, and by that, they have failed to address this bug in the correct manner. And last and not least, the bug is still there. Bruce, to me you are still a phenomenal Ninja.
Relevant links:,289498,sid14_gci1366853,00.html