Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.

You Must Trust Your DBAs

This is a follow-on post to You Must Trust Someone. My point in that post was to establish that being able to and and actually trusting your account and server administrators is a necessity. I didn't go into the business aspect of that, but basically it boils down to having a good selection process for candidates, checking out their references, their backgrounds, doing the proper security and criminal background checks, etc., and getting to know them not only during the interview process but especially after they have come on board. Even if you do all of that, you should still put good measures in place to ensure someone has to make an overt act to breach security and even then, have proper auditing set up to hopefully document that breach. SQL Server MVP Arnie Rowland expanded on that a bit with respect to network engineers in his blog post.

My ealier post focused on account and server administrators. Now let's turn that focus on DBAs. Allen Kinsel (Twitter: sqlinsaneo) and I traded a few comments on Twitter, and I did the same with Russ Johnson (Twitter: russjohnson). I asked a simple question and that was if anyone audited jobs created for SQL Server Agent. Not very glamorous, I know. But a job can be set to be owned by a sysadmin level user, such as sa. And SQL Server Agent will run it under the context of that login, even if it is disabled. Which leads to the following attack mechanism:

  1. Rogue DBA create a new SQL Server Agent job owned by sa that does the following:
    1. Creates a new SQL Server-based login.
    2. Issues a GRANT CONTROL SERVER to that login (in case you're only auditing for additions to members of the sysadmin fixed server role).
    3. Creates a new job owned by the login which runs the data retrieval.
    4. Deletes itself upon successful completion.
  2. The second job does the following:
    1. Queries the sensitive table(s) and gets it out of SQL Server. One way would be to use Database Mail and push the results of the query to an anonymous Internet email account provider (especially if the organization isn't blocking these).
    2. Creates a new job owned by sa which deletes the login.
    3. Deletes itself upon successful completion.
  3. The third job does the following:
    1. Deletes the created login.
    2. Deletes itself upon successful completion.

If you're auditing 100% of the commands the DBAs execute, you'll audit this attack. But the question is, with the amount of events to sift through, will you pick it up quickly? Eventually, yes, you should, if you're watching for unusual queries against sensitive tables/views. You'll see the unknown login making the query and you'll back-track. But unless you've got really tight control on your SQL Server Agent jobs, you'll not bat an eye at the fact that a job is being created by a DBA. This is because it happens frequently enough that the watchers get desensitized to it. And the automated processes which try to mine out which events are of concern and which aren't will likely be tuned back on SQL Agent job creations. I've seen this with a could of the IDS packages I've looked at. For instance, they have a signature that says if they see xp_cmdshell running across the URL for an HTTP request, to flag it. The problem is, legitimate requests can cause that signature to be matched and for the IDS to fire. Don't believe me? Check out the video I did on xp_cmdshell execution and once you go there, look closely at the URL. Notice the xp_cmdshell in there? It causes that signature to fire. After a few false positives like that, whoever is managing the IDS will either (a) tell the IDS not to fire on that signature or (b) ignore the alert when the IDS does fire. That's desensitization.

So that means the whole alerting process starts when the unusual query is noticed. But how long will it take? Again, even if caught, the DBA has gotten the data and had time to do something with it. The repercussions I listed in the earlier post are the same. So at the end of the day you've got to trust the DBA. Yes, you still must audit, but you definitely must have DBAs you can trust. And keep in mind, I've listed just one attack pattern here which looks to evade detection, if only for a short time. If someone really wants to get in and that person is good enough, that person will find a way. However, good security measures and auditing practices will stop most folks, even if they're smart, and smart enough to figure out the limitations of the security you've put in place.

 

Comments

Posted by Steve Jones on 22 February 2009

Nice job, and glad you posted this. Definitely something you need to be aware of and while you need to trust DBAs, you need to verify as well.

Posted by Hugo Shebbeare on 22 February 2009

Hmmm...sounds like an interesting course in white-hat hacking:) Too bad some companies are not open to this.  

Posted by Steve Jones on 23 February 2009

It's hard to get anyone to agree to this, especially if it shows holes, on the other hand, that's how most of us would need to learn. Personally I'd love to see articles on various ways people have hacked sites so I could fix my own.

Posted by jima on 3 March 2009

Couldn't agree more, surely the first step to fixing security issues is to understand exactly the process that is involved in creating the issue.  The more 'open' we are with information such as this the more prepared we can be to protect our systems & if we don't act upon the information then we have no one else but ourselves to look too when it all goes Pete Tong !

Leave a Comment

Please register or log in to leave a comment.