Terminal Services vulnerable to man-in-the-middle attacks
Results 1 to 8 of 8

Thread: Terminal Services vulnerable to man-in-the-middle attacks

  1. #1
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,884

    Terminal Services vulnerable to man-in-the-middle attacks

    This write-up was released through Bugtraq and I believe that every IT shop should at least be aware of it. The write-up details how Terminal Server sessions are built and how they are exploited. The author confirms that they have code to make the exploit happen but they are not releasing it at this time. I can guarantee that code will surface for this exploit as many IT shops use Terminal Services for remote administration.

    Read on.....

    During extensive investigation of the Remote Desktop Protocol (RDP), the protocol used to connect to Windows Terminal Services, we (Cendio
    Systems) have found that although the information sent over the network is encrypted, there is no verification of the identity of the server when setting up the encryption keys for the session.

    This means RDP is vulnerable to Man In The Middle attacks (from here on referred to as MITM attacks). The attack works as follows:

    1) The client connects to the server, however by some method (DNS
    spoofing, arp poisioning, etc.) we've fooled it to connect to the
    MITM instead. The MITM sends the request further to the server.
    2) The server sends it's public key and a random salt, in cleartext,
    again through the MITM. The MITM sends the packet further to the
    client, but exchanges the public key to another one for which it
    knows the private part.
    3) The client sends a random salt, encrypted with the server public
    key, to the MITM.
    4) The MITM deencrypts the clients random salt with it's private key,
    encrypts it with the real servers public key and sends it to the
    server.
    5) The MITM now know both the server and the client salt, which is
    enough information to construct the session keys used for further
    packets sent between the client and the server. All information
    sent between the parts can now be read in cleartext.

    The vulnerability occurs because the clients by no means try to verify the public key of the server, sent in step 2 above. In other protocols, such as the Secure Shell protocol, most client implementations solve this for example by letting the user answer a question whether a specific serverkey fingerprint is valid.

    The clients we've seen so far for RDP have no way to preinsert a known server key. There is also no interaction with the user in order to verify a key the first time a connection is made to a new server.

    We have communicated with Microsoft in this matter, and they
    confirmed 2003-03-19 that the problem do exist in their current implementation. They are currently "investigating the feasability in adding this functionality". They also point out that they do not claim RDP having the functionality of providing server authentication.

    We feel that Microsoft is not taking this seriously enough. We know there are sites using Terminal Services to transfer sensitive data, and we feel that they need to be informed about this vulnerability in order to be able protect their networks. This is why we publish this information at this moment.

    We've tested this vulnerability against Windows 2000 Terminal Server, Windows 2000 Advanced Server and the upcoming Windows Server 2003 using both the clients delivered with Windows 2000 and the latest downloadable RDP client from Microsoft. We have reason to believe that the vulnerability exists when running both RDP version 4 and 5, and regardless of terminal server mode.

    We have developed software that can be used to exploit this vulnerability, but we choose not to release it.

    \EF
    --
    Erik Forsberg Telephone: +46-13-21 46 00
    Cendio Systems Web: http://www.thinlinc.com

    Hope this helps!
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  2. #2
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    This vulnerability is quite easily overcome if you provide Terminal Services access to clients across the internet. We use a PPTP VPN to the firewall as an initial connection. The firewall then provides the client with a local, (read private), IP address through the tunnel. The request for the terminal server is then made across the private addresses through the tunnel itself. This adds an additional level of security for only a small amount of inconvenience to the client and means that we do not need the additional port 3389 access allowed through the firewall.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  3. #3
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    I believe that most users of Terminal Server will not mind this too much. Terminal server is more commonly used on trusted networks, i.e. by admins for managing servers, and for multiuser environments.

    Like Tiger Shark says, if you are running over a VPN it is not a problem.

    It's interesting to note that an attacker doesn't actually need to carry out the technically complex Man-in-the-middle attack to exploit this problem- he can simply create a fake server instead and grab the passwords (feigning an error message to explain why the user cannot log on)

  4. #4
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,884
    You guys are correct. I posted this for those who run TS connections across the internet or other untrusted networks. I don't have to tell either of you how many people still do this kind of thing

    Regards

    --TH13
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  5. #5
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    What has surprised me in the past is the very small number of scans done for port 3389 that is publicly available. Less than one a month definitely.
    Don\'t SYN us.... We\'ll SYN you.....
    \"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides

  6. #6
    Member
    Join Date
    Mar 2003
    Posts
    30
    I wonder if they've carried this testing out with the Citrix version? I am pretty sure that TS is basic Citrix technology that rolled back to M$ a couple years back due to a licensing issue.

    Interesting! Worth looking into I would think - but to find the time....

    Yeah, I believe there are a lot of people who run this "in the raw" - but I can't see this as being something that the average script kiddie would be after.

    I'm a firm believer in putting either TS or Citrix behind a VPN connection whenever possible, preferably with strong authentication of some form or another.

    Thanks for the info.

  7. #7
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,884
    I believe that Citrix uses an SSL connection via their secure gateway product though I haven't personally seen it in action.
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

  8. #8
    Member
    Join Date
    Mar 2003
    Posts
    30
    You can configure nFuse to use an SSL connection. nFuse is a gateway product for Citrix. However, I have seen it used with a general HTTP connection as well, so SSL is not a requirement.

    Additionally, I've seen some people with publicly-accessible Citrix servers sitting on DMZ's with holes for the full client connection. Again, their client software supports encryption.

    I'm wondering if there is the same MITM potential with the traditional Citrix Client/Citrix Server configuration.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •