By Chris Brenton
During its March patch cycle, Microsoft quietly fixed a remote code execution problem with the Remote Desktop Protocol (RDP). RDP is the service used for remote Windows system management, as well as remote desktop services. Identified as CVE-2012-0002, the exploit can permit an attacker to execute any command on the target system with “System” level privileges. Further, no authentication is required to perform the attack. While the vulnerability has been labeled as critical, its implications in the cloud may be far more severe than is being discussed publically.
Unfortunately, many security professionals have down played the potential impact of this vulnerability. They counter that RDP is disabled by default, and most firewalls do not let RDP past the perimeter. Given these facts, many have stated that the impact of this vulnerability will be negligible. However this analysis completely ignores the potential impact from public Infrastructure as a Service (IaaS) deployments.
The Cloud Factor
A large portion of public IaaS deployments are comprised of Windows servers. While no exact numbers have been published, it is generally accepted that Windows servers make up 40% or more of the public IaaS market share. Typically, these servers are deployed from images supplied by the cloud provider. These images are very often unpatched with the RDP enabled so that the tenant can gain remote access to their server.
So, right out of the gate, most public IaaS Windows servers are vulnerable to this attack. While patching fixes the problem, at best there will still be a window of time while patches are being installed when the system will be vulnerable. At worst, the system will never be patched, as automatic updating is usually disabled by default. Further, since most cloud providers charge for network utilization, applying patches costs the cloud tenants money. This means some number of tenants, typically on the smaller side, may actually choose not to enable automatic software updates in the interest of lowering their monthly billing costs. All of this adds up to the potential that there will be a large number of systems vulnerable to this attack.
Exploit in the Works
Luckily, we have yet to see a worm in the wild that is capable of leveraging this exploit. That is changing, however, as a few days after the patch was released a working exploit was found on a Chinese hosting server. What made this event particularly disconcerting was the code was apparently leaked via the Microsoft Active Protections Program. While this code was only capable of exploiting Windows 2000 and 2003 systems, gun.io is offering a $1,500 bounty to anyone who can create a fully functional exploit. The bounty is partially being funded by HD Moore, who plans on incorporating the code into the Metasploit framework. Metasploit is a freely available tool that can be used to penetrate remote systems.
To review where we are at today, we potentially have a large number of IaaS cloud-based system vulnerable to this critical exploit, there is financial motivation on the table to create a fully functional exploit, and once the exploit is available it will be incorporated into an attack tool that anyone can use. Ouch.
Historical Perspective
Back in 2001, the Code Red worm leveraged a known exploit in the Windows IIS Web server. Despite there being a patch available, Code Red, and the later variant Code Red 2, were responsible for infecting a huge number of systems on the Internet. The number of infected systems was so large, that all Internet connectivity was impacted. Even if your system was not vulnerable, you still suffered from slow Internet access speed due to all of the traffic being generated by infected systems.
If it turns out that the RDP exploit is capable of propagating in a similar fashion to Code Red, what would be the impact on public IaaS cloud users? Slow network links would obviously be the first problem. Since public cloud is a shared environment, it is also possible that infected system may also consume excessive CPU and memory resources. This will leave fewer resources available to other tenants on the same hardware, possibly impacting local processing as well. Finally, when Code Red was released, most of your users and servers all sat behind layers of perimeter protection. This means that, while your Internet connectivity was impacted, so long as you could avoid infection local server access remained normal. If today those servers are located in a public cloud, critical business functions could be impacted.
Mitigating Your Risks
As I write this, I’m monitoring the firewall logs on some of my AWS servers. Sure enough, there is an uptick in the number of RDP probes being recorded. In order to avoid becoming part of this potential problem, here are some steps you can take with your public IaaS servers:
- Patch your systems!
- Leverage firewalls to limit system access while patching
- Leverage host-based firewalls to limit RDP (TCP/3389) access overall
- Implement host-based intrusion detection to detect compromises when they occur
- Have a contingency plan in case your cloud servers become inaccessible
It is entirely possible this vulnerability will never be widely exploited and we’ll dodge the bullet. Given the attraction of mass server compromise opportunities to fraudsters and e-criminals, however, sooner or later we are bound to see another worm-like exploit tearing across the Internet. We first need to recognize that mass infections will impact publically hosted resources differently, and to a much greater scale, than resources on a private network. We then need to identify how to broadly safeguard against these types of attacks, and how we should respond when the inevitable outbreaks occur.
About the author
Chris Brenton is a cloud security architect for CloudPassage, the leading cloud server security provider. Brenton, who’s also a Fellow Instructor at the SANS Institute and a published author, is an IT and security expert with substantial experience directing the demands of complex projects and developing innovative systems. Find Brenton tweeting at @Chris_Brenton
