[THIN] FW: MSKB: Cryptographic Flaw in RDP Protocol can Lead to Information Disclosure (Q324380)

  • From: Jim Kenzig <jimkenz@xxxxxxxxxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Thu, 19 Sep 2002 09:21:37 -0400


Important security fix for RDP.
JK

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
bulletin/ms02-051.asp

Microsoft Security Bulletin MS02-151     Print
Cryptographic Flaw in RDP Protocol can Lead to Information Disclosure
(Q324380)
Originally posted: September 18, 2002
Summary
        Who should read this bulletin: System administrators who operate 
terminal
servers using Microsoft® Windows® 2000, or Windows XP users who have enabled
Remote Desktop.
        Impact of vulnerability: Two vulnerabilities: information disclosure,
denial of service.
        Maximum Severity Rating: Moderate.
        Recommendation: Administrators of Windows 2000 terminal servers and 
Windows
XP users who have enabled Remote Desktop should apply the patch.
        Affected Software:
*       Microsoft Windows 2000
*       Microsoft Windows XP
 Technical details
        Technical description:

        The Remote Data Protocol (RDP) provides the means by which Windows 
systems
can provide remote terminal sessions to clients. The protocol transmits
information regarding a terminal sessions' keyboard, mouse and video to the
remote client, and is used by Terminal Services in Windows NT 4.0 and
Windows 2000, and by Remote Desktop in Windows XP. Two security
vulnerabilities, both of which are eliminated by this patch, have been
discovered in various RDP implementations.
        The first involves how session encryption is implemented in certain
versions of RDP. All RDP implementations allow the data in an RDP session to
be encrypted. However, in the versions in Windows 2000 and Windows XP, the
checksums of the plaintext session data are sent without being encrypted
themselves. An attacker who was able to eavesdrop on and record an RDP
session could conduct a straightforward cryptanalytic attack against the
checksums and recover the session traffic.
        The second involves how the RDP implementation in Windows XP handles 
data
packets that are malformed in a particular way. Upon receiving such packets,
the Remote Desktop service would fail, and with it would fail the operating
system. It would not be necessary for an attacker to authenticate to an
affected system in order to deliver packets of this type to an affected
system.
        Mitigating factors:
        Cryptographic Flaw in RDP Protocol:
*       An attacker would need the ability to capture an RDP session in order to
exploit this vulnerability. In most cases, this would require that the
attacker have physical access to the network media.
*       Because encryption keys are negotiated on a per-session basis, a
successful attack would allow an attacker to decrypt only a single session
and not multiple sessions. Thus, the attacker would need to conduct a
separate cryptanalytic attack against each session he or she wished to
compromise.
        Denial of Service in Remote Desktop:
*       Remote Desktop service in Windows XP is not enabled by default.
*       Even if Remote Desktop service were enabled, a successful attack would
require that the attacker be able to deliver packets to the Remote Desktop
port on an affected system. Customers who block port 3389 at the firewall
would be protected against attempts to exploit this vulnerability. (By
default Internet Connection Firewall does block port 3389).
        Severity Rating:
        Internet Servers        Intranet Servers        Client Systems
Cryptographic Flaw in RDP Protocol      Moderate        Moderate        Moderate
Denial of Service in Remote Desktop     None    None    Moderate
The above assessment
<http://www.microsoft.com/technet/security/topics/rating.asp> is based on
the types of systems affected by the vulnerability, their typical deployment
patterns, and the effect that exploiting the vulnerability would have on
them. Successfully exploiting the encryption vulnerability requires the
attacker to have access to the network media; the denial of service
vulnerability only affects Windows XP systems, and only if Remote Desktop
Sharing has been enabled.
        Vulnerability identifier:
*       Weak Encryption in RDP Protocol:CVE-CAN-2002-0863
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0863>
*       Denial of Service in Remote Desktop:CVE-CAN-2002-0864
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0864>
        Tested Versions:
        Microsoft tested Windows NT 4.0 Terminal Services Edition, Windows 2000 
