An Insincere Form of Flattery: Impersonating Users on Microsoft Exchange
December 19, 2018 | The ZDI Research TeamThis is the third in our series of Top 5 interesting cases from 2018. Each of these bugs has some element that sets them apart from the approximately 1,400 advisories released by the program this year. Today we look at an Exchange bug that allows any authenticated user to impersonate anyone else on Exchange Server.
In his December patch blog, ZDI’s Dustin Childs mentioned an Exchange bug that allowed anyone on an Exchange server to impersonate anyone else on that Exchange server. While this bug certainly could be used for some interoffice hijinks, it’s much more likely that this vulnerability would be used in a spear phishing campaign, data exfiltration, or other malware operation. As a part of our Top 5 of 2018 series, this blog delves into the details of this fascinating Server Side Request Forgery (SSRF) vulnerability and shows how this impersonation takes place.
The Vulnerability
This impersonation occurs due to a SSRF vulnerability when combined with other weaknesses. Exchange allows any user to specify a desired URL for Push Subscription, and the server will attempt to send notifications to this URL. The issue exists because Exchange server uses CredentialCache.DefaultCredentials for the connection:
Within Exchange Web Services, CredentialCache.DefaultCredentials runs at NT AUTHORITY\SYSTEM. This causes the Exchange Server to send NTLM hashes to the attacker’s server.
Exchange server also has the following registry key set by default:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck = 1
This allows us to use these NTLM hashes for HTTP authentication. For example, it’s possible to use these hashes to access Exchange Web Services (EWS). Since it is running at the NT AUTHORITY\SYSTEM level, an attacker can get “privileged” session with TokenSerializationRight and would then be able to use a SOAP header to impersonate any desired user.
Here’s an example of such a SOAP header that impersonates the Administrator user with the SID of S-1-5-21-4187549019-2363330540-1546371449-500:
The Exploit
For this demonstration, we’ll be using a couple of Python scripts:
serverHTTP_relayNTLM.py – That takes NTLM hashes from inbound connection and uses them for EWS authentication
Exch_EWS_pushSubscribe.py – Causes the PushSubscription EWS call with URL to our serverHTTP_relayNTLM.py
You can download these scripts here. You’ll also need the python-ntlm module.
The first step in this exploit involves getting the SID of the person we want to impersonate. One possible method to use goes something like this:
1 - Log in to OWA as an authorized user. In this case, we log on as “attacker”:
2 - Next, create any new folder. We use tempFold in this example. Click on “Permissions…” item in context menu:
3 - Here, add the email of the person to impersonate. In this example, we’ll be targeting victim@contoso.local:
4 - Now we need to press F12 key and choose Network Tab. After that, again choose “Permissions…” item in context menu of our new folder:
5 - We need to review the response on the first service.svc?action=GetFolder request. To see this, navigate to:
Body->ResponseMessages->Items->0->Folders->0->PermissionSet->Permissions->N->UserId->SID
N – in this example it is 2 (the latest one), but you can check all of them to find correct one. PrimarySmtpAddress should be desired victim. If response does not contain PermissionSet item, we need to review another service.svc?action=GetFolder request.
6 - We will use this SID in serverHTTP_relayNTLM.py for impersonation of the victim user. Also, we need to choose any TCP port that is unlikely to be blocked on the attacker controlled machine and will allow and outgoing connection on the Exchange Server. For example, TCP port 8080 is likely available for this purpose.
Now let’s change the next lines in serverHTTP_relayNTLM.py with actual information:
Once the script has the correct variable, it’s ready to be started:
7 - The next step is to set the proper variables in the Exch_EWS_pushSubscribe.py script:
Once that’s completed, we can execute this script:
8 - One last step. We need to have some event trigger a Push Notification. We can wait for a while if we’re being stealthy, or we can perform some action like create and send a new email or delete our new folder:
If successful, we should receive inbound connection from Exchange server to our serverHTTP_relayNTLM.py:
If our attack is successful, we will see UpdateInboxRulesResponse ResponseClass="Success" in the last response. This means the inbound rule was added to the victim mailbox, and all inbound emails will be forwarded to the attacker.
Now that everything is in place, it’s time to test the new rule. We need to send an email to the victim from any account, but not the same as the destination in our new rule (in this example attacker@contoso.local) because the rule will not forward emails if source and destination are the same address. Let’s login as administrator and send some “sensitive” info to the victim:
Checking the attacker’s inbox, we see the message successfully forwarded:
As we can see, the new email is forwarded to the attacker. Similar results can be achieved through other EWS APIs like AddDelegate or assigning edit permissions to the target folder.
The Patch
Microsoft assigned this vulnerability CVE-2018-8581 and mitigated it in the November release. There isn’t actually a patch to correct this issue. Instead, Microsoft states a registry key should be deleted. The removal of this key enables a loopback check. If you recall from above, Exchange server has the following registry key set by default:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck = 1
This CVE is rendered unexploitable if the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck key is removed. To remove the registry key, type the following command in an elevated CMD window:
No restart of the OS or the Exchange Server is required after removing the key. The bulletin notes future Cumulative Updates for Exchange will no longer enable the registry key by default.
Conclusion
Exchange Server has been a popular target over the years as email has become a central component of our business life. While this bug allows impersonation, a previous bug reported through the program allowed arbitrary code execution. Both cases demonstrate how sometimes the greatest threat comes from within. These bugs also show how an external attacker could pivot from a single entry point to proliferate throughout an enterprise.
Stay tuned for the next Top 5 bug blog, which will be released tomorrow. Until then, follow the team for the latest in exploit techniques and security patches.