DEF CON 29 - Orange Tsai - ProxyLogon Just Tip of the Iceberg, New Attack Surface on Exchange Server

00:12 - Without doubt, Microsoft Exchange Server is the most widely deployed mail solution within governments and enterprises.

00:21 - It is an integration of their daily operations and security.

00:27 - This January, we found a series of vulnerabilities on Exchange Server to Microsoft, and that gave us ProxyLogon.

00:38 - If you are paying attention to the industry news, you must have heard this then.

00:45 - ProxyLogon may be the most severe vulnerability in Exchange history ever.

00:51 - However, as we went into a deep dive on ProxyLogon, it came to us that it is not just a single bug, but a whole new attack surface to help researchers to uncover more vulnerabilities.

01:08 - To unveil the beauty of this attack surface, we will start from explaining the architecture, analyzing the root cause, and ending up with eight vulnerabilities we find.

01:22 - By understanding the passives of this new attack surface, you won’t be surprised why we can pop out zero-days easily.

01:33 - Let me introduce myself first, I’m Orange, and now, the Principal Security Researcher at DEVCORE, and a zero-day researcher, and focusing on web and application security.

01:47 - My job is to find out the most severe vulnerabilities that can impact the work ahead of the bad guys, and report them to the vendors directly.

02:00 - Apart from that, I’m also a speaker, CTF player, and bug bounty hunter.

02:06 - I got several awards from my researches, such as the Pwnie Awards, and the Champion of Pwn2Own.

02:15 - If you are interested, welcome to follow my Twitter and blog.

02:22 - Before I get started, here’s the disclaimer.

02:25 - All the CVS mentioned today have been reported responsibly, and have been patched by Microsoft.

02:36 - So why were we targeting Exchange Server? In terms of enterprise security, mail servers are high-value assets since they are the place to keep corporate confidentials.

02:51 - With that being said, if someone controls the mail server, they can dominate the lifeline of the corporation.

02:59 - Exchange Server is the most well-known and important mail solution in the world.

03:05 - With this in mind, Exchange has also been the top target for nation state hackers for a long time.

03:13 - Based on our research, there are more than 400,000 Exchange Servers exposed on the internet.

03:22 - Every server represents a company. You can imagine how severe it could be when there’s a critical vulnerability on Exchange Server.

03:36 - Normally, I will review the existing papers and bugs before starting a research.

03:43 - Another whole Exchange history, is there any interesting bug? Of course, also known bugs are best unknown attack vectors, such as the deserialization or input validation.

03:58 - There are several bugs that are worth mentioning.

04:03 - The more special one is the arsenal from Equation Group in 2017.

04:09 - It’s the only practical and public pre-auth RCE in the Exchange history.

04:17 - Unfortunately, the arsenal only works on an ancient Exchange Server.

04:23 - If the arsenal leak happened earlier, it could lead to another nuclear-label crisis.

04:31 - Another oh, I would say the most surprising one is CVE 2020-0688.

04:39 - The nature of this bug is due to a hard-code crypto key.

04:46 - It’s 2020 now, such a common weakness could still be find in a crucial software, which inspired me to dig more into the security of Exchange.

05:02 - So what have we done? We have reviewed the Exchange security from the architectural levels and find a new attack surface.

05:13 - Through this new attack surface, we uncovered eight vulnerabilities and chained these bugs into three attacking exploits.

05:23 - The first and the most famous one is ProxyLogon.

05:28 - It’s a pre-auth RCE. The second one is ProxyOracle.

05:33 - It’s an exploit that can recover any user’s password in plain text format.

05:41 - The last one is ProxyShell. It’s the exploit we demonstrate at Pwn2Own 2021.

05:48 - It’s also a pre-auth RCE. I would like to highlight that all vulnerabilities we uncovered here are logic bugs, which means they could be reproduced and exploited easily than any memory corruption bugs.

06:10 - Here’s my bug list. The ones in red indicates the bug is relate to the attack surface directly.

06:18 - And others are the bugs which shared together.

06:25 - For your references, there are other bugs relate to this new attack surface.

06:31 - You can see from this table, and as nation state hackers are also playing that, which means the attack surface we shared today is a critical hit for Exchange Server.

06:49 - Exchange is a very sophisticated application.

06:52 - Before we cut to the chase, let me introduce the architecture first.

06:58 - Since 2000, Exchange has released a new version every three years.

07:04 - Whenever Exchange released a new version, the architecture changed a lot and becomes different.