and
Windows XP to assess whether they are affected by these vulnerabilities.
Previous versions are no longer supported
<http://support.microsoft.com/directory/discontinue.asp>, and may or may not
be affected by these vulnerabilities.
 Frequently asked questions
        What vulnerabilities are eliminated by this patch?
        This patch eliminates two vulnerabilities affecting the implementation 
of
the RDP protocol:
*       The first involves a cryptographic flaw affecting the Windows 2000 and
Windows XP implementations.
*       The second involves denial of service vulnerability affecting the 
Windows
XP implementation only.
        What is the RDP protocol?
        Remote Desktop Protocol
<http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtech
nol/winxppro/reskit/pree_rem_higy.asp> is a networking protocol that
supports remote Windows terminal sessions between a client and a server. It
transmit all of the information usually associated with a local console
session ? keystrokes, video and mouse data, and so forth ? across a network,
allowing users to have full, interactive logon sessions with remote systems.
Microsoft Knowledge Base article Q186607
<http://support.microsoft.com/default.aspx?scid=kb;EN-US;q186607> provides
detailed technical information about the protocol.
        In which Microsoft products is RDP implemented?
        In general, RDP is the underlying protocol for Windows features that 
allow
remote desktop sessions. For instance:
*       Windows NT 4.0, Terminal Server Edition implements RDP 4.0.
*       Terminal Services in Windows 2000 implements RDP 5.0
                *       Remote Desktop Sharing
<http://www.microsoft.com/windowsxp/pro/using/howto/gomobile/remotedesktop/d
efault.asp> in Windows XP implements RDP 5.1
        Are RDP sessions enabled by default in Windows?
        RDP sessions are enabled by default in Windows NT 4.0, Terminal Server
Edition, but not in any other version of Windows. (Please note, however,
that neither of these vulnerabilities occur in Windows NT 4.0 Terminal
Server Edition).





        Cryptographic Flaw in RDP Protocol (CAN-2002-0863):
        What?s the scope of first vulnerability?
        This vulnerability could enable an attacker to read the contents of an
encrypted RDP session, thereby compromising any data within it. This could
include information such as usernames and passwords, as well as any data the
user entered into an application or which an application displayed for the
user.
        To exploit the vulnerability, the attacker would need the ability to
eavesdrop on and record an RDP session. In most cases, this would require
the attacker to have physical access to the network media itself. It would
also require the attacker to have the technical ability to mount a
cryptanalytic attack on the recorded data (the attack is, however,
straightforward). Only the RDP implementations in Windows 2000 and Windows
XP are affected.
        What causes the vulnerability?
        The vulnerability results because, although session data is encrypted in
RDP 5.0 (the version that ships with Windows 2000) and RDP 5.1 (the version
that ships with Windows XP), the checksums of the session data are not.
        What is RDP Encryption?
        Because RDP packets can sometimes be sent across uncontrolled or 
untrusted
networks like the Internet or an extranet, RDP
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/termserv/t
ermserv/remote_desktop_protocol.asp> encrypts the data in a remote session
using the RC4 cryptoalgorithm. In versions prior to Windows XP, the server
administrator could select the key size to use; in Windows XP, all sessions
are protected using 128-bit key.
        The vulnerability, however, has nothing to do with the cryptoalgorithm 
used
by RDP, nor with the key size. Instead, it results because of an
implementation error involving the handling of checksum data.
        What is checksum data?
        Checksums are frequently used in networking applications as a way of
detecting and correcting errors that occur during transmission. Before one
computer sends a data packet, it performs a mathematical operation on the
data, and sends the result of the operation along with the data itself. Upon
receiving the data and checksum, the other computer performs the same
mathematical operation on the data it received, and confirms that the result
matches what it received. If they match, it?s a good indicator that the data
wasn?t corrupted in transit.
        What?s wrong with the way checksums are handled in encrypted RDP 
sessions?
        The checksums, like the session data itself, should be encrypted. 
However,
in the Windows 2000 and Windows XP implementations of RDP, they aren?t. The
session data is encrypted, but before it?s encrypted a checksum is
calculated ? and that checksum is sent in plaintext.
        Why does this constitute a security vulnerability? After all, the 
checksums
aren?t the same as the session data, they?re just information about the
session data.
        True, but there are straightforward cryptanalytic techniques that would
