From Public Key to Exploitation:

Exploiting the Authentication in

MS-RDP [CVE-2018-0886]
Eyal Karni, Preempt Research Team
Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Vulnerability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Issue #1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Toward Issue #2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 Issue #2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Broken RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Finding Primes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3 Finding Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4 Exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.5 Real World Obstacles. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5. Reference/Technical Background. . . . . . . . . . . . . . . . . . . . 9
 3

1. Introduction
In March 2018 Patch Tuesday, Microsoft released a patch for CVE-2018-0886, a critical
vulnerability that was discovered by Preempt. This vulnerability can be classified as a
logical remote code execution (RCE) vulnerability. It resembles a classic relay attack, but
with a nice twist: It is related to RSA cryptography (and prime numbers) which makes it
quite unique and interesting.

The vulnerability consists of a design flaw in CredSSP, which is a Security Support Provider
involved in the Microsoft Remote Desktop and Windows Remote Management (Including
Powershell sessions). An attacker with complete Man in the Middle (MITM) control over such a
session can abuse it to run an arbitrary code on the target server on behalf of the user!

We have demonstrated the attack for Remote Desktop Protocol (RDP) in a domain environment.
If the user is a local administrator on the target system, the exploit allows the attacker to
run code as SYSTEM, effectively compromising the target server. This is applicable both to
Restricted Admin mode and to regular mode of RDP.

Figure 1 - An illustration of CVE-2018-0886 exploit scenario

For the described reasons, and since RDP sessions are very common, this vulnerability could
be really valuable to attackers. Further, because it is by design, the vulnerability resides in all
windows versions (from Vista), as long as fix is not applied.
Fix can be found here: https://aka.ms/credssp

In this paper, we will go through the journey I went in facilitating the exploit. Along the way, I will
explain the technical and mathematical details of the vulnerability.

It is assumed that the reader has some familiarity with the Active Directory (AD) environment,
mainly with Kerberos, NT LAN Manager (NTLM), MS-RDP and Security Support Provider
Interface (SSPI). If you would like to learn more about these terms you can find it in the
 4

2. Vulnerability Details
2.1 Issue #1
Our journey begins with another vulnerability that we discovered at Preempt. In the context of
that vulnerability we demonstrated the ability to do NTLM relay in the case of RDP Restricted
Admin mode even without knowledge of the private key of the destination server. This is not
trivial since the entire process is done under Transport Layer Security (TLS), and is thus
encrypted by the certificate of the server.

Exploiting the NTLM relay vulnerability was possible because of the way RDP is implemented.
Let’s take a look at the process:

1. Negotiation over capabilities (Usually CredSSP is chosen) ​

2. TLS is established​
3. Network Layer Authentication (NLA) is carried out using CredSSP ​
4. The client verifies the certificate, displaying warning if needed ​
5. The user accepts the warning​
6. The user sends its password over CredSSP​(In Regular Mode)
7. Login and remote UI activities
After establishing the encrypted secure session, the next step in RDP is NLA. The server
validates that the client possesses the credentials for the user by the usual method of
authentication (e.g., Kerberos). This saves the need to allocate resources needed for logon.

In step 4, the client checks the certificate. A warning

won’t be shown if the certificate is signed by a trusted
Certificate Authority (CA) or if the certificate is trusted
manually. However, Microsoft decided the server is
also considered validated if Kerberos authentication is
performed. The certificate is coupled with the Kerberos
Identity in step 3. If neither condition is met, a warning
will be shown as in Figure 2.

You can see that NLA happens before validating the

certificate. Thus, step 3 can be made with any forged
certificate. Assuming everything else is done securely
and correctly, this won’t be an issue, but this is not the
Figure 2 - A standard MS-RDP warning
case here. We will call this issue #1.
 5

2.2 Toward Issue #2

When dealing with issues, sometimes it takes two to tango. I found a second issue when I
looked at the specification of CredSSP.