07:14 - The change of architecture and iterations make it difficult to upgrade an Exchange Server.

07:22 - In order to ensure the compatibility between the new architecture and old ones, several design steps were incurred and led to the new attack surface we found.

07:38 - So currently, we focused on the Client Access Service, CAS.

07:46 - CAS is a fundamental component in Exchange.

07:50 - The official document indicates CAS is a frontend that accept client connections for all protocols, and they’re responsible for routing and proxying connections.

08:07 - CAS was prior repatched attention to the whole attack service existed.

08:14 - Because the CAS is located at a very early stage of Exchange requires processing, all bugs here are authentication-free.

08:26 - So you can imagine how dangerous it is when this fundamental service is vulnerable.

08:36 - Here is the CAS architecture copied from the document.

08:41 - As you can see, the left side is the clients.

08:45 - No matter where the connection comes from, either HTTP, POP3, IMAP, or SMTP, CAS in the middle part proxies all connections and proxy to the backend service on the right side.

09:04 - The backend service will continue to handle first, the business logics.

09:13 - Because I specialize in web security, so we focus on the web part.

09:22 - The CAS web is built on Microsoft IIS. As you can see, there are two websites inside of IIS.

09:31 - The default website is the frontend we mentioned before, and the Exchange backend is where the business logic is.

09:44 - If you look at the configuration carefully, you will notice the frontend is listening on ports 80 and 443, and the backend is listening on ports 81 and 444.

10:00 - It should be note that the ports are exposed on all interfaces.

10:06 - You may sense something wrong here. All the ports are open to all interfaces, which means you can access the backend directly.

10:17 - Wouldn’t it be dangerous? Please keep this question in mind, and we will answer that later.

10:27 - The CAS is composed of several IIS modules.

10:32 - Applications in frontend include the ProxyModule, which is responsible for passing all incoming requests, applying protocol-specific settings, and forwarding them to the backend.

10:47 - As for the backend, applications include a RehydrationModule, which is taking charge of parsing frontend requests, populating the client information back, and continue the business logic.

11:02 - So here is a question for you, how did the frontend and backend exchange the information? They synchronize the information and internal status by HTTP headers.

11:20 - For client requests, it will first be handled by the frontend, and the request will be passed through several IIS modules, such as the filter, validation, locking, and alas, Proxy Module.

11:36 - The Proxy Module then takes up a handler based on the current application tests such as the \OWA or \ECP.

11:48 - The handler will do the proxy warp and forward the request to the backend.

11:54 - When the backend receives the request, it passes the request to the RehydrationModule to restore the original client state and continue the business logics.

12:09 - Our idea is simple. Could we access the backend intentionally? Since the Exchange synchronize the information by HTTP headers, it seems like most of the access control is done by the frontend.

12:26 - If we can access the backend without restrictions, maybe there are several internal API we can abuse.

12:35 - We all know implementing a proxy isn’t easy, and the frontend seems like a well-implemented HTTP client.

12:44 - If there are some magic checks to manipulate the context between the frontend and backend, it must be found.

12:56 - In order to abuse the context, we have to know how the ProxyModule works first.

13:03 - The ProxyRequestHandler is the most important part of the frontend.

13:09 - All handlers should inherit this class to implement their methods such as how to handle the client cookies or headers, and how to proxy the client request to the backend.

13:24 - We separate the methods into three section.

13:27 - The first is Request, which will pass and modify the client request.

13:34 - Next is Proxy section, which will proxy and send the HTTP request to the backend.

13:42 - And the last section is Response. This section will receive the response from the backend and decide which header or cookie should be sent back to the client.

13:55 - Because this handler is important, we will explain the methods one by one.

14:04 - The first method of Request section is CopyHeadersToServerRequest.

14:10 - It will decide which HTTP header from the client to be sent to the backend.

14:18 - As we said, the frontend and backend synchronize information and internal status by HTTP headers.

14:26 - Maybe you are thinking I could forge the header to confuse something.

14:32 - This is a nice try but unfortunately, you can see here is a backlist in the method.

14:40 - The frontend blocks several HTTP headers which are used internally.

14:47 - Please keep in mind that the header, X-CommonAccessToken is an important one, and we will learn this later.

14:59 - The second is CopyCookiesToServerRequest. The functionality is the same as the previous one, but it copies cookies instead.

15:13 - The last method of Request is AddProtocolSpecificHeadersToServerRequest.