enable an attacker to recover the session data from the checksums. Having
broken the encryption, the attacker would be able to see the user?s entire
RDP session. Any information ? from the information the user entered at the
keyboard, to the movements of his or her mouse, to the information displayed
on the screen ? could be read.
        How could an attacker exploit this vulnerability?
        To exploit this vulnerability, an attacker would first have to have the
means to capture a user?s encrypted network traffic, most likely through the
use of a network packet tracer. This is an important point, because in most
cases it would require the attacker to have physical access to the network
cabling that carries the session data.
        Having captured the data, the attacker would need to subject it to a
cryptanalytic attack in order to ?crack? the encryption on the session data.
This would require some technical knowledge about the RDP data format and
cryptanalytic techniques, but these are not insurmountable hurdles.
        If an attacker managed to decrypt one session, would that make it 
easier to
decrypt future ones?
        No. Unique session keys are negotiated at the start of every RDP 
session,
so each attempt to compromise a session would need to start from scratch.
        Does the vulnerability affect Windows NT 4.0?
        No. Only the RDP implementations in Windows 2000 and Windows XP are
affected.
        What does the patch do?
        The patch eliminates the vulnerability by encrypting the checksums as 
well
as the session data.





        Denial of Service in Remote Desktop (CAN-2002-0864):
        What?s the scope of the second vulnerability?
        This is a denial of service
<http://www.microsoft.com/technet/security/bulletin/glossary.asp>
vulnerability. An attacker who successfully exploited this vulnerability
could cause a system hosting remote sessions to fail, with the loss of any
unsaved data.
        This vulnerability only affects Windows XP, but even then, the affected
feature is not enabled by default. Even if it were enabled, an attacker
would need the ability to deliver data to an affected system in order to
exploit the vulnerability, so users who have observed normal firewalling
precautions would not at risk from Internet-based attacks.
        What causes the vulnerability?
        The vulnerability results because of a flaw in the way RDP 5.1 (the 
version
implemented in Windows XP) handles certain types of invalid data packets.
Instead of handling them gracefully, RDP ? and with the operating system
itself ? would fail upon processing them.
        What?s wrong with the way the RDP implementation in Windows XP handles 
the
invalid data involved in the vulnerability?
        By design, RDP should always check the validity of all incoming data
packets before trying to act upon them. However, the RDP implementation in
Windows XP doesn?t check for one particular type of flaw in the incoming
packets. Because of this, it would be possible to create a packet that, when
processed, would create a series of failures that would culminate in the
failure of the operating system itself.
        What could an attacker do via this vulnerability?
        An attacker could cause a Windows XP system to fail, if it's been
configured to allow Remote Desktop sessions. The operator would need to
reboot the machine in order to restore normal service.
        Who could exploit the vulnerability?
        Any user who could deliver the specific type of packets involved in this
vulnerability to an affected Windows XP system could exploit it.
        Are default installations of Windows XP affected by the vulnerability?
        No. Remote Desktop Service does not run by default.
        I don?t know if I?ve enabled Remote Desktop. How can I tell? Select 
Start,
then Control Panel, then System. In the System Properties dialog, select the
Remote tab, and inspect the checkbox in the Remote Desktop section. If it?s
selected, Remote Desktop is enabled; if it?s not, Remote Desktop is
disabled.
        Would the attacker need to be able to establish a Remote Desktop 
session in
order to exploit this vulnerability?
        No. The attacker would only need to send the correct set of packets to 
the
correct port.
        Could the vulnerability be exploited from the Internet?
        It depends on whether the attacker were able to deliver packets to the 