CredSSP is the underlying protocol that is used to relay the credentials of the user in MS-RDP.
Basically, this protocol is very simple: TSRequest messages are transferred from the client to
the server and vice versa. These messages carry SPNEGO tokens used for the negotiation
phase of the authentication protocol. The negotiation is transparent for the CredSSP client/
server. The protocol is carried over the secured TLS session established in step 1.

Let’s take a look at the chart:

Figure 3 - CredSSP NLA Part

In the final negotiation message (accept_complete), the client computer transfers the NLTM/
Kerberos final token, but it also sends the public key of the server encrypted and signed with
SSPI. The public key structure is derived from the key parameters of the RSA. What is important
for now, is that it contains the N,e parameters that are the essence of the server certificate.
 6

This is a common variant of a technique called Channel Binding which is aimed at thwarting
credential relay attacks by binding the TLS session with the Windows authentication. So, the
identity of the server (as represented by the certificate) is coupled with the standard Windows
Authentication identity (as represented by the relevant account secret1).

Still, this design carries a fatal flaw inherent in it. In this stage, you might want to take a few
minutes to spot it yourself.

2.3 Issue #2
The second issue is that the client trusts the public key of the server. It actually encrypts and signs
bytes of the server (the public key structure) without first validating its identity. We can see the
attack as a private case of a Chosen Plaintext Attack (CPA). In this case, it encrypts and signs it the
same way it does for an application in SSPI (compared to a classical attack which only encrypts).

This is the essence of the vulnerability. To exploit it, an attacker would set up a rogue server, and
use the public key both as application data and as a valid RSA key. Then it would forward the
encrypted and signed application data to the real intended server (no other server is possible in the
current exploit).

Figure 4 - A diagram of the exploit

1 As a side note, in CredSSP by default a User2User process is taking place instead of regular kerberos. First the
server sends its TGT to the client. Then the TGS is encrypted with the TGT session key. This has no effect on the
vulnerability, so it is ignored.
 7

But is it really possible? After all, the public key is dual purposed. It should be valid as both an
RSA key and as a signed application data of a yet-to-be-determined windows protocol. This
protocol should support SSPI of course, but all the standard windows protocols do support it.

Let us focus our attention first on what seems to be the toughest problem: we need control over
the RSA public key (which is translated to Application Data).

3. Exploitation
3.1 Broken RSA
 8

3.2 Finding Primes

 9

3.3 Finding Protocols

Protocol Requirements

The most obvious requirement is that the Public Key Structure will be coded as the Application
Data. This structure is ASN.12.

Figure 5 - Public Key Structure

What it means for us is that the first 8 bytes of the data are not under our (full) control.

NTLM or Kerberos

A question to consider is whether we can implement NTLM or Kerberos. SSPI has standard
mechanisms for signing based on NTLM and Kerberos authentication. In both cases a header
that contains the checksum and sequence number is added to the Application Data, if signing
was agreed in the negotiation. In addition, the SPNEGO negotiation ends with signing and
encryption enabled, and the the sequence number in the case of Public Key Structure will be 0.

2 CredSSP version 2-4

 10

However, there is an important difference between NTLM and Kerberos handling. It is

demonstrated in the following diagram (for RPC as an important example) 3 4:

Figure 6 - NTLM vs Kerberos in GSSAPI

The Public Key Structure is actually encoded as “headerless protocol”. The entire structure is
encrypted and signed in NTLM case, but the RPC server expects only the Application Data
to be encrypted. So, NTLM adds another restriction for the protocol. This restriction actually
prevented us from implementing the attack for NTLM because we couldn’t find a suitable
“headerless” protocol. We aren’t sure that it is impossible. Finding such protocol would likely
produce a stronger exploit, allowing the attacker to choose a different server to target using
NTLM Relay.

Another point to note is that in Kerberos, ticket service name is not strictly forced, as long as the
account matches. The account in RDP is the machine account. So, we can say that Kerberos
is mildly vulnerable to Kerberos Relay. A data signed for use in one application can be used in
another one, given a similar CPA.

Here is a summary of the requirements for the protocol:

