I was talking to a few MS security guys last week about the number of methods Microsoft provides for remote access to corporate resources. It was an interesting exercise to come up with a list of products and technologies that Microsoft has to provide remote access, and sometimes even secure remote access.
Some examples remote access of these products and technologies include:
- ISA Firewall Web Publishing
- ISA Firewall Server Publishing
- ISA Firewall VPN server
- IAG 2007 SSL VPN Gateway
- RRAS PPTP and L2TP/IPSec VPN server
- Longhorn RRAS SSTP VPN server
- RRAS Reverse NAT
- Windows Dial up RAS Server
- Remote Desktop Web Connection (RDP)
Of all of these methods of remote access to resources on the corporate network, which one do you think is the least secure? When I said that RDP was by far the least secure method, I was surprised to hear several of the others ask me why I thought that was the case, because it never occurred to them that RDP would be least secure, much less unsecure.
The answer if actually quite easy and the reasons transparent when you try to live your life by principles. And as a security specialist, which principle do you think would be the most overarching? The answer is the principle of least privilege. When you think of security as a method of applying least privilege to all connections to your network, you’ll see why RDP is the least secure option and in fact should be banned from all remote access schemes.
For example, think of secure Exchange RPC publishing and RPC/HTTP. Both these methods can be deployed through the ISA Firewall make it possible to get full Outlook MAPI client connectivity without requiring a VPN connection. Network security admins realized that requiring full network level connectivity through a VPN connection was ridiculous when only Outlook MAPI connectivity was required, so solutions such as secure Exchange RPC and RPC/HTTP publishing were implemented.
Now think about RDP publishing. This is the opposite of the principle of least privilege. In fact, when you provide remote access to RDP connections to corporate desktops or RDP servers you’re actually implementing the principle of maximum privilege, which puts your network at significant risk.
Consider the situations of secure Exchange RPC publishing and RDP publishing from a hacker’s point of view. When the attacker tries to compromise the RPC publishing solution, the target of the attack is going to be limited to what he might be able to do to the Exchange Server through the secure Exchange RPC connection. Since there are no reported exploits or flaws with the secure Exchange RPC publishing solution, the attacker is stopped in his tracks. Good guys one, bad guys zero.
Now consider the scenario when the attacker is able to hack into an RDP session. When the attacker has connected to the desktop or server over RDP, that hacker will own the box. There will be very little effort required on the attacker’s part to reconnoiter the network, place a network sniffer to capture user names and passwords moving over the network, and work with great stealth with a full complement of hacker tools that will enable him to steal, change and destroy data on the network, all with the credentials of a legitimate user.
Enabling remote access to corporate networks over RDP is a recipe for disaster, as you needlessly expose your network to the worst case scenario — a machine completely owned by a malicious user. In contrast, with the ISA Firewall and IAG 2007 publishing — users are provided restricted access to specific services and that access is controlled via strong application layer intelligence to slow or stop hackers from compromising the service made available to the users.
Even VPN is more secure, as you can configure the ISA Firewall’s VPN server to provide per user/group access to specific servers and protocols and apply both stateful packet and application layer inspection to those connections to help insure that they’re clean. With RDP, you provide a nice clear channel for intruders to not only own the machine that the RDP connection is made to, but to the entire network, because you gave them full access to a machine to launch the attack and provided no security measures to stop them.
Some might argue that strong authentication will mitigate the RDP security problem. While authentication and authorization are important aspects of security, they are not complete in and of themselves. A comprehensive security solution takes into account authentication, authorization, access control, packet inspection, application inspection, monitoring and reporting. With RDP connection you have no application inspection, no monitoring and no reporting. You have no idea what is being done on the RDP server to which the user or attacker is connected to, and you have no control over what that user can do over the RDP channel.
Bottom line: Providing remote access to RDP servers on your corporate network is hazardous to your company’s health. Remote access to RDP servers is a ticking time bomb that should be defused by removing all remote connections to RDP and applying least privilege by allowing access only to specific services that might be required and by applying application layer inspection to those connections.