Windows vs. Rootkits

The recent MS10-015 incident, related to BSODs and rootkit infections, got me thinking about a time, not so long ago, when Microsoft had to fight with security companies in order actually secure Windows. I know of no other example of a company doing valid work to bulletproof their software only to be accused by prominent members of the security industry that it was actually making its products less secure. But such is Microsoft and the Windows ecosystem, full of paradoxes. Some three years back, the Redmond company had to fight its way amidst accusations fueling the perspective that Windows and user security were not intersecting concepts in a PR face-off, just to add mitigations to its OS to prevent rootkit infections. The kind of mitigation that safeguards PCs against Alureon, and other rootkits.

Sometimes, all it takes is an apparently insignificant piece of malware for customers to lose their sensitive information via credit card data theft, or get their identities stolen, to have their compromised PCs turned into zombie computers and harvested for botnets, or to find their machine completely useless. Just ask the Windows users recently infected with the Alureon rootkit. As soon as they deployed Microsoft Security Bulletin MS10-015 (KB977165) released this month, they threw their PCs in an unbootable state and were confronted with frustrating Blue Screen of Death errors. And this is the least of their problems, as they should run to check their bank accounts for disappearing money.

I say ‘apparently insignificant’ because, ahead of MS10-015, the Alureon rootkit infections had little visibility. And for all the right reasons, as the last thing that the authors of Alureon wanted was any sort of attention. They were more than content with their malicious code running in the background and harvesting sensitive information from customers. After all, Win32/Alureon is a family of data-stealing trojans.

“These trojans allow an attacker to intercept incoming and outgoing Internet traffic in order to gather confidential information such as user names, passwords, and credit card data. The Win32/Alureon trojan may also allow an attacker to transmit malicious data to the infected computer. The trojan may modify DNS settings on the host computer to enable the attacker to perform these tasks. Therefore it may be necessary to reconfigure DNS settings after the trojan is removed from the computer,” Microsoft explains.

PatchGuard in 64-bit (x64) Windows Vista

At the start of 2006, when Windows Vista was launched, 32-bit (x86) architectures were prevalent by far, with 64-bit (x64) still considered exceptions in consumer computing. Vista was the first client OS from Microsoft to truly bet on x64 CPUs becoming mainstream in the near future, and the 64-bit flavor of the platform was more evolved than the 32-bit version. Among the extra technologies that it packed was a “small thing” called PatchGuard, or Kernel Patch Protection, and the detail that got Symantec, McAfee and other security vendors all fired up.

Here is what Symantec’s Oliver Friedrichs said at the time: “I have to say that it is not surprising to see that Microsoft is countering the claims (that Symantec, McAfee, and others are making) that Windows Vista will hinder innovation, while putting consumers at risk.” (emphasis added)

“(…) The security industry is very concerned that the decisions being made with 64-bit Windows will, in turn, result in a less secure platform. They will directly impact the development of new security technologies, and Microsoft themselves will lose out, due to an insecure platform. Security ISVs who deliver advanced behavior blocking and tamper-resistant security technologies all agree that this issue must be addressed,” he added. (emphasis added)

The explanation was also made available: “PatchGuard prevents anyone (with the exception of Microsoft) from tampering with, extending, enhancing, and protecting the Windows Vista kernel. It does this by detecting when a driver, or other code running inside the kernel, attempts to add this extended functionality. It monitors key system structures, one in particular being the System Service Dispatch Table (SSDT). When it detects a modification to this table, it results in a blue screen of death (BSOD), with the belief that malicious code may have tampered with the kernel. It is important to note that there are both legitimate, as well as malicious reasons for an application to modify this table.”

“The SSDT is frequently used by many software vendors in existing versions of Microsoft Windows to extend the kernel in order to protect users. Entire classes of security technologies, behavior blocking for one, rely on this much needed capability. The SSDT allows security vendors to monitor System Services, which are the fundamental functions in Windows that applications need to do their work. There are over 400 System Service calls. Each of these provide a specific function; whether it is to access the registry, access files, add a user to the system, or reboot the computer. By monitoring System Services, security technologies can monitor the behavior of both good and bad applications running on a system,” Friedrichs explained.

The accusations exchanged between Microsoft and some security companies escalated to the point in which the European Antitrust Commission felt the need to step in and ask the Redmond company to remove PatchGuard. Microsoft refused. The software giant instead chose to work with Symantec, McAfee and others to provide APIs (application programming interfaces) to compensate the fact that the Windows Kernel was now locked and could no longer be patched.

