1 00:00:05,640 --> 00:00:07,760 Hello, everyone. 2 00:00:07,920 --> 00:00:13,380 This should be my only live talk this year. 3 00:00:13,700 --> 00:00:15,700 Hello, everyone. 4 00:00:15,700 --> 00:00:25,500 In January this year, I reported to Microsoft a series of loopholes about Exchange Server and named one of the loopholes as ProxyLogon. 5 00:00:25,500 --> 00:00:30,780 If you believe you are concerned about the security industry, you must have heard of this name. 6 00:00:31,300 --> 00:00:36,800 ProxyLogon should be the most serious loophole in the 20-year history of Exchange Server. 7 00:00:37,480 --> 00:00:51,900 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. 8 00:00:52,440 --> 00:01:03,640 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. 9 00:01:03,780 --> 00:01:09,100 After understanding the structure, I believe everyone will not be surprised why I can easily find so many loopholes on Exchange Server. 10 00:01:11,920 --> 00:01:13,400 First, let me introduce myself. 11 00:01:13,400 --> 00:01:13,860 Hello, everyone. 12 00:01:13,860 --> 00:01:14,780 I am Orange. 13 00:01:14,780 --> 00:01:18,160 I am currently the chief security researcher at DevCore. 14 00:01:18,160 --> 00:01:27,980 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. 15 00:01:27,980 --> 00:01:32,740 In addition, I am also the captain of HITCOM CTF and also a lecturer. 16 00:01:32,780 --> 00:01:38,160 I have been to many competitions around the world, in many places, and in many countries. 17 00:01:38,500 --> 00:01:49,880 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. 18 00:01:50,360 --> 00:01:55,920 If you are interested in my experience, you are welcome to follow my Twitter or my blog. 19 00:01:55,920 --> 00:01:59,360 Or if you want to chat with me later, feel free to do so. 20 00:02:00,720 --> 00:02:03,700 So, why do we need to study the Exchange server? 21 00:02:03,700 --> 00:02:08,480 I believe that 2021 is a painful year for Microsoft. 22 00:02:08,480 --> 00:02:18,860 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. 23 00:02:19,220 --> 00:02:22,840 I believe I don't need to emphasize its seriousness. 24 00:02:22,840 --> 00:02:27,100 The Exchange server is probably the most famous mail server in the world. 25 00:02:27,100 --> 00:02:35,200 Because of Microsoft's support, many big companies and government agencies have chosen Exchange as their main mail server. 26 00:02:36,280 --> 00:02:41,420 Email servers are born with the property of storing a lot of confidential information. 27 00:02:41,700 --> 00:02:47,100 So you can imagine what a disaster it would be when there is a serious loophole in the Exchange server. 28 00:02:49,900 --> 00:02:52,080 So, what have we done? 29 00:02:52,080 --> 00:02:59,940 I reviewed the security of Exchange from the architecture side and found a new attack side. 30 00:03:00,060 --> 00:03:07,600 According to this new attack side, we found nine loopholes and grouped them into four different attacks. 31 00:03:07,740 --> 00:03:11,100 The first one, which is also the most famous, is called ProxyLogon. 32 00:03:11,100 --> 00:03:14,500 It is a simple violent pre-auth RCE. 33 00:03:14,500 --> 00:03:16,380 The attacker does not need any account password. 34 00:03:16,380 --> 00:03:18,760 As long as you know your IP, you can directly log in. 35 00:03:19,180 --> 00:03:21,240 The second one is ProxyOracle. 36 00:03:21,240 --> 00:03:27,200 Compared to ProxyLogon, it is a loophole related to cryptography. 37 00:03:27,440 --> 00:03:31,300 The attacker can use this loophole to restore the password of any user. 38 00:03:32,180 --> 00:03:34,680 The third one is ProxyShell. 39 00:03:34,680 --> 00:03:41,640 This is also the loophole that we earned 200,000 US dollars and won the championship in the Pong2Own main event this year . 40 00:03:41,940 --> 00:03:44,980 It is also a violent pre-auth RCE. 41 00:03:45,260 --> 00:03:49,400 The last one is the latest one, which is called ProxyRelay. 42 00:03:49,400 --> 00:03:50,720 This is a new attack. 43 00:03:50,720 --> 00:03:52,700 I am sure you have not heard of it before. 44 00:03:52,700 --> 00:03:54,680 You can listen to it later. 45 00:03:57,440 --> 00:04:05,600 By the way, the new attack that I proposed also made the security community around the world go crazy. 46 00:04:05,600 --> 00:04:13,900 You can imagine that before I proposed ProxyLogon, almost no one could create a pre-auth RCE on the Exchange server. 47 00:04:14,020 --> 00:04:19,640 Everyone's attitude towards Exchange is that it is a fat, soft, and hard-to-defeat thing. 48 00:04:19,640 --> 00:04:27,160 But since I proposed this attack, based on my research, more and more Exchange loopholes have been found. 49 00:04:27,160 --> 00:04:36,640 For example, in April, there was a ProxyNotFound Or there was a ProxyToken of Vietnam Telecommunications Group. 50 00:04:39,300 --> 00:04:47,240 You can see that their names all use the prefix Proxy to pay tribute to my attack. 51 00:04:47,300 --> 00:04:51,400 You can listen to why this thing is related to Proxy. 52 00:04:52,960 --> 00:04:55,940 Exchange is actually a very complex software. 53 00:04:55,940 --> 00:05:02,100 It started in 1993 and is probably older than most of you here. 54 00:05:02,920 --> 00:05:05,220 Since 2000, Exchange has been... 55 00:05:05,220 --> 00:05:07,380 Why does it keep jumping? 56 00:05:07,380 --> 00:05:08,740 Never mind. 57 00:05:08,740 --> 00:05:13,540 Since 2000, it has been releasing a new version every three years. 58 00:05:13,540 --> 00:05:17,280 I don't know if it's the engineers who didn't do a good job designing the architecture. 59 00:05:17,280 --> 00:05:20,380 Almost every new version, the architecture would be changed. 60 00:05:21,600 --> 00:05:30,680 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. 61 00:05:30,800 --> 00:05:39,460 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. 62 00:05:39,460 --> 00:05:44,120 Or to say, some of the architectural debt would be even closer. 63 00:05:44,120 --> 00:05:48,440 The new attack surface is actually in this place. 64 00:05:49,900 --> 00:05:54,160 We are going to introduce a service called Client Access Service. 65 00:05:54,220 --> 00:05:55,620 It's called CAS. 66 00:05:55,620 --> 00:05:59,900 CAS is a very basic part of Exchange. 67 00:05:59,900 --> 00:06:02,580 I copied it from the official manual. 68 00:06:02,600 --> 00:06:14,580 It says CAS is a front-end service that accepts all protocol users' connections, and is responsible for proxying to the corresponding back-end. 69 00:06:15,800 --> 00:06:19,560 This CAS is what we are focusing on this time. 70 00:06:19,640 --> 00:06:34,120 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. 71 00:06:34,220 --> 00:06:40,740 So you can imagine that when this basic component has a bug or a loophole, its seriousness is at stake. 72 00:06:42,120 --> 00:06:45,480 This is the from the official website. 73 00:06:47,140 --> 00:06:54,520 You can see on the left, right, left, I don't care, on the left is the normal user's connection. 74 00:06:54,520 --> 00:07:14,740 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. 75 00:07:15,640 --> 00:07:19,280 Of course, after processing, it is also returned to the user through CAS . 76 00:07:20,220 --> 00:07:24,900 Since I am a web dog, I will focus on the web the CAS component. 77 00:07:28,100 --> 00:07:31,560 The whole CAS is built on IIS. 78 00:07:31,580 --> 00:07:37,840 In IIS, in the exchange's IIS, you will see two websites. 79 00:07:37,840 --> 00:07:39,440 One is called default website . 80 00:07:39,440 --> 00:07:43,100 It is the of the CAS proxy . 81 00:07:43,100 --> 00:07:46,320 The other is exchange back -end. 82 00:07:46,320 --> 00:07:51,220 It is actually processing the logic back -end. 83 00:07:52,820 --> 00:07:59,200 The default website is listed in 80 and 443. 84 00:07:59,200 --> 00:08:05,520 The back-end is listed in 81 and 444. 85 00:08:06,240 --> 00:08:12,800 So, if you observe your exchange, it will open at least 4 ports. 86 00:08:12,800 --> 00:08:23,680 80, 81, 443. 87 00:08:23,680 --> 00:08:27,140 can access the service directly. 88 00:08:27,140 --> 00:08:42,020 So, all the front-end services composed of many IIS modules. 89 00:08:42,020 --> 00:08:49,140 All the front-end applications have a proxy module . 90 00:08:49,140 --> 00:09:01,240 This proxy module receives the HTTP request from user , and sends it to the back-end. 91 00:09:01,240 --> 00:09:08,140 All the back-end applications have a rehydration module. 92 00:09:08,140 --> 00:09:14,700 It handles the front -end request and the business 93 00:09:18,440 --> 00:09:32,020 logic of the business logic How do the front-end and the back-end exchange the information? 94 00:09:33,000 --> 00:09:38,480 They use HTTP header to send the from front -end . 95 00:09:41,070 --> 00:10:07,750 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. 96 00:10:07,750 --> 00:10:13,610 And the back-end service handles the business logic of service . 97 00:10:16,270 --> 00:10:19,870 This is the when you send something to the exchange. 98 00:10:23,250 --> 00:10:26,130 So our idea is very simple. 99 00:10:26,130 --> 00:10:29,930 Can we directly visit the back-end exchange ? 100 00:10:29,930 --> 00:10:40,630 Because the back-end the exchange uses the HTTP header to send the information. 101 00:10:40,790 --> 00:11:00,590 And it looks like all of the front-end processes are connected the back -end service. 102 00:11:05,530 --> 00:11:08,270 And back-end service the 103 00:11:20,690 --> 00:11:25,430 business logic And the back-end service the business service. 104 00:11:25,430 --> 00:11:28,690 And the back-end service business logic 105 00:11:34,770 --> 00:11:36,130 The happy side 106 00:11:41,490 --> 00:11:49,830 2 is the hand-hold We talk about 107 00:11:53,070 --> 00:11:55,850 something here in due date. 108 00:11:55,850 --> 00:11:56,130 But I am going to talk about more in due language. 109 00:11:56,130 --> 00:11:58,370 The third one is response. 110 00:12:00,010 --> 00:12:08,630 The first method in the request stage is to use a function called copyHeadersToServerRequest. 111 00:12:08,630 --> 00:12:16,130 This function will decide which HTTP headers can be sent to the backend in the user's request. 112 00:12:16,310 --> 00:12:22,070 Just like what we said before, Exchange will exchange the information to the backend through HTTP headers. 113 00:12:22,070 --> 00:12:28,770 So the first step of the exchange is to check which headers can be sent to the backend. 114 00:12:29,150 --> 00:12:40,250 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. 115 00:12:40,650 --> 00:12:45,750 You can remember that there is a very important header here called XCommonAccessToken. 116 00:12:45,750 --> 00:12:47,650 This is a very important header. 117 00:12:47,650 --> 00:12:50,090 We will talk about it many times later. 118 00:12:51,410 --> 00:12:55,130 The next one is copyCookieToServerRequest. 119 00:12:55,130 --> 00:12:55,550 It's the same as before. 120 00:12:55,550 --> 00:13:00,350 Copy the user's cookie to a new request and send it to the backend. 121 00:13:00,730 --> 00:13:02,850 It's pretty much the same as before. 122 00:13:03,290 --> 00:13:11,450 The next one is called addProtocol specificHeaderToServerRequest. 123 00:13:11,510 --> 00:13:17,490 This handler will add some customized protocol settings. 124 00:13:17,490 --> 00:13:20,090 You can think of it as adding some settings. 125 00:13:20,090 --> 00:13:27,130 For example, when you visit your webmail, when you visit some web services, it will add corresponding settings. 126 00:13:27,130 --> 00:13:28,950 They are all added in this place. 127 00:13:29,550 --> 00:13:32,870 These settings will be sent to the backend with the HTTP request. 128 00:13:38,850 --> 00:13:48,510 In addition to the additional settings that the handler will add, this method will also do one more thing. 129 00:13:48,510 --> 00:13:59,750 It will copy your current login email identity and put it in a header called XCommonAccessToken. 130 00:14:00,030 --> 00:14:02,650 So I just said that this header is used internally in Exchange. 131 00:14:02,650 --> 00:14:08,750 This header actually stores your current user identity that you have logged in at the frontend . 132 00:14:08,790 --> 00:14:13,790 So how does the backend sync your user identity? 133 00:14:13,790 --> 00:14:15,830 Through this header. 134 00:14:15,830 --> 00:14:22,990 After you log in at the frontend, the frontend will serialize your login result and put it in this header. 135 00:14:22,990 --> 00:14:25,410 Then it will be sent to the backend with the HTTP header. 136 00:14:27,990 --> 00:14:33,370 So after the request is built, we will move on to the Proxy stage. 137 00:14:33,510 --> 00:14:45,710 Proxy will start with a method called getTargetBackendServerURL to calculate and find out which backend my user request will be sent to. 138 00:14:45,710 --> 00:14:49,510 You have to remember that this is where the most loopholes are. 139 00:14:49,510 --> 00:14:51,930 We will talk about this later. 140 00:14:53,470 --> 00:14:59,830 Next, we will create an HTTP client and send your request to the backend. 141 00:15:03,550 --> 00:15:10,830 I just said that the frontend and backend of Exchange are both based on 0.0.0.0. 142 00:15:11,170 --> 00:15:17,350 You wouldn't think that since they are both external, I can just visit the backend of 811 and 444. 143 00:15:18,330 --> 00:15:21,250 Here, Exchange does a little trick. 144 00:15:21,250 --> 00:15:34,270 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. 145 00:15:34,270 --> 00:15:40,110 After the Kerberos ticket is created, it will put it on the authorization header. 146 00:15:40,110 --> 00:15:45,710 So, how does the backend verify if the frontend is a legitimate frontend? 147 00:15:45,710 --> 00:15:49,870 It uses the Kerberos ticket to determine that. 148 00:15:52,040 --> 00:15:57,100 You can see that its method is generateKerberosAuthHeader. 149 00:15:57,100 --> 00:16:03,170 It uses the HTTP of Exchange's SPN to generate a set of Kerberos tickets. 150 00:16:03,170 --> 00:16:15,910 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. 151 00:16:15,910 --> 00:16:18,070 One is the authorization header. 152 00:16:18,070 --> 00:16:28,270 This header is the Kerberos ticket generated by the machine account of the frontend to verify that you are a legitimate frontend. 153 00:16:28,270 --> 00:16:30,910 The other one is XCommonAccessToken. 154 00:16:30,910 --> 00:16:36,170 This is the login ID of the frontend of Exchange. 155 00:16:40,040 --> 00:16:44,820 Next, we will send the request to the backend. 156 00:16:44,820 --> 00:16:49,460 After that, we will move on to the response stage. 157 00:16:49,460 --> 00:16:51,920 The response stage is the same as the request. 158 00:16:51,920 --> 00:16:55,640 After the backend is processed, it will return some results. 159 00:16:55,660 --> 00:17:05,140 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. 160 00:17:05,140 --> 00:17:06,700 These are all judged here. 161 00:17:09,320 --> 00:17:13,540 After talking about the frontend, let's talk about the backend. 162 00:17:13,900 --> 00:17:22,960 I just mentioned that almost all applications in the backend will inherit a module called Backend Rehydration. 163 00:17:23,620 --> 00:17:28,640 This module will verify whether you have successfully logged in through the IIS built-in method. 164 00:17:30,580 --> 00:17:38,930 The verification here is to verify if the Kerberos Tiki you sent to the frontend is correct. 165 00:17:39,300 --> 00:17:44,820 After the verification, it will call a method called TryGetCommonAccessToken. 166 00:17:45,000 --> 00:17:52,740 This TryGetCommonAccessToken you can see here, it is the XCommonAccessToken of the HTTP header . 167 00:17:52,740 --> 00:17:58,040 It will be re-serialized as a Windows login certificate. 168 00:17:58,040 --> 00:18:01,480 The login certificate will be placed in your current request. 169 00:18:01,700 --> 00:18:08,560 You can use this certificate to represent who you are in the business logic. 170 00:18:09,820 --> 00:18:10,240 So... 171 00:18:12,580 --> 00:18:13,420 So... 172 00:18:13,760 --> 00:18:14,180 So... 173 00:18:15,960 --> 00:18:17,680 Let's skip this part. 174 00:18:17,980 --> 00:18:20,160 I think I have a lot of stuff today. 175 00:18:20,160 --> 00:18:24,380 This is just a summary for you. 176 00:18:25,200 --> 00:18:41,120 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. 177 00:18:41,540 --> 00:18:48,960 Next, the frontend will create a Kerberos Tiki and place it on the authorization header. 178 00:18:49,160 --> 00:19:12,760 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. 179 00:19:12,760 --> 00:19:21,780 After the verification, the frontend will use the XCommonAccessToken to find out who you are in the frontend. 180 00:19:22,220 --> 00:19:24,320 Then it will know who you are. 181 00:19:24,320 --> 00:19:30,660 This is a simplified verification process on the frontend. 182 00:19:33,140 --> 00:19:35,680 Finally , we are done with the complicated stuff. 183 00:19:35,680 --> 00:19:38,620 We can start to explain the cool stuff. 184 00:19:38,760 --> 00:19:40,740 Let's start the hack. 185 00:19:41,980 --> 00:19:45,540 The first attack we are going to talk about is ProxyLogon . 186 00:19:45,700 --> 00:19:52,140 As I explained before, this is the most serious and famous bug in the past 20 years . 187 00:19:52,140 --> 00:19:56,920 ProxyLogon uses two loopholes to create a pre-auth RCE. 188 00:19:56,920 --> 00:19:59,900 One is pre-auth SSRF. 189 00:19:59,900 --> 00:20:06,740 The other one is pre-auth SSRF The other one is a loophole at the backend. 190 00:20:09,920 --> 00:20:11,700 Where is ProxyLogon? 191 00:20:12,160 --> 00:20:18,120 This bug mainly exists in the proxy section at the frontend. 192 00:20:18,400 --> 00:20:24,280 As I said before, the frontend decides which backend the request is going to be sent to. 193 00:20:24,420 --> 00:20:31,800 So it uses a method called getTargetBackendServerURL to decide where the request is going to be sent to. 194 00:20:31,800 --> 00:20:44,280 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. 195 00:20:44,940 --> 00:20:49,960 So when you understand the whole structure, you will realize that this bug is actually that simple. 196 00:20:49,960 --> 00:20:56,140 There is a place that will use cookie to decide where the backend of the exchange is. 197 00:20:58,730 --> 00:21:07,670 So you just need to send a specific cookie and specify this cookie as your own network address. 198 00:21:08,150 --> 00:21:18,310 The frontend of the exchange will automatically visit the network address you specified and bring the result back. 199 00:21:19,150 --> 00:21:23,190 So this is a very classic SSRF case. 200 00:21:23,730 --> 00:21:27,070 So why does this bug occur? 201 00:21:27,170 --> 00:21:33,390 As we mentioned earlier, the structure of the exchange will change a lot as the new version is updated. 202 00:21:34,110 --> 00:21:37,750 This cookie looks like a dirty hack. 203 00:21:37,750 --> 00:21:40,870 It is a dirty hack by the engineers . 204 00:21:40,870 --> 00:21:49,090 In order to make sure the frontend of the new exchange can quickly find the backend of the old structure. 205 00:21:49,310 --> 00:21:57,370 So they introduced this cookie not to let the user specify, but to let the frontend specify. 206 00:21:57,370 --> 00:22:00,270 But this thing can be directly accessed by the user. 207 00:22:00,270 --> 00:22:07,390 In order to make sure the compatibility of this structure is... 208 00:22:09,430 --> 00:22:11,090 a design issue caused by the compatibility . 209 00:22:11,210 --> 00:22:15,310 So through this cookie, we can specify the backend of the exchange. 210 00:22:15,310 --> 00:22:18,310 So we have a super SSRF here. 211 00:22:18,310 --> 00:22:21,210 So why is it a super SSRF? 212 00:22:21,210 --> 00:22:29,890 Because we can almost control all the HTTP requests and get all the HTTP response. 213 00:22:29,930 --> 00:22:37,770 What's more, in this SSRF, the exchange will also bring us a set of Kerberos Tiki. 214 00:22:37,770 --> 00:22:48,210 So even if you are protected by the internet, we can use the machine account of the exchange to break it. 215 00:22:50,110 --> 00:23:01,670 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. 216 00:23:01,710 --> 00:23:06,950 This set of APIs is also why we named this loop as ProxyLogon. 217 00:23:08,390 --> 00:23:11,410 I believe there are a lot of analysis on the internet about how to use it later . 218 00:23:11,410 --> 00:23:14,010 So I will skip it for now. 219 00:23:14,990 --> 00:23:19,450 As for the demo video, we also have it on our website, so I will skip it as well. 220 00:23:20,910 --> 00:23:23,550 Next, I want to share ProxyOracle. 221 00:23:24,870 --> 00:23:28,610 ProxyLogon is a loop related to cryptography. 222 00:23:29,550 --> 00:23:32,050 ProxyOracle has two loops. 223 00:23:32,050 --> 00:23:35,790 One is cross-site scripting, and the other is Paid-in-Oracle. 224 00:23:37,350 --> 00:23:43,430 First, when you log into the exchange, you will see this familiar login interface. 225 00:23:43,430 --> 00:23:47,990 Have you ever wondered how the exchange implements the login interface? 226 00:23:48,210 --> 00:23:52,770 The answer is on the implementation of the login. 227 00:23:56,560 --> 00:23:59,780 Let's go back to the CIS architecture. 228 00:23:59,780 --> 00:24:05,140 In the CIS architecture, there is a place called FBA. 229 00:24:05,140 --> 00:24:09,120 The full name of the FBA is Phonebest Authentication. 230 00:24:09,580 --> 00:24:13,280 Phonebest, in Chinese, is a verification based on a form. 231 00:24:14,620 --> 00:24:16,600 What this module does is to verify 232 00:24:19,740 --> 00:24:23,220 whether you have successfully logged in, and if so, convert it into a cookie. 233 00:24:23,220 --> 00:24:29,840 Or when you visit it with a cookie, it will verify whether your cookie is legal or illegal. 234 00:24:29,840 --> 00:24:32,960 If it is legal, convert it into your account password. 235 00:24:33,640 --> 00:24:42,400 So, this implementation stores your account and password directly in the cookie. 236 00:24:42,740 --> 00:25:00,000 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. 237 00:25:01,740 --> 00:25:11,740 So, after you log in to Exchange, if you carefully observe the HTTP request you sent, you will see a lot of these cookies. 238 00:25:12,020 --> 00:25:17,240 These cookies represent your account password and your identity. 239 00:25:17,880 --> 00:25:25,140 In the following mail operations, you must bring this set of cookies so that Exchange will know who you are. 240 00:25:25,140 --> 00:25:28,120 There are five important cookies here. 241 00:25:28,120 --> 00:25:30,720 They all start with CAData. 242 00:25:30,720 --> 00:25:34,140 The most important one is CAData. 243 00:25:34,140 --> 00:25:38,860 It stores your account and password. 244 00:25:41,540 --> 00:25:42,620 OK. 245 00:25:42,620 --> 00:25:48,240 This is a summary of the encryption process of the account password . 246 00:25:48,690 --> 00:25:56,980 Exchange will first generate two sets of random strings, which are the current session's IV and key. 247 00:25:57,140 --> 00:26:01,980 Then, it will use AES to encrypt your account password with AES. 248 00:26:03,220 --> 00:26:04,660 In order to prevent... 249 00:26:04,660 --> 00:26:09,820 Next, it will return the IV and key to you with the cookie. 250 00:26:11,180 --> 00:26:22,760 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. 251 00:26:22,760 --> 00:26:32,300 In order to prevent this, it will use its own SSL and RSA to encrypt everything again. 252 00:26:34,580 --> 00:26:35,820 So tiring. 253 00:26:36,760 --> 00:26:37,140 OK. 254 00:26:37,200 --> 00:26:37,980 That's right. 255 00:26:37,980 --> 00:26:47,140 If you heard AES just now, you can imagine that in 2021, you can still decrypt OLOCO on such a large exchange. 256 00:26:47,140 --> 00:26:48,580 You can still decrypt OLOCO. 257 00:26:48,840 --> 00:26:50,360 I didn't mention it just now. 258 00:26:50,360 --> 00:26:52,740 AES uses CPC mode. 259 00:26:52,740 --> 00:26:57,960 If you have some sense of cryptography , you will think that CPC mode should have OLOCO decryption. 260 00:26:58,020 --> 00:26:59,680 That's right. 261 00:26:59,680 --> 00:27:03,580 In 2021, there is still OLOCO decryption on the exchange. 262 00:27:05,400 --> 00:27:08,500 So now, basically, we have OLOCO decryption. 263 00:27:08,500 --> 00:27:12,180 We don't need to decrypt any cookie. 264 00:27:12,800 --> 00:27:17,040 But the problem is how do we get the user's cookie? 265 00:27:17,040 --> 00:27:19,680 If you want to decrypt a fish, you need a fish to decrypt. 266 00:27:19,680 --> 00:27:24,300 If you want to decrypt a cookie, you need to get the user's cookie first. 267 00:27:25,000 --> 00:27:27,180 So here, we made another loophole. 268 00:27:27,180 --> 00:27:30,520 We found another cross-site scripting. 269 00:27:30,520 --> 00:27:33,900 We used this loophole to steal the user's cookie. 270 00:27:35,840 --> 00:27:38,500 Here is another tricky part. 271 00:27:38,500 --> 00:27:45,340 Basically, in the exchange, all cookies use HTTP-only to protect the cookie. 272 00:27:45,500 --> 00:27:50,060 But because of time constraints, we can't talk about how to bypass this mechanism. 273 00:27:53,130 --> 00:27:55,330 Let's take a look at the demo. 274 00:27:59,130 --> 00:28:04,570 As you can see, there is a victim at the beginning, followed by the attacker. 275 00:28:04,990 --> 00:28:08,450 The attacker executes the scary attack program. 276 00:28:08,450 --> 00:28:11,610 We specify that the victim is... 277 00:28:11,610 --> 00:28:13,370 Oops, I typed too slowly. 278 00:28:14,050 --> 00:28:17,650 When I was recording this video, I had to re-record as soon as I made a mistake. 279 00:28:17,650 --> 00:28:19,350 So I recorded this about 10 times. 280 00:28:20,010 --> 00:28:23,490 I sent a letter to the attacker. 281 00:28:23,890 --> 00:28:31,850 When the user clicked the letter, the cookie would be sent to me. 282 00:28:31,890 --> 00:28:41,590 After we received the cookie, we can turn off the browser and still decrypt the user's cookie. 283 00:28:41,610 --> 00:28:52,370 After about 30 seconds of the attack, we can get the user's password. 284 00:28:52,370 --> 00:28:55,750 The user's password is T234. 285 00:28:55,750 --> 00:29:00,090 So as long as you click a letter, we can get your password. 286 00:29:00,090 --> 00:29:01,550 Something like this. 287 00:29:02,130 --> 00:29:04,910 This is ProxyOracle. 288 00:29:08,390 --> 00:29:11,670 The third one is ProxyShell. 289 00:29:11,670 --> 00:29:15,670 Compared to ProxyLogon, this loophole is more serious. 290 00:29:15,770 --> 00:29:22,090 This is the loophole we used to get rid of Exchange in Pwn2Pwn 2021 . 291 00:29:22,090 --> 00:29:26,350 It is also a pre-auth RCE without authentication . 292 00:29:26,350 --> 00:29:29,630 There are three loopholes in this attack. 293 00:29:29,630 --> 00:29:34,430 The first one is a pre-auth pass confusion to bypass its ACL. 294 00:29:34,430 --> 00:29:39,190 The second one is a full-line upgrade on PowerShell. 295 00:29:39,190 --> 00:29:41,570 The third one is also a full-line upgrade on PowerShell. 296 00:29:42,850 --> 00:29:45,730 Where is ProxyShell? 297 00:29:46,170 --> 00:29:53,550 It is also in the ProxySection's getTargetBackendServerURL. 298 00:29:56,050 --> 00:29:59,750 What is the main reason for this? 299 00:30:00,330 --> 00:30:08,070 There is a special feature called ExplicitLogonFeature. 300 00:30:08,070 --> 00:30:26,830 In order to allow something to be displayed, for example, a user's email, calendar, or something related to a meeting. 301 00:30:26,830 --> 00:30:30,770 So it designed an ExplicitLogonFeature. 302 00:30:30,770 --> 00:30:39,430 This feature allows you to set your calendar as a public full-line. 303 00:30:39,430 --> 00:30:44,470 You can use a URL to let others see your calendar. 304 00:30:45,430 --> 00:30:52,350 In order to make this smooth, let's say I want to see your URL. 305 00:30:52,350 --> 00:30:54,970 Your URL will be on the web page. 306 00:30:55,290 --> 00:31:06,550 I just need to pass the URL and your email to make sure if there is a public full-line. 307 00:31:06,550 --> 00:31:09,210 Then I can show my calendar to you. 308 00:31:09,210 --> 00:31:13,350 This is how you can make the ExplicitLogonFeature. 309 00:31:13,810 --> 00:31:23,470 So the Exchange will pass the URL and pass the email of the user in the middle. 310 00:31:24,230 --> 00:31:26,510 Then you can take it away. 311 00:31:26,510 --> 00:31:33,630 The original URL is in the original route of the Exchange. 312 00:31:37,650 --> 00:32:02,370 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. 313 00:32:02,370 --> 00:32:11,410 Although the user still needs to open the feature, we can use another way to specify the email. 314 00:32:13,990 --> 00:32:26,170 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. 315 00:32:27,710 --> 00:32:35,650 After removing the URL, it can match the original route and use the original code to process it. 316 00:32:35,990 --> 00:32:41,310 So when the Exchange does the processing, it does not do too many checks. 317 00:32:41,310 --> 00:32:46,810 It just selects the email and removes the URL in the middle of the URL. 318 00:32:47,230 --> 00:32:54,090 So one thing is that we can remove the content of the URL in the middle of the URL. 319 00:32:54,650 --> 00:32:58,190 Here is a simple example. 320 00:32:58,190 --> 00:33:02,690 For example, this is the URL we are going to visit. 321 00:33:05,810 --> 00:33:09,090 This is the URL we are going to visit. 322 00:33:09,430 --> 00:33:16,370 Of course, this is just a malicious pattern. 323 00:33:16,970 --> 00:33:23,730 When Exchange sees this, it will remove the corresponding part of the URL in the middle of the URL. 324 00:33:23,730 --> 00:33:30,190 So , this part will be removed by Exchange. 325 00:33:30,950 --> 00:33:39,770 After removing this part, the whole path will become like this. 326 00:33:39,770 --> 00:33:49,890 This means that we can remove the path we don't want to visit so that Exchange can visit any back end. 327 00:33:51,600 --> 00:34:02,790 So here we use an example to prove that we can actually pass confusion to visit the back end of Exchange. 328 00:34:02,790 --> 00:34:05,730 And the whole path is synced. 329 00:34:09,310 --> 00:34:10,150 OK. 330 00:34:10,150 --> 00:34:18,410 now we can visit the back end as we like , and the rest is the post-infiltration part. 331 00:34:18,410 --> 00:34:21,690 Originally, OK. 332 00:34:24,190 --> 00:34:31,130 Originally, we used the approach on ProxyLogon , which is the API of ProxyLogon.ecp. 333 00:34:31,130 --> 00:34:36,890 Because there are some internal defense of Exchange, we can't use the API directly. 334 00:34:36,890 --> 00:34:41,130 So we have to find a new way to create a shell. 335 00:34:41,330 --> 00:34:46,450 Here we focus on a feature called PowerShell Remoting. 336 00:34:47,950 --> 00:34:58,370 PowerShell Remoting is an internal part of Exchange that allows users to automate some reading, collecting, or setting processes through PowerShell. 337 00:34:58,370 --> 00:35:02,470 Although I don't know who is using it, it provides such a useful feature. 338 00:35:02,890 --> 00:35:16,730 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? 339 00:35:18,290 --> 00:35:21,270 But this part is a failure. 340 00:35:21,270 --> 00:35:25,510 Because our identity is a user of Synston. 341 00:35:25,510 --> 00:35:33,330 When we visit the back end of PowerShell, it will tell you that the user of Synston doesn't have a legal mailbox. 342 00:35:33,330 --> 00:35:39,610 So even if we can verify, we still can't run PowerShell. 343 00:35:39,610 --> 00:35:42,110 Because my authority is too high. 344 00:35:42,110 --> 00:35:45,070 And I can't do anything. 345 00:35:45,270 --> 00:35:48,290 So what should we do? 346 00:35:48,290 --> 00:36:00,990 After we looked at its implementation in detail, we found that the remote function of PowerShell , besides finding out your X.S.S. 347 00:36:00,990 --> 00:36:08,330 token, if it doesn't see the X.S.S. 348 00:36:08,330 --> 00:36:21,070 token in the header, it will from your query string take out a parameter and serialize it as your current identity. 349 00:36:21,070 --> 00:36:28,530 So here we have an elevation of privilege. 350 00:36:29,210 --> 00:36:39,370 But we can use the query string to specify the token and turn it into another user. 351 00:36:39,510 --> 00:36:42,810 So we have a privilege loop here. 352 00:36:42,810 --> 00:36:48,270 But here, we use this privilege loop to lower our authority. 353 00:36:48,270 --> 00:36:50,050 Because our authority is too high. 354 00:36:50,050 --> 00:36:51,870 I heard this request for the first time. 355 00:36:52,210 --> 00:36:59,330 So we use this privilege loop to turn us into a lower authority Exchange Admin user. 356 00:36:59,390 --> 00:37:03,070 The Exchange Admin user must have a mailbox. 357 00:37:03,070 --> 00:37:09,670 So we can use this privilege loop to run any PowerShell in Exchange . 358 00:37:10,770 --> 00:37:25,170 So now we can run any PowerShell command and as the saying goes a hacker without a shell is not a good hacker. 359 00:37:25,170 --> 00:37:27,450 So our goal is to get a shell. 360 00:37:27,450 --> 00:37:30,590 This is actually very easy for us now. 361 00:37:30,590 --> 00:37:38,170 Because there are hundreds of PowerShell commands You can see if there are any weaknesses. 362 00:37:38,170 --> 00:37:53,010 So we found a NewMailboxExportRequest to export a user's mailbox to our WebRoot to make it our WebShell. 363 00:37:54,850 --> 00:37:57,150 You can skip some details here. 364 00:37:57,150 --> 00:37:59,750 If you are interested, you can go to our blog. 365 00:38:01,230 --> 00:38:03,470 Actually, there are many other uses. 366 00:38:03,470 --> 00:38:05,870 But there are too many details here. 367 00:38:05,990 --> 00:38:07,150 Let's skip it. 368 00:38:07,150 --> 00:38:09,010 Because there are some other things. 369 00:38:09,430 --> 00:38:12,030 So the whole attack chain looks like this. 370 00:38:12,030 --> 00:38:14,690 At the beginning, Let's skip the attack chain. 371 00:38:14,690 --> 00:38:16,130 Let's look at the demo. 372 00:38:20,010 --> 00:38:22,070 This is a simple demo. 373 00:38:22,070 --> 00:38:25,590 As long as I see this page, I can download the Exchange server. 374 00:38:25,950 --> 00:38:38,710 The Exchange server is called ex01.orange.local Because my export uses something related to PowerShell and WinRM, so I wrote it on Windows. 375 00:38:39,570 --> 00:38:45,310 Let's specify the demo to be black, and a shell will pop out. 376 00:38:45,310 --> 00:38:52,450 You can see that we did something related to WinRM, and specified a PowerShell command. 377 00:38:52,810 --> 00:38:55,730 Next, it looks like we exported a WebShell. 378 00:38:55,730 --> 00:38:56,790 Let's wait for it. 379 00:39:01,620 --> 00:39:02,540 Wait for it. 380 00:39:03,040 --> 00:39:04,200 Wait for it. 381 00:39:05,400 --> 00:39:06,840 OK, there is a shell. 382 00:39:07,080 --> 00:39:12,120 In fact, in this place, if you type in whoami, it will be a systems shell. 383 00:39:12,320 --> 00:39:14,020 Let's give it a round of applause. 384 00:39:18,690 --> 00:39:23,470 So, as you can see, as long as you give me the IP of the server , I can just type it in. 385 00:39:24,310 --> 00:39:26,910 This is a very cool loophole. 386 00:39:28,150 --> 00:39:30,330 OK, I'm going to talk about something new. 387 00:39:31,150 --> 00:39:37,170 I was going to talk about this video in August, but due to the pandemic, it was postponed to November. 388 00:39:37,170 --> 00:39:39,250 So I was going to talk about this after BlackHat. 389 00:39:39,590 --> 00:39:41,050 OK, I know. 390 00:39:41,050 --> 00:39:43,890 I was going to talk about this after BlackHat or DEFCON. 391 00:39:44,150 --> 00:39:45,910 It looks great. 392 00:39:45,910 --> 00:39:51,030 But postponing to November, if I have to talk about something three months ago, I feel sorry for everyone. 393 00:39:51,030 --> 00:39:53,390 So I added some new things here. 394 00:39:53,390 --> 00:40:02,350 Let's talk about after BlackHat's speech, is there anything new after BlackHat's speech? 395 00:40:03,350 --> 00:40:07,730 First of all, I didn't talk about NSA repaid 396 00:40:10,910 --> 00:40:13,690 a bunch of exchange-related loopholes after my speech . 397 00:40:13,690 --> 00:40:18,930 They didn't name it, but someone called it Proxy Not Found. 398 00:40:19,530 --> 00:40:22,710 This Proxy Not Found was repaid by NSA. 399 00:40:22,970 --> 00:40:25,390 It was fixed in April. 400 00:40:25,390 --> 00:40:33,430 When the fixed version came out, a lot of security companies went to see where the loopholes were. 401 00:40:33,430 --> 00:40:37,330 At that time, there was a Vietnamese national security center. 402 00:40:37,330 --> 00:40:42,130 They found the loopholes and named it Proxy Not Found. 403 00:40:42,130 --> 00:40:42,750 It was... 404 00:40:42,750 --> 00:40:44,170 Forget it. 405 00:40:44,430 --> 00:40:48,850 Proxy Not Found is mainly related to two loopholes. 406 00:40:48,850 --> 00:40:52,470 These two loopholes are pre-auth SSRF. 407 00:40:52,810 --> 00:40:58,390 Of course, NSA found the loopholes under my speech. 408 00:41:00,030 --> 00:41:03,030 Proxy Not Found is very similar to Proxy Logon. 409 00:41:04,110 --> 00:41:08,230 The only difference is in Proxy Logon, cookies are used. 410 00:41:08,330 --> 00:41:11,350 In Proxy Not Found, cookies are different. 411 00:41:11,350 --> 00:41:14,430 But all look codes are the same. 412 00:41:17,350 --> 00:41:19,530 I won't go into details. 413 00:41:19,530 --> 00:41:22,090 You can see the result. 414 00:41:22,090 --> 00:41:25,430 You can see another set of cookies. 415 00:41:25,430 --> 00:41:27,510 This set of cookies is encrypted. 416 00:41:28,830 --> 00:41:30,490 Base64 encoded. 417 00:41:31,910 --> 00:41:35,230 The password is the network address. 418 00:41:35,230 --> 00:41:41,430 If you leave it in the cookie to the other party, Exchange will visit it. 419 00:41:41,850 --> 00:41:45,290 The reason is very similar to Proxy Logon. 420 00:41:47,130 --> 00:41:49,510 Next, Proxy Token. 421 00:41:49,510 --> 00:41:54,890 This is reported by a Vietnamese team. 422 00:41:55,530 --> 00:42:07,830 They reported another set of features related to But it's under the new attack we proposed. 423 00:42:07,830 --> 00:42:11,070 Due to time constraints, we skipped it. 424 00:42:12,010 --> 00:42:27,090 In the patch in April, they added a very good patch so that all attacks related to authentication are fixed. 425 00:42:27,090 --> 00:42:35,270 So after April, many attacks can be reduced. 426 00:42:35,270 --> 00:42:40,670 The method is to verify your current request before the Kerberos Tiki. 427 00:42:41,670 --> 00:42:50,250 This is a very good solution for hackers. 428 00:42:50,330 --> 00:42:54,450 Of course, it's a bad thing for hackers. 429 00:42:54,830 --> 00:43:01,830 So we were thinking after the April patch, what can we do to attack Exchange? 430 00:43:01,990 --> 00:43:06,110 It seems the attack I proposed has become low. 431 00:43:06,110 --> 00:43:10,370 Is there any other way to attack Exchange? 432 00:43:10,370 --> 00:43:13,130 Of course, there are other ways. 433 00:43:13,130 --> 00:43:17,850 For example, Exchange is built on Windows. 434 00:43:17,850 --> 00:43:21,490 It uses many built-in features of Windows . 435 00:43:21,490 --> 00:43:25,430 If there is a problem with those features, there may be a problem with Exchange. 436 00:43:25,430 --> 00:43:30,070 So we came up with a new attack method. 437 00:43:30,590 --> 00:43:34,190 We came up with a new way to attack Exchange. 438 00:43:35,650 --> 00:43:37,650 This is what we are going to talk about today. 439 00:43:37,650 --> 00:43:39,350 It's called Proxy Relay. 440 00:43:41,030 --> 00:43:44,290 Proxy Relay is a new authentication loop. 441 00:43:45,390 --> 00:43:55,410 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. 442 00:43:56,170 --> 00:44:00,630 It has a series of CVEs, but almost every CVE has the same effect. 443 00:44:00,730 --> 00:44:02,590 Some have not been fixed, and some have been fixed. 444 00:44:02,590 --> 00:44:05,510 I will talk about what can be fixed today. 445 00:44:06,410 --> 00:44:08,550 Why do we call it Proxy Relay? 446 00:44:08,550 --> 00:44:12,630 Because it uses the same problem as CES Proxy. 447 00:44:13,190 --> 00:44:16,690 Here we use another method called NTLM Relay. 448 00:44:16,690 --> 00:44:20,210 We put two things together, so we call it Proxy Relay. 449 00:44:20,890 --> 00:44:24,410 This Proxy Relay is not affected by the patch of Microsoft April. 450 00:44:24,610 --> 00:44:31,030 Because it uses another architecture label issue to attack Exchange. 451 00:44:34,330 --> 00:44:41,690 NTLM Relay has been around for a long time, and Microsoft has a lot of mitigation to solve this issue. 452 00:44:41,690 --> 00:44:49,750 First, NTLM Relay requires users to trigger the authentication of NTLM. 453 00:44:49,750 --> 00:44:55,770 But as attackers, we don't want to wait for users to trigger. 454 00:44:55,770 --> 00:44:58,810 We have to trigger this issue. 455 00:44:59,730 --> 00:45:03,450 Here we combine a bug called PrinterBug. 456 00:45:06,610 --> 00:45:19,210 We use PrinterBug to make Microsoft a non-fixable feature so that the server can start the authentication process of NTLM. 457 00:45:19,230 --> 00:45:22,270 So we can turn passive into active. 458 00:45:25,110 --> 00:45:29,330 Some mitigation also prohibit Sandhost Reflection. 459 00:45:29,330 --> 00:45:35,010 You can't relay the NTLM of A to A. 460 00:45:35,770 --> 00:45:41,770 Here we use the idea that in big companies, there is not only one Exchange. 461 00:45:41,770 --> 00:45:44,590 There may be an Exchange Cluster. 462 00:45:44,590 --> 00:45:55,750 If I use NTLM Relay to relay the authentication of Exchange A to Exchange B, this defense won't be able to stop us. 463 00:45:55,870 --> 00:46:07,510 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. 464 00:46:07,510 --> 00:46:09,610 But it has nothing to do with us. 465 00:46:09,610 --> 00:46:15,470 We use HTTP to trigger the attack of NTLM Relay. 466 00:46:15,470 --> 00:46:18,170 So these defenses are not bad for us. 467 00:46:19,990 --> 00:46:23,630 Let's talk about CV2021-33768. 468 00:46:23,710 --> 00:46:26,070 This is a loophole in the July patch. 469 00:46:29,390 --> 00:46:31,490 Microsoft thanked two researchers in this loophole. 470 00:46:31,490 --> 00:46:34,410 One is me, and the other is someone in Tencent. 471 00:46:35,490 --> 00:46:40,630 That person also talked about this loophole in this year's DEFCON . 472 00:46:41,210 --> 00:46:43,530 The concept of this loophole is like this. 473 00:46:43,530 --> 00:46:50,550 You use PrinterBug to relay the NTLM of Exchange A to Exchange B. 474 00:46:51,430 --> 00:46:58,330 Through this NTLM Relay, we can pass the certification of Exchange. 475 00:46:58,970 --> 00:47:08,070 After the certification, we can visit the Exchange such as EWS and manipulate the user's web. 476 00:47:08,070 --> 00:47:10,410 Something like this. 477 00:47:12,070 --> 00:47:13,430 OK. 478 00:47:14,710 --> 00:47:20,930 After that loophole, we also found another similar, but lower-level loophole. 479 00:47:20,930 --> 00:47:23,690 It was also reported to MSRC in June. 480 00:47:23,690 --> 00:47:35,870 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. 481 00:47:37,630 --> 00:47:43,950 So they couldn't push the patch in time in November. 482 00:47:44,130 --> 00:47:49,890 After many discussions, we finally decided not to talk about the details. 483 00:47:50,430 --> 00:47:53,290 But I can still show you the video. 484 00:47:55,670 --> 00:47:56,470 OK. 485 00:47:56,470 --> 00:48:02,250 As you can see, there are two Exchange servers in this attack scenario . 486 00:48:02,250 --> 00:48:05,290 We use Exchange-01 and Exchange-02. 487 00:48:05,290 --> 00:48:07,150 First, let's look at Exchange-02. 488 00:48:07,150 --> 00:48:10,510 It is the latest version. 489 00:48:12,730 --> 00:48:25,290 Next, we use the NTLM RelayX we modified to relay Exchange-01's NTLM to Exchange-02. 490 00:48:26,310 --> 00:48:28,610 Sorry, this is NTLM Relay. 491 00:48:28,610 --> 00:48:29,790 To relay to Exchange-02. 492 00:48:29,790 --> 00:48:38,370 Next, we use Pinterbug to relay Exchange-01's NTLM to Exchange-02. 493 00:48:38,370 --> 00:48:40,110 Then we relay it to Exchange-02. 494 00:48:40,110 --> 00:48:40,790 So here... 495 00:48:40,790 --> 00:48:42,470 It's gone. 496 00:48:42,470 --> 00:48:46,650 Anyway, we can see that we can read the user's email. 497 00:48:48,150 --> 00:48:50,570 Of course, we can do more things. 498 00:48:50,570 --> 00:48:52,850 But this is just an example. 499 00:48:52,850 --> 00:48:55,330 We just want to show its seriousness. 500 00:48:56,310 --> 00:48:57,550 Finally, I'm done. 501 00:48:58,010 --> 00:48:59,950 I still have two pages. 502 00:49:00,770 --> 00:49:03,230 Finally, let's talk about mitigation. 503 00:49:03,370 --> 00:49:08,150 Of course, the most important thing is to keep your Exchange up-to-date. 504 00:49:08,450 --> 00:49:09,370 I've talked about this a lot. 505 00:49:09,370 --> 00:49:10,550 There's nothing more to say. 506 00:49:10,690 --> 00:49:14,350 Another thing I want to talk about is Proxy Relay. 507 00:49:14,350 --> 00:49:16,790 It's a problem of design classification. 508 00:49:16,890 --> 00:49:22,590 You can't simply pass a patch or prevent it in the current stage. 509 00:49:28,490 --> 00:49:34,710 Some mitigations are to turn off the printer bug or the printer spooler service. 510 00:49:34,710 --> 00:49:40,450 Or you don't want to let NTLM authentication exist in your company. 511 00:49:40,690 --> 00:49:47,790 Or if you are too lazy, you can consider putting your Exchange server on the Exchange 365 platform. 512 00:49:48,250 --> 00:49:50,230 Just kidding. 513 00:49:50,830 --> 00:49:53,770 That's all for my speech today. 514 00:49:53,770 --> 00:49:57,050 If you have any questions, feel free to ask me later. 515 00:49:57,050 --> 00:49:57,830 Thank you. 516 00:50:27,050 --> 00:50:29,390 I don't know if you have any questions. 517 00:50:29,970 --> 00:50:32,130 Are you watching the slides? 518 00:50:33,150 --> 00:50:35,610 Let's see if there are any questions. 519 00:50:35,750 --> 00:50:37,890 Is there anyone who has a question? 520 00:50:37,890 --> 00:50:39,490 Sorry, the time is a bit delayed. 521 00:50:39,490 --> 00:50:41,730 Is there anyone? 522 00:50:42,030 --> 00:50:44,050 I have a question. 523 00:50:44,050 --> 00:50:50,190 You just mentioned that you discussed with the Microsoft team not to provide details in the near future. 524 00:50:50,230 --> 00:50:54,570 When do they expect to solve the bug? 525 00:50:54,570 --> 00:50:55,790 They said in December. 526 00:50:55,790 --> 00:50:57,310 But I think it will be delayed. 527 00:50:57,410 --> 00:51:00,330 We usually give them a deadline when we report a bug . 528 00:51:00,350 --> 00:51:02,310 Of course, we are a good company. 529 00:51:02,310 --> 00:51:05,070 Even if we exceed the deadline, we will still do our best. 530 00:51:06,450 --> 00:51:09,830 I originally gave them until September. 531 00:51:09,910 --> 00:51:12,870 But they said it was a problem with the underlying architecture. 532 00:51:12,870 --> 00:51:14,050 They can't just change it. 533 00:51:14,050 --> 00:51:16,910 The deadline they gave is December. 534 00:51:16,910 --> 00:51:24,090 So in December, if everything goes well, the architecture of Exchange will be changed. 535 00:51:24,790 --> 00:51:25,910 Yes. 536 00:51:26,070 --> 00:51:28,410 Are we going to start patching again? 537 00:51:28,410 --> 00:51:30,050 That's you, not us. 538 00:51:31,370 --> 00:51:32,230 Yes. 539 00:51:32,630 --> 00:51:36,510 Actually, for this matter, we have been patching the Exchange server this year. 540 00:51:36,590 --> 00:51:38,250 Yes, I have received complaints from many people. 541 00:51:38,250 --> 00:51:43,690 They said that we reported an Exchange bug every few months , and their company had to work overtime. 542 00:51:43,690 --> 00:51:45,130 Yes. 543 00:51:45,410 --> 00:51:47,610 I don't know if you have any questions. 544 00:51:48,530 --> 00:52:02,810 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 . 545 00:52:03,330 --> 00:52:08,590 You can imagine that Exchange is not designed to be one. 546 00:52:08,590 --> 00:52:10,490 It may have many ports. 547 00:52:10,490 --> 00:52:15,390 So you have to open this port to other Exchange visitors. 548 00:52:16,070 --> 00:52:22,910 So if you can bind it to 127.0.0.1, if you only have one Exchange server, it should be fine. 549 00:52:22,910 --> 00:52:27,610 But usually big companies have more than 20 or even hundreds of Exchange clusters. 550 00:52:27,610 --> 00:52:28,790 There's nothing you can do about it. 551 00:52:28,790 --> 00:52:30,930 Anyway, if it can't be used, it will be changed back. 552 00:52:30,930 --> 00:52:32,110 Yes, it's a problem with the architecture. 553 00:52:32,350 --> 00:52:35,050 Why do I have a source code? 554 00:52:35,050 --> 00:52:37,250 Because Exchange is written in .NET. 555 00:52:37,250 --> 00:52:40,170 Everyone knows .NET. 556 00:52:40,170 --> 00:52:41,390 That's it. 557 00:52:42,390 --> 00:52:43,330 Really? 558 00:52:43,330 --> 00:52:45,050 Can I decompile it? 559 00:52:45,050 --> 00:52:47,630 No, even if you write in C, I can decompile it. 560 00:52:47,790 --> 00:52:49,310 Okay. 561 00:52:50,890 --> 00:52:53,570 Because .NET decompiles relatively easily. 562 00:52:53,970 --> 00:52:54,570 So... 563 00:52:54,570 --> 00:52:55,730 It doesn't mix? 564 00:52:55,730 --> 00:52:56,530 It doesn't. 565 00:52:57,130 --> 00:53:02,450 Later on Twitter, I started to study my results in March and April. 566 00:53:02,450 --> 00:53:07,510 After my results came out, a bunch of people started to research Exchange. 567 00:53:07,510 --> 00:53:13,470 On Twitter, I saw a lot of people complaining that it looked simple, but the architecture was so complicated. 568 00:53:13,750 --> 00:53:17,910 So actually, the threshold to research Exchange is very low. 569 00:53:17,910 --> 00:53:21,850 But its code is too complicated. 570 00:53:21,850 --> 00:53:28,970 So the trouble is you have to understand its architecture and spend a lot of time to read it carefully. 571 00:53:29,530 --> 00:53:34,170 So when you see the source code, it's actually not difficult. 572 00:53:34,270 --> 00:53:36,310 Is it possible that the previous CSS will be changed? 573 00:53:37,470 --> 00:53:38,750 The architecture will be changed. 574 00:53:38,750 --> 00:53:40,450 I just said that it will be changed every three years. 575 00:53:40,850 --> 00:53:41,970 I don't know... 576 00:53:43,550 --> 00:53:46,210 2019 plus three years will be 2022. 577 00:53:46,390 --> 00:53:48,390 The architecture will be changed next year. 578 00:53:50,630 --> 00:53:52,030 Anyone else has a question? 579 00:53:52,030 --> 00:53:53,090 Yes, anyone else has a question? 580 00:53:58,390 --> 00:54:02,130 Okay, if no one has a question, let's thank Orange again. 581 00:54:02,130 --> 00:54:03,430 Okay, thank you. 582 00:54:03,630 --> 00:54:05,750 That's all for today. 583 00:54:05,750 --> 00:54:07,270 You can go home now. 584 00:54:07,270 --> 00:54:07,890 Thank you.