SQL-Snake

Most recently, on May 21, 2002, security analysts became aware of SQL-Snake, a self-propagating worm that targets Microsoft's SQL Server software. SQL-Snake exploits a known security hole in SQL Servers when server accounts aren't properly protected. Once inside, the worm looks for administrative accounts that have no passwords and then transfers administrative privileges to the guest account. It then grabs the password files from the registry and mails them to an email account. Then it scans for new systems to infect.

Analysts became aware of the worm when they spotted a large increase in scanning activity on the server port used by Microsoft SQL Server. Infection of new systems was progressing at a rate of about 100 per hour.

SQL Servers that are misconfigured with no administrative passwords are an easy target for the worm, and this problem is fairly widespread. The solution is, obviously, to require administrative passwords on SQL Servers, but it's clear that there will be substantial damage before administrators find time to lock down their systems. Why Microsoft has failed to implement this simple requirement still baffles the analysts.

Users can mitigate their exposure by blocking Internet access to port T1433. It's also important to ensure that the administrator account has a password and to disable TCP/IP Network Libraries if they are not being used. Also, analysts recommend that IT review the configuration and installation of all systems that may be inadvertently running SQL Server and disable any unnecessary deployment.

At this time, there is no word as to how to disinfect an SQL Server once it's been infected. But this is just the latest problem in Microsoft's battle to strengthen the overall security of its systems.

Internet Explorer Patch Ineffective

Security analysts are also concerned that the recent patch to Internet Explorer doesn't fix the holes that it claims to have addressed. A little more than two weeks ago, Microsoft released a security patch for Internet Explorer (IE) Versions 5.01 through 6.0 and the Outlook email client that was designed to fix privacy flaws and to plug holes in cross-site scripting.

Unfortunately, according to some researchers, the patch only solved the cross-site scripting problem in one of the listed browsers. It also failed to even address secondary vulnerabilities completely, according to some analysts.

Microsoft claims that the security flaw can be exploited only if a user clicks on an HTML link on a Web page or in an email message. But analysts claim that this assessment is not accurate and that code embedded in the HTML file can automatically execute malicious code when a user simply opens an infected email message. According to these analysts, the patch doesn't address the vulnerability because it resides in the dialogArguments component of IE, a component that was not re-worked in Microsoft's patch.

Furthermore, even though Microsoft says that the problem only exists in IE Version 6.0, some analysts insist that the same problem is in IE 5.01 and 5.5. Finally, researchers say that the remedy for a second vulnerability--a vulnerability that could allow an attacker to read documents on a PC remotely--was also missing from the most recent patch.

Flawed Software and Flawed Patches

The issue of flawed patches--including the one Microsoft provided last February that caused browsers to crash--continues to raise doubts about Microsoft's ability to address its security problems. Patching patches can be an expensive waste of IT resources as administrators attempt to roll out security updates in the field. This issue may be one of the causes of complaints that Gartner Group has about the seeming indifference of IT to implement security upgrades and updates.

According to Gartner, the majority of attacks on computer systems exploit well-known security weaknesses, weaknesses for which patches exist. Gartner claims that the most recent attacks by hackers, worms, and viruses might have been avoided if organizations had merely taken the time to implement those patches that currently exist.

For instance, patches were available to protect systems against the Code Red virus, but the majority of IT installations simply did not implement them. As a result, the Nimda virus exploited the very same security hole a few months later, causing still further chaos around the globe.

Billions Spent to Plug Security Holes and Repair Systems

Gartner estimated that the cost of repairing systems after these two incidents is currently exceeding billions of dollars in lost productivity and reconfiguration by IT. Gartner further estimates that through 2005, 90 percent of these cyber attacks will merely exploit the security flaws for which patches are readily available or for which some preventative measure is already well known. Gartner analysts also believe that the costs for fixing the damaged systems will be 50 percent larger than the cost of initial prevention.

However, if security analysts' claims about the failures of Microsoft security patches prove accurate, it becomes increasingly understandable why some IT organizations view with a jaundiced eye the problem of patching Microsoft's code.

If the security of the initial product is flawed from the date of release--and if the patches to those flaws are equally suspect--IT shops often choose to take a wait-and-see attitude to determine the real vulnerability of the overall system. Though this tactic is expensive, the consequences of repairing damaged systems may be less time-consuming than updating systems with every patch that is released, particularly when those patches may or may not actually work. And when the software patches themselves create problems, as happened last February with the IE patch, the very act of fixing flawed software begins to have dire consequences to user productivity.

Microsoft's View

For Microsoft's part, it promises to review the recent reports that its IE software patch is flawed. According to Craig Mundie, Senior Vice President and Chief Technical Officer, Advanced Strategies and Policy at Microsoft, "A lot of work has to be done before we reach a place where people inherently trust their computing systems. We are doing everything we can right now to address current problems and to change the fundamental way in which we develop software to make it as private and secure as possible. But that isn't the whole solution, and Microsoft can't do it alone. It is crucial that we work together as an industry to address this issue. We are not going to solve it overnight, but through collaborative work and a long-term commitment, we will move toward the right solutions."

If the current quality control of security patches is any indication of Microsoft's level of success, then we are a long way indeed from finding a solution.

Thomas M. Stockwell is the Editor in Chief of MC Press, LLC. He has written extensively about program development, project management, IT management, and IT consulting and has been a frequent contributor to many midrange periodicals. He has authored numerous white papers for iSeries solutions providers. His most recent consulting assignments have been as a Senior Industry Analyst working with IBM on the iSeries, on the mid-market, and specifically on WebSphere brand positioning. He welcomes your comments about this or other articles and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

Thomas M. Stockwell is an independent IT analyst and writer. He is the former Editor in Chief of MC Press Online and Midrange Computing magazine and has over 20 years of experience as a programmer, systems engineer, IT director, industry analyst, author, speaker, consultant, and editor.  

 

Tom works from his home in the Napa Valley in California. He can be reached at ITincendiary.com.

 

 

Also Read

IBM i Shops Pivot to Battle COVID-19

Energy, Vibe, and Atmosphere

Murphy’s Security Law