I often come across DBAs and network administrators who are afraid to patch their SQL Server systems for fear of causing problems. There's a part of me that doesn't blame them. After all, SQL Server houses "the goods" and when the goods are disturbed, business tends to slow down and job security tends to drop. Images of shriveling up and fleeing even come to mind. The argument against patching is that the system is doing fine as it is and, of course, it's safe because SQL Server is "behind the firewall." The mode of operation is to let sleeping dogs lie – no need to upset the beast.
The problem is that many DBAs and network administrators aren't aware of just what can happen when vulnerabilities created by lack of patching are exploited by a trusted insider. This goes for SQL Server software, the Windows OS and other software running on the same host, such as VNC, backup software and IIS. Many claim that even if a serious vulnerability were present on their SQL Server systems, no one on their network would have a clue about how to take advantage of it. A logical argument, but that's not the point.
Fact is, all it takes is a trusted insider (or outsider via an unsecured wireless connection) downloading free security tools off the Internet, playing around with them a bit and then using them maliciously to gain full access into the sacred database system. BackTrack and, specifically, Metasploit come to mind.
With the right tools and the right amount of time – both of which are on the side of trusted insiders – anything's fair game. For instance, there are several known SQL Server vulnerabilities (fixed by patches of course) that are easily exploited using Metasploit and commercial alternatives for those who have access to them. This means that anyone with just a basic network connection can gain full admin-level Windows command prompt access to SQL Server systems. They don't even need a Windows or SQL Server login! Physical acc
To continue reading for free, register below or login
To read more you must become a member of SearchSQLServer.com
ess to the network is all it takes.
The following screenshots are an example of how an insider can exploit the Slammer worm buffer overflow vulnerability on an unpatched SQL Server system. "Slammer," you say? Don't laugh, I still find SQL Servers vulnerable to it.
[IMAGE]Figure 1: Using Metasploit to gain access to an unpatched SQL Server system's command prompt
[IMAGE]Figure 2: Full admin-level access to SQL Server files is made possible
There are even more possibilities for gaining this type of access by exploiting other unpatched applications running on the same system. And this is just the beginning. Using vulnerability scanning tools, users can find other exploits specific to SQL Server, including privilege escalation, denial of service and access to the system table. Again, this is all because the recommended patches haven't been applied. No external firewall is going to keep these internal misdeeds from happening.
You've got to ask yourself what's worse: 1) installing a hotfix or service pack that brings your database server down (or even creates data corruption) for a relatively short period of time until it's backed out (or restored) or 2) presenting low-hanging fruit in the form of unpatched software for unruly insiders to exploit? Don't get me wrong, I've been burned very badly in the past by being too eager to patch Microsoft software. But that was years ago. Based on my experience, the quality of patches has greatly improved (albeit not perfect).
There is no great answer, but it boils down to a balance of risk and a matter of choice. In the end, I'd rather suffer through a botched patch install than face the consequences.
Envision yourself answering to executives, customers or regulators who are asking why countermeasures to a known exploit were never put in place after identity theft, data destruction or a related incident occurs. If a patch install creates problems, at least you were doing what was in the best interest of the business. You can't say that when patches are simply ignored. Heck, if a problem does arise due to a patch, at least you now have a good reason to push for a test environment that everyone knows they need but can't seem to justify having.
[TABLE]
