Tip

SQL Server's emerging rootkit threat

Rootkits are stealthy tools used by hackers to control your Windows operating systems. Completely unknown to you, a hacker may install a rootkit by exploiting a vulnerability or cracking a password. The rootkit may then be used to hide processes, redirect application I/O, alter specific application programming interfaces or, simply, take over your operating system.

But what about database-specific threats posed by rootkits? Minimal threats are here now -- but bigger ones are coming.

Plenty of good resources are available to get you up to speed on

    Requires Free Membership to View

rootkit detection and removal for your operating systems. Rather than discuss that in detail here, I'll outline the emerging rootkit threats against database systems that every DBA needs to know about.

Although presented in an Oracle context in his report "Database Rootkits," Alexander Kornbrust of Germany-based Red-Database-Security says no database is safe from rootkits. He explains that rootkit exploits and methods originally designed for operating systems can easily translate into database exploits because of their underlying similarities. Both operating systems and databases have executable files, system processes, user accounts, etc., that can be attacked in basically the same ways. Imagine the possibilities!

The following threats are specific to rootkits against SQL Server systems. Some are theoretical while others (especially those that affect the underlying Windows operating system) are actual. Rootkits may be used to:

  • Directly manipulate database user accounts
  • Hide processes and jobs
  • Trap or redirect alerts for events such as login and object access failures
  • Redirect logging
  • Redirect network communications
  • Modify the data dictionary
  • Generate unnecessary CPU instructions and cause interruptions that slow down production systems
  • Alter SQL query statements
  • Alter data returned from SQL queries
  • Hide or alter specific SQL Server versions, service packs and hotfixes
  • Grant non-sysadmin accounts access to stored procedures and extended stored procedures that should otherwise be prevented
  • Conceal otherwise obvious buffer overflows, privilege escalations and similar vulnerabilities in Windows or SQL Server

The exploit possibilities are unlimited.

Because SQL Server systems house sensitive personal and corporate information (much of which is likely to be protected by laws and regulations), rootkit contamination could lead to a situation you'd much rather avoid. You can use that list of threats for security motivation and budget justification. Either way, it's critical to keep an eye out for publicized exploits against databases and do what you can to prevent infections from occurring in your Windows environment.

Check out the prevention guide referenced earlier or this Windows Security Clinic for help protecting your operating system.

Theoretically, an attacker would only need to exploit a weak password or SQL Server vulnerability to install a rootkit tweaked for database shenanigans (think Metasploit). Rootkits installed via hacks or malware are bad enough, but database-specific rootkits are a true threat and a great way for an attacker to "own the goods" of an organization. We're only in the beginning stages of this new malware craze, but mark my words: The time will come for rootkits that specifically target SQL Server.

About the author: Kevin Beaver is an independent information security consultant, author and speaker with Atlanta-based Principle Logic LLC. He has more than 17 years of experience in IT and specializes in performing information security assessments. He has written five books including Hacking For Dummies (Wiley), the brand new Hacking Wireless Networks For Dummies, and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). Beaver can be reached at kbeaver@principlelogic.com.


More information from SearchSQLServer.com

  • Tip: Top 10 security enhancements in SQL Server 2005
  • Learning Guide: SQL Server security
  • Topic: Get SQL Server security best practices


  • This was first published in October 2005

    There are Comments. Add yours.

     
    TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

    REGISTER or login:

    Forgot Password?
    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
    Sort by: OldestNewest

    Forgot Password?

    No problem! Submit your e-mail address below. We'll send you an email containing your password.

    Your password has been sent to:

    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.