In-Depth
RDP Fix Shows Microsoft's Smarter about Windows Security Updates
As Microsoft's response to a recent critical vulnerability demonstrates, Windows security has come a long way -- for the better -- since the days of Code Red.
Microsoft Corp. this month released an update (CVE-2012-0002) to fix a critical vulnerability in its Remote Desktop Protocol (RDP) implementation.
It's part of a series of recent mishaps that -- deservedly or not -- have involved RDP, which provides essential management services in Microsoft environments.
Remote Desktop is implemented on Microsoft Windows Server 2003 and 2008 operating platforms, as well as on the Professional, Enterprise, and Ultimate editions of its Windows 7 operating system. RDP is likewise supported in Windows Vista Ultimate Edition, as well as in the Professional editions of Windows XP and Windows Vista. There's even an open source implementation of RDP, dubbed XRDP, that uses the RDP protocol to serve up X sessions.
Unlike the RDP-specific "Mordo" worm that troubled Windows administrators last summer, this new RDP vulnerability is serious stuff: an attacker who successfully exploits it can execute arbitrary code on a compromised system. By contrast, the only vulnerability that Mordo exploited was IT sloppiness. For this reason, administrators who'd followed common security best practices -- to say nothing of Microsoft's own hardening recommendations -- didn't sweat Mordo.
You can bet that IT admins were sweating this one, however. The severity of CVE-2012-0002 is such that it absolutely needs to be patched. To expose an at-risk RDP port to the Internet, or even to an internal subnet, is to risk complete and total system compromise. "We strongly recommend that customers examine and prepare to apply this bulletin as soon as possible," Microsoft warned in its March 2012 security bulletin.
On its surface, the situation seemed to invite comparison with blockbuster Windows flaws of the past – issues that worms such as Code Red or SQL Slammer were able to exploit to horrific effect. However, as Microsoft's response demonstrates, Windows security has come a long way -- for the better -- since 2001 and 2002.
The classic Code Red scenario posed problems for security administrators. IT professionals prefer to rigorously test patches to ensure that they don't break existing dependencies or cause other problems. This isn't possible in zero-day cases, however. In addition, patches sometimes require system reboots. Given the cost of downtime in most large organizations, server reboots -- an aspect of overall system maintenance (of which the application of patches or software updates is a major component) -- are almost always scheduled. The more critical the system, the more carefully they're scheduled, but careful scheduling likewise isn't possible in zero-day cases.
As a result, IT admins tend to prefer workarounds, which can at least hold them over until they're able to test a patch and slip it into the next maintenance window. Sometimes, however, there aren't any workarounds. This was the case with Code Red, which wrought havoc in part because Microsoft's response -- a patch, which required a reboot -- gave admins no winning move.
The good news with this month's RDP vulnerability is that there's a workaround -- several of them, in fact. "We understand that our customers need time to evaluate and test all bulletins before applying them. To provide for a bit of scheduling flexibility, we're offering a one-click, no-reboot Fix it [i.e., a downloadable .msi executable] that enables Network-Level Authentication [NLA], [which is] an effective mitigation for this issue," wrote Angela Gunn, of Microsoft's Trustworthy Computing team, on the Microsoft Security Response Center blog.
(Microsoft announced Trustworthy Computing specifically in response to Code Red. Two of its stated goals were to improve the consistency and reliability of Microsoft's patching process and to minimize the need for system reboots to apply patches.)
In the NLA scheme, a user must first authenticate to a system before a remote desktop session can be established. While an attacker who successfully does so could then execute arbitrary code on a system, that's a separate problem: if an attacker's able to authenticate to a system, the attacker could conceivably perform all kinds of mischief.
Microsoft's hardening guide suggests that organizations enable NLA by default. The rub is that NLA isn't supported -- client- or server-side -- on Windows XP and Windows Server 2003. (A caveat involves Redmond's Terminal Services, or TS, Gateway, which tunnels RDP -- as RPC -- over HTTPS. Windows Server 2003 systems configured as TS Gateways -- i.e., that do not expose vanilla RDP ports -- are likewise protected against attack.)
Microsoft provided an additional workaround, of sorts, for these users, too. "If you need to initiate a remote desktop protocol connection to an NLA-enabled server from a Windows XP client, you can install support for Credential Security Support Provider [CredSSP] on each connecting Windows XP client," wrote Suha Can and Jonathan Ness, both of MSRC Engineering, on Microsoft's Security Research and Defense blog
Code Red Revisited?
For some customers, this month's RDP flaw poses problems for IT: the enterprise is vulnerable, IT can't implement Microsoft's workarounds, and -- from an IT perspective -- applying patches to production systems without first testing them poses an unacceptable risk. The existence of several workarounds, combined with the patching policies that are in place in most IT organizations, should help to substantially reduce the number of customers affected.
It certainly isn't to reprise the situation that helped produce Code Red. 11 years ago, when Microsoft released a fix to patch a flaw in its Index Server (on Windows NT 4.0) and Indexing Service (on Windows 2000) engines. At that time, the reverse was the case: at least 50 percent of Windows server implementations were believed to be affected. That they were affected was a testament to Microsoft's sloppiness and naiveté. Although Code Red nominally exploited a flaw in the Windows indexing service, it used IIS as its point of entry and propagation. The indexing service was a default component of both IIS 4.0 (which shipped with the Windows NT 4.0 Option Pack) and IIS 5.0 (which shipped with Windows 2000).
In other words, it was installed – out-of-the-box – in the vast majority of IIS configurations. Simply uninstalling or disabling indexing services wouldn't fix the problem, either: a vulnerable IIS component (IDQ.DLL) would continue to receive and parse requests. Besides, the patch management practices of a decade ago were primitive. Trustworthy Computing didn't yet exist, Microsoft hadn't yet settled on a standardized patching schedule, its security updates weren't always to be trusted, and neither Redmond nor most Windows administrators could yet imagine something like Code Red. It was a category-defining worm.
The rest, as they say, is history: Microsoft released its patch on June 19, 2001; a little over three weeks later, Code Red blindsided Windows administrators, confronting them for the first time with a problem that -- for the next few years, at least -- would become very familiar to them.
[Editor's Note: For more on the possible source of the RDP vulnerability, see Did Microsoft Partner Lead Windows RDP Exploit Code?.]