Anatomy of Attack : Exchange Breach Feb’21

POC: https://youtu.be/SvjGMo9aMwE

In January, a series of vulnerability was found on Exchange server to Microsoft which allowed proxyLogon.

ProxyLogon is the sever vulnerability in Exchange . It is not just a single Bug, But it is a new whole attack surface which helps researcher’s to uncover more vulnerabilites.

Why target Exchange Server?

  • Mail Server always keep confidential secrets and exchange server is most well-known mail soultion for enterprise and governments worldwide.
  • Has been the targets for NAtion-sponsored hackers.
  • More than 4000,000 Exchange Servers exposed on the internet.

Most Bugs are based on known attack surface, but there are several notable bugs:

  • Arsenal : it is the most special bug from Equation Group in 2017. It’s the only parctical and public pre-auth Remote Code Execution. it works only on Exchange Server 2003.
  • CVE-2020-0688: It is a .net deseralization bug due to hardcoded cryptography key.
  • Exchange Architecture: Exchange is a very Sphosticated application. Exchange has released a new version every three years since 2000. The change of architecture and iterations make it difficult to upgrade Exchange server.
  • Where They Focused?
    • They focus on Client Access Service(CAS.
    • It is a fundamental component in Exchange server.
    • The offical document indicates: ” Mailbox servers contains the CAS that accepts client connections for all protocols. These frontend services are responsible for routing or proxying connections to the corresponding backend services”
    • CAS is located at early stage of exchange requires processing, all bugs here are authetication free.
  • CAS Architecture:
    • CAS web is built on mircosoft IIS:
    • There are two websites mentioned in IIS: The default website is the frontend, and the exchange backend is where the business logic is.
    • Frontend is listening on port 80 and 443 and the backend is listening on port 81 and 444. The ports are exposed on all interface which means we can access the backend directly.
  • CAS is composed of several IIS modules
    • Application in frontend include the Proxy Module which is responsible for passing all incoming requests, applying protocol specified settings and forward to the backend
    • Application in the Backend includes the BackendRehydration Module which charges of parsing fronted requests, populating the client information back, and continue business logic
    • Application synchronizes the informstion and the internal status by HTTP headers
  • How Proxy Module Work:(How Frontend Works)
    • The Proxy Request HAndler is the most important part of frontend. All handlers should inherit this class to implment their methods like how to handle client cookiess or how to proxy the client request to the backend.
    • The methods are in three sections:
      • The Request section, which will pass and modify the client request.
        1. CopyHeardsToServerRequest: it will decide which HTTp header from the client to be sent to the backend. The frontend blocks several HTTP headers which are used internally.
        2. CopyCookiesToServerRequest: It is same as previous one, but it copies cookies instead.
        3. AddProtocolSpecificHeadersToServerRequest: it allows handler to apply customized protocol settings. Besides the customized protocol settings, the method also clones user identity to a new HTTP header. The identity is the client authentication result in IIS.Note: Frontend and Backend synchronize the identity by the header X-Common AccessToken
      • The Proxy section which will proxy and send the HTTP request to the backend.
        • The Proxy section which will proxy and send the HTTP request to the backend.
          1. CreateServerRequest: which first initialize an HTTP client, sets up the HTTP method and header, and forward it to backend.
            1. GetTargetBackendServerURl: to calculate the url where the frontend should send to. This request consists of vulnerablity as it is a bad request.POSTs in IIS are open to anyone which is dangerous. While front end is creating request, it will generate a kerberos ticket and put it in authorization header. This header will be sent to backend along with the request. The traffic between frontend and backend, we will see two headers in the request:
            • Authrorization header: whichj is the kerberos ticket used to indicate valid frontend.
            • X_CommonAccessToken header: its a serialized token indicates your identity.
        1. GetServerResponse: after the request is sent to the backend, the frontend receives the responses and enter last section.
      • The Response section will recive the response from the backend and decide which header or cookie should be sent back to the client. The response section is similar to Request. It checks the response from the backend and decide which headers or cookies are allowed to be sent to the client.
  • How Backend Processess and populates the requests from the frontend. (How backend works).
    • The BackendRehydration Module first used SYSTEM method to check whether the incoming request is authenticated or not.
    • It time to leravge the Kerberos ticket the fronted generated. by handing over the ticket, the backend knows it is valid frontend now.
    • The backend then call method TryGetCommonAccessToken to restore the users identity from the frontend.
    • The method retrieves the header, deserialize it back to the original access token, and post in the httpContext object for later use.Can we autheticate as a normal user in the background? If we access backend directly and authenticate with normal account we can specify what header values in the Header X-CommonAccessToken and impersonate as any users.
    • The Method IsTokenSerializationAllowed: magnifies the current logged user and raised a RehydrationException if the checkpoint is failed.
    • Check AD Extended rights: It checks if you have a token Serialization right. By default, only the exchange machine account has this right. That’s the reason, kerboes ticket generated by frontend can pass the checkpoint but will fail even using a correct credential.
  • Auth-Flow Summary:
    • When there is a client request, the frontend IIS first tries to authenticate the request. if succeed the frontend serialize the user identity and adds it in to the header X-CommonAccesstoken.
    • The frontend then generated a kerberos ticket by its HTTP SPN and post it into the authjroization header.
    • It will forward these requests along with the client requests to the backend.
    • the backend also trys to authenticate the requesrt at the beginning.
    • The rehydrationModule will verify whether the user have the right of token serilization.
    • the rehydration restores the user identity from the header X-CommonAccessToken and continue backened business logic.
  • Eight Vulnerabilities. It covers server side,client side and crypto bugs through the new attack surface. It is chained into 3 attacks:
    • ProxyLogon: Pre-auth Remote code execution chain.
    • ProxyOracle: A plaintext-password recovery attacking chain.
    • ProxyShell: The pre-auth Remote code execution chain.All the Vulnerablities which are uncovered are logic bugs, which means they could be reproduced and exploited easily than any memory corruption bugs.
  • Proxy Logon:
    • The most sever vulnerability in Exchange Server. An unauthenticated attacker can execute arbitrary codes on Exchange server through exposed 443 port.
    • ProxyLogon is chained with two bugs to get remote code execution.
      • SSRF(Server side request forgery) on the frontend which leads to authentication bypass – CVE-2021-26855
      • Arbitrary File Write which leads to Remote code execution on the control panel of the backend- CVE-2021-27065
    • Where ProxyLogon Beign?
      • The bug is mainly located at the Proxy Section on the frontend.
      • The frontend handler calculates the backend url and forwards the request to that URL. The other handler is in charge of processing the static resources. It will assign the backend target from the cookie.
      • The frontend trace the user-supplied cookie as the domain name and the domain name will be concatenate with the backend url.
      • it uses a bit of passing tricks to enclose the url and force the exchange to fetch example.com. The exchange will then return the whole response back to us.
    • Root Cause of Arbitrary backend?
      • The exchange server change its architecture while releasing new versions. This cookie is a quick solution for exchange to make the frontend in the new architecture to identify where the old backend is.
      • The exchange has to adapt the compatibility between new and old architecture, hence exchange introduces cookies.
      • Super SSRF(Server side request forgery) can control almost all the HTTP requests and get all the responses.
      • It will generate kerbores ticket , which means even when a protected and domain -joined HTTP service is taken, still authentication can be hacked of Exchange machine account.
      • Leverage the internal API /Proxylogon.ecp to get a valid session to access the control panel.
  • Proxy Oracle:
    • Proxy Oracle will allow the attacker to recover the victims plain text password simply by leading them to malicious link.
    • Cross site scripting is used and padding oracle to complete the exploit.
    • CVE-2021-31195- Reflected Cross site Scripting
    • CVE-2021-31196- Padding oracle attack on Exchange cookies parsing.
    • Explaination: We first send a malicious link to victim. once the victim triggers our Cross-sit scripting . we insert the SSRF cookie to pretend we are the backend of exchange. and then the exchange server becomes a proxy between victim and attacker and take over all the traffic to bypass the HTTPOnly to get the encrypted cookies.
  • ProxyShell:
    • An authenticated attacker can execute arbitrary commands on Microsoft Exchange server through an only exposed 443 port.
    • CVE-2021-34473: proxy shell is chained with an ACL bypass in the frontend
    • CVE-2021-34523: Elevation of Privilege in the exchange powershell backend.
    • CVE-2021-31207: post-auth arbitrary file write to get Remote code excution.
    • Where ProxyShell Begin?
      • the first pre-auth path is also a GET at the backend URL calculation. it begins with path confusion.
      • Exchange has a feature called Explicit Logon feature. This feature is used to describe another users mailbox or calendra in browser window.- the exchange parsed the mailbox address and normalize the URL internally.
      • Exchange PowerShell Remoting:
        • it is the post exploitation part. the approach of original ProxyLogon fails due to some Exchange in-depth protections.
        • Exchange PoweShell remoting is a command line interface that enables the automation of Exchange tasks.
        • it is built upon POwerShell API and uses Runspace for isolation. All the operations are based on WinRM protocol.
        • We also can forge the identity by header X-CommonAccessToken due to the backlist in the frontend
      • Privilege Downgrade:
        • evevation of privilege because exchange poweshell backend can be accessed directly.
        • The intension of this operation is to be quick proxy for internal exchange powershell communications.
        • EOP is used to downgrade from the SYSTEM result mailbox to Exchange Admin.
        • Specify the access token in X-Rps-Cat to impersonate to any user.
      • Attack exchange POwershell:
        • The last peice of puzzel is find post-auth Remote code execution to chain together
        • its easy to abuse exchange powershell command New-MailboxExportRequest to export users mailbox into an UNC path.
      • Payload Delivery: How to embed the malicious payload into exported files:
        • Malicious payload is delivered by Emails(SMTP),however the exported file is encoded. The exported file is in Outlook Personal folder(PST) format and the encoding is just a simple table matrix.
        • We can encode the payload before sending out. While server tries to save and encode the payload it turns into the original malicious code.
        • Delivery encoded webshell payload to target mailbox by SMTP.
        • LAunch the windows powershelland intercept the WinRM protocol
          • Rewrite the /powershell/ to /Autodiscover/ to tigger the path confusion bug.
          • Add query string X-Rps-CAT with corresponding Exchange admin access token.
        • Export commands inside established powerhsell sessions
          • New-ManagementRoleAssignment to grant Mailbox Import Export rule.
          • New-MailboxExportRequest to write ASPX file into the local UNC path.
  • Mitigation:
    • Keep exchange server upto date and with support of firewall or ACL to not externally facing the internet.
    • Microsoft has enhanced the CAS Architecture frontend in April 2021
      • The authentication part of this attack surface has been reduced in this patch and reduced the pre-auth effectively.
    • Please update to the latest or atleast to the April patch.
    • Move to Office365 Exchnage online
  • Conclusion:
    • Modern problems require modern solutions
      • try to comprehend the architecture froma higher point of view.
    • The exchange CAS is still good attack surface.
      • Due to lack of pre-auth bugs,(results may not be powerfull as before)
    • Even a critical bug is found, microsoft will not reward any bounty because Exchange Server on-perm is out of scope.

By:

Posted in:


Leave a comment