Security Experts:

Netting Out a Response to the Microsoft RDP Vulnerability

Microsoft made lots of news recently with the disclosure that a key vulnerability (MS12-020) involving the RDP protocol had been leaked, apparently from Microsoft’s Active Protections Program (MAPP). MAPP enables Microsoft to share information with select security vendors so that security products can have protections ready when the vulnerability is disclosed to the public. In spite of some criticism, I believe MAPP is a good program that the industry needs. Without something like MAPP, every time a vulnerability is disclosed, your security vendor will be in a race to write and distribute a protection before a hacker can hit your network. With MAPP, multiple layers of defense can be at the ready before hackers can exploit it.

The Risks and Responses

Network Security RDP VulnerabilitySo enough about the leak; lets talk about what you actually need to know to protect yourself from the vulnerability and others like it. First and foremost, everyone needs to apply the patch for MS12-020 as soon as possible, full stop. Even though an exploit has yet to be seen in the wild, if successful it would instantly provide system level access on any device with RDP enabled and listening on the default port of 3389. As has been discussed widely, this creates a very “wormable” scenario where infections could quickly spread from machine to machine.

Patching is a great start, but what where do we go from there? One of Microsoft’s recommendations is to block port 3389 at the firewall to prevent access to vulnerable devices. This is probably not a very viable solution, given the overwhelmingly popularity of RDP in the enterprise. The latest results from the Application Usage and Risk Report show that RDP is the leading remote access technology in enterprises, with over 80% of companies using RDP. Thus it’s probably not one of the services that enterprises can simply turn off.

A Move to Non-Standard Ports

As an alternative, a growing number in the industry have begun to recommend moving RDP (link) and other network facing services off of their default ports. The idea being that a large percentage of external exploits will be launched and delivered by automated scripts and tools that are simply looking for vulnerable machines on default ports. Thus if you move RDP to a different port, you at least obscure your vulnerable devices from worms and script-kiddies. This seems like a pretty sensible approach as long as one understands the limitations and ensures that other security layers aren’t compromised in the process.

The key here is that to do this sort of thing safely, you will need a network security layer that truly understands traffic independent of port and protocol. The stark truth is that the vast majority of network security solutions continue to rest on port-based controls as the bedrock of their analysis and enforcement. For instance, IPS solutions will apply signatures to traffic on a certain port based on what traffic it expects to see on that port. Running all signatures on all ports would become a performance bottleneck very quickly. Additionally most solutions marketed as next-generation firewalls will only recognize a particular application on its default port and the web ports (port 80, and 443). True next-generation firewalls and their embedded threat preventions should recognize and decode any traffic on any port to avoid this problem, and save the headache of reconfiguring the network security layer. The key here is to make sure that you don’t compromise your defense in depth in order to gain additional obscurity. Demand both.

Beware the Lateral Move

Thus far, we have been thinking of the RDP vulnerability in terms of a traditional externally driven attack. However, modern targeted attacks typically begin by infecting a few users with stealthy malware, which will then enumerate the local network environment for further exploitation. This is where the RDP vulnerability gets really scary. In this scenario, running RDP on an alternative port will provide little protection if any. It’s a trivial exercise to enumerate machines and discover which service they have running on which ports, and it’s a quite common technique in modern malware and targeted attacks. This makes the RDP vulnerability a perfect escalation tool. Once the attacker compromises a host, he can look for a privileged user, and take control of that system using the RDP exploit. The attacker could quickly hop from machine to machine until he finds the information he wants.

This illustrates the imperative need to bring network security and analysis inside the perimeter. Advanced attacks depend on their ability to move laterally within a network, and rely on the fact that internal visibility and controls are rarely on par with those found at the perimeter. Jon Kindervag of Forrester has championed the concept of the Zero-Trust Architecture for just these sorts of reasons. At a bare minimum, enterprises should monitor traffic of their core switches in order to maintain visibility into their internal traffic, lest they allow one owned client to spread to the entire enterprise.

Vulnerabilities are a fact of life. MS12-020 is a bad one, but there will be more. It may sound trite, but patch management and defense in depth continues to be the best medicine. As a security professional, the hard part is making sure we take a realistic, unflinching look at our defense in depth to make sure that its really providing what we intended.

view counter
Wade Williamson is Director of Product Marketing at Vectra Networks. Prior to joining Vectra, he was a Senior Threat Researcher at Shape Security. He has extensive industry experience in intrusion prevention, malware analysis, and secure mobility. He has extensive speaking experience having delivered the keynote for the EICAR malware conference and led the Malware Researcher Peer Discussion at RSA. Prior to joining Shape, he was Sr. Security Analyst at Palo Alto Networks where he led the monthly Threat Review Series and authored the Modern Malware Review. He has also led the product management team at AirMagnet where he helped to develop a variety of security and network analysis tools targeted to WiFi networks. He has been a steady and active researcher of new threats and techniques used to compromise enterprise networks and end-users.