However, this was not a conspiracy of the members of the security industry. While they were quick to form an anti-PatchGuard group, security vendors were essentially interested in selling their products and nothing more. Symantec was trying to pressure Microsoft into providing APIs that would allow its security products to deliver similar functionality to System Services monitoring patches. But Symantec simply went too far claiming that Microsoft was opening 64-bit Vista to attackers, when in fact it was securing the OS.

Jim Allchin, co-president, Platforms & Services Division, responded in October 2006. “Contrary to some media reports, Microsoft will not weaken the security of 64-bit Windows by enabling some applications to modify the kernel of the operating system.

“We have applied our no-exceptions policy against kernel patching to Microsoft applications as well as third party applications, consistent with our Windows Principles. No application can bypass or weaken Kernel Patch Protection—this is essential to improving security and reliability for you. Note that many third-party security companies provide highly competitive products without modifying the Windows kernel in unsupported ways.

“For legitimate third-party applications that have intentionally patched the 32-bit Windows kernel in unsupported ways, Microsoft will continue to work with these third-parties to identify, prioritize, design and develop new interfaces for 64-bit Windows that will help their applications perform needed tasks, without directly modifying, bypassing or weakening Kernel Patch Protection. We have already begun discussions with the engineering teams of major third-party security vendors about the functionality they are seeking.”

The root(kit) of all evils Fast forward three years. Microsoft releases a patch for a 17-year-old vulnerability in Windows that crashes computers infected with the Alureon. Infected are mostly 32-bit copies of Windows XP that do not feature PatchGuard. In fact, the Redmond company informs that no 64-bit copies of Windows, be them Vista or Windows 7, had been compromised by Alureon. The rootkit can’t get past PatchGuard. Microsoft went ahead and, after it pulled MS10-015 from Automatic Updates, started the distribution of the patch for x64 Windows via AU once again.

“Microsoft has taken steps to deter tampering with the Windows Kernel using technologies like Kernel Patch Protection (sometimes referred to as PatchGuard) and Kernel Mode Code Signing (KMCS), both of which are enabled in 64-bit systems. These technologies make it possible to detect when integrity checks fail. The different versions of Alureon that we have investigated only infect 32-bit systems and would fail to infect 64-bit systems. That said, it is important to note that running as a standard user instead of using an administrator account is a best practice that in most cases will prevent kernel mode malware from infecting a system. Similarly, keeping anti-virus signatures current will also prevent most malware from infections. Additionally, since we have determined that 64-bit systems are not affected, we are opening Automatic Updates for these platforms,” Mike Reavey, director, MSRC, said.

“Alureon has existed for several years and has undergone a number of evolutionary changes. The ability to ‘infect’ the miniport driver associated with the hard disk of the operating system is a recent notable change. This functionality first appeared around August 2009. For the most common system configuration (for machines using ATA hard disk drives), the ATA miniport driver ‘atapi.sys’ is the file which is targeted,” Microsoft’s Scott Molenkamp stated.

“While the concept of modifying Windows system files as part of an installation method is not new, it is not a common approach. The file modification performed by Alureon overwrites the data in the target driver’s resource section with its own code. The entry point of the driver is modified to point to this code. By doing so, the malicious code is executed when the driver is loaded by the operating system. (Note that this infection method is mitigated on the 64-bit versions of Windows from XP SP1 onwards because of a technology called Kernel Patch Protection (‘PatchGuard’)),” he added.

Microsoft is currently cooking a solution that will detect and remove the Alureon rootkit from infected computers. It is important to underline that users of 64-bit Windows Vista and Windows 7 benefitted from the additional protection offered by PatchGuard, which locked the kernel to Alureon infections. Critics have pointed out that Kernel Patch Protection can be bypassed by attackers and malware, with several circumventing methods already documented in the wild as early as 2006.

Yes, this is completely true. Nowhere does Microsoft claim that PatchGuard is an impenetrable security barrier. But an attacker or a piece of malicious code attempting to own a 64-bit Windows 7 machine for example won’t have just PatchGuard standing in its way, but also User Account Control, IE Protect Mode, Data Execution Prevention (DEP), Address space layout randomization (ASLR), etc. It is the combination of all these security mitigations that contributes to making Windows 7 secure, the sum of security elements and not a single silver-bullet solution.

Security and hypocrisy