Remote Code Execution vulnerability in Microsoft Intune managed Windows devices

Aapo Oksman, is a Senior Security Specialist at Nixu Corporation, working with application, protocol and device security with a focus on industrial IoT. His background is in electrical engineering, embedded devices, and test automation. Combining his background with a hobby in hacking lead to a natural career shift to cybersecurity. In his free time, Bug Bounties and CTFs keep Aapo motivated and learning, but he is more interested in developing the tools and making the challenges than actually solving them. Aapo has gained professional and Bug Bounty success with his work in PKI and TLS, resulting in multiple CVEs in notable products from Microsoft and Apple.

Summary

A bug in the Transport Layer Security (TLS) certificate validation code in the Microsoft Intune Management Extension (IME) allows for a remote attacker in privileged network position to execute arbitrary code with system privileges on the Windows operating system enrolled into Intune running IME. Microsoft has released a security advisory for the vulnerability: CVE-2021-31980.

This vulnerability does not rely on any user interaction as IME runs automatically on system boot and every hour. The vulnerability can be exploited even without the user logging in as IME runs as a system service at boot before the user logs in. An attacker can run any PowerShell commands with system privileges through a Man-in-the-Middle attack. For example, they can install malicious programs to the machine. Additionally, they can bypass Microsoft Bitlocker if the machine is configured to boot into Windows without a pin code or other additional authentication.

The affected version is Microsoft Intune Management Extension 1.40.200.3 and before. The vulnerability was fixed in version 1.41.203.0 that is dated 2021-03-24. The IME automatically updates itself without any user action when the computer is connected to internet.

Computers taken out of use before 2021-03-24 or not connected to internet after 2021-03-23 might still run the vulnerable version on startup. In these cases, an attacker with access to the hardware could gain access to their contents by starting the machine and bypassing the Bitlocker security by exploiting the vulnerability. It is advisable that machines running IME version below 1.41.203.0 are updated to a fixed version.

Additionally, some computers have not received the automatic update even when connected to the Internet. Nixu has been researching possible reasons for this and recommends that companies using Intune with IME check the versions running on their systems for IME versions prior to 1.41.203.0.

Background

Intune

“Microsoft Intune is a cloud-based service that focuses on mobile device management (MDM) and mobile application management (MAM). You control how your organization’s devices are used, including mobile phones, tablets, and laptops. You can also configure specific policies to control applications. For example, you can prevent emails from being sent to people outside your organization. Intune also allows people in your organization to use their personal devices for school or work. On personal devices, Intune helps make sure your organization data stays protected, and can isolate organization data from personal data.”

“Intune is part of Microsoft's Enterprise Mobility + Security (EMS) suite. Intune integrates with Azure Active Directory (Azure AD) to control who has access, and what they can access. It also integrates with Azure Information Protection for data protection. It can be used with the Microsoft 365 suite of products. For example, you can deploy Microsoft Teams, OneNote, and other Microsoft 365 apps to devices. This feature enables people in your organization to be productive on all of their devices, while keeping your organization’s information protected with policies you create.”

Microsoft Intune Management Extension (IME) is installed on a managed Windows device automatically when a PowerShell script or Win32 app is assigned to the user or device. For more information about IME, see: https://docs.microsoft.com/en-us/mem/intune/apps/intune-management-extension

Transport Layer Security

“Transport Layer Security, or TLS, is a widely adopted security protocol designed to facilitate privacy and data security for communications over the Internet. A primary use case of TLS is encrypting the communication between web applications and servers, such as web browsers loading a website.”

For detailed descriptions of attacks on TLS, check the authors talk “Practical attacks against modern TLS implementations - Aapo Oksman - HelSec Virtual Meetup”.

Description of the vulnerability

Microsoft Intune is a remote management system for devices. Intune allows for running arbitrary PowerShell scripts on managed devices through Intune Management Extension (IME) installed on the device. IME is installed automatically if PowerShell scripts are specified to be run on the device. More details.

IME connects to the Microsoft Endpoint Manager (manage.microsoft.com) and fetches scripts to be executed on the device. IME then executes these scripts.

IME connects to manage.microsoft.com using HTTP protocol inside a TLS envelope (HTTPS). This is a standard way of securing web traffic. TLS is used for authenticating a remote server and then establishing an encrypted connection to it. The server is authenticated by validating its certificate against multiple criteria. For example, who has issued the certificate, who the certificate issued to, can the server prove ownership of the certificate, etc. If the certificate is not validated correctly, a network attacker between the victim and the server can intercept the connection and pose as the server by obtaining or generating a certificate that the victim accepts. The attacker can then forward the communication to the real server and tamper with it.

IME fails to validate the server certificate for manage.microsoft.com properly. Any certificate is treated by the IME as a valid one for any server on certain parts of the application. Some of the parts happen to be responsible for querying and fetching the PowerShell scripts to be executed. This allows for a suitably positioned attacker to tamper with the scripts while they are being downloaded. This also allows the attacker to run any arbitrary PowerShell commands with system privileges on the victim machine.

The IME application is written in C#. This allows for easy decompilation of the vulnerable code. The JetBrains decompiler was used to decompile the application.

The CertificateHelper is used to provide an additional CertificateValidation function if the operating system cannot verify the server certificate. This function also allows for debugging the application by setting the SslPolicyErrors argument to SslPolicyErrors. None. The Helper is used to ensure that some certificates are accepted even when the operating system does not want to validate the certificate, essentially to ensure that IME can securely connect to Microsoft regardless of the certificate handling configured in the system.

Unfortunately, the code is riddled with errors.