15:20 - This method allows a handler to apply customized protocol settings.

15:26 - For example, if the frontend OWA would like to pass information to the backend, here is the class it can insert information to headers.

15:41 - Besides the customized protocol settings, the method also clones the user identity to a new HTTP header.

15:50 - The identity is the client authentication result in IIS, also consisting of your security identifier.

16:00 - This method serialize it to a string and put it into the headers, which will be forward to the backend later.

16:10 - As of now, you note how the frontend and backend synchronized your identity.

16:16 - They do it by the header X-CommonAccessToken.

16:24 - Once the request passing is done, it will lead to the Proxy section.

16:30 - The Proxy first uses the GetTargetBackEndServerUrl to calculate the URL where the frontend should send to.

16:40 - This method is also a bad request and full of vulnerabilities.

16:45 - We will discuss this later. The second step of Proxy is CreateServerRequest, which first initialize an HTTP client, sets up the HTTP method and headers, and forwards it to the backend.

17:06 - We mentioned that POSTs in IIS are open to anyone and this is dangerous.

17:13 - So that’s why Exchange has a mechanics and to avoid the situation.

17:21 - While the frontend is creating a request, it will generate a Kerberos ticket and put it in the Authorization header.

17:31 - This header will be sent to the backend along with the request.

17:36 - So how does backend know which connection is from a valid frontend? It do it by verifying this Kerberos ticket.

17:50 - We look into the GenerateKerberosAuthHeader and know that the header is generated with the HTTP SPN of the Exchange machine account.

18:08 - If you observe the traffic between the frontend and backend, you will see two headers shown in the request.

18:16 - One is the Authorization header, which is the Kerberos ticket used to indicate you are a valid frontend.

18:25 - The other is the header X-CommonAccessToken.

18:28 - It’s a serialized token indicates your identity.

18:33 - For example, if you log in with the name Orange, the header is the serialized result of your security identifier.

18:48 - After sending the request to the backend, the frontend receives the response and enter the last section.

18:58 - The Response section is similar to Request.

19:01 - It checks the response from the backend and decide which headers or cookies are allowed to be sent back to the client.

19:11 - Now, you understand how the frontend works, let’s move on to see how the backend processes and populates the requests from the frontend.

19:25 - The BackendRehydrationModule first used SYSTEM method to check whether the incoming request is authenticated or not.

19:34 - It is the time to leverage the Kerberos ticket the frontend generate.

19:40 - By handing over this ticket, the backend knows you are a valid frontend now.

19:47 - The backend then call the method TryGetCommonAccessToken to restore the user’s identity from the frontend.

19:59 - The method retrieves the header, deserialize it back to the original access token, and post in the httpContext object for later use.

20:12 - So far, you learned how the frontend and backend synchronized the user’s identity and how the header X-CommonAccessToken plays an important role in the CAS architecture.

20:25 - Since the method just checks if the users are logged in or not, it doesn’t check the identity.

20:33 - Here comes a question. Can we authenticate as a normal user in the backend? If you access the backend directly and authenticate with a normal account, we can specify what header values in the header X-CommonAccessToken and impersonate as any users.

20:57 - The idea is good, and actually, you can test the IIS authentication of backend.

21:05 - But there’s one more checkpoint. The method IsTokenSerializationAllowed magnifies the current logged user and raised a RehydrationException if the checkpoint is failed.

21:25 - It checks if you have a token serialization right.

21:29 - By default, only the Exchange machine account has this right.

21:35 - So that’s why the Kerberos ticket generate by frontend can pass the checkpoint, but you will fail even you are using a correct credential.

21:49 - So here is a quick summary for you. When there is the client request, the frontend IIS first tries to authenticate the request.

22:00 - If succeed, the frontend serialize the user identity and adds it into the header X-CommonAccessToken.

22:10 - The frontend then generates a Kerberos ticket by its HTTP SPN and posts it into the Authorization header.

22:20 - It will forward these headers along with the client request to the backend.

22:27 - The backend also tries to authenticate the request at the beginning.

22:32 - The RehydrationModule will verify whether the user have the right of token serialization.

22:41 - Since we are using a Kerberos ticket generate by the frontend we passed.

22:47 - Lastly, the Rehydration restores the user identity from the header X-CommonAccessToken and continue the backend business logic.

23:01 - So far, we briefly explained the communication between the frontend and backend in short.

23:08 - Let’s start a hack. Okay, the first exploit is ProxyLogon.

