From Public Key to Exploitation: Exploiting the Authentication in MS-RDP [CVE ]

Transcription

1 From Public Key to Exploitation: Exploiting the Authentication in MS-RDP [CVE ] Eyal Karni, Preempt Research Team

2 Contents 1. Introduction Vulnerability Issue # Toward Issue # Issue # Exploitation Broken RSA Finding Primes Finding Protocols Exploitation Real World Obstacles Summary Reference/Technical Background...9

3 3 1. Introduction In March 2018 Patch Tuesday, Microsoft released a patch for CVE , 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 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: 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 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 case here. We will call this issue #1. Figure 2 - A standard MS-RDP warning

5 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 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 secret 1 ). 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 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 8

9 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.1 2. 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 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 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 12 This command creates a task with user id of SYSTEM 5. 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 interface 6. 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 protocols 7. (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 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 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 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: 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: 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. Public_key_infrastructure

15 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 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: 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 info@preempt.com 2018 Preempt Security, Inc. All rights reserved. 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 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 right time. The platform easily scales to provide comprehensive identity based protection across organizations of any size.