1. The code checks if the certificate is signed by a certificate from a root certificate with a certain SHA1 Thumbprint.
   • The SHA1 hash D4DE20D05E66FC53FE1A50882C78DB2852CAE474 is for the Baltimore CyberTrust Root. However, SHA1 has been deprecated and should not be used to identify the root certificate.
2. The code does not check if the certificate is actually signed by the Baltimore CyberTrust Root CA.
   • An attacker can craft a certificate chain with the Baltimore CyberTrust Root CA and an attacker generated certificate. The code only checks the last element of the chain (the root CA) without validating that the chain is properly constructed of certificates signed by each other.
3. The code always returns true.
   • The code should only return true on the line 42 of the decompilation when all the checks have passed. However, the code returns true also on the line 47 of the decompilation if the checks fail.

This can be seen in the IME logs when a connection is made and the certificate validation fails but the application continues with the connection.

With this information we can actually exploit the application. This can be achieved by intercepting the TLS connections from IME and presenting any certificate for it. This can be done with proxy tools such as sslsplit or Burp Suite simply by setting the proxy to intercept the TLS traffic with self-signed certificates.

By examining traffic from IME, it seems that IME fetches the powershell scripts (or policies) form a subdomain of manage.microsoft.com. The response contains the hash of the policy, but no signature data to verify the authenticity of the PowerShell scripts. This suggests that the scripts could be modified simply by replacing the original hash with the hash of the modified script.

The hashing algorithm is not obvious, but it could be reverse engineered from the application. However, the IME logs are quite verbose.

The logs reveal that the correct hash for the modified script should be ndzdbt249rLnFE7opKvMiYgvcpVu14UvDlI/FR6dTtA=

By setting this as the policy hash, we observe that the script is executed successfully as a system user.

This proof-of-concept shows that remote attackers can run code with system privileges on a Windows machine by intercepting the TLS connections. This vulnerability could be exploited to install malware to the victim’s machine to take persistent full control over it.

Microsoft released a fix for the vulnerability. This fix removes the code that that would try to validate the certificate and only checks for the debug state. If the application is not in debug state, the CertificateHelper returns false to indicate that the certificate is not to be trusted.

Exploitation

The exploitation of the vulnerability requires that the attacker can first intercept the traffic from the victim computer. Due to the nature of TCP/IP protocol and the internet, this is not hard to achieve. The TLS protocol should normally protect the application network traffic from tampering. However, in this case the vulnerability allows for the attacker to break the TLS connection.

For example, an attacker could attack the victim in the following scenarios:

1. An attacker steals a physical laptop that is protected with Bitlocker.
   • The attacker can power the laptop on and use the vulnerability to gain access to the stolen laptop and all its files.
2. The victim uses the same WIFI connection as the attacker.
   • For example, if the victim uses the WIFI or network connection of a public place such as a cafe. The attacker could use multiple different methods to intercept the connections. For example: ARP-spoofing or a rogue access point.
3. The attacker broadcasts an open or a common public WIFI access point.
   • Many computers connect automatically to access points that they recognize. For example, the attacker could mimic the WIFI access point of a local train or a coffee chain.
4. The attacker hijacks a VPN server, a proxy server or host their own TOR exit node.
   • The attacker could infiltrate a VPN server of a company and then use the vulnerability to move laterally in the company to all Windows devices using the VPN.
5. A malicious network provider or an attacker in an ISP network could target tens of thousands of users simultaneously.
6. A country could intercept connections passing through its borders to attack foreign users.
   • This way the attacker could install malicious software potentially on hundreds of thousands of computers or high-profile targets.

Timeline

2021-03-20 – The vulnerability is discovered by Aapo Oksman
2021-03-21 – The vulnerability is disclosed to Microsoft through the Microsoft Security Response Center Researcher Portal
2021-03-24 – The vulnerability is fixed by Microsoft and released to be automatically updated
2021-03-30 – The fix is verified by Aapo Oksman
2021-06-08 – The CVE id CVE-2021-31980 is assigned to the vulnerability by Microsoft
2021-06-29 – The technical details of the vulnerability are publicly disclosed by Aapo Oksman

Additional materials and references

TLS and Man in the Middle Attacks from YouTube:
Secure Web Browsing - Computerphile
Transport Layer Security (TLS) - Computerphile
TLS Handshake Explained – Computerphile
Man in the Middle Attacks & Superfish - Computerphile

Scientific publications:

• Georgiev, Martin, et al. "The most dangerous code in the world: validating SSL certificates in non-browser software." Proceedings of the 2012 ACM conference on Computer and communications security. 2012.
• Akhawe, Devdatta, et al. "Here's my cert, so trust me, maybe? Understanding TLS errors on the web." Proceedings of the 22nd international conference on World Wide Web. 2013.
• Huang, Lin Shung, et al. "Analyzing forged SSL certificates in the wild." 2014 IEEE Symposium on Security and Privacy. IEEE, 2014.
• Brubaker, Chad, et al. "Using frankencerts for automated adversarial testing of certificate validation in SSL/TLS implementations." 2014 IEEE Symposium on Security and Privacy. IEEE, 2014.
• Onwuzurike, Lucky, and Emiliano De Cristofaro. "Danger is my middle name: experimenting with SSL vulnerabilities in Android apps." Proceedings of the 8th ACM Conference on Security & Privacy in Wireless and Mobile Networks. 2015.
• Sivakorn, Suphannee, et al. "HVLearn: Automated black-box analysis of hostname verification in SSL/TLS implementations." 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 2017.
• Chau, Sze Yiu, et al. "Symcerts: Practical symbolic execution for exposing noncompliance in X. 509 certificate validation implementations." 2017 IEEE Symposium on Security and Privacy (SP). IEEE, 2017.
• Durumeric, Zakir, et al. "The Security Impact of HTTPS Interception." NDSS. 2017.