23:18 - As introduced before, this may be the most severe vulnerability in the Exchange history.

23:26 - ProxyLogon is chained with two bugs to get the RCE.

23:31 - One is an SSRF on the frontend, and the other is an arbitrary file write on the Control Panel of the backend.

23:43 - So here is the ProxyLogon. The bug is mainly locate at the Proxy section in the frontend.

23:52 - We mentioned that the frontend handler calculates the backend URL and forwards the request to that URL.

24:04 - One of the handlers is in charge of processing the static resources.

24:10 - It will assign a backend target from the cookie.

24:15 - You will figure out how simple this bug is after learning the architecture.

24:25 - The frontend trace the user-supplied cookie as the domain name, and the domain name will be concatenate as the backend URL.

24:34 - We used a bit of passing tricks to enclose the URL and forced the Exchange to fetch example. com.

24:44 - The Exchange will then return the whole response back to us.

24:54 - So what is the root cause of this arbitrary backend assignment? As we mentioned that the Exchange Server changed its architecture while releasing new versions.

25:08 - This cookie is a quick solution for Exchange to make the frontend in new architecture to identify where the old backend is.

25:19 - It looks like a design step to adopt backward compatibility.

25:26 - With the backend assignment, we have a super SSRF that can control almost all the requests and get all the responses.

25:38 - The most impressive is that it will generate a Kerberos ticket for us, which means even when we are taking a protected and domain-joined HTTP service, we can still hack with the authentication of Exchange machine account.

25:58 - Thanks to the super SSRF, we can leverage the internal API /proxylogon. ecp to get a valid session to assess the Control Panel.

26:11 - The API is also the reason why we call a ProxyLogon.

26:18 - As for the rest of the exploitation, I believe there are already lots of technical analyses out there.

26:27 - We will skip it today for the consideration of time.

26:35 - We will not do the demonstration today, but if you are interested, welcome to check the demo on our website.

26:47 - Next, I will be sharing details about ProxyOracle.

26:52 - Compared to ProxyLogon, ProxyOracle is an interesting exploit with a different approach.

27:00 - ProxyOracle will allow the attacker to recover the victim’s plain text password simply by leading them to a malicious link.

27:11 - We used a cross-site scripting and padding oracle to complete the exploit.

27:19 - First, we would like to explain how the OWA or ECP authenticate users.

27:27 - If the negative IIS authentication is used, an ugly prompt will pop out, asking you to enter the password instead of this fancy interface, which means Exchange is using a certain mechanics to execute the transformation between the credentials and cookies.

27:50 - So let’s take a look at how this fancy interface is working with the original architecture.

28:00 - Let’s get back to the IIS architecture. All the OWA and ECP login mechanics are done by the Form-Based Authentication module.

28:13 - The FBA is an authentication manager prior to the Exchange frontend and responsible for converting the username and password into cookies, or translating cookies to the original credential pairs.

28:29 - The implementation store your username and password in cookies directly.

28:35 - Of course, the cookie is encrypted to avoid bad guys catching your password in plain text on the fly.

28:46 - If you read the login traffic carefully, you will see several cookies, which stand for your identity.

28:54 - For the later mail configuration, you have to attach cookies to identify who you are, but not all cookies, there are five important ones with the prefix cadata.

29:10 - You can see from the screen, the cadata contains your encrypted username and password.

29:20 - Here is the pseudocode for the encryption logic.

29:24 - Exchange generates two random strings as the IV and Key for every session.

29:30 - The IV and Key will be sent and stored on the client’s side.

29:35 - However, to avoid someone stealing the cookies and decrypting it with the IV and key, Exchange uses RSA to encrypt with its private key again before sending.

29:51 - The Exchange then uses the AES to encrypt your encoded credential with the IV and Key and put the result into the cookies.

30:05 - And yes, you can find padding oracle here. Exchange texts the CBC of its padding mode.

30:18 - If you are familiar with cryptography, you must know that CBC is vulnerable to the padding oracle attack.

30:27 - The Exchange implementation catches the padding error and returns immediately.

30:37 - When the login process fails, Exchange redirects the HTTP back to the login patch with an error code.

30:46 - Due to the return, we have an oracle here. If the encryption fails, the error code is zero, which stands for null.

30:58 - And if we corrupt the cyber attacks successfully, the Exchange will try to log in with the corrupted credential pair.

31:08 - At this moment, the result must be a failure and the error code is two, which stands for the invalid credentials.

31:20 - By differing from the error number, we have an oracle to recover the plain text.