• Supports SPNEGO​
• Encoding requirements​
• Application Data is Non-ASN.1​
• Specific 8-bytes Prefix which we have no control over​
• Includes some degree of freedom ​
• No Header if dealing with NTLM​
• Able to do harm with a single signed packet​
• Available on wide variety of machines
One protocol that satisfies all of the requirements is MSRPC (Besides the extra requirement
required for NTLM to work). We are not aware of any other protocol that meets these
requirements.
3 Application Data is actually more generally the data wrapped by GSS_WRAP or similar method
4 This happens in modern NTLM usage if NEGOTIATE_EXTENDED_SESSIONSECURITY is on
 11

3.4 Exploitation
The coding of MSRPC Application Data is MIDL. This is quite an messy and very diverse
structure that basically describes the arguments passed to the remote procedure.

For the 8 uncontrolled bytes in the beginning we can choose any function where its first argument
is string(maybe pointer in general). This is because an 8-bytes field (in the case of 64-bit
implementation) called ReferentId is present, where the destination server is indifferent to its value.

As for the freedom bytes, it wouldn’t have been much of a problem anyway, but RPC ignores
excessive bytes, so it is easiest to put them all at the end.

The exploit uses the following function (Opnum 1) of the Task Scheduler Interface:

Figure 7 - The exported function

The Task Scheduler Interface is the modern interface for managing scheduled tasks in windows.
It is similar to the ATSvc interface (triggered by the AT command), but is more powerful, as it
provides more control over the created task and its properties.

This is an example for the command that is coded in the exploit:

 12

This command creates a task with user id of SYSTEM5. The executable is found in a share
controlled by the attacker, and it is run immediately. Therefore, it could be any stale code. So,
there is no need to do privilege escalation if the user is already an Administrator.

3.5 Real World Obstacles

Finally, we consider some real world obstacles. While doing MITM, in many cases, is not that
difficult for an attacker (for example through ARP Poisoning), the real obstacle here is Windows
Firewall. If it is ON, then on a regular modern OS, incoming RPC is not enabled by default for
any interface6.

Despite this, the vulnerability and threat is still very much real, and applying the patch is
important. Because of the following reasons:

1. Domain Controllers are still vulnerable to this attack by default. This is because a rule
concerning RPC exists in Domain Controllers that enables any svchosts.exe DCOM
interfaces. Furthermore, a quick survey found that RDP is the most common way in which
domain admins tends to access the DC. In other words, by exploiting this attack, an attacker
is likely to gain a full control over the domain!

2. Many times, Windows Firewall is turned OFF or RPC is enabled extensively (It is
recommended to enable it selectively for the services you need)

3. It could be exploited in various ways, bypassing different possible defences in various

environments. Not only using different interfaces of MSRPC, but also exploiting different
protocols7. (If you manage to, we would like to know)

In the scenario described in the beginning, the remote desktop session would fail with the
following message after a few seconds:

Figure 8: Error message displayed after RDP

5 given local administration privileges, that should work

6 Verified on Windows Server 2012 and Windows 10
7 If you manage to create another exploitation, please let us know. Databases seems like a really strong
target.
 13

And a malicious payload would run silently on the server in a privileged context. Other than this,
no warning or suspicious indication will be present.

4 Summary
In this paper, we have laid out the details for an attack on MS-RDP with the Task Scheduler
Interface as the destination. This attack has nearly 100% success given a server with RPC
enabled. And assuming an attacker is capable of doing MITM.

Hopefully you found this vulnerability interesting. Apparently, strong protocol-based logical
vulnerabilities haven’t passed from the world. I think this vulnerability stresses the importance
of identity validation as soon as possible and strictly before signing any data. The issue brought
here of public key signing might be something to look for in general.

You can see the demo of the attack here:

The author wishes to thank Yaron Zinar, Preempt Research Team Lead, for the support and
guidance along the way, as well as on help in writing this paper. And also to Heather Howland,
VP Marketing, and to Wade Williamson, Product Marketing for all their assistance regarding this
paper.

We intend to release the tools used for the exploit after we present at Black Hat Asia later in
March 2018.

-------------------

5 Reference / Technical Background

