About a week ago a very interesting proof of concept tool and blog post were published by security researcher Dirk-jan Mollema (@_dirkjan), which you can read at here. Now folks, this is HUGE. Extremely huge. If you are running Exchange make sure that you read this diary and the original blog. Basically, the PoC tool exploits the fact that Exchange servers have very high privileges in Active Directory domains – the WriteDacl privilege that allows them to change domain privileges. Exchange servers are part of the Exchange Trusted Subsystem group, which is further included in the Exchange Windows Permissions group which has this critical privilege enabled. The issue is in Exchange Web Services (EWS) PushSubscription service, specifically PushSubscriptionRequest method that allows a user to subscribe for push events. The user specifies the location of the client Web service for push notifications. In other words, once an event happens, the Exchange server will connect to the URL specified in the call to the PushSubscriptionRequest method. Now, once a subscription has been created, relaying is the final step. The Exchange server will now try to connect to the attacker’s machine (the URL specified in the subscription) and will happily pass NTLM credentials. These can be then relayed to a Domain Controller (provided there is no SMB signing – see below for mitigations). Dirk-jan’s exploit relays the credentials to LDAP in order to escalate a user’s privilege: it adds the Replication-Get-Changes-All privilege to an account effectively allowing that account to perform any actions on the domain, including dumping all passwords from a Domain Controller by performing DCSync. With hashes of all users, the attacker can further impersonate any other user and takeover the complete domain. Running the exploit is very simple - once the subscription is created, Exchange connects to the supplied URL as shown in the figure below: Now, the biggest issue here is that this works with the latest version of Exchange, fully patched. Various versions are listed on the original blog, I tested with a fully patched version of Exchange 2016. Note that the deletion of registry key as specified in Microsoft’s advisory for CVE-2018-8581 does not fix this vulnerability! It prevents a malicious user from impersonating another user on the Exchange server, but not on a Domain Controller, through LDAP. Additionally, I have installed patches on an Exchange 2016 servers, and the registry key was not removed (even though Microsoft’s advisory says that they will remove it). The best mitigation options as far as we are aware of are the following:
Of course, be very careful when modifying any of the settings above to make sure that you will not break your Exchange deployments. Finally, the exploit does not work on Exchange 2010 which has signing enabled by default, but this setting does not exist in Exchange 2013, 2016 or 2019. Go figure :/ UPDATE 1: Here's a bit more information about detection of the vulnerability:
Thanks to all readers for great and useful comments. We’ll continue researching the issue – if you have any new or information to share - let us know! I will be teaching next: Web App Penetration Testing and Ethical Hacking - SANS Pen Test Hackfest Europe 2022 - Berlin |
Bojan 402 Posts ISC Handler Jan 29th 2019 |
Thread locked Subscribe |
Jan 29th 2019 3 years ago |
Yes this is huge.
Pentesters doing internal pentests right now are really lucky ;) Thanks for this post ! Not a lot of media coverage for this (why ??) so I'm glad you're talking about this beauty. Monitoring AD "5136" events for a few GUID can help you to detect successful attempts of the PoC as explained here: http://blog.randorisec.fr/privexchange-from-user-to-domain-admin-in-less-than-60sec/ Davy |
Anonymous |
Quote |
Jan 29th 2019 3 years ago |
Thanks Davy!
Good catch on the event, indeed monitoring for 5136 can catch the relay. As far as I can see the usernames are not directly visible (instead it logs SID's) but still such events should not happen too often - especially not coming from the Exchange server (since this is what will be logged as the Account Name). Thanks, Bojan |
Bojan 402 Posts ISC Handler |
Quote |
Jan 29th 2019 3 years ago |
You can also monitor for logins to AD with Exchange servers' computer account, e.g., EXCHANGE1$ with NTLM authentication.
If you have an ADC/load balancer, you can drop all connections that send a POST /EWS/ with privexchange.py's push subscription XML data. |
Anonymous |
Quote |
Jan 29th 2019 3 years ago |
We were looking at this yesterday. Exchange 2010 SP3, at least in our implementation, appears to be vulnerable. When we specified --exchange-version 2010_SP2 the CAS server made an outbound connection (as the CAS server computer account) and I was able to relay that to LDAP.
I thought the exploit had succeeded (PCAP showed successful LDAP bind), but after emailing Dirk-jan Mollema it looks like subsequent queries may have failed due to previously setting the registry entries for CVE-2018-8518. Still, with the potential impact if exploited it's probably a bad idea to not mitigate this for Exchange 2010. |
Anonymous |
Quote |
Jan 29th 2019 3 years ago |
"Finally, the exploit does not work on Exchange 2010 which has signing enabled by default, but this setting does not exist in Exchange 2013, 2016 or 2019. Go figure :/" I am struggling with this can you or Microsoft respond with the vulnerable versions? Does this mean 2007 and older are vulnerable or a misconfiguration in 2010 could make you vulnerable?
|
Anonymous |
Quote |
Jan 29th 2019 3 years ago |
Regarding affected versions:
- Exchange 2013, 2016 and 2019 have been confirmed as vulnerable - Exchange 2010 apparently has signing enabled so NTLM relaying should not work. I haven't tested this as I don't have Exchange 2010 handy - Exchange 2007 is unknown status, however according to the documentation, it does support the PushSubscriptionRequest method so it could be affected. I'll see about updating the diary as we get more information. Bojan |
Bojan 402 Posts ISC Handler |
Quote |
Jan 29th 2019 3 years ago |
With the value deleted per https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8581 the PoC seems to yield a false positive. Is this the removal of the value working, or another mitigation that may be in place? Can we confirm the PoC should work with the value removed?
|
Anonymous |
Quote |
Jan 30th 2019 3 years ago |
From the testing I did with Exchange 2016, removing the registry key did not help in preventing the attack.
I updated Exchange to the latest patch level and noticed that the registry key was not removed. Then I deleted it manually, but the exploit still worked. My understanding is that it prevents "reflection" attacks where you use NTLM relaying against the Exchange itself. Bojan |
Bojan 402 Posts ISC Handler |
Quote |
Jan 30th 2019 3 years ago |
From my tests I noticed you can monitor for the POC exploit use by checking Event ID 4662 to check for when a user accesses the control {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} (DS-Replication-Get-Changes-All). This event will also show the actual user involved. There are sometimes machine names in the Account Name but you can filter that out by removing entries with $ sign at the end.
Sample log: Subject : Security ID: testdomain\testuser Account Name: testuser Account Domain: testdomain Logon ID: 0x26BB12 Object: Object Server: DS Object Type: domainDNS Object Name: DC=testdomain,DC=com Handle ID: 0x0 Operation: Operation Type: Object Access Accesses: Control Access Access Mask: 0x100 Properties: Control Access {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} {19195a5b-6da0-11d0-afd3-00c04fd930c9} ~Jovsky |
Jovsky 1 Posts |
Quote |
Jan 31st 2019 3 years ago |
MS Advisory ADV190007 reports that Exchange 2010 SP3 RU26 is vulnerable.
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190007 |
Jed 1 Posts |
Quote |
Feb 7th 2019 3 years ago |
Sign Up for Free or Log In to start participating in the conversation!