31:30 - Now, we know we can decrypt any cookies with the padding oracle but the problem is how to get the cookies from the victim? In order to get a cookie on clients, we uncover a cross-site scripting to chain together.

31:54 - But it comes up with another problem being Exchange-authenticated cookies are protected by HttpOnly, so we can’t access the cookies by JavaScript.

32:11 - So how can we do? Since we can execute arbitrary JavaScript on client side, why don’t we just insert an SSRF cookie, which is used in ProxyLogon? Why don’t we add a cookie to the browser? We can sniff and take over all the user’s web requests.

32:36 - All we need to do is to sit on our server and wait for the cookies to come back.

32:46 - I will elaborate the process further. We first send a malicious link to the victim.

32:54 - And once the victim triggers our cross-site scripting, we insert the SSRF cookie to pretend we are the backend of Exchange.

33:05 - And then the Exchange Server becomes a proxy between the victim and us, we will take over all the traffic to bypass the HttpOnly to get the encrypted cookies.

33:23 - Okay, the demo part. First, we have the victim, and we pass his mail address to our exploit.

33:34 - The exploit first send a malicious link to the target.

33:39 - And once the victim triggers our cross-site scripting, we insert a SSRF cookie and wait for the connection back to obtain the encrypted cookies.

33:57 - Okay, we got a connection. We can now decrypt the blocks by padding oracle.

34:04 - It should be note that all the decryption could be done without the cross-site scripting.

34:10 - Even the user close the browser, we can still recover the password.

34:19 - With a little bit waiting, we recovered the password in plain text successfully.

34:32 - The last exploit I will share today is ProxyShell.

34:36 - This is the exploit we demonstrate at Pwn2Own 2021.

34:41 - The result of ProxyShell is the same as ProxyLogon.

34:46 - An unauthenticated attacker can execute arbitrary commands on the Exchange Server.

34:54 - But the exploit chain is different. ProxyShell is chained with an ACL bypass in the frontend, an elevation of privilege in the Exchange PowerShell backend, and an arbitrary file-write to get RCE.

35:14 - So where is the ProxyShell? The first pre-auth path is also a GET at the backend URL calculation.

35:25 - ProxyShell begins with a path confusion. Exchange has a feature called Explicit Logon feature.

35:33 - This feature is used to describe another user’s mailbox or calendar in a new browser window.

35:42 - Of course, the displayed mailbox must have to be configured with permission to publish first.

35:51 - In order to open with a single GET request, the URL format must be simple, and the mailbox address must be include in the URL such as the highlight part in the slide.

36:07 - The Exchange normalize this special URL and reroutes it to the existing handlers.

36:17 - Of course, the path is not the only way to specify the mailbox address.

36:23 - We find that a special cast in the Autodiscover handler, Exchange will consider address from the current string if the path. EndsWith /autodiscover. json.

36:39 - After getting the address, the handler tries to normalize the URL.

36:45 - You’ll see that Exchange won’t conduct too much checking on the pattern of removing mailbox address, which led us to use the substring to erase any part of the URL.

37:02 - As you could see from the slide, this is the URL we will be visiting.

37:09 - And this is the mailbox address we use the query string to specify.

37:17 - And here is the part will be removed from Exchange according to our pattern with the address.

37:31 - This is the actual URL the request will be sent to the backend.

37:38 - But for now, we can access any Exchange backend again.

37:46 - Also, this block is not as powerful as the SSRF in ProxyLogon.

37:52 - It’s sufficient to assess arbitrary backends.

37:56 - We tries to access the API in the path to identify our privilege.

38:03 - From the screenshot, you could see that we could access the backend with the Exchange instant privilege again.

38:15 - Here comes the post-exploitation part. The approach of original ProxyLogon fails due to some Exchange in-depth protections.

38:26 - So we have to discover a new approach. Now, let’s turn the focus to Exchange PowerShell Remoting, a feature for Exchange automations.

38:39 - Through the defined PowerShell commands, users can read mail, send mail, and even configure settings by command lines.

38:49 - The Exchange PowerShell implementation is built upon the PowerShell API.

38:55 - By calling the API, Exchange could realize a PowerShell server and uses the Runspace to name it and isolate the command execution.

39:07 - All the operations are based on the WinRM protocol.

39:12 - It should be note that also we can access the PowerShell backend directly.

39:17 - We can still interact with it because we are the SYSTEM.

39:23 - We will fail the business logic since there is no mailbox for the SYSTEM user.

39:31 - We also can forge our identity by the header X-CommonAccessToken due to the blacklist in the frontend.

39:41 - So what should I do? We dive into the PowerShell server implementation and find a piece of code that extracts the access token from the URL.

39:56 - The code is leading after the IIS backend authentication and before the Rehydration.

40:03 - It checks if there is no X-CommonAccessToken header, the code will call out another method to get the access token from the URL.

40:17 - The CommonAccessTokenFromUrl is a short method and retrieves the value of X-Rps-CAT from query string, and then deserialize it back to the access token.

40:35 - As for now, we have an elevation of privilege because we can access the PowerShell backend and specify the access token directly.

40:45 - The intention of this operation is to be a quick proxy for internal Exchange PowerShell communication.

40:54 - By abusing this feature, we can impersonate as any user.

41:00 - Here, we use the EOP to downgrade ourself from the SYSTEM result mailbox to Exchange Admin.

41:12 - I can now execute arbitrary Exchange PowerShell commands as Admin, and then? The last piece of the puzzle is to find a post-auth RCE to chain everything together.

41:29 - Because we are adding, and there are hundreds of Exchange PowerShell commands out there, it’s easy to find a post-auth bug.

41:39 - We abused the command New-MailboxExportRequest to explore the user’s mailbox into the WebLoad to be our WebShell.

41:53 - Now, we can create files on arbitrary tests.

41:57 - The next problem is how to embed our malicious payload into this file.

42:04 - It’s also easy. We can deliver our payload by mail.

42:08 - However, the exploited file is encoded. By reading the Microsoft document, we learned it’s in PST format and the encoding is just a simple table matrix.

42:22 - We can just encode the payload before sending out.

42:27 - While the server tries to save and encode our payload, it turns into the original malicious code.

42:37 - Let’s check everything together. We first deliver our encoded WebShell to the target mailbox, and then launch the Windows PowerShell client to connect to our proxy server.

42:52 - We use a proxy server because we have to modify the WinRM protocol to rewrite the path to the vulnerable Autodiscover handler, which will eventually trigger the path confusion bug and add an access token to the query string.

43:11 - Once the station has been established, we can execute the PowerShell command to grant ourself the mailbox export log and involve the mailbox exploiting.

43:23 - And the next step is to enjoy the shell. Let’s go to the demonstration.

43:35 - So this is the Exchange Server, and we run our exploit.

43:43 - The exploit first sent our encoded payload to the mailbox and launched the PowerShell to establish the WinRM connection.

43:55 - We used a proxy server to rewrite the traffic to implement our exploit.

44:04 - Okay, we see our shell is dropped. And we are the SYSTEM.

44:35 - Let’s talk about mitigations. Since it’s an architectural problem, it’s hard to mitigate the attack surface with one single action.

44:46 - All you can do is keep your Exchange Server up to date and with the support of a firewall or ACL to not externally facing the internet.

44:59 - Microsoft has enhanced the CAS architecture in April.

45:05 - The authentication part of this attack surface has been reduced in the patch.

45:11 - So if you are lazy, please update the April patch at least.

45:17 - And if you are super lazy, maybe you can give a shot at the Office 365.

45:27 - Okay, conclusion, modern problems require modern solutions.

45:33 - It’s hard to find traditional bugs in modern architecture.

45:37 - Sometimes comprehending the architecture from a higher point of view can help you fight new, interesting bugs.

45:46 - The CAS is still a good attack surface although Microsoft has patched it in April.

45:54 - However, in fact, we still find a few bugs after the April patch.

46:01 - But since the authentication part of this attack surface is reduced, the result may not be as powerful as before due to the lack of pre-auth bugs.

46:15 - Lastly, the Exchange is still a treasure waiting for you to find bugs.

46:21 - As mentioned, even in 2020, a hard-code crypto key can still be find in Exchange Server.

46:30 - I can assure you that Microsoft will fix more Exchange vulnerabilities in the future.

46:38 - But here comes the spoiler alert. Even if you find a super critical vulnerability like ProxyLogon, Microsoft will not reward you any bounty because the Exchange Server on-premise is out of scope.

46:57 - So is it was fun hunting bugs on Exchange Server? You tell me.

47:07 - This is the end of my presentation. If you have any questions, here’s my contact information.

47:15 - By the way, I will post a detailed article on my blog.

47:20 - Please look forward to that. Thank you again for being here, thanks. .