Unfortunately, this vulnerability tends to be quite evolved. The technical background section is
given as a reference for completing the required knowledge for this vulnerability.

Kerberos in Active Directory

Kerberos is the basic authentication protocol in Active Directory Environment. It is used by

default (in case you refer to a server by DNS) and is considered secure and trusted.

Basically, it provides authenticity and SSO across the entire Windows domain, by relaying on
shared secrets found on DCs (Domain Controllers). DCs are the trusted entities that manages
the domain. Compromising a DC (or a special account called KRBTGT) would result in complete
compromise of the domain.
 14

There are many sites that explains how kerberos works. Although the most of the details
wouldn’t be relevant for our vulnerability, it would be nice to get the overall picture:
https://redmondmag.com/articles/2012/02/01/understanding-the-essentials-of-the-kerberos-
protocol.aspx

NTLM (Network LAN Manager)

NTLM is a legacy protocol used for authentication in Active Directory Environment. It is still used
quite widely today, mainly in scenarios where there is no domain trust , and in legacy software.

This is an old style challenge-response protocol. The important variant is version 2, providing
some protection against some attacks. It is not resilient for NTLM relay attack in case there is no
additional protection from relay such as server signing or EPA.

But you might find more details here:

https://en.wikipedia.org/wiki/NT_LAN_Manager

https://blog.preempt.com/new-ldap-rdp-relay-vulnerabilities-in-ntlm - Actually, it is good source

to learn about ntlm relay from

SSPI (Security Support Provider Interface)

SSPI is an API that allows application to add authenticity and authorization almost transparently
(Although some pain might be involved). Any application that supports “Windows Authentication”
as a provider also support SSPI. For example: “Microsoft SQL Server​”

Essentially, that means that it supports the security providers offered by Windows (Again, this
is transparent to the application). It is implemented as a layer over the application protocol. The
data that is protected using SSPI is called (at least in this blog) Application Data.

Among the providers you could find : NTLM, Kerberos as well as SPNEGO. SPNEGO is used
to negotiate over the chose the authentication protocol (some variant of NTLM or Kerberos
usually), which will be used to derive keys for encrypting and/or signing the session data.

PKI

It is the infrastructure that makes sure that the identity of entities is reliable. It does so based on
commonly trusted entities called CAs , and on digital signatures. https://en.wikipedia.org/wiki/
Public_key_infrastructure
 15

RSA

9 It can be formulated more meticulously

10 By multiplying two numbers from this group (co-prime to N) you get a number still in this group
 16

MS-RDP

Microsoft Remote Desktop Protocol is a protocol used to remotely control another computer.
Mostly, the user has to type its username and password in order to connect.

MS-RDP offers a Restricted Admin mode that is used when an administrator can use its
credentials to connect to another computer seamlessly. This mode is considered more secure
(although it has its limitations).

Microsoft even suggested to use it in situation where you suspect the destination machine is
compromised: https://docs.microsoft.com/en-us/windows/security/identity-protection/remote-
credential-guard

For helpdesk support scenarios in which personnel require administrative access to provide
remote assistance to computer users via Remote Desktop sessions, Microsoft recommends
that Windows Defender Remote Credential Guard should not be used in that context. This is
because if an RDP session is initiated to a compromised client that an attacker already controls,
the attacker could use that open channel to create sessions on the user’s behalf (without
compromising credentials) to access any of the user’s resources for a limited time (a few hours)
after the session disconnects.

Therefore, we recommend instead that you use the Restricted Admin mode option.

MSRDP is vulnerable to the attack we will describe as it relies on a vulnerable protocol

CredSSP for the authentication. The restricted admin mode is vulnerable as well.

preempt.com Preempt protects organizations by eliminating security threats. Threats are not black or white
and the Preempt Platform is the only solution that preempts threats with continuous threat
info@preempt.com prevention that automatically adapts based on identity, behavior and risk. This ensures that both
security threats and risky employee activities are responded to with the right level of security at the
© 2018 Preempt Security, Inc. right time. The platform easily scales to provide comprehensive identity based protection across
All rights reserved. organizations of any size.