{"vuid":"VU#465632","idnumber":"465632","name":"Microsoft Exchange server 2013 and newer are vulnerable to NTLM relay attacks","keywords":["PrivExchange"],"overview":"Microsoft Exchange 2013 and newer fail to set signing and sealing flags on NTLM authentication traffic, which can allow a remote attacker to gain the privileges of the Exchange server.","clean_desc":"Microsoft Exchange supports a API called Exchange Web Services(EWS). One of the EWS API functions is called PushSubscriptionRequest,which can be used to cause the Exchange server to connect to an arbitrary website. Connections made using the PushSubscriptionRequest function will attempt to negotiate with the arbitrary web server using NTLM authentication. Starting with Microsoft Exchange 2013,the NTLM authentication over HTTP fails to set the NTLM Sign and Seal flags. The lack of signing makes this authentication attempt vulnerable to NTLM relay attacks. Microsoft Exchange is by default configured with extensive privileges with respect to the Domain object in Active Directory. Because the Exchange Windows Permissions group has WriteDacl access to the Domain object,this means that the Exchange server privileges obtained using this vulnerability can be used to gain Domain Admin privileges for the domain that contains the vulnerable Exchange server.","impact":"An attacker that has credentials for an Exchange mailbox and also has the ability to communicate with both a Microsoft Exchange server and a Windows domain controller may be able to gain domain administrator privileges. It is also reported that an attacker without knowledge of an Exchange user's password may be able to perform the same attack by using an SMB to HTTP relay attack as long as they are in the same network segment as an Exchange user.","resolution":"Apply an update This issue is mitigated by the Microsoft Exchange updates for CVE-2019-0686. This update will cause the Exchange server to not attempt NTLM authentication with hosts that it contacts as the result of a PushSubscriptionRequest API call. The versions of Exchange that contain this fix include: Exchange Server 2010 Service Pack 3 Update Rollup 26\nExchange Server 2013 Cumulative Update 22\nExchange Server 2016 Cumulative Update 12\nExchange Server 2019 Cumulative Update 1 These updates also include the fix for CVE-2019-0724, which removes some of the unnecessary privileges that are granted to an Exchange server in a default installation. This is a defense-in-depth update that can help mitigate the impact of exploitation of this vulnerability.","workarounds":"Disable EWS push/pull subscriptions If you have an exchange server that does not leverage EWS push/pull subscriptions, you can block the PushSubscriptionRequest API call that triggers this attack. In an Exchange Management Shell window, execute the following commands: New-ThrottlingPolicy -Name NoEWSSubscription -ThrottlingPolicyScope Organization -EwsMaxSubscriptions 0\nRestart-WebAppPool -Name MSExchangeServicesAppPool Remove privileges that Exchange has on the domain object Please note that the following workaround was not developed by CERT and is not supported by Microsoft. Please test any workarounds in your environment to ensure that they work properly. https://github.com/gdedrouas/Exchange-AD-Privesc/blob/master/DomainObject/Fix-DomainObjectDACL.ps1 is a PowerShell script that can be executed on either the Exchange Server or Domain Controller system. By default this script will check for vulnerable access control entries in the current active directory. When executed with Domain Admin privileges and the -Fix flag, this script will remove the ability for Exchange to write to the domain object. Note that if you encounter an error about Get-ADDomainController not being recognized, you will need to install and import the ActiveDirectory PowerShell module, and then finally run Fix-DomainObjectDACL.ps1 : Import-Module ServerManager\nAdd-WindowsFeature RSAT-AD-PowerShell\nImport-Module ActiveDirectory\n.\\Fix-DomainObjectDACL.ps1 If the script reports that faulty ACE were found, run: .\\Fix-DomainObjectDACL.ps1 -Fix PowerShell may be configured to block the execution of user-provided .ps1 files. If this is the case, first find your current PowerShell execution policy: Get-ExecutionPolicy\nTemporarily allow the execution of the Fix-DomainObjectDACL.ps1 script by running: Set-ExecutionPolicy unrestricted\nOnce you are finished running the Fix-DomainObjectDACL.ps1script, set the policy back to the original value as reported by Get-ExecutionPolicy: Set-ExecutionPolicy [POLICY] Consider additional workarounds The blog post for this vulnerability contains several mitigations that may also help protect against this and similar vulnerabilities.","sysaffected":"","thanks":"This vulnerability was publicly disclosed by Dirk-jan Mollema.","author":"This document was written by Will Dormann.","public":["https://dirkjanm.io/abusing-exchange-one-api-call-away-from-domain-admin/","https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190007","https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0686","https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0724","https://www.thezdi.com/blog/2018/12/19/an-insincere-form-of-flattery-impersonating-users-on-microsoft-exchange","https://docs.microsoft.com/en-us/dotnet/api/microsoft.exchange.webservices.data.pushsubscription?view=exchange-ews-api+","https://docs.microsoft.com/en-us/exchange/client-developer/web-service-reference/pushsubscriptionrequest","https://docs.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/dd877045(v%3Dexchg.140)","https://msdn.microsoft.com/en-us/library/cc236702.aspx","https://msdn.microsoft.com/en-us/library/cc236707.aspx"],"cveids":["CVE-2019-0686"],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2019-01-26T20:34:25Z","publicdate":"2019-01-21T00:00:00Z","datefirstpublished":"2019-01-28T22:43:44Z","dateupdated":"2019-06-21T20:21:43Z","revision":48,"vrda_d1_directreport":"0","vrda_d1_population":"4","vrda_d1_impact":"4","cam_widelyknown":"0","cam_exploitation":"0","cam_internetinfrastructure":"0","cam_population":"0","cam_impact":"0","cam_easeofexploitation":"0","cam_attackeraccessrequired":"0","cam_scorecurrent":"0","cam_scorecurrentwidelyknown":"0","cam_scorecurrentwidelyknownexploited":"0","ipprotocol":"","cvss_accessvector":"A","cvss_accesscomplexity":"L","cvss_authentication":null,"cvss_confidentialityimpact":"C","cvss_integrityimpact":"C","cvss_availabilityimpact":"C","cvss_exploitablity":null,"cvss_remediationlevel":"W","cvss_reportconfidence":"C","cvss_collateraldamagepotential":"ND","cvss_targetdistribution":"H","cvss_securityrequirementscr":"ND","cvss_securityrequirementsir":"ND","cvss_securityrequirementsar":"ND","cvss_basescore":"8.3","cvss_basevector":"AV:A/AC:L/Au:N/C:C/I:C/A:C","cvss_temporalscore":"7.5","cvss_environmentalscore":"7.5176549591808","cvss_environmentalvector":"CDP:ND/TD:H/CR:ND/IR:ND/AR:ND","metric":0.0,"vulnote":null}