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