port
on which RDP operates, port 3389. If standard best practices have been
followed, this port will be blocked at the firewall. (For instance, this
port is blocked by default by Internet Connection Firewall
<http://www.microsoft.com/windowsxp/pro/using/howto/networking/icf.asp>).
        Could a user inadvertently exploit this vulnerability?
        No. The specific series of packets needed to cause the server to fail
cannot be generated as part of a normal Remote Desktop session.
        What does the patch do?
        The patch addresses the vulnerability by ensuring that the Remote 
Desktop
service handles malformed packets gracefully.
Patch availability
        Download locations for this patch
*       Windows 2000:
<http://www.microsoft.com/Downloads/Release.asp?ReleaseID=41326>
*       Windows XP:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID= 41288
<http://www.microsoft.com/Downloads/Release.asp?ReleaseID=41288>
*       Windows XP 64 bit Edition:
http://www.microsoft.com/Downloads/Release.asp?ReleaseID= 41314
<http://www.microsoft.com/Downloads/Release.asp?ReleaseID=41314>
 Additional information about this patch
        Installation platforms:
        The patch for Windows 2000 can be installed on systems running Windows 
2000
Service Pack 2
<http://www.microsoft.com/windows2000/downloads/servicepacks/sp2/default.asp
> or Windows 2000 Service Pack 3
<http://www.microsoft.com/windows2000/downloads/servicepacks/sp3/default.asp
>. The patch for Windows XP can be installed on systems running Windows XP
Gold.
        Inclusion in future service packs:
*       The fix for this issue will be included in Windows 2000 Service Pack 4.
*       The fix for this issue is included in Windows XP Service Pack 1.
        Reboot needed: Yes
        Patch can be uninstalled: Yes
        Superseded patches: None.
        Verifying patch installation: Windows 2000:
*       To verify that the patch has been installed on the machine, confirm that
the following registry key has been created on the machine:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q324380.
*       To verify the individual files, use the date/time and version 
information
provided in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows
2000\SP4\Q324380\Filelist
        Windows XP:
*       To verify that the patch has been installed on the machine, confirm that
the following registry key has been created on the machine:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\Q324380.
*       To verify the individual files, use the date/time and version 
information
provided in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows
XP\SP1\Q324380\Filelist.
        Caveats:
        None
        Localization:
        Localized versions of this patch are available at the locations 
discussed
in ?Patch Availability?.
        Obtaining other security patches:
        Patches for other security issues are available from the following
locations:
*       Security patches are available from the Microsoft Download Center
<http://www.microsoft.com/downloads/search.asp?Search=Keyword&Value='securit
y_patch'&OpSysID=1>, and can be most easily found by doing a keyword search
for "security_patch".
*       Patches for consumer platforms are available from the WindowsUpdate
<http://windowsupdate.microsoft.com/> web site
Other information:
        Support:
*       Microsoft Knowledge Base article Q324380 discusses this issue and will 
be
available approximately 24 hours after the release of this bulletin.
Knowledge Base articles can be found on the Microsoft Online Support
<http://support.microsoft.com/?scid=fh;en-us;kbhowto> web site.
*       Technical support is available from Microsoft Product Support Services
<http://support.microsoft.com/directory/question.asp?sd=gn&fr=0>. There is
no charge for support calls associated with security patches.
        Security Resources: The Microsoft TechNet Security
</technet/security/default.asp> Web Site provides additional information
about security in Microsoft products.
        Disclaimer:
        The information provided in the Microsoft Knowledge Base is provided "as
is" without warranty of any kind. Microsoft disclaims all warranties, either
express or implied, including the warranties of merchantability and fitness
for a particular purpose. In no event shall Microsoft Corporation or its
suppliers be liable for any damages whatsoever including direct, indirect,
incidental, consequential, loss of business profits or special damages, even
if Microsoft Corporation or its suppliers have been advised of the
possibility of such damages. Some states do not allow the exclusion or
limitation of liability for consequential or incidental damages so the
foregoing limitation may not apply.
        Revisions:
*       V1.0 (September 18, 2002): Bulletin Crea

**********************************************
This weeks sponsor Jetro Platforms 
Jetro Platforms Ltd. is an enterprise software developer, 
bringing a new era in server-based computing, secured internet 
access, and disaster recovery.  We make IT Easy! 
http://www.jp-inc.com/
***********************************************

For Archives, to Unsubscribe, Subscribe or 
set Digest or Vacation mode use the below link.

http://thethin.net/citrixlist.cfm

Other related posts:

  • » [THIN] FW: MSKB: Cryptographic Flaw in RDP Protocol can Lead to Information Disclosure (Q324380)