In-Depth

An RDP Vulnerability Just Waiting to Happen?

According to security professionals, it''s possible for users of Microsoft''s new RDP 6.0 client to bypass server-side security settings and successfully establish connections.

• By Stephen Swoyer
• 05/01/2007

According to security professionals, it's possible for users of Microsoft's new RDP [Remote Desktop Protocol] 6.0 client to bypass server-side security settings and successfully establish connections — even when their sessions haven't been authenticated.

"With Terminal server installed on Windows 2003 Server [sic] with current service packs and patches it is possible to bypass the server side setting that requires SSL [Secure Sockets Layer] with a self-signed cert," the Bugtraq contributor — an enterprise support specialist with a state government agency — wrote. "You will automatically be downgraded to not using TLS [Transport Layer Security] and not be notified. The padlock will be missing on the RDP banner."

Just to clarify, this contributor indicated, RDP client 5.2 apparently cannot bypass the server-side setting; RDP client 6.0 always connects, however — even if authentication fails. "It is interesting that the client-side piece can control the server settings," this poster deadpanned.

So what's the big deal? At the very least, the Bugtraq contributor points out, this scheme could expose Terminal Services users to at least one common exploit. "Using a cert and SSL was [Microsoft's] answer to prevent man-in-the-middle attacks when using RDP. You may think that you are protected but you are not. This behavior exposes itself when you use the RDP 6.0 client. Nothing else is required," he wrote.

Microsoft, for its part, doesn't think there's anything wrong with this behavior. "The MSRC [Microsoft Security Response Center] determined that this is not a vulnerability, because the server-side setting in question controls authentication not encryption," said a Microsoft spokesperson in response to an inquiry. "If a server has been configured to allow session[s] without authentication, this setting would have no bearing whatsoever: the user would be able to proceed with an unauthenticated session. We do want to note, however, that a warning message that authentication has failed is displayed to the user."

This muddies the issue, however, according to the original Bugtraq contributor. After all, he points out, Microsoft's explanation ignores the likelihood of a man-in-the-middle attack.

With the increasing prevalence of phishing and other scams, the emergence of a man-in-the-middle RDP exploit is an all-too-conceivable — if not inevitable — possibility. "The use of a certificate for server authentication — the user has not entered his password yet — provides protection against this. You are using the certificate to authenticate that the terminal server you are connecting to is actually who you think it is and not someone in the middle proxying your traffic to your server while at the same time reading it," the Bugtraq poster explained.

Nor does this security pro agree with Microsoft's claim that users are warned when they've established unauthenticated sessions. "Microsoft's [claim] that you are warned is not what we see in our tests with the default settings," he wrote, adding that "when server authentication is successful, you will see the 'Lock' [similar to using https:// for secure Web transactions]. When it fails, the lock is not present."

He starts with a scenario in which an administrator configures a Terminal Server to require the use of SSL and high encryption to safeguard against man-in-the-middle attacks. So far, so good. But if a client uses the default RDP 6.0 installation and attempts to connect to what she thinks is server, she'll be able to establish a connection even if the system she's connected to is using a self-signed certificate that isn't actually in her trusted certificate store.

"The connection would have occurred unauthenticated," he said. "The server has not been verified to be who the user actually thinks it is." And while there's no "lock" in the RDP tab to indicate that the session has been authenticated, the user isn't given any explicit warning by the RDP client. From the user's perspective, she's logged into her designated terminal server - why shouldn't she enter her user name and password? "The default setting for the RDP 6.0 client is 'Always connect, even if authentication fails,'" this IT pro pointed out. "This is basically saying, ?always connect, even if your connection is being hijacked.'"

Organizations use Terminal Services to support a variety of activities, including the manipulation of sensitive data, such as personal health information and financial data, for example. "To me it is a significant problem and an unacceptable risk," he concluded. The risk is compounded, he argued, by the increasing mobility of many workers. Terminal Services users aren't always (or even mostly) sitting at thin client devices behind corporate firewalls, he pointed out. "We cannot control what laptop or computer a remote client may be connecting from or if they have the self-signed certificate authority trusted. The server settings should be able to provide the control," this security professional stated. "Remote users may be connecting from high risk areas such as hotels, airports and untrusted wireless access points, all areas where the potential for man in the middle attacks are higher."