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 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.
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 firstname.lastname@example.org.
More information from SearchSQLServer.com