Phil Factor's Phrenetic Phoughts

Simple-Talk columnist
The wilder shores of Transact SQL

A temporary inconvenience

Published Monday, November 12, 2007 11:08 AM

Here is an interesting interview question. You have a PC in front of you, switched off,  with a database on it. You don’t know any of the passwords and you want to get at the database. Is this possible? If so, then how?

This happened to me recently, due to a freakish accident concerning me reacting stupidly and impetuously to the death of a domain. I was left with a development database I had to get to urgently, (Backup of development work? Of course, on the local hard disk!) and I had no idea of any of the passwords. Normally, I'd never have bothered to find out by trying.

In my case, it was ridiculously easy, once the feelings of panic had subsided. I just downloaded a utility from the internet that blanked out all the Windows passwords. Because the BIOS was not secured by any password, I could boot up with a CDROM, blank out the Windows passwords, and then, once more, I was god in this little PC world. At first, I stopped the SQL Service and copied the MDF files off and re-attached them to another SQL Server. Then I realised that I had gained admin rights to the database anyway through a local account. If all else had failed the backups weren’t encrypted anyway, so I could have got at them without any bother.

I was just chucking to myself over a cup of coffee about my foolishness in getting in a panic about losing the database. It then occurred to me how wise it is to treat server rooms like forts. I could immediately think of several commercial databases with unsecured BIOSs.

The problem with Database Developers and DBAs dealing with security issues at this level is that they have the wrong mindset. Finding security loopholes is a job for a different sort of thinking. The best security experts I know have a built-in malicious streak. They are like hunters that thrill to run down, and kill, a beautiful wild creature.

In the meantime, we innocents carry on believing that intruders cannot get at our data by gaining admin rights to the database. I realise that most production servers are properly nailed down and their server rooms secure and monitored, but for the rest of us, maybe it is time to think again.

Comments

 

GSquared said:

Even if you can't boot up Windows on the machine the database is on, if the hard drive is intact, you can usually physically remove the hard drive from the machine it's in, add it as a second (third, whatever) drive to a machine you have admin rights on, and be good to go.

The only trick to that is if the database is spread across multiple drives and you don't know what RAID settings to use.

Of course, a database that doesn't allow Windows security access, but instead requires an SQL Server password, or a database on an encrypted hard drive, etc., can block some such tricks, which is why things like that have to be used if you store anything that needs any security at all.  Just using domain security and assuming you can store credit card data (for example) unencrypted, is ignorance/negligence at its worst.  

Domain level security is the equivalent to the lock on your front door - it will keep out honest people and truly incompetent criminals, but won't keep out the people you really, really, really want to keep out.
November 19, 2007 3:00 PM
 

Phil Factor said:

I'm glad to see it stated that Domain-level security has its risks. The trouble with SQL Server security, on the other hand, is that the actual password is transferred rather than the token, which creates a different risk. I've noticed several commercial programs that provide SQL Server password-cracking facilities.

I think we have to be absolutely clear that, if an intruder cen get to your server room, there is little you can do to protect your data. Usually, things are much easier than that for an intruder. They can clone a database remotely. More than once, I've been able to gain access to a system I'm checking, using  xp_cmdshell via SQL Injection (once via sa-[no password]), find the backups (the mdf file is locked at this point) or execute a backup if poss, use FTP to copy them off to an FTP site, re-create the database on my own server, and send a little message around the network to tell the Sysadmins I've done it.

As I'm an innocent sort of chap doing a simple security audit, there are probably even easier ways of doing it I'm unaware of. Anyone know?
November 29, 2007 3:31 AM
 

GSquared said:

Actually, if you have access to the mdf and ldf files, you don't need to crack the SQL sa password, you just need a server that you do have the password for.  Copy the files to that server and the database will accept that "sa" is logged in and give you what you want.

That's why I mention encrypting data.  Preferably not with the encryption key in the same table as the data (yes, I've seen that done)!  Nor with the key hard-coded into the select procs.  And definitely not with a table called dbo.EncryptionKeys.  (Other "solutions" I've seen/heard of.)

An encrypted drive/partition can prevent someone from physically stealing the hard drive (as mentioned in my first post) and having access to its data.  Encrypted data can be a last-ditch effort to protect the critical stuff if someone can get the files anyway.

As for the people who leave xp_cmdshell turned on and leave the sa password blank, personally, I'm minded to think they've earned any trouble they get into.  It's like people whose credit is ruined by identity theft after they fall for a phishing scam - all in all, they should probably never have had credit in the first place.  (I know, that's harsh and more than a little unrealistic.  I'm feeling cynical this morning.)
November 29, 2007 8:33 AM
 

GSquared said:

Additional thought: Would it be a good idea to ask MS for database-level security that overrides server-level security in certain cases?  E.g.: A database-level login, with data read/write and proc exec rights, stored as part of the database file in some way, and the ability to lock out server-level logins to that database?  This way, even if the mdf files were obtained, they couldn't be read without the database-specific login and password?

Of course, if you lose the login/password, even the DBA wouldn't be able to recover the data in that case, but in certain security situations, that might be desirable.  Thoughts on that?
November 29, 2007 8:39 AM
 

Phil Factor said:

One of the things my company does is a 'hired assassin' service where we get hired to try to break in to a company's databases. (I don't do it myself, we have a 'security expert' called Colonel Parker who does the 'wet jobs'). I'm always amazed how simple it is to hack into networks. There is, for example, a manufacturing company nearby whose main system has only one login. sa /(no password), which everyone uses, even for doing Excel reports. Even I can break into their system.

Hollywood has perpetuated the idea that hackers go pummelling away at keyboards, laughing diabilically and wearing baseball bats back to front. Nowadays, it is a simple matter of buying an application for five/ten grand or so and watching pretty graphics. There are a lot of sites out there that are still wide-open despite all the lurid warnings we give out.

Moral?

use secure off-site hosting; Use custom endpoints; use stored procedure interface only; deny access to tables for all users; use intrusion-detection techniques. Encrypt everything you can. (e.g. SQL Backup)
November 29, 2007 12:47 PM
You need to sign in to comment on this blog

















<November 2007>
SuMoTuWeThFrSa
28293031123
45678910
11121314151617
18192021222324
2526272829301
2345678
Creating Technical Presentations
 Making a technical presentation is like being interviewed. It is not a skill that you are likely to... Read more...

Go With the Flow
 Knowing enough about the routes that messages take is vital to being an effective Exchange admin,... Read more...

Policy-Based Management
 Every DBA knows the frustration of trying to manage tens of servers, each of which has a subtly... Read more...

When Email Collaboration Could Have Changed History
 In our mission to make history relevant to the busy IT executive, we speculate how Email might have... Read more...

Bunnikins!
 When an IT manager is selected as a victim of office politics of a large corporate, it is time for him... Read more...