Common oversights with SQL Server security audits

Common oversights with SQL Server security audits

How are your SQL Server systems standing up to security exploits these days? Are they current with patches? Have they been hardened from the elements? What about passwords – do they meet reasonable complexity requirements and are they changed periodically? Is audit logging enabled?

    Requires Free Membership to View

    Login

    By submitting your registration information to SearchSQLServer.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSQLServer.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Premium Access

Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in January 2010

More on SQL Server security
Password cracking tools for SQL Server

Meet compliance requirements with improved database security practices

Securing the server and database in SQL Server

If you can answer "Yes" to most of these questions then you might assume that everything's hunky dory. In fact, many people would look at such an environment and say the same. Unfortunately, this is rarely the case.

You'd be surprised by how many "audited" and "compliant" SQL Server systems I see that are actually riddled with security flaws waiting to be exploited. It's the curse of the checklist audit where everything's sound and secure at 50,000 feet but once you dig in you start seeing the ugly truth. The following are examples of SQL Server security oversights that can get you in a world of hurt pretty quickly:

  • Servers with their C: drives shared out – literally. I often see the C$ share on SQL Server systems providing full share and NTFS access to the 'Everyone' group. If SQL Server is not started, the master.mdf file is accessible, which is all that's needed to crack or reset any/all SQL Server passwords using a tool like Elcomsoft's Advanced SQL Password Recovery.

    If SQL Server is started, odds are pretty good that another vulnerability (weak Windows passwords or a missing patch, for example) is all it'll take for an attacker to gain full access to the system and SQL Server.

  •  

  • Unprotected disk images (such as Acronis TrueImage .tib files) and basic folder-level backups of entire SQL Server systems sitting on servers and storage systems. It's a problem related to the point above – unsecured share and NTFS permissions. Again, master.mdf and all of SQL Server are fair game.

  •  

  • Unprotected instances of SQL Server Express and MSDE running on workstations. These seemingly unimportant databases actually house very important data that shouldn't be exposed to insiders. The only way to find all the live SQL Server systems on your network is to use a good vulnerability scanner such as QualysGuard or LANguard.

    An even simpler method is to use the SQLPing3 tool which is made for not only seeking out default SQL Server installations, but also uncommonly-configured or otherwise locked-down SQL Server instances.

  •  

  • Web applications that are not properly validating input and facilitating SQL injection. Even the most secure SQL Server controls can't ward off this attack. In a recent Web application security assessment, I came across a SQL injection exploit that provided full and complete access to an otherwise rock-solid SQL Server environment -- effectively negating most database security controls.

There are endless ways to exploit a seemingly secure SQL Server system The reality is that the higher-level audits commonly performed on SQL Server are missing the boat. You've got to look at every level if you want true visibility into the security status of your databases.

From the OS to the Web application and everything in between, you've got to consider all the variables. Otherwise you may look good to the auditors and the regulators, but you're only setting yourself up for failure.

ABOUT THE AUTHOR

Kevin Beaver, is an information security consultant, keynote speaker and expert witness with Atlanta-based Principle Logic LLC. Kevin specializes in performing independent security assessments. Kevin has authored/co-authored seven books on information security, including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley). He's also the creator of the Security on Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at  kbeaver@principlelogic.com.

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.

    Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    Back to top