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.

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."

About the Author

Stephen Swoyer is a Nashville, TN-based freelance journalist who writes about technology.

comments powered by Disqus

Featured

  • Windows Community Toolkit v8.2 Adds Native AOT Support

    Microsoft shipped Windows Community Toolkit v8.2, an incremental update to the open-source collection of helper functions and other resources designed to simplify the development of Windows applications. The main new feature is support for native ahead-of-time (AOT) compilation.

  • New 'Visual Studio Hub' 1-Stop-Shop for GitHub Copilot Resources, More

    Unsurprisingly, GitHub Copilot resources are front-and-center in Microsoft's new Visual Studio Hub, a one-stop-shop for all things concerning your favorite IDE.

  • Mastering Blazor Authentication and Authorization

    At the Visual Studio Live! @ Microsoft HQ developer conference set for August, Rockford Lhotka will explain the ins and outs of authentication across Blazor Server, WebAssembly, and .NET MAUI Hybrid apps, and show how to use identity and claims to customize application behavior through fine-grained authorization.

  • Linear Support Vector Regression from Scratch Using C# with Evolutionary Training

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the linear support vector regression (linear SVR) technique, where the goal is to predict a single numeric value. A linear SVR model uses an unusual error/loss function and cannot be trained using standard simple techniques, and so evolutionary optimization training is used.

  • Low-Code Report Says AI Will Enhance, Not Replace DIY Dev Tools

    Along with replacing software developers and possibly killing humanity, advanced AI is seen by many as a death knell for the do-it-yourself, low-code/no-code tooling industry, but a new report belies that notion.

Subscribe on YouTube