Hello, everyone.
This should be my only live talk this year.
Hello, everyone.
In January this year, I reported to Microsoft a series of loopholes about Exchange Server and named one of the loopholes as ProxyLogon.
If you believe you are concerned about the security industry, you must have heard of this name.
ProxyLogon should be the most serious loophole in the 20-year history of Exchange Server.
But as we study ProxyLogon in more depth, we found that it is not just a loophole, not just an attack, but it can allow researchers or hackers to dig out more loopholes, a whole new attack.
So, in order to let everyone better understand this attack, I will start from explaining the structure of Exchange to let everyone understand why this attack is so special.
After understanding the structure, I believe everyone will not be surprised why I can easily find so many loopholes on Exchange Server.
First, let me introduce myself.
Hello, everyone.
I am Orange.
I am currently the chief security researcher at DevCore.
My job is to find the most serious loopholes that can affect the whole world and use them before the bad guys so that they can be fixed.
In addition, I am also the captain of HITCOM CTF and also a lecturer.
I have been to many competitions around the world, in many places, and in many countries.
My research has also won many awards, such as the Oscar of Hacking, or the Best Web Hacking Technology of the Year, or even the world's master of decoding, I have won all of them.
If you are interested in my experience, you are welcome to follow my Twitter or my blog.
Or if you want to chat with me later, feel free to do so.
So, why do we need to study the Exchange server?
I believe that 2021 is a painful year for Microsoft.
This year, all kinds of events related to Exchange, no matter what kind of loopholes occurred, or which companies were attacked by hackers because of the loopholes of Exchange.
I believe I don't need to emphasize its seriousness.
The Exchange server is probably the most famous mail server in the world.
Because of Microsoft's support, many big companies and government agencies have chosen Exchange as their main mail server.
Email servers are born with the property of storing a lot of confidential information.
So you can imagine what a disaster it would be when there is a serious loophole in the Exchange server.
So, what have we done?
I reviewed the security of Exchange from the architecture side and found a new attack side.
According to this new attack side, we found nine loopholes and grouped them into four different attacks.
The first one, which is also the most famous, is called ProxyLogon.
It is a simple violent pre-auth RCE.
The attacker does not need any account password.
As long as you know your IP, you can directly log in.
The second one is ProxyOracle.
Compared to ProxyLogon, it is a loophole related to cryptography.
The attacker can use this loophole to restore the password of any user.
The third one is ProxyShell.
This is also the loophole that we earned 200,000 US dollars and won the championship in the Pong2Own main event this year .
It is also a violent pre-auth RCE.
The last one is the latest one, which is called ProxyRelay.
This is a new attack.
I am sure you have not heard of it before.
You can listen to it later.
By the way, the new attack that I proposed also made the security community around the world go crazy.
You can imagine that before I proposed ProxyLogon, almost no one could create a pre-auth RCE on the Exchange server.
Everyone's attitude towards Exchange is that it is a fat, soft, and hard-to-defeat thing.
But since I proposed this attack, based on my research, more and more Exchange loopholes have been found.
For example, in April, there was a ProxyNotFound Or there was a ProxyToken of Vietnam Telecommunications Group.
You can see that their names all use the prefix Proxy to pay tribute to my attack.
You can listen to why this thing is related to Proxy.
Exchange is actually a very complex software.
It started in 1993 and is probably older than most of you here.
Since 2000, Exchange has been...
Why does it keep jumping?
Never mind.
Since 2000, it has been releasing a new version every three years.
I don't know if it's the engineers who didn't do a good job designing the architecture.
Almost every new version, the architecture would be changed.
No matter where you merge something, or remove the original architecture, or use a new name to define the old one, the architecture would be changed anyway.
In order to make sure the compatibility between the new and old versions of the Exchange server, it actually left a lot of technical debt.
Or to say, some of the architectural debt would be even closer.
The new attack surface is actually in this place.
We are going to introduce a service called Client Access Service.
It's called CAS.
CAS is a very basic part of Exchange.
I copied it from the official manual.
It says CAS is a front-end service that accepts all protocol users' connections, and is responsible for proxying to the corresponding back-end.
This CAS is what we are focusing on this time.
Because this CAS is located at the very front of the Exchange when processing connections, you can imagine that the loophole on the CAS is naturally that doesn't need authentication.
So you can imagine that when this basic component has a bug or a loophole, its seriousness is at stake.
This is the from the official website.
You can see on the left, right, left, I don't care, on the left is the normal user's connection.
No matter what protocol the user uses to proxy, whether it's HTTP, POP3, IMAP, or even SNTP, CAS will proxy all the connections in the middle and give these connections to the back-end service on the to deal with the email logic.
Of course, after processing, it is also returned to the user through CAS .
Since I am a web dog, I will focus on the web the CAS component.
The whole CAS is built on IIS.
In IIS, in the exchange's IIS, you will see two websites.
One is called default website .
It is the of the CAS proxy .
The other is exchange back -end.
It is actually processing the logic back -end.
The default website is listed in 80 and 443.
The back-end is listed in 81 and 444.
So, if you observe your exchange, it will open at least 4 ports.
80, 81, 443.
can access the service directly.
So, all the front-end services composed of many IIS modules.
All the front-end applications have a proxy module .
This proxy module receives the HTTP request from user , and sends it to the back-end.
All the back-end applications have a rehydration module.
It handles the front -end request and the business
logic of the business logic How do the front-end and the back-end exchange the information?
They use HTTP header to send the from front -end .
So for a user , it will go to the front -end module , like validation , log , and some other modules , and then the proxy module at the back-end service.
And the back-end service handles the business logic of service .
This is the when you send something to the exchange.
So our idea is very simple.
Can we directly visit the back-end exchange ?
Because the back-end the exchange uses the HTTP header to send the information.
And it looks like all of the front-end processes are connected the back -end service.
And back-end service the
business logic And the back-end service the business service.
And the back-end service business logic
The happy side
2 is the hand-hold We talk about
something here in due date.
But I am going to talk about more in due language.
The third one is response.
The first method in the request stage is to use a function called copyHeadersToServerRequest.
This function will decide which HTTP headers can be sent to the backend in the user's request.
Just like what we said before, Exchange will exchange the information to the backend through HTTP headers.
So the first step of the exchange is to check which headers can be sent to the backend.
Of course, there is a blacklist here to block the headers that will be used in the exchange to prevent some bad guys from forging something.
You can remember that there is a very important header here called XCommonAccessToken.
This is a very important header.
We will talk about it many times later.
The next one is copyCookieToServerRequest.
It's the same as before.
Copy the user's cookie to a new request and send it to the backend.
It's pretty much the same as before.
The next one is called addProtocol specificHeaderToServerRequest.
This handler will add some customized protocol settings.
You can think of it as adding some settings.
For example, when you visit your webmail, when you visit some web services, it will add corresponding settings.
They are all added in this place.
These settings will be sent to the backend with the HTTP request.
In addition to the additional settings that the handler will add, this method will also do one more thing.
It will copy your current login email identity and put it in a header called XCommonAccessToken.
So I just said that this header is used internally in Exchange.
This header actually stores your current user identity that you have logged in at the frontend .
So how does the backend sync your user identity?
Through this header.
After you log in at the frontend, the frontend will serialize your login result and put it in this header.
Then it will be sent to the backend with the HTTP header.
So after the request is built, we will move on to the Proxy stage.
Proxy will start with a method called getTargetBackendServerURL to calculate and find out which backend my user request will be sent to.
You have to remember that this is where the most loopholes are.
We will talk about this later.
Next, we will create an HTTP client and send your request to the backend.
I just said that the frontend and backend of Exchange are both based on 0.0.0.0.
You wouldn't think that since they are both external, I can just visit the backend of 811 and 444.
Here, Exchange does a little trick.
It has a mechanism when the frontend creates a request to the backend, it will use the machine account of Exchange to create a set of Kerberos tickets.
After the Kerberos ticket is created, it will put it on the authorization header.
So, how does the backend verify if the frontend is a legitimate frontend?
It uses the Kerberos ticket to determine that.
You can see that its method is generateKerberosAuthHeader.
It uses the HTTP of Exchange's SPN to generate a set of Kerberos tickets.
So, if you observe the communication between the frontend and the backend, you will find that except for the request you sent, Exchange will at least add two headers for you.
One is the authorization header.
This header is the Kerberos ticket generated by the machine account of the frontend to verify that you are a legitimate frontend.
The other one is XCommonAccessToken.
This is the login ID of the frontend of Exchange.
Next, we will send the request to the backend.
After that, we will move on to the response stage.
The response stage is the same as the request.
After the backend is processed, it will return some results.
The result here is that the frontend of Exchange will decide which return results, which headers, and which cookies I can send back to the user.
These are all judged here.
After talking about the frontend, let's talk about the backend.
I just mentioned that almost all applications in the backend will inherit a module called Backend Rehydration.
This module will verify whether you have successfully logged in through the IIS built-in method.
The verification here is to verify if the Kerberos Tiki you sent to the frontend is correct.
After the verification, it will call a method called TryGetCommonAccessToken.
This TryGetCommonAccessToken you can see here, it is the XCommonAccessToken of the HTTP header .
It will be re-serialized as a Windows login certificate.
The login certificate will be placed in your current request.
You can use this certificate to represent who you are in the business logic.
So...
Let's skip this part.
I think I have a lot of stuff today.
This is just a summary for you.
When a request is sent to an exchange, the frontend will verify the request, and then serialize your login certificate to the XCommonAccessToken HTTP header.
Next, the frontend will create a Kerberos Tiki and place it on the authorization header.
The third step is to throw these headers to the backend The backend will first verify the authorization header to verify if your identity is a legal Kerberos Tiki generated by the frontend to verify if your request is legal.
After the verification, the frontend will use the XCommonAccessToken to find out who you are in the frontend.
Then it will know who you are.
This is a simplified verification process on the frontend.
Finally , we are done with the complicated stuff.
We can start to explain the cool stuff.
Let's start the hack.
The first attack we are going to talk about is ProxyLogon .
As I explained before, this is the most serious and famous bug in the past 20 years .
ProxyLogon uses two loopholes to create a pre-auth RCE.
One is pre-auth SSRF.
The other one is pre-auth SSRF The other one is a loophole at the backend.
Where is ProxyLogon?
This bug mainly exists in the proxy section at the frontend.
As I said before, the frontend decides which backend the request is going to be sent to.
So it uses a method called getTargetBackendServerURL to decide where the request is going to be sent to.
But in this method, in one of the actual places, there is a place where you can easily use cookie to specify where the backend of the exchange is.
So when you understand the whole structure, you will realize that this bug is actually that simple.
There is a place that will use cookie to decide where the backend of the exchange is.
So you just need to send a specific cookie and specify this cookie as your own network address.
The frontend of the exchange will automatically visit the network address you specified and bring the result back.
So this is a very classic SSRF case.
So why does this bug occur?
As we mentioned earlier, the structure of the exchange will change a lot as the new version is updated.
This cookie looks like a dirty hack.
It is a dirty hack by the engineers .
In order to make sure the frontend of the new exchange can quickly find the backend of the old structure.
So they introduced this cookie not to let the user specify, but to let the frontend specify.
But this thing can be directly accessed by the user.
In order to make sure the compatibility of this structure is...
a design issue caused by the compatibility .
So through this cookie, we can specify the backend of the exchange.
So we have a super SSRF here.
So why is it a super SSRF?
Because we can almost control all the HTTP requests and get all the HTTP response.
What's more, in this SSRF, the exchange will also bring us a set of Kerberos Tiki.
So even if you are protected by the internet, we can use the machine account of the exchange to break it.
So with this super SSRF, we used an API inside the exchange called ProxyLogon.ecp to get a set of legal sessions and visit its management interface.
This set of APIs is also why we named this loop as ProxyLogon.
I believe there are a lot of analysis on the internet about how to use it later .
So I will skip it for now.
As for the demo video, we also have it on our website, so I will skip it as well.
Next, I want to share ProxyOracle.
ProxyLogon is a loop related to cryptography.
ProxyOracle has two loops.
One is cross-site scripting, and the other is Paid-in-Oracle.
First, when you log into the exchange, you will see this familiar login interface.
Have you ever wondered how the exchange implements the login interface?
The answer is on the implementation of the login.
Let's go back to the CIS architecture.
In the CIS architecture, there is a place called FBA.
The full name of the FBA is Phonebest Authentication.
Phonebest, in Chinese, is a verification based on a form.
What this module does is to verify
whether you have successfully logged in, and if so, convert it into a cookie.
Or when you visit it with a cookie, it will verify whether your cookie is legal or illegal.
If it is legal, convert it into your account password.
So, this implementation stores your account and password directly in the cookie.
Of course, it is afraid that the password is stored directly in the cookie, so it uses an additional encryption mechanism to encrypt your account password so that your account password won't be stored in the cookie in an anonymous way.
So, after you log in to Exchange, if you carefully observe the HTTP request you sent, you will see a lot of these cookies.
These cookies represent your account password and your identity.
In the following mail operations, you must bring this set of cookies so that Exchange will know who you are.
There are five important cookies here.
They all start with CAData.
The most important one is CAData.
It stores your account and password.
OK.
This is a summary of the encryption process of the account password .
Exchange will first generate two sets of random strings, which are the current session's IV and key.
Then, it will use AES to encrypt your account password with AES.
In order to prevent...
Next, it will return the IV and key to you with the cookie.
In order to prevent someone from getting the cookie, you may think that the IV and key and the encryption are in the cookie, but if someone gets it, he can still decrypt your account password.
In order to prevent this, it will use its own SSL and RSA to encrypt everything again.
So tiring.
OK.
That's right.
If you heard AES just now, you can imagine that in 2021, you can still decrypt OLOCO on such a large exchange.
You can still decrypt OLOCO.
I didn't mention it just now.
AES uses CPC mode.
If you have some sense of cryptography , you will think that CPC mode should have OLOCO decryption.
That's right.
In 2021, there is still OLOCO decryption on the exchange.
So now, basically, we have OLOCO decryption.
We don't need to decrypt any cookie.
But the problem is how do we get the user's cookie?
If you want to decrypt a fish, you need a fish to decrypt.
If you want to decrypt a cookie, you need to get the user's cookie first.
So here, we made another loophole.
We found another cross-site scripting.
We used this loophole to steal the user's cookie.
Here is another tricky part.
Basically, in the exchange, all cookies use HTTP-only to protect the cookie.
But because of time constraints, we can't talk about how to bypass this mechanism.
Let's take a look at the demo.
As you can see, there is a victim at the beginning, followed by the attacker.
The attacker executes the scary attack program.
We specify that the victim is...
Oops, I typed too slowly.
When I was recording this video, I had to re-record as soon as I made a mistake.
So I recorded this about 10 times.
I sent a letter to the attacker.
When the user clicked the letter, the cookie would be sent to me.
After we received the cookie, we can turn off the browser and still decrypt the user's cookie.
After about 30 seconds of the attack, we can get the user's password.
The user's password is T234.
So as long as you click a letter, we can get your password.
Something like this.
This is ProxyOracle.
The third one is ProxyShell.
Compared to ProxyLogon, this loophole is more serious.
This is the loophole we used to get rid of Exchange in Pwn2Pwn 2021 .
It is also a pre-auth RCE without authentication .
There are three loopholes in this attack.
The first one is a pre-auth pass confusion to bypass its ACL.
The second one is a full-line upgrade on PowerShell.
The third one is also a full-line upgrade on PowerShell.
Where is ProxyShell?
It is also in the ProxySection's getTargetBackendServerURL.
What is the main reason for this?
There is a special feature called ExplicitLogonFeature.
In order to allow something to be displayed, for example, a user's email, calendar, or something related to a meeting.
So it designed an ExplicitLogonFeature.
This feature allows you to set your calendar as a public full-line.
You can use a URL to let others see your calendar.
In order to make this smooth, let's say I want to see your URL.
Your URL will be on the web page.
I just need to pass the URL and your email to make sure if there is a public full-line.
Then I can show my calendar to you.
This is how you can make the ExplicitLogonFeature.
So the Exchange will pass the URL and pass the email of the user in the middle.
Then you can take it away.
The original URL is in the original route of the Exchange.
Of course, after reading the original code of the Exchange , we found that we can not only specify the email of the user but also if your URL ends with autodiscover.json, we can use a query string to specify the email of the user.
Although the user still needs to open the feature, we can use another way to specify the email.
As I said, in order to re-router the new feature to the original feature, it must remove the URL in the middle of the URL.
After removing the URL, it can match the original route and use the original code to process it.
So when the Exchange does the processing, it does not do too many checks.
It just selects the email and removes the URL in the middle of the URL.
So one thing is that we can remove the content of the URL in the middle of the URL.
Here is a simple example.
For example, this is the URL we are going to visit.
This is the URL we are going to visit.
Of course, this is just a malicious pattern.
When Exchange sees this, it will remove the corresponding part of the URL in the middle of the URL.
So , this part will be removed by Exchange.
After removing this part, the whole path will become like this.
This means that we can remove the path we don't want to visit so that Exchange can visit any back end.
So here we use an example to prove that we can actually pass confusion to visit the back end of Exchange.
And the whole path is synced.
OK.
now we can visit the back end as we like , and the rest is the post-infiltration part.
Originally, OK.
Originally, we used the approach on ProxyLogon , which is the API of ProxyLogon.ecp.
Because there are some internal defense of Exchange, we can't use the API directly.
So we have to find a new way to create a shell.
Here we focus on a feature called PowerShell Remoting.
PowerShell Remoting is an internal part of Exchange that allows users to automate some reading, collecting, or setting processes through PowerShell.
Although I don't know who is using it, it provides such a useful feature.
We were thinking at that time, since we can visit the back end unlimitedly , can we visit the back end of PowerShell so that we can run any PowerShell?
But this part is a failure.
Because our identity is a user of Synston.
When we visit the back end of PowerShell, it will tell you that the user of Synston doesn't have a legal mailbox.
So even if we can verify, we still can't run PowerShell.
Because my authority is too high.
And I can't do anything.
So what should we do?
After we looked at its implementation in detail, we found that the remote function of PowerShell , besides finding out your X.S.S.
token, if it doesn't see the X.S.S.
token in the header, it will from your query string take out a parameter and serialize it as your current identity.
So here we have an elevation of privilege.
But we can use the query string to specify the token and turn it into another user.
So we have a privilege loop here.
But here, we use this privilege loop to lower our authority.
Because our authority is too high.
I heard this request for the first time.
So we use this privilege loop to turn us into a lower authority Exchange Admin user.
The Exchange Admin user must have a mailbox.
So we can use this privilege loop to run any PowerShell in Exchange .
So now we can run any PowerShell command and as the saying goes a hacker without a shell is not a good hacker.
So our goal is to get a shell.
This is actually very easy for us now.
Because there are hundreds of PowerShell commands You can see if there are any weaknesses.
So we found a NewMailboxExportRequest to export a user's mailbox to our WebRoot to make it our WebShell.
You can skip some details here.
If you are interested, you can go to our blog.
Actually, there are many other uses.
But there are too many details here.
Let's skip it.
Because there are some other things.
So the whole attack chain looks like this.
At the beginning, Let's skip the attack chain.
Let's look at the demo.
This is a simple demo.
As long as I see this page, I can download the Exchange server.
The Exchange server is called ex01.orange.local Because my export uses something related to PowerShell and WinRM, so I wrote it on Windows.
Let's specify the demo to be black, and a shell will pop out.
You can see that we did something related to WinRM, and specified a PowerShell command.
Next, it looks like we exported a WebShell.
Let's wait for it.
Wait for it.
OK, there is a shell.
In fact, in this place, if you type in whoami, it will be a systems shell.
Let's give it a round of applause.
So, as you can see, as long as you give me the IP of the server , I can just type it in.
This is a very cool loophole.
OK, I'm going to talk about something new.
I was going to talk about this video in August, but due to the pandemic, it was postponed to November.
So I was going to talk about this after BlackHat.
OK, I know.
I was going to talk about this after BlackHat or DEFCON.
It looks great.
But postponing to November, if I have to talk about something three months ago, I feel sorry for everyone.
So I added some new things here.
Let's talk about after BlackHat's speech, is there anything new after BlackHat's speech?
First of all, I didn't talk about NSA repaid
a bunch of exchange-related loopholes after my speech .
They didn't name it, but someone called it Proxy Not Found.
This Proxy Not Found was repaid by NSA.
It was fixed in April.
When the fixed version came out, a lot of security companies went to see where the loopholes were.
At that time, there was a Vietnamese national security center.
They found the loopholes and named it Proxy Not Found.
It was...
Forget it.
Proxy Not Found is mainly related to two loopholes.
These two loopholes are pre-auth SSRF.
Of course, NSA found the loopholes under my speech.
Proxy Not Found is very similar to Proxy Logon.
The only difference is in Proxy Logon, cookies are used.
In Proxy Not Found, cookies are different.
But all look codes are the same.
I won't go into details.
You can see the result.
You can see another set of cookies.
This set of cookies is encrypted.
Base64 encoded.
The password is the network address.
If you leave it in the cookie to the other party, Exchange will visit it.
The reason is very similar to Proxy Logon.
Next, Proxy Token.
This is reported by a Vietnamese team.
They reported another set of features related to But it's under the new attack we proposed.
Due to time constraints, we skipped it.
In the patch in April, they added a very good patch so that all attacks related to authentication are fixed.
So after April, many attacks can be reduced.
The method is to verify your current request before the Kerberos Tiki.
This is a very good solution for hackers.
Of course, it's a bad thing for hackers.
So we were thinking after the April patch, what can we do to attack Exchange?
It seems the attack I proposed has become low.
Is there any other way to attack Exchange?
Of course, there are other ways.
For example, Exchange is built on Windows.
It uses many built-in features of Windows .
If there is a problem with those features, there may be a problem with Exchange.
So we came up with a new attack method.
We came up with a new way to attack Exchange.
This is what we are going to talk about today.
It's called Proxy Relay.
Proxy Relay is a new authentication loop.
As long as you give me an Exchange server, I can turn into any user to read your email, send you a message, or do anything.
It has a series of CVEs, but almost every CVE has the same effect.
Some have not been fixed, and some have been fixed.
I will talk about what can be fixed today.
Why do we call it Proxy Relay?
Because it uses the same problem as CES Proxy.
Here we use another method called NTLM Relay.
We put two things together, so we call it Proxy Relay.
This Proxy Relay is not affected by the patch of Microsoft April.
Because it uses another architecture label issue to attack Exchange.
NTLM Relay has been around for a long time, and Microsoft has a lot of mitigation to solve this issue.
First, NTLM Relay requires users to trigger the authentication of NTLM.
But as attackers, we don't want to wait for users to trigger.
We have to trigger this issue.
Here we combine a bug called PrinterBug.
We use PrinterBug to make Microsoft a non-fixable feature so that the server can start the authentication process of NTLM.
So we can turn passive into active.
Some mitigation also prohibit Sandhost Reflection.
You can't relay the NTLM of A to A.
Here we use the idea that in big companies, there is not only one Exchange.
There may be an Exchange Cluster.
If I use NTLM Relay to relay the authentication of Exchange A to Exchange B, this defense won't be able to stop us.
The last one is in the attack of NTLM Relay, there will be a lot of SMB signing or channel binding to prevent the attack of NTLM Relay.
But it has nothing to do with us.
We use HTTP to trigger the attack of NTLM Relay.
So these defenses are not bad for us.
Let's talk about CV2021-33768.
This is a loophole in the July patch.
Microsoft thanked two researchers in this loophole.
One is me, and the other is someone in Tencent.
That person also talked about this loophole in this year's DEFCON .
The concept of this loophole is like this.
You use PrinterBug to relay the NTLM of Exchange A to Exchange B.
Through this NTLM Relay, we can pass the certification of Exchange.
After the certification, we can visit the Exchange such as EWS and manipulate the user's web.
Something like this.
OK.
After that loophole, we also found another similar, but lower-level loophole.
It was also reported to MSRC in June.
I wanted to talk about it today, but after a long time of communication with Microsoft , they said there was no quick way to fix this loophole because it is a very low-level and structural issue.
So they couldn't push the patch in time in November.
After many discussions, we finally decided not to talk about the details.
But I can still show you the video.
OK.
As you can see, there are two Exchange servers in this attack scenario .
We use Exchange-01 and Exchange-02.
First, let's look at Exchange-02.
It is the latest version.
Next, we use the NTLM RelayX we modified to relay Exchange-01's NTLM to Exchange-02.
Sorry, this is NTLM Relay.
To relay to Exchange-02.
Next, we use Pinterbug to relay Exchange-01's NTLM to Exchange-02.
Then we relay it to Exchange-02.
So here...
It's gone.
Anyway, we can see that we can read the user's email.
Of course, we can do more things.
But this is just an example.
We just want to show its seriousness.
Finally, I'm done.
I still have two pages.
Finally, let's talk about mitigation.
Of course, the most important thing is to keep your Exchange up-to-date.
I've talked about this a lot.
There's nothing more to say.
Another thing I want to talk about is Proxy Relay.
It's a problem of design classification.
You can't simply pass a patch or prevent it in the current stage.
Some mitigations are to turn off the printer bug or the printer spooler service.
Or you don't want to let NTLM authentication exist in your company.
Or if you are too lazy, you can consider putting your Exchange server on the Exchange 365 platform.
Just kidding.
That's all for my speech today.
If you have any questions, feel free to ask me later.
Thank you.
I don't know if you have any questions.
Are you watching the slides?
Let's see if there are any questions.
Is there anyone who has a question?
Sorry, the time is a bit delayed.
Is there anyone?
I have a question.
You just mentioned that you discussed with the Microsoft team not to provide details in the near future.
When do they expect to solve the bug?
They said in December.
But I think it will be delayed.
We usually give them a deadline when we report a bug .
Of course, we are a good company.
Even if we exceed the deadline, we will still do our best.
I originally gave them until September.
But they said it was a problem with the underlying architecture.
They can't just change it.
The deadline they gave is December.
So in December, if everything goes well, the architecture of Exchange will be changed.
Yes.
Are we going to start patching again?
That's you, not us.
Yes.
Actually, for this matter, we have been patching the Exchange server this year.
Yes, I have received complaints from many people.
They said that we reported an Exchange bug every few months , and their company had to work overtime.
Yes.
I don't know if you have any questions.
I saw that someone on Slido said what would be the impact of changing the listening port from 0.0.0.0 to 127.0.0.1 from 0.0.0.0 to 0 .0 .0 .0 .
You can imagine that Exchange is not designed to be one.
It may have many ports.
So you have to open this port to other Exchange visitors.
So if you can bind it to 127.0.0.1, if you only have one Exchange server, it should be fine.
But usually big companies have more than 20 or even hundreds of Exchange clusters.
There's nothing you can do about it.
Anyway, if it can't be used, it will be changed back.
Yes, it's a problem with the architecture.
Why do I have a source code?
Because Exchange is written in .NET.
Everyone knows .NET.
That's it.
Really?
Can I decompile it?
No, even if you write in C, I can decompile it.
Okay.
Because .NET decompiles relatively easily.
So...
It doesn't mix?
It doesn't.
Later on Twitter, I started to study my results in March and April.
After my results came out, a bunch of people started to research Exchange.
On Twitter, I saw a lot of people complaining that it looked simple, but the architecture was so complicated.
So actually, the threshold to research Exchange is very low.
But its code is too complicated.
So the trouble is you have to understand its architecture and spend a lot of time to read it carefully.
So when you see the source code, it's actually not difficult.
Is it possible that the previous CSS will be changed?
The architecture will be changed.
I just said that it will be changed every three years.
I don't know...
2019 plus three years will be 2022.
The architecture will be changed next year.
Anyone else has a question?
Yes, anyone else has a question?
Okay, if no one has a question, let's thank Orange again.
Okay, thank you.
That's all for today.
You can go home now.
Thank you.