Technical findings: CVE-2019-0686
Microsoft Exchange Server 2010 SP3 UR26
Microsoft Exchange Server 2013 CU22
Microsoft Exchange Server 2016 CU12
Microsoft Exchange Server 2019 CU1
-Microsoft Exchange Server is affected by a elevation of privilege vulnerabilities. An attacker who successfully exploits the vulnerability may impersonate any other user of the Exchange server.
-To exploit this vulnerability, an attacker would need to execute a man-in-the-middle attack to forward an authentication request to a Microsoft Exchange Server, thereby allowing impersonation of another Exchange user.
The attack relies on two key components to be successful:
-Firstly, it relies on utilizing a man-in-the-middle attack against Exchange Server to perform an NTLM relay attack. In essence, this relies on an attacker intercepting the authentication process. This in itself isn’t an Exchange vulnerability, but as Exchange uses NTLM over various HTTP channels, it makes it susceptible to exploit.
NTLM :-NTLM is a challenge/response-based ol Microsoft authentication protocol, Using NTLM, users might provide their credentials to a bogus server.when a client authenticates to a server using NTLM, it cannot validate the identity of the server. This means that a malicious actor with man-in-the-middle capabilities could send the client fake/malicious data while impersonating the server.
-The second component of this vulnerability relates to the ability of an attacker to force Exchange to attempt to authenticate as the computer account. To do this, the attacker can use Exchange Web Services to force Exchange Server to make a new outbound HTTP call that uses NTLM to attempt to authenticate against an arbitrary URL via the EWS Push Subscription feature.
Instead of NTLM , kerberos protocol is preferred to avoid NTLM Relay attack
Conclusion of this vulnerability: This could allow the attacker to perform activities such as accessing the mailboxes of other users. Till far no active exploitation seen.
Some Questions people are asking about this vulnerability
-Is this Exchange vulnerability exploitable from outside their network?
Active and successful exploitation is not seen so far, but yes its possible remotely. It can be exploited via Man in the middle attack, if the exchange server and DC were some how accessed externally.
-To exploit this vulnerability Exchange server and the Domain Controller would have to be externally accessible for a remote attacker to leverage the exploit via MiTM(Man in the middle attack process).
-Can external scanning tools detect this vulnerable?
Personally I am not aware of any Exploit scanning tool, which can find current running exchange version number. But there are ways which can be leveraged to find the running Exchange server version number, if that's the case then yes remote attackers can detect the vulnerability.
If on-prem Exchange server of an organization is using MAPI over HTTP . you can use the following URL to check which version of Exchange is running on the server hosting your mailbox:
For Office 365 use https://outlook.office.com/mapi/emsmdb/
The bad thing about this method is that even works externally as long as Outlook Anywhere is published to the Internet.
Solution / Mitigation:
- Guidance for "PrivExchange" Elevation of Privilege Vulnerability by Microsoft
To address this vulnerability, a Throttling Policy for EWSMaxSubscriptions could be defined and applied to the organization with a value of zero. This will prevent the Exchange server from sending EWS notifications, and prevent client applications which rely upon EWS notifications from functioning normally. Examples of impacted applications include Outlook for Mac, Skype for Business, notification reliant LOB applications, and some iOS native mail clients. Please see Throttling Policy, for more information
- Remove the unnecessary high privileges that Exchange has on the Domain object.
- Enable Lightweight Directory Access Protocol (LDAP) signing and enable LDAP channel binding to prevent relaying to LDAP and LDAPS respectively.
- Block Exchange servers from making connections to workstations on arbitrary ports.
- Enable Extended Protection for Authentication on the Exchange endpoints in IIS (but not the Exchange Back End ones, this will break Exchange). This will verify the channel binding parameters in the NTLM authentication, which ties NTLM authentication to a TLS connection and prevent relaying to Exchange web services.
- Remove the registry key which makes relaying back to the Exchange server possible, as discussed in Microsoft’s mitigations.
- Enforce SMB signing on Exchange servers (and preferable all other servers and workstations in the domain) to prevent cross-protocol relay attacks to SMB.
Some useful links for your reference:
Author : Rajat Bajpai
Rajat Bajpai has done Master in Engineering in Information and Network Security from University of Limerick. He is having approx 2 years of experience and currently working with University of Limerick as a SOC Analyst.
His job as a security Analyst involves him in dealing with day to day cyber attacks and exploits.
Attacks and exploits keep on changing and attackers keep modifying their attack patterns and attack vectors. In-order to deal with such attacks, Rajat keep updating himself and act as first line of defense against all such attacks.