1 00:00:00,240 --> 00:00:01,073 - Okay. 2 00:00:01,073 --> 00:00:01,906 Hi everyone. 3 00:00:01,906 --> 00:00:02,910 Great to be here. 4 00:00:02,910 --> 00:00:05,883 We're both very, very excited. 5 00:00:06,960 --> 00:00:09,783 First, maybe, we wanna thank you for attending, 6 00:00:10,860 --> 00:00:14,640 DEFCON organizers for having us accepting us to talk here, 7 00:00:14,640 --> 00:00:18,693 friends on the first and not the first lines to support. 8 00:00:21,510 --> 00:00:25,533 And thanks for coming to our talk on Microsoft RPC. 9 00:00:26,460 --> 00:00:29,100 We'll start by introducing ourselves. 10 00:00:29,100 --> 00:00:30,180 My name is Ophir. 11 00:00:30,180 --> 00:00:31,920 I lead one of the security teams 12 00:00:31,920 --> 00:00:34,053 in Akamai technologies in Israel. 13 00:00:35,040 --> 00:00:39,480 This is Ben senior security researcher in my team. 14 00:00:39,480 --> 00:00:41,490 These are our Twitter handles. 15 00:00:41,490 --> 00:00:44,970 You're very welcome to follow for more material 16 00:00:44,970 --> 00:00:48,693 and the things that we do and see our work. 17 00:00:50,490 --> 00:00:51,323 Okay. 18 00:00:52,260 --> 00:00:54,360 Why choosing Microsoft RPC 19 00:00:54,360 --> 00:00:56,490 as a vulnerability research target, 20 00:00:56,490 --> 00:00:58,950 and first of all, what is MS-RPC? 21 00:00:58,950 --> 00:01:01,800 So Microsoft Remote Procedure Call, 22 00:01:01,800 --> 00:01:06,690 it's practically an inter-process communication protocol. 23 00:01:06,690 --> 00:01:09,360 It can take place both locally 24 00:01:09,360 --> 00:01:11,610 on a machine between processes, 25 00:01:11,610 --> 00:01:14,730 but also between machines in the network. 26 00:01:14,730 --> 00:01:19,730 And Microsoft's implementation was written somewhere 27 00:01:20,010 --> 00:01:25,010 around the nineties, which is quite a long time ago. 28 00:01:25,020 --> 00:01:30,020 And the most important reason why we chose to try 29 00:01:31,530 --> 00:01:35,820 to target MS-RPC is because it's practically everywhere. 30 00:01:35,820 --> 00:01:39,480 This is a screenshot from a program called RPC View. 31 00:01:39,480 --> 00:01:41,370 It's on GitHub. 32 00:01:41,370 --> 00:01:44,430 There's a link to it if you wanna try it yourself. 33 00:01:44,430 --> 00:01:47,790 And it shows basically all RPC activity on your machine, 34 00:01:47,790 --> 00:01:49,500 on the machine where it runs. 35 00:01:49,500 --> 00:01:52,980 And here we can see a list of many processes 36 00:01:52,980 --> 00:01:57,980 that use RPC in some way, either they host an RPC server 37 00:01:58,140 --> 00:02:01,113 in the process, or they are RPC clients. 38 00:02:02,790 --> 00:02:06,150 Many Windows services use RPC to perform 39 00:02:06,150 --> 00:02:08,670 and expose their functionality over the network 40 00:02:08,670 --> 00:02:10,500 to various clients. 41 00:02:10,500 --> 00:02:12,540 But again, this is on a single machine. 42 00:02:12,540 --> 00:02:16,710 And what I think is very interesting is to see RPC activity 43 00:02:16,710 --> 00:02:17,543 in a network. 44 00:02:17,543 --> 00:02:21,870 And here's a screenshot of one of a random network. 45 00:02:21,870 --> 00:02:24,120 Let's say Windows network, 46 00:02:24,120 --> 00:02:26,910 where the edges represent RPC traffic. 47 00:02:26,910 --> 00:02:31,680 So this specifically is traffic filtered for TCP port 135, 48 00:02:31,680 --> 00:02:34,980 which we will get familiar with soon. 49 00:02:34,980 --> 00:02:38,370 But what I want you to take away from this is that networks, 50 00:02:38,370 --> 00:02:40,650 Windows networks heavily rely 51 00:02:40,650 --> 00:02:43,113 on Microsoft RPC implementation. 52 00:02:45,240 --> 00:02:46,073 Good. 53 00:02:47,280 --> 00:02:50,010 Yet it's everywhere, and there's not a lot 54 00:02:50,010 --> 00:02:51,450 of public research on it. 55 00:02:51,450 --> 00:02:53,850 At least not that we're too familiar with. 56 00:02:53,850 --> 00:02:57,900 So when we try to kind of bootstrap our research 57 00:02:57,900 --> 00:03:00,090 and Google Microsoft RPC, 58 00:03:00,090 --> 00:03:02,190 most of the information we found boiled 59 00:03:02,190 --> 00:03:04,980 to Microsoft's own documentation, 60 00:03:04,980 --> 00:03:08,430 which can be quite dazzling sometimes specifically 61 00:03:08,430 --> 00:03:10,740 with old protocols. 62 00:03:10,740 --> 00:03:12,930 There are several research oriented blog posts 63 00:03:12,930 --> 00:03:15,060 that we will reference to later on 64 00:03:15,060 --> 00:03:18,240 at the end of the presentation 65 00:03:18,240 --> 00:03:20,940 and with regards to public vulnerabilities. 66 00:03:20,940 --> 00:03:23,340 Also, we tried to look for bugs 67 00:03:23,340 --> 00:03:26,190 that were disclosed to Microsoft, 68 00:03:26,190 --> 00:03:28,620 and there weren't a lot of them. 69 00:03:28,620 --> 00:03:30,840 Lately there have been a couple of vulnerabilities 70 00:03:30,840 --> 00:03:32,160 in the RPC runtime. 71 00:03:32,160 --> 00:03:34,615 I don't know if some of you may have heard, 72 00:03:34,615 --> 00:03:37,770 but again, not too many of them not compared 73 00:03:37,770 --> 00:03:40,983 to other products on Windows. 74 00:03:42,960 --> 00:03:44,190 Our assumption again, 75 00:03:44,190 --> 00:03:47,430 is that it's not such a fancy research target 76 00:03:47,430 --> 00:03:50,970 because it's old, as you'll see, it's quite complex. 77 00:03:50,970 --> 00:03:55,970 It has a lot of mechanisms to enforce security, 78 00:03:56,400 --> 00:03:58,830 which are not always synced with each other 79 00:03:58,830 --> 00:04:01,503 and can be quite confusing. 80 00:04:02,910 --> 00:04:03,873 And, 81 00:04:05,580 --> 00:04:08,070 we thought it was actually a good thing 82 00:04:08,070 --> 00:04:10,050 to try to deep dive into. 83 00:04:10,050 --> 00:04:14,100 And what we had in mind was specifically exploiting RPC 84 00:04:14,100 --> 00:04:17,940 or the services that use RPC to gain lateral movement 85 00:04:17,940 --> 00:04:20,790 within a network and gain this ability 86 00:04:20,790 --> 00:04:25,230 to hop from one machine to another, or exploit RPC bugs, 87 00:04:25,230 --> 00:04:27,510 to elevate privileges on a machine. 88 00:04:27,510 --> 00:04:30,660 So, as I mentioned before, many Windows services use it. 89 00:04:30,660 --> 00:04:32,910 They run with higher privileges, 90 00:04:32,910 --> 00:04:36,120 maybe exploiting their RPC server would lead 91 00:04:36,120 --> 00:04:39,063 to having higher privileges ourselves. 92 00:04:41,790 --> 00:04:44,100 So with the motivation in mind, 93 00:04:44,100 --> 00:04:45,780 this is our agenda for today. 94 00:04:45,780 --> 00:04:49,860 I will do the part where we all learn about RPC together. 95 00:04:49,860 --> 00:04:53,190 And then we'll talk about RPC security mechanisms 96 00:04:53,190 --> 00:04:56,790 and demonstrate a bug that he found 97 00:04:56,790 --> 00:04:59,073 in a very common Window service. 98 00:05:00,660 --> 00:05:05,430 This is not getting any less exciting. 99 00:05:05,430 --> 00:05:07,200 I'm still very excited. 100 00:05:07,200 --> 00:05:08,033 Okay. 101 00:05:08,942 --> 00:05:10,140 (audience cheers) 102 00:05:10,140 --> 00:05:10,973 I'm good. 103 00:05:10,973 --> 00:05:11,806 Thanks. 104 00:05:13,350 --> 00:05:14,183 Okay. 105 00:05:14,183 --> 00:05:16,023 So RPC overview, and thank you again. 106 00:05:16,980 --> 00:05:18,030 By the end of my section, 107 00:05:18,030 --> 00:05:21,690 what I want you to have learned is all these terms, 108 00:05:21,690 --> 00:05:23,700 all this terminology that you see here, 109 00:05:23,700 --> 00:05:25,140 it might be a little bit confusing, 110 00:05:25,140 --> 00:05:28,410 but hopefully if I do my job, well, you'll get it right. 111 00:05:28,410 --> 00:05:31,140 So I mentioned before RPC, 112 00:05:31,140 --> 00:05:34,230 inter-process communication protocol, 113 00:05:34,230 --> 00:05:35,970 it's based on a client server model. 114 00:05:35,970 --> 00:05:38,790 So the client wishes to execute some functionality 115 00:05:38,790 --> 00:05:43,260 on a server, local server, remote server, you name it. 116 00:05:43,260 --> 00:05:46,020 In our case, the client wants to run a function called Foo, 117 00:05:46,020 --> 00:05:49,260 which takes two parameters in our case five and hello. 118 00:05:49,260 --> 00:05:52,260 But how does the client know that Foo even exists 119 00:05:52,260 --> 00:05:55,290 that Foo is implemented on this server? 120 00:05:55,290 --> 00:05:58,170 For this purpose we have RPC interfaces 121 00:05:58,170 --> 00:06:03,170 that are written into plain textual files called IDL files, 122 00:06:03,780 --> 00:06:06,120 Interface Definition Language. 123 00:06:06,120 --> 00:06:07,830 If we scan from top to bottom, 124 00:06:07,830 --> 00:06:11,460 we see that an IDL or a very basic IDL file 125 00:06:11,460 --> 00:06:14,940 has the unique identifier of the interface at the top, 126 00:06:14,940 --> 00:06:17,490 the interface name, which in our case is test. 127 00:06:17,490 --> 00:06:20,460 And then the function declarations parameters, 128 00:06:20,460 --> 00:06:24,270 return values, basically their prototypes. 129 00:06:24,270 --> 00:06:25,293 Water, I think. 130 00:06:30,150 --> 00:06:30,983 One minute. 131 00:06:37,020 --> 00:06:37,853 Okay. 132 00:06:38,700 --> 00:06:40,620 So that's a textual file. 133 00:06:40,620 --> 00:06:42,330 Applications can't really use it, right, 134 00:06:42,330 --> 00:06:43,768 so they need code. 135 00:06:43,768 --> 00:06:44,700 For this reason, 136 00:06:44,700 --> 00:06:48,780 Microsoft developed their own ideal compiler called M.I.D.L 137 00:06:48,780 --> 00:06:49,860 or MIDL. 138 00:06:49,860 --> 00:06:54,030 It takes an ideal file as input and then outputs source 139 00:06:54,030 --> 00:06:57,300 and header files that the client and server can use. 140 00:06:57,300 --> 00:06:58,470 So, as you can see here, 141 00:06:58,470 --> 00:07:01,650 we have files for the server and the client 142 00:07:01,650 --> 00:07:04,350 and a header file that is used by both. 143 00:07:04,350 --> 00:07:07,320 The two applications can then include these files 144 00:07:07,320 --> 00:07:12,320 and make whatever use they want with the RPC functionality. 145 00:07:14,490 --> 00:07:17,640 So this is all very conceptual contract, right? 146 00:07:17,640 --> 00:07:20,400 This is how the client knows what the server is capable of, 147 00:07:20,400 --> 00:07:23,910 but how does the client know who to reach out to. 148 00:07:23,910 --> 00:07:25,170 For this reason, 149 00:07:25,170 --> 00:07:28,560 Microsoft came up with the notion of Endpoints 150 00:07:28,560 --> 00:07:30,240 that are basically the gateways 151 00:07:30,240 --> 00:07:33,570 to the RPC server implemented on the server. 152 00:07:33,570 --> 00:07:36,900 So Endpoints can use various transports. 153 00:07:36,900 --> 00:07:40,980 There is a pretty long list of network transports 154 00:07:40,980 --> 00:07:43,920 that can be the basis for the traffic. 155 00:07:43,920 --> 00:07:45,660 Here we have a non-exhaustive list. 156 00:07:45,660 --> 00:07:48,330 So we see TCP, and UDP, HTTP, 157 00:07:48,330 --> 00:07:51,960 named pipes that are based on SMB, et cetera. 158 00:07:51,960 --> 00:07:55,770 For each such transport we have the protocol sequence, 159 00:07:55,770 --> 00:07:57,960 which is a string representing the transport. 160 00:07:57,960 --> 00:08:01,470 And the Endpoints itself is basically the TCP port, 161 00:08:01,470 --> 00:08:06,470 the name of the pipe, the host name for HTTP transports, 162 00:08:06,510 --> 00:08:07,343 et cetera. 163 00:08:08,340 --> 00:08:10,320 What I'd like all of us to remember 164 00:08:10,320 --> 00:08:12,480 for the rest of this talk is that 165 00:08:12,480 --> 00:08:15,210 the interface and the Endpoints are registered separately. 166 00:08:15,210 --> 00:08:16,830 They're not bound to each other. 167 00:08:16,830 --> 00:08:19,470 So if I wanna implement an RPC server, 168 00:08:19,470 --> 00:08:21,420 I can declare a single interface 169 00:08:21,420 --> 00:08:23,550 and have various Endpoints exposing it, 170 00:08:23,550 --> 00:08:25,620 but I can also have various Endpoints 171 00:08:25,620 --> 00:08:28,383 and expose them over a single Endpoints. 172 00:08:30,720 --> 00:08:31,553 Good. 173 00:08:31,553 --> 00:08:33,253 Some examples for Endpoints 174 00:08:33,253 --> 00:08:36,630 that we see on regular Windows machines, 175 00:08:36,630 --> 00:08:38,070 I don't know if you can see this well, 176 00:08:38,070 --> 00:08:41,460 but we see TCP ports here, some named pipes 177 00:08:41,460 --> 00:08:42,930 that some of you may know, 178 00:08:42,930 --> 00:08:47,163 UUIDs for HyperV sockets that are used as transport, 179 00:08:48,030 --> 00:08:49,560 RPC ports, et cetera. 180 00:08:49,560 --> 00:08:52,563 So really there's everything there. 181 00:08:54,930 --> 00:08:56,040 Speaking of Endpoints, 182 00:08:56,040 --> 00:08:57,446 I want to make a distinction 183 00:08:57,446 --> 00:09:00,810 between Well-Known and Dynamic Endpoints. 184 00:09:00,810 --> 00:09:02,790 Well-Known Endpoints, as you can guess, 185 00:09:02,790 --> 00:09:06,840 are known in advance so they can be hard coded in the client 186 00:09:06,840 --> 00:09:09,060 and server applications. 187 00:09:09,060 --> 00:09:13,050 The Endpoints can be hard coded in the ideal file itself, 188 00:09:13,050 --> 00:09:14,460 but eventually the client knows 189 00:09:14,460 --> 00:09:16,140 in advance exactly who to talk to. 190 00:09:16,140 --> 00:09:18,780 So in our example of the client knows that the server 191 00:09:18,780 --> 00:09:22,380 is on TCP port 39776. 192 00:09:22,380 --> 00:09:23,670 But this can lead to trouble 193 00:09:23,670 --> 00:09:28,290 because these Endpoints can be exhausted 194 00:09:28,290 --> 00:09:31,830 or one server can override another server's Endpoint, 195 00:09:31,830 --> 00:09:34,920 so Microsoft came up with dynamic Endpoints 196 00:09:34,920 --> 00:09:36,543 that are dynamically resolved. 197 00:09:37,500 --> 00:09:39,540 For this purpose, we have a Window service 198 00:09:39,540 --> 00:09:42,543 that is called the Endpoint Mapper or EP Mapper. 199 00:09:43,680 --> 00:09:46,020 This is a service that the client can query 200 00:09:46,020 --> 00:09:48,420 for the server's Endpoints. 201 00:09:48,420 --> 00:09:51,690 And actually the EP Mapper itself has a well known Endpoint, 202 00:09:51,690 --> 00:09:53,580 which is TCP port 135. 203 00:09:53,580 --> 00:09:55,710 We saw that before, if you remember. 204 00:09:55,710 --> 00:09:58,170 So the client simply asks the Endpoints Mapper, 205 00:09:58,170 --> 00:09:59,910 please give me the Endpoints 206 00:09:59,910 --> 00:10:03,810 for server whose interface UUID is yada yada yada, 207 00:10:03,810 --> 00:10:07,050 and they get in return the TCP port or named pipe, 208 00:10:07,050 --> 00:10:10,410 or whatever it is they need to actually use. 209 00:10:10,410 --> 00:10:11,493 So this is it. 210 00:10:12,720 --> 00:10:15,450 Now just some examples of Windows services 211 00:10:15,450 --> 00:10:17,880 and their Endpoints and interface, UUIDs. 212 00:10:17,880 --> 00:10:22,880 I took three, hopefully famous Windows services here. 213 00:10:23,610 --> 00:10:25,980 At the top is the task scheduler service. 214 00:10:25,980 --> 00:10:30,360 We see that it implements three different RPC interfaces, 215 00:10:30,360 --> 00:10:32,700 each with its UUID 216 00:10:32,700 --> 00:10:34,950 but there is no Endpoints specified here. 217 00:10:34,950 --> 00:10:36,270 There's no Endpoints mentioned. 218 00:10:36,270 --> 00:10:41,270 So it's a dynamically resolved server or Endpoints, sorry. 219 00:10:42,720 --> 00:10:46,980 The Service Control Manager, SCM remote protocol has a UUID 220 00:10:46,980 --> 00:10:49,890 for an interface and a well known named pipe 221 00:10:49,890 --> 00:10:52,620 that we see over there at the middle. 222 00:10:52,620 --> 00:10:54,180 And the encrypting file system, 223 00:10:54,180 --> 00:10:55,380 may be some of you have heard it 224 00:10:55,380 --> 00:10:59,763 due to somewhat recently disclose vulnerabilities. 225 00:11:00,660 --> 00:11:03,870 This one has actually two well known Endpoints, 226 00:11:03,870 --> 00:11:08,160 two named pipes, and also two RPC interfaces. 227 00:11:08,160 --> 00:11:10,740 This is all in Microsoft's portal. 228 00:11:10,740 --> 00:11:14,733 It's documented in their technical documentation section. 229 00:11:16,680 --> 00:11:17,513 Okay. 230 00:11:17,513 --> 00:11:18,346 So dynamic resolution. 231 00:11:18,346 --> 00:11:21,690 Let's see what it looks like by observing network traffic. 232 00:11:21,690 --> 00:11:23,310 This is a screenshot from our shark. 233 00:11:23,310 --> 00:11:28,310 Obviously we start by querying the Endpoint Mapper. 234 00:11:28,320 --> 00:11:32,160 Obviously we start with the TCP handshake over TCP port 135. 235 00:11:32,160 --> 00:11:33,180 We do this handshake. 236 00:11:33,180 --> 00:11:36,930 And then we move on to sort of what I like to call 237 00:11:36,930 --> 00:11:40,590 the RPC handshake, which is also called the binding process. 238 00:11:40,590 --> 00:11:41,850 And once we're done with that, 239 00:11:41,850 --> 00:11:45,480 we can query the Endpoints Mapper for the service Endpoints. 240 00:11:45,480 --> 00:11:49,980 In this case, we're asking for the task scheduler Endpoints. 241 00:11:49,980 --> 00:11:54,000 And now that we have this information returned to us 242 00:11:54,000 --> 00:11:54,960 by the Endpoint Mapper. 243 00:11:54,960 --> 00:11:59,373 We can move on to talk directly to the task scheduler, 244 00:12:00,720 --> 00:12:02,880 TCP handshake, as we can expect, 245 00:12:02,880 --> 00:12:04,320 and then the binding process again, 246 00:12:04,320 --> 00:12:06,360 and then we have an established session 247 00:12:06,360 --> 00:12:07,683 with the task scheduler. 248 00:12:10,170 --> 00:12:13,050 I mentioned binding, so let's cover this one. 249 00:12:13,050 --> 00:12:15,630 Binding is basically the representation 250 00:12:15,630 --> 00:12:19,830 or logical representation of the client server session. 251 00:12:19,830 --> 00:12:22,470 Practically, it's a handle of a Windows object 252 00:12:22,470 --> 00:12:25,980 and both client and server can set and manipulate data 253 00:12:25,980 --> 00:12:27,360 on this object. 254 00:12:27,360 --> 00:12:29,640 We will see later on that it is mostly used 255 00:12:29,640 --> 00:12:31,593 for authentication purposes. 256 00:12:34,260 --> 00:12:37,140 I think we sort of covered all terms at this point. 257 00:12:37,140 --> 00:12:39,270 So let's try to kind of wrap it up 258 00:12:39,270 --> 00:12:42,870 with the full communication flow. 259 00:12:42,870 --> 00:12:45,420 So the clients, as we already know, 260 00:12:45,420 --> 00:12:47,670 it tries to call Foo function. 261 00:12:47,670 --> 00:12:48,990 This function is, 262 00:12:48,990 --> 00:12:50,970 when it's compiled by the Microsoft compiler, 263 00:12:50,970 --> 00:12:54,483 it calls RPC runtime function called NdrClientCall. 264 00:12:55,800 --> 00:12:57,390 I didn't mention the RPC runtime, 265 00:12:57,390 --> 00:13:01,530 but that's a library called rpcrt4.dll. 266 00:13:01,530 --> 00:13:02,850 It implements both the client 267 00:13:02,850 --> 00:13:07,650 and the servers side of RPC operations or functionality. 268 00:13:07,650 --> 00:13:11,340 On the client side it does all sorts of things, 269 00:13:11,340 --> 00:13:12,870 marshaling the parameters, 270 00:13:12,870 --> 00:13:16,380 namely converting them into network, group presentation, 271 00:13:16,380 --> 00:13:18,960 being responsible for connecting to the Endpoint 272 00:13:18,960 --> 00:13:21,843 on the server and authenticating if necessary. 273 00:13:22,950 --> 00:13:26,040 On the server side, after the connection has been made, 274 00:13:26,040 --> 00:13:29,550 the RPC is well before that it's responsible for listening 275 00:13:29,550 --> 00:13:30,383 on the Endpoints, 276 00:13:30,383 --> 00:13:33,420 then doing the reverse operation of unmarshalling, 277 00:13:33,420 --> 00:13:37,590 the parameters that were sent to or with the function 278 00:13:37,590 --> 00:13:40,770 and perform access checks on the RPC interface. 279 00:13:40,770 --> 00:13:42,303 We'll get into that as well. 280 00:13:43,590 --> 00:13:45,940 Eventually the RPC runtime calls Foo 281 00:13:47,210 --> 00:13:49,410 and Foo is implemented 282 00:13:49,410 --> 00:13:51,063 on the server and being executed. 283 00:13:52,590 --> 00:13:56,640 How does the RPC time actually specify FOO? 284 00:13:56,640 --> 00:13:59,250 Well, it doesn't have Foo as a string, 285 00:13:59,250 --> 00:14:02,940 it rather has an ordinal number of Foo. 286 00:14:02,940 --> 00:14:06,270 So we already know FOO is declared in an ideal file. 287 00:14:06,270 --> 00:14:08,970 It's then compiled to a client's stub. 288 00:14:08,970 --> 00:14:12,090 And this stub calls the RPC runtime 289 00:14:12,090 --> 00:14:15,300 where one of the parameters specify the ordinal number 290 00:14:15,300 --> 00:14:18,180 of the function in the interface file. 291 00:14:18,180 --> 00:14:19,830 So since Foo is our first, 292 00:14:19,830 --> 00:14:23,070 the operation number or opnum is zero. 293 00:14:23,070 --> 00:14:24,480 If it were the second function, 294 00:14:24,480 --> 00:14:27,750 it would be a one there and et cetera. 295 00:14:27,750 --> 00:14:31,530 So actually remember opnum because it's important 296 00:14:31,530 --> 00:14:34,353 for the rest of the talk. 297 00:14:35,460 --> 00:14:36,293 Okay. 298 00:14:36,293 --> 00:14:37,890 So I think now we're really are done. 299 00:14:37,890 --> 00:14:39,630 We'll just have a quick recap. 300 00:14:39,630 --> 00:14:42,630 Things are not aligned as I was expecting them to be, 301 00:14:42,630 --> 00:14:44,100 but okay. 302 00:14:44,100 --> 00:14:45,270 So interface, 303 00:14:45,270 --> 00:14:49,380 it's the logical representation or conceptual agreement 304 00:14:49,380 --> 00:14:52,170 between the client and the server specifies the functions 305 00:14:52,170 --> 00:14:55,470 and represented by a unique identifier, a UUID. 306 00:14:55,470 --> 00:14:57,630 The transport is the communication medium. 307 00:14:57,630 --> 00:15:01,440 It's represented by a string called protocol sequence. 308 00:15:01,440 --> 00:15:03,180 The Endpoint is the actual destination 309 00:15:03,180 --> 00:15:04,710 or gateway to connect to. 310 00:15:04,710 --> 00:15:07,050 It's represented by a port number, 311 00:15:07,050 --> 00:15:10,710 a pipe name, an RPC port, et cetera. 312 00:15:10,710 --> 00:15:12,780 The binding is the session itself 313 00:15:12,780 --> 00:15:15,840 and represented by a binding handle. 314 00:15:15,840 --> 00:15:19,860 So I think we should all be somewhat RPC experts 315 00:15:19,860 --> 00:15:22,290 at this point, and I'll hand the ball to Ben 316 00:15:22,290 --> 00:15:24,393 to talk about RPC security and the bug. 317 00:15:25,765 --> 00:15:28,598 (audience cheers) 318 00:15:32,430 --> 00:15:33,750 - Thank you Ophir. 319 00:15:33,750 --> 00:15:36,893 So I'm going to talk about MS-RPC security, 320 00:15:36,893 --> 00:15:41,460 and I'm going to divide this part into two subparts. 321 00:15:41,460 --> 00:15:44,820 The first one is MS-RPC security mechanisms, 322 00:15:44,820 --> 00:15:48,150 and this subpart is also the basis for the second one, 323 00:15:48,150 --> 00:15:51,063 security related problems in MS-RPC. 324 00:15:52,290 --> 00:15:53,891 - Closer. 325 00:15:53,891 --> 00:15:55,160 Thank you. 326 00:15:55,160 --> 00:15:58,140 - So the first thing I wanna begin with 327 00:15:58,140 --> 00:15:59,970 is that the security mechanisms 328 00:15:59,970 --> 00:16:01,440 are basically a complete mess. 329 00:16:01,440 --> 00:16:03,510 There are multiple security mechanisms. 330 00:16:03,510 --> 00:16:06,450 There are system wide policies, flags, 331 00:16:06,450 --> 00:16:08,880 and various combinations of those. 332 00:16:08,880 --> 00:16:13,440 So basically it's very easy for developer to make a mistake 333 00:16:13,440 --> 00:16:16,713 while trying to secure the interface. 334 00:16:17,610 --> 00:16:20,220 In our talk we try to simplify this part 335 00:16:20,220 --> 00:16:23,880 and we are going to mostly focus on remote communication. 336 00:16:23,880 --> 00:16:25,980 For each security mechanism, 337 00:16:25,980 --> 00:16:29,370 we are going to specify relevant flags. 338 00:16:29,370 --> 00:16:32,940 Those flags are set during the interface registration 339 00:16:32,940 --> 00:16:34,233 by the server side. 340 00:16:35,190 --> 00:16:38,670 And the first authentication, the first security mechanism 341 00:16:38,670 --> 00:16:41,100 that I would like to talk about is authentication. 342 00:16:41,100 --> 00:16:42,960 And even for authentication, 343 00:16:42,960 --> 00:16:45,210 we have two types of authentication. 344 00:16:45,210 --> 00:16:49,260 The first one is not really explicitly set by the server 345 00:16:49,260 --> 00:16:51,090 or the client. 346 00:16:51,090 --> 00:16:54,450 It happens as part of the network interaction. 347 00:16:54,450 --> 00:16:59,190 So for example, when we used an Endpoint like HTTP, 348 00:16:59,190 --> 00:17:02,910 then HTTP uses IIS authentication. 349 00:17:02,910 --> 00:17:07,350 And more commonly used is the named pipe Endpoint. 350 00:17:07,350 --> 00:17:12,350 And the named pipe Endpoint is carried over SMB protocol. 351 00:17:12,690 --> 00:17:17,690 And the SMB protocol has authentication as part 352 00:17:17,730 --> 00:17:18,567 of the protocol. 353 00:17:18,567 --> 00:17:21,330 And it basically requires us to have a valid user 354 00:17:21,330 --> 00:17:22,920 for the target machine. 355 00:17:22,920 --> 00:17:25,500 In a domain environment, this is not really a problem. 356 00:17:25,500 --> 00:17:27,480 We have our own domain user, 357 00:17:27,480 --> 00:17:32,480 and that's enough to pass this check against another machine 358 00:17:32,550 --> 00:17:33,780 in the same domain. 359 00:17:33,780 --> 00:17:36,270 But if we're in some random network, 360 00:17:36,270 --> 00:17:38,190 some public wifi, for example, 361 00:17:38,190 --> 00:17:42,180 then unless we have the credentials of a local account. 362 00:17:42,180 --> 00:17:46,410 On that machine, we cannot pass this check. 363 00:17:46,410 --> 00:17:47,460 And in the past, 364 00:17:47,460 --> 00:17:50,130 they used to be the option to specify 365 00:17:50,130 --> 00:17:52,320 or use the NA session access, 366 00:17:52,320 --> 00:17:56,460 which basically means providing no user at all. 367 00:17:56,460 --> 00:17:58,800 These days it doesn't work anymore, 368 00:17:58,800 --> 00:18:02,664 but there is one caveat and that's the DC 369 00:18:02,664 --> 00:18:05,310 only for those specific named pipes. 370 00:18:05,310 --> 00:18:08,190 So those are configured in a system-wide policy. 371 00:18:08,190 --> 00:18:10,890 And basically what it means is that, 372 00:18:10,890 --> 00:18:15,300 an unauthenticated client coming from outside the domain 373 00:18:15,300 --> 00:18:18,570 can connect to those specific named pipes 374 00:18:18,570 --> 00:18:20,373 on the DC domain control. 375 00:18:21,570 --> 00:18:23,160 So is it the end of the wall 376 00:18:23,160 --> 00:18:25,800 if we decide to use an unauthenticated transports 377 00:18:25,800 --> 00:18:28,410 like TCP or UDP? 378 00:18:28,410 --> 00:18:29,400 The answer is no, 379 00:18:29,400 --> 00:18:32,070 because there's another authentication 380 00:18:32,070 --> 00:18:34,770 and this is authenticated binding. 381 00:18:34,770 --> 00:18:36,360 So just a quick reminder, 382 00:18:36,360 --> 00:18:39,960 binding is the representation of a logical connection 383 00:18:39,960 --> 00:18:42,450 between a client and a server. 384 00:18:42,450 --> 00:18:45,150 So authenticated binding is a binding 385 00:18:45,150 --> 00:18:47,250 that has authentication info. 386 00:18:47,250 --> 00:18:48,083 And that happens 387 00:18:48,083 --> 00:18:50,610 when the server registers authentication info 388 00:18:50,610 --> 00:18:53,640 and the client sets authentication info. 389 00:18:53,640 --> 00:18:57,240 Why do we actually need this mechanism? 390 00:18:57,240 --> 00:18:59,910 Well, it gives us the option 391 00:18:59,910 --> 00:19:02,370 to have identity based access control 392 00:19:02,370 --> 00:19:06,690 and also various network protections. 393 00:19:06,690 --> 00:19:09,990 So we can have the advocacy called encrypted, 394 00:19:09,990 --> 00:19:13,590 or temple proof against many of the middle attacks 395 00:19:13,590 --> 00:19:14,940 or spoofing. 396 00:19:14,940 --> 00:19:17,310 And the level of protection is specified 397 00:19:17,310 --> 00:19:21,570 by the authentication, authentication level. 398 00:19:21,570 --> 00:19:23,847 This is said by the client and later on, 399 00:19:23,847 --> 00:19:26,733 the server can inquire what level was used. 400 00:19:27,960 --> 00:19:30,993 So how does this process look behind the scenes? 401 00:19:32,190 --> 00:19:36,150 Basically, there's a bind packets exchange. 402 00:19:36,150 --> 00:19:39,210 Those contain the authentication info section. 403 00:19:39,210 --> 00:19:40,200 And at the end of the day, 404 00:19:40,200 --> 00:19:44,760 you have the security provider to handle this data. 405 00:19:44,760 --> 00:19:47,790 So basically you have the NTLM security provider 406 00:19:47,790 --> 00:19:50,760 or the KBOs one or negotiate 407 00:19:50,760 --> 00:19:54,060 which chooses the best available option 408 00:19:54,060 --> 00:19:56,970 between NTLM and KBOs. 409 00:19:56,970 --> 00:19:58,230 And as you can see here, 410 00:19:58,230 --> 00:20:00,480 we have a snippet from wild shark 411 00:20:00,480 --> 00:20:02,850 and it has the authentication info section. 412 00:20:02,850 --> 00:20:06,270 And we can see the NTLM security provider is used. 413 00:20:06,270 --> 00:20:11,270 And also the authentication level is sixth packet privacy, 414 00:20:12,210 --> 00:20:13,233 the highest one. 415 00:20:14,100 --> 00:20:18,840 The end result of this process is a security context. 416 00:20:18,840 --> 00:20:21,900 And the security context is somewhat similar 417 00:20:21,900 --> 00:20:23,250 to a normal binding. 418 00:20:23,250 --> 00:20:26,250 You can inquire information like what level was used, 419 00:20:26,250 --> 00:20:27,873 what security provider was used. 420 00:20:29,280 --> 00:20:30,113 Okay. 421 00:20:30,113 --> 00:20:33,003 So what's the catch with authenticated binding. 422 00:20:33,870 --> 00:20:37,230 If the server registered authentication info, 423 00:20:37,230 --> 00:20:41,340 it doesn't mean that the client is going to authenticate. 424 00:20:41,340 --> 00:20:45,600 He's not enforced to, he is not obligated to authenticate. 425 00:20:45,600 --> 00:20:50,190 So basically what that means is unauthenticated clients 426 00:20:50,190 --> 00:20:52,290 can still access the interface, 427 00:20:52,290 --> 00:20:56,250 even if the server did register authentication info. 428 00:20:56,250 --> 00:20:59,490 And we can see this in this access metrics below, 429 00:20:59,490 --> 00:21:03,600 we have an unauthenticated client from the client side 430 00:21:03,600 --> 00:21:06,600 and authenticated binding from the server side, 431 00:21:06,600 --> 00:21:08,700 and the end result is still success. 432 00:21:08,700 --> 00:21:11,280 The client can access the interface. 433 00:21:11,280 --> 00:21:13,920 Obviously if we are a server developers 434 00:21:13,920 --> 00:21:16,020 and we register authentication info, 435 00:21:16,020 --> 00:21:18,960 that means that we want the client to authenticate. 436 00:21:18,960 --> 00:21:20,670 So what can we do? 437 00:21:20,670 --> 00:21:22,380 We can specify the following flag. 438 00:21:22,380 --> 00:21:26,820 And the follow flag basically tells the RPC runtime 439 00:21:26,820 --> 00:21:31,110 to make sure that the client uses an authentication level 440 00:21:31,110 --> 00:21:32,220 of at least one, 441 00:21:32,220 --> 00:21:35,733 which basically means that the client indeed authenticated. 442 00:21:36,630 --> 00:21:37,463 Okay. 443 00:21:37,463 --> 00:21:40,043 So let's move to another security mechanism. 444 00:21:40,043 --> 00:21:42,630 This is the Security Descriptor. 445 00:21:42,630 --> 00:21:44,040 And the Security Descriptor 446 00:21:44,040 --> 00:21:48,990 is a general Windows security mechanism. 447 00:21:48,990 --> 00:21:52,290 The concept is that we can set a Security Descriptor 448 00:21:52,290 --> 00:21:56,520 on a Windows object and the security contains rules 449 00:21:56,520 --> 00:21:58,770 like this user can access the object, 450 00:21:58,770 --> 00:22:00,990 this user cannot access the object, 451 00:22:00,990 --> 00:22:04,410 this group can access the object, et cetera, et cetera. 452 00:22:04,410 --> 00:22:08,640 Later on, when a client tries to access the object, 453 00:22:08,640 --> 00:22:11,340 then Windows are going to compare his access token 454 00:22:11,340 --> 00:22:13,443 against the Security Descriptor. 455 00:22:14,340 --> 00:22:16,050 And in our case, 456 00:22:16,050 --> 00:22:20,340 the object is the end point and the interface. 457 00:22:20,340 --> 00:22:23,310 So it can set the Security Descriptor on both the Endpoints 458 00:22:23,310 --> 00:22:26,643 and the interface, or none of them. 459 00:22:27,930 --> 00:22:28,763 Cool. 460 00:22:28,763 --> 00:22:32,460 So this is an example of a real Security Descriptor. 461 00:22:32,460 --> 00:22:36,120 We can see the Security Descriptor thing and we can convert 462 00:22:36,120 --> 00:22:37,800 it into something readable. 463 00:22:37,800 --> 00:22:42,800 This is from service called App ID service. 464 00:22:45,360 --> 00:22:46,193 Yeah. 465 00:22:46,193 --> 00:22:49,350 So we're going to move to the last security mechanism. 466 00:22:49,350 --> 00:22:51,570 And this is also the one that we believe 467 00:22:51,570 --> 00:22:53,370 to be the most interesting one. 468 00:22:53,370 --> 00:22:55,410 This is the security callback. 469 00:22:55,410 --> 00:22:58,860 And the security callback is basically function callback 470 00:22:58,860 --> 00:23:01,500 that is called every time the client tries 471 00:23:01,500 --> 00:23:04,590 to access a function on the server. 472 00:23:04,590 --> 00:23:07,050 And the logic of the security callback 473 00:23:07,050 --> 00:23:08,370 is up to the developer. 474 00:23:08,370 --> 00:23:10,687 They can write whatever they wanted, 475 00:23:10,687 --> 00:23:15,687 but the purpose is to restrict access to specific functions 476 00:23:15,810 --> 00:23:18,993 or users or groups, et cetera, et cetera. 477 00:23:20,280 --> 00:23:24,060 So here we have the prototype of the call back. 478 00:23:24,060 --> 00:23:27,000 It basically receive the interface UUID. 479 00:23:27,000 --> 00:23:28,530 And also the context 480 00:23:28,530 --> 00:23:30,660 which the server can inquire information 481 00:23:30,660 --> 00:23:34,833 about the call, or the user, or the connection. 482 00:23:35,670 --> 00:23:37,980 Now, one small thing to note is 483 00:23:37,980 --> 00:23:40,350 if the server registers a security call back 484 00:23:40,350 --> 00:23:42,270 then unauthenticated clients 485 00:23:42,270 --> 00:23:45,390 are going to be denied automatically. 486 00:23:45,390 --> 00:23:48,720 So this is another way to prevent authenticated kinds 487 00:23:48,720 --> 00:23:50,553 from accessing the interface. 488 00:23:51,690 --> 00:23:55,590 Let's move to some examples to get ourselves familiar 489 00:23:55,590 --> 00:23:57,570 with security callbacks. 490 00:23:57,570 --> 00:24:00,415 So here we have the task scheduler security callback, 491 00:24:00,415 --> 00:24:03,910 and we can notice that it checks the authentication level 492 00:24:04,873 --> 00:24:06,180 is at least packet privacy. 493 00:24:06,180 --> 00:24:09,450 The highest one also checks the protocol sequence 494 00:24:09,450 --> 00:24:10,743 that the client used. 495 00:24:12,606 --> 00:24:14,400 So here we have the IAS, 496 00:24:14,400 --> 00:24:17,610 which checks if the client is a remote one, and if it is, 497 00:24:17,610 --> 00:24:20,520 then it needs to use at least packet privacy. 498 00:24:20,520 --> 00:24:24,453 Authentication level also checks the protocol sequence. 499 00:24:26,190 --> 00:24:27,630 Here we have the DHCP one, 500 00:24:27,630 --> 00:24:31,440 which checks basically the protocol sequence. 501 00:24:31,440 --> 00:24:33,367 And finally, we have LSASS. 502 00:24:33,367 --> 00:24:36,660 And LSASS does things a little bit differently. 503 00:24:36,660 --> 00:24:41,280 It makes a distinction, separation distinction 504 00:24:41,280 --> 00:24:43,680 based upon the opnum that the client call. 505 00:24:43,680 --> 00:24:46,260 So if the client calls opnum zero, for example, 506 00:24:46,260 --> 00:24:50,520 then the transport that should have been used is TCP 507 00:24:50,520 --> 00:24:53,520 and opnum one then it needs to be named pipe, 508 00:24:53,520 --> 00:24:54,663 et cetera, et cetera. 509 00:24:56,010 --> 00:24:56,843 Cool. 510 00:24:56,843 --> 00:25:00,360 So this flag relates to what I've said before 511 00:25:00,360 --> 00:25:02,460 about the automatic behavior 512 00:25:02,460 --> 00:25:07,460 of automatically denying access to unauthenticated clients. 513 00:25:07,710 --> 00:25:11,820 And basically this flags just disabled this behavior. 514 00:25:11,820 --> 00:25:15,990 So it allows or gives the chance to unauthenticated client 515 00:25:15,990 --> 00:25:18,090 to still access the interface 516 00:25:18,090 --> 00:25:20,403 if they pass the security callback. 517 00:25:23,730 --> 00:25:24,563 Okay. 518 00:25:24,563 --> 00:25:28,470 So we talked about some security mechanisms and we talked 519 00:25:28,470 --> 00:25:30,780 about some caveats of those. 520 00:25:30,780 --> 00:25:35,780 Let's talk about two design flaws that we found interesting. 521 00:25:35,910 --> 00:25:39,240 And the first one is actually somewhat described 522 00:25:39,240 --> 00:25:42,420 by Microsoft "Beware of other RPC Endpoints running 523 00:25:42,420 --> 00:25:43,980 in the same process." 524 00:25:43,980 --> 00:25:46,200 And basically what it means is, 525 00:25:46,200 --> 00:25:48,480 let's imagine the foreign scenario, we have a client 526 00:25:48,480 --> 00:25:51,610 and a server and interface A registers 527 00:25:52,950 --> 00:25:57,000 is a local interface and interface B is a remote one. 528 00:25:57,000 --> 00:26:00,000 So interface A is supposed to be accessible only 529 00:26:00,000 --> 00:26:01,770 for local clients. 530 00:26:01,770 --> 00:26:06,660 And therefore we told local privileged operations 531 00:26:06,660 --> 00:26:09,330 interface B is for remote times. 532 00:26:09,330 --> 00:26:13,110 So interface A registers an RPC Endpoint, 533 00:26:13,110 --> 00:26:15,450 which is only accessible locally. 534 00:26:15,450 --> 00:26:18,210 You can't use RPC over the network. 535 00:26:18,210 --> 00:26:21,180 It's an IPC protocol 536 00:26:21,180 --> 00:26:24,930 and interface B registers at TCP Endpoint, 537 00:26:24,930 --> 00:26:27,660 which is a remote one, socket. 538 00:26:27,660 --> 00:26:30,570 So the client can access interface A, 539 00:26:30,570 --> 00:26:32,400 the local one using RPC, 540 00:26:32,400 --> 00:26:37,053 and it can also access interface B the remote one using TCP. 541 00:26:37,920 --> 00:26:39,630 But here's the actual catch, 542 00:26:39,630 --> 00:26:43,590 the client can access interface B the remote one 543 00:26:43,590 --> 00:26:45,720 using a RPC. 544 00:26:45,720 --> 00:26:50,670 And more than that, it can actually access the interface A, 545 00:26:50,670 --> 00:26:52,770 the local one using TCP. 546 00:26:52,770 --> 00:26:56,250 And basically what that means is that a remote machine 547 00:26:56,250 --> 00:27:00,060 can access the local interface using TCP 548 00:27:00,060 --> 00:27:04,590 and therefore access privileged operations. 549 00:27:04,590 --> 00:27:07,260 And there is another one problem here, 550 00:27:07,260 --> 00:27:10,050 and that happens when interface A registers, 551 00:27:10,050 --> 00:27:13,110 a Security Descriptor on the Endpoint. 552 00:27:13,110 --> 00:27:16,020 And the reason is because the client can just use 553 00:27:16,020 --> 00:27:19,287 the TCP Endpoint and bypass this mechanism, 554 00:27:19,287 --> 00:27:20,613 the security check. 555 00:27:21,810 --> 00:27:23,940 So why does this happen? 556 00:27:23,940 --> 00:27:25,590 This happen, this relates to what? 557 00:27:25,590 --> 00:27:28,020 something that I feel said before, 558 00:27:28,020 --> 00:27:31,440 interfaces are not bound to Endpoints, 559 00:27:31,440 --> 00:27:35,100 and basically we can have multiple Endpoints 560 00:27:35,100 --> 00:27:37,470 and we can access each one of the interfaces 561 00:27:37,470 --> 00:27:40,440 using each one of the Endpoints. 562 00:27:40,440 --> 00:27:43,050 But in what real life scenario, 563 00:27:43,050 --> 00:27:46,860 we will not be aware of other Endpoints running 564 00:27:46,860 --> 00:27:48,630 in the same process. 565 00:27:48,630 --> 00:27:50,910 So in Windows, when you write a service, 566 00:27:50,910 --> 00:27:52,890 then this service is going to be run 567 00:27:52,890 --> 00:27:55,380 inside the SVC host process. 568 00:27:55,380 --> 00:28:00,150 And that SVC host process might run other services as well. 569 00:28:00,150 --> 00:28:03,480 So you might share the same SVC host process 570 00:28:03,480 --> 00:28:05,520 with other RPC servers 571 00:28:05,520 --> 00:28:09,753 that did in fact register other Endpoints. 572 00:28:10,980 --> 00:28:13,530 So what can we do to prevent this from happening? 573 00:28:13,530 --> 00:28:15,210 We can specify the following flag. 574 00:28:15,210 --> 00:28:18,840 And the following flag basically tells the RPC runtime 575 00:28:18,840 --> 00:28:22,590 to make sure that the client that accesses the interface 576 00:28:22,590 --> 00:28:23,940 is a local one. 577 00:28:23,940 --> 00:28:26,940 So it doesn't matter what Endpoint it's used, 578 00:28:26,940 --> 00:28:28,680 it must be a local client. 579 00:28:28,680 --> 00:28:31,350 And about the Security Descriptor problem, 580 00:28:31,350 --> 00:28:34,710 well, Microsoft just recommends to not use it 581 00:28:34,710 --> 00:28:35,793 on the Endpoint. 582 00:28:37,830 --> 00:28:41,940 Now let's move to another design flaw we found interesting, 583 00:28:41,940 --> 00:28:46,320 this is undocumented, this is the security callback caching. 584 00:28:46,320 --> 00:28:49,590 And I'm going to explain it using the following diagram. 585 00:28:49,590 --> 00:28:51,480 So let's say we have a client and a server, 586 00:28:51,480 --> 00:28:55,710 and the server exposes several functions, 587 00:28:55,710 --> 00:28:59,070 opnum zero and opnum one, et cetera, et cetera. 588 00:28:59,070 --> 00:29:01,350 And the client tries to call opnum zero. 589 00:29:01,350 --> 00:29:05,070 And the security callback is called, and it says, 590 00:29:05,070 --> 00:29:08,340 opnum zero, okay, you can access this function. 591 00:29:08,340 --> 00:29:10,530 Now the client has to call opnum one 592 00:29:10,530 --> 00:29:14,400 and the security Callback is called, and it says opnum one. 593 00:29:14,400 --> 00:29:16,683 Yeah, not really, access denied. 594 00:29:17,970 --> 00:29:20,940 So this is what you would expect to happen. 595 00:29:20,940 --> 00:29:25,140 But then security call back cashing comes right in 596 00:29:25,140 --> 00:29:27,030 and changes what happens. 597 00:29:27,030 --> 00:29:30,044 So this is how it actually goes. 598 00:29:30,044 --> 00:29:33,780 The client calls opnum zero, the Security Callback is called 599 00:29:33,780 --> 00:29:37,230 and it says, okay yeah, you can access this function. 600 00:29:37,230 --> 00:29:39,750 And now the result is actually cached. 601 00:29:39,750 --> 00:29:42,240 So the next time the same client 602 00:29:42,240 --> 00:29:45,540 is going to call the same interface. 603 00:29:45,540 --> 00:29:47,850 Then the cash is going to be used. 604 00:29:47,850 --> 00:29:51,390 So the client calls opnum one, and the, IPC says, okay, 605 00:29:51,390 --> 00:29:55,350 same client, same interface, you can access this function. 606 00:29:55,350 --> 00:29:58,440 And this is obviously not something that we want. 607 00:29:58,440 --> 00:30:00,240 This is a dangerous behavior. 608 00:30:00,240 --> 00:30:02,250 The client can now access opnum one, 609 00:30:02,250 --> 00:30:06,930 although it should not be possible, not supposed to be. 610 00:30:06,930 --> 00:30:10,413 So when does this actually happen? 611 00:30:11,610 --> 00:30:13,380 This is actually the default behavior 612 00:30:13,380 --> 00:30:17,340 for Security Callbacks, but there is one requirement, 613 00:30:17,340 --> 00:30:20,640 the whole caching mechanism depends or relies 614 00:30:20,640 --> 00:30:25,560 upon the context identifier of the security context. 615 00:30:25,560 --> 00:30:28,380 So the security context is the output 616 00:30:28,380 --> 00:30:30,330 of the authentication process. 617 00:30:30,330 --> 00:30:33,060 So basically if the binding is not authenticated, 618 00:30:33,060 --> 00:30:34,773 then there's no cash in. 619 00:30:36,210 --> 00:30:39,000 And what can we do to prevent this from happening? 620 00:30:39,000 --> 00:30:40,800 By now you should have guessed. 621 00:30:40,800 --> 00:30:43,260 We can use one of the two following flags. 622 00:30:43,260 --> 00:30:45,840 The first one is somewhat documented. 623 00:30:45,840 --> 00:30:48,480 The other one is not documented. 624 00:30:48,480 --> 00:30:49,950 The first one, basically disables 625 00:30:49,950 --> 00:30:51,750 the whole caching mechanism 626 00:30:51,750 --> 00:30:54,720 and the other one changes the default behavior 627 00:30:54,720 --> 00:30:58,830 to be on a call basis instead of an interface basis. 628 00:30:58,830 --> 00:31:00,300 And that basically means that 629 00:31:00,300 --> 00:31:01,770 if the client calls opnum zero, 630 00:31:01,770 --> 00:31:05,970 then cash entry is going to be created for opnum zero. 631 00:31:05,970 --> 00:31:07,650 And if it's going to call opnum one, 632 00:31:07,650 --> 00:31:09,390 then it's not the same function. 633 00:31:09,390 --> 00:31:11,310 The security call back will be called 634 00:31:11,310 --> 00:31:13,350 and returns access denied. 635 00:31:13,350 --> 00:31:16,140 And if it does decide to call the same function again, 636 00:31:16,140 --> 00:31:18,720 then the cash entry will be used 637 00:31:18,720 --> 00:31:20,943 and it can access opnum zero. 638 00:31:22,631 --> 00:31:23,464 Okay. 639 00:31:23,464 --> 00:31:26,100 So just a quick recap, 640 00:31:26,100 --> 00:31:30,000 we talked about a security mechanism, some caveats, 641 00:31:30,000 --> 00:31:32,730 some interesting design flaws. 642 00:31:32,730 --> 00:31:34,410 And in our research, 643 00:31:34,410 --> 00:31:35,850 we found the Security Callback 644 00:31:35,850 --> 00:31:37,650 to be the most interesting place 645 00:31:37,650 --> 00:31:40,203 to look into an interesting attack surface. 646 00:31:41,700 --> 00:31:45,390 So we decided to look into multiple services 647 00:31:45,390 --> 00:31:47,370 and also the Security callbacks, 648 00:31:47,370 --> 00:31:50,010 and by doing so we found couple of vulnerabilities, 649 00:31:50,010 --> 00:31:52,680 but most of them are still under disclosure. 650 00:31:52,680 --> 00:31:54,930 There is one interesting vulnerability 651 00:31:54,930 --> 00:31:56,490 that we can talk about, 652 00:31:56,490 --> 00:32:00,690 and this is a bug in the server service. 653 00:32:00,690 --> 00:32:03,330 So I'm going to talk about the bug and the exploitation, 654 00:32:03,330 --> 00:32:05,013 and also show a quick demo. 655 00:32:06,210 --> 00:32:08,070 So the server service, 656 00:32:08,070 --> 00:32:11,010 which is also known as landman server 657 00:32:11,010 --> 00:32:13,110 is the service that is responsible 658 00:32:13,110 --> 00:32:14,700 for the management of shelves. 659 00:32:14,700 --> 00:32:17,850 Well, shelves are basically resources like folders 660 00:32:17,850 --> 00:32:20,310 or printers, for example, 661 00:32:20,310 --> 00:32:23,520 that are shelve with other network machines. 662 00:32:23,520 --> 00:32:27,120 The service runs by default on all Windows machines, 663 00:32:27,120 --> 00:32:31,530 and it is accessible to the named pipe Lserver service 664 00:32:31,530 --> 00:32:34,500 From now on I'm gonna call it Lserver service for gravity. 665 00:32:34,500 --> 00:32:36,603 It is just much easier. 666 00:32:37,620 --> 00:32:39,870 So let's take a look at the Security Callback 667 00:32:39,870 --> 00:32:41,910 of Lserver service, 668 00:32:41,910 --> 00:32:46,290 and basically the logic of the security callback implemented 669 00:32:46,290 --> 00:32:50,190 by the server is to check that if the client tries 670 00:32:50,190 --> 00:32:55,110 to access the range of ordinances between 64 to 69, 671 00:32:55,110 --> 00:32:58,530 then deny access if he's a remote client. 672 00:32:58,530 --> 00:33:02,103 So those functions are only available to local clients. 673 00:33:03,060 --> 00:33:04,500 And when we saw this code, 674 00:33:04,500 --> 00:33:08,893 we kind of TOIs that may be in other RPC services 675 00:33:10,710 --> 00:33:12,180 that implement similar logic, 676 00:33:12,180 --> 00:33:16,900 or maybe in your versions of this service, 677 00:33:17,815 --> 00:33:22,260 they might screw up and there will be availability. 678 00:33:22,260 --> 00:33:23,790 So we decided to be on the lookout 679 00:33:23,790 --> 00:33:27,240 and look for newer versions. 680 00:33:27,240 --> 00:33:29,950 And when we looked into Lserver service 681 00:33:31,320 --> 00:33:34,440 Security Callback in Windows 1020H2, 682 00:33:34,440 --> 00:33:37,440 we noticed that four new functions were added, 683 00:33:37,440 --> 00:33:40,740 but the range also changed to include them. 684 00:33:40,740 --> 00:33:43,230 So there is no vulnerability here. 685 00:33:43,230 --> 00:33:44,670 The code is still okay. 686 00:33:44,670 --> 00:33:46,320 And at this point we thought, okay, 687 00:33:46,320 --> 00:33:48,180 well maybe they have a mark 688 00:33:48,180 --> 00:33:50,970 to somehow automatically calculate this range 689 00:33:50,970 --> 00:33:53,580 and it wouldn't have any vulnerability. 690 00:33:53,580 --> 00:33:55,560 But we didn't give up and we decide 691 00:33:55,560 --> 00:33:59,010 to look into Windows 11 Security Call back. 692 00:33:59,010 --> 00:34:02,700 And in Windows 11, we noticed that a new function was added 693 00:34:02,700 --> 00:34:04,860 and the Security Callback didn't change. 694 00:34:04,860 --> 00:34:08,100 The range did not change at all. 695 00:34:08,100 --> 00:34:09,810 And the function is a local one. 696 00:34:09,810 --> 00:34:10,643 It's local. 697 00:34:10,643 --> 00:34:12,960 Our server certificate mapping modified. 698 00:34:12,960 --> 00:34:15,150 This is obviously a local one 699 00:34:15,150 --> 00:34:17,910 and the range does not include this function now. 700 00:34:17,910 --> 00:34:20,610 So that means that a remote machine 701 00:34:20,610 --> 00:34:22,533 can now access this function. 702 00:34:23,970 --> 00:34:25,621 And this is obviously availability, 703 00:34:25,621 --> 00:34:30,063 which see the foreign CVE with CSS score 8.8. 704 00:34:31,020 --> 00:34:35,640 So before we talk about what we can do with this function 705 00:34:35,640 --> 00:34:38,970 and exploitation, let's talk about what it relates to. 706 00:34:38,970 --> 00:34:43,590 And this relates to a feature called SMB over QUIC, 707 00:34:45,300 --> 00:34:49,080 where SMB is the SMB protocol and QUIC 708 00:34:49,080 --> 00:34:54,080 is somewhat new transport layer protocol designed by Google, 709 00:34:55,080 --> 00:34:58,980 not that long ago with the purpose of being secure 710 00:34:58,980 --> 00:35:02,223 and privacy in mind, and also low latency. 711 00:35:03,870 --> 00:35:08,250 And as part of the network interaction in QUIC, 712 00:35:08,250 --> 00:35:12,660 the server provides a certificate and that allows the client 713 00:35:12,660 --> 00:35:14,910 to verify the identity of the server, 714 00:35:14,910 --> 00:35:17,970 basically that prevents spoofing attacks 715 00:35:17,970 --> 00:35:19,470 or many in the middle attacks. 716 00:35:20,430 --> 00:35:22,560 And those new functions that were added, 717 00:35:22,560 --> 00:35:25,440 they basically manage the symbolic link 718 00:35:25,440 --> 00:35:28,980 between a QUIC certificate to a real certificate 719 00:35:28,980 --> 00:35:32,460 in the Windows certificate store. 720 00:35:32,460 --> 00:35:36,183 So certificate mapping is basically a symbolic link. 721 00:35:38,550 --> 00:35:40,440 So as you can understand, 722 00:35:40,440 --> 00:35:44,580 we can modify an existing certificate mapping 723 00:35:44,580 --> 00:35:47,130 and therefore do some tampering many 724 00:35:47,130 --> 00:35:48,930 in the middle attacks maybe, 725 00:35:48,930 --> 00:35:52,500 but we asked ourself, can we do more than that? 726 00:35:52,500 --> 00:35:54,780 And when we looked into the structure 727 00:35:54,780 --> 00:35:57,780 that the function receives, this is after everything, 728 00:35:57,780 --> 00:36:01,410 we notice the store location variable. 729 00:36:01,410 --> 00:36:04,320 And this variable is basically the path 730 00:36:04,320 --> 00:36:07,200 of the Windows certificate store. 731 00:36:07,200 --> 00:36:09,120 And we thought, okay, well, 732 00:36:09,120 --> 00:36:12,720 what would happen if we provide a UNC path? 733 00:36:12,720 --> 00:36:14,490 And the UNC path is basically the path 734 00:36:14,490 --> 00:36:16,530 of another network machine. 735 00:36:16,530 --> 00:36:17,880 And by doing so, 736 00:36:17,880 --> 00:36:21,720 we managed to cause the RPC server, call, 737 00:36:21,720 --> 00:36:25,350 send an RPC request to a machine that we can control. 738 00:36:25,350 --> 00:36:27,554 And why is this interesting? 739 00:36:27,554 --> 00:36:31,260 That's interesting because part of this interaction, 740 00:36:31,260 --> 00:36:35,730 the RPC server presents his authentication info. 741 00:36:35,730 --> 00:36:38,430 And we can now take this authentication info 742 00:36:38,430 --> 00:36:41,730 and relate onto another network machine, 743 00:36:41,730 --> 00:36:46,057 basically impersonating the RPC server and saying, 744 00:36:46,057 --> 00:36:50,010 "Hi, I'm that RPC server, here's my authentication info." 745 00:36:50,010 --> 00:36:52,143 Let me access your service. 746 00:36:53,250 --> 00:36:55,890 So for those of you who are familiar with (unintelligible) 747 00:36:55,890 --> 00:36:58,520 or with DFS coarce or shadow coarse, 748 00:36:58,520 --> 00:37:01,260 this is the same exact scenario. 749 00:37:01,260 --> 00:37:05,190 We have an authentication coarsion vulnerability. 750 00:37:05,190 --> 00:37:08,310 And in order to exploit this, 751 00:37:08,310 --> 00:37:13,310 I base the exploitation on a research by Specter Ops guys, 752 00:37:13,330 --> 00:37:15,540 where they found out that you can relay 753 00:37:15,540 --> 00:37:18,390 the authentication info of the DC, 754 00:37:18,390 --> 00:37:21,150 the Domain Controller to ADCS, 755 00:37:21,150 --> 00:37:24,390 the Active Directory Certificate Service. 756 00:37:24,390 --> 00:37:27,510 And by doing so you can receive a certificate 757 00:37:27,510 --> 00:37:31,260 of the DC machine, and I'm gonna work 758 00:37:31,260 --> 00:37:32,160 through the exploitation. 759 00:37:32,160 --> 00:37:36,033 Although this is not the main part of the talk. 760 00:37:37,410 --> 00:37:39,840 So we begin by using the vulnerability. 761 00:37:39,840 --> 00:37:42,720 We found the authentication coarsion. 762 00:37:42,720 --> 00:37:46,500 And as a result, we get the credentials of the DC. 763 00:37:46,500 --> 00:37:48,420 Once we have the credentials of the DC, 764 00:37:48,420 --> 00:37:53,420 we can relay it onto the ADCS and we get a certificate 765 00:37:53,550 --> 00:37:55,470 from the ADCS. 766 00:37:55,470 --> 00:38:00,470 Using this certificate, we can now request a Kerberos TGT 767 00:38:01,320 --> 00:38:03,810 and with the Kerberos TGT, 768 00:38:03,810 --> 00:38:06,060 we can now perform DC sync attack, 769 00:38:06,060 --> 00:38:11,060 which basically allows us to retrieve NTLM hashes 770 00:38:11,910 --> 00:38:13,950 of local accounts. 771 00:38:13,950 --> 00:38:17,580 And finally, once we have the NTLM hash of an account, 772 00:38:17,580 --> 00:38:22,580 we can use past the hash attack and get a shell. 773 00:38:22,980 --> 00:38:25,923 So I'm going to show a quick demo of this. 774 00:38:32,926 --> 00:38:37,926 One second. 775 00:38:59,706 --> 00:39:03,456 (speaks in foreign language) 776 00:39:04,605 --> 00:39:05,522 One second. 777 00:39:09,750 --> 00:39:10,583 Okay. 778 00:39:17,970 --> 00:39:20,940 - We do have it on a here. 779 00:39:20,940 --> 00:39:23,103 So maybe wait one second. 780 00:39:28,200 --> 00:39:29,403 That had to happen. 781 00:39:46,044 --> 00:39:50,211 (conversing in foreign language) 782 00:39:52,710 --> 00:39:54,903 Do we have speaker offs here somewhere? 783 00:39:56,400 --> 00:39:57,270 Speaker goon. 784 00:39:57,270 --> 00:39:58,770 Somebody? 785 00:39:58,770 --> 00:39:59,940 - Yeah, the files. 786 00:39:59,940 --> 00:40:01,640 - We have a demo we wanna show it. 787 00:40:11,280 --> 00:40:15,060 Can we access the sync folder here from this laptop? 788 00:40:15,060 --> 00:40:15,893 It's here. 789 00:40:18,750 --> 00:40:19,623 Saturday. 790 00:40:20,490 --> 00:40:21,323 Track three. 791 00:40:26,820 --> 00:40:27,653 - Yeah, you're up. 792 00:40:27,653 --> 00:40:28,486 - Okay. - We're up? 793 00:40:28,486 --> 00:40:29,490 - Yeah. - Yeah. 794 00:40:29,490 --> 00:40:30,323 - Does it play? 795 00:40:32,610 --> 00:40:33,747 No, it's not. 796 00:40:41,206 --> 00:40:42,330 It's not showing. 797 00:40:42,330 --> 00:40:43,470 We see it. 798 00:40:43,470 --> 00:40:44,730 You wanna come here? 799 00:40:44,730 --> 00:40:45,852 Watch it with us. 800 00:40:45,852 --> 00:40:47,834 (audience laughing) 801 00:40:47,834 --> 00:40:50,223 - If you have to mirror your display in order to do that. 802 00:40:50,223 --> 00:40:51,056 - How? 803 00:40:52,578 --> 00:40:54,245 - The AV guy's come. 804 00:41:01,803 --> 00:41:02,833 - She has a video on. 805 00:41:02,833 --> 00:41:04,710 - Yeah, yeah, yeah, but you got her an extended view. 806 00:41:04,710 --> 00:41:06,720 So only you're gonna look at it. 807 00:41:06,720 --> 00:41:08,430 But what we can do is I can go to logo. 808 00:41:08,430 --> 00:41:10,200 You can put it on mirror and then point at me 809 00:41:10,200 --> 00:41:11,213 and I'll bring it back up and then it'll go. 810 00:41:11,213 --> 00:41:13,113 - But can we just flip the mirror now? 811 00:41:14,023 --> 00:41:15,523 - You can do that. 812 00:41:17,765 --> 00:41:19,682 - Do you know how to... 813 00:41:35,250 --> 00:41:36,990 - That's why I said it would've been better to go to logo. 814 00:41:36,990 --> 00:41:38,640 So nobody would've seen all this. 815 00:41:44,850 --> 00:41:46,083 - How are you doing all? 816 00:41:47,310 --> 00:41:48,330 Please be patient. 817 00:41:48,330 --> 00:41:49,920 Just one more minute. 818 00:41:49,920 --> 00:41:51,243 We really wanna show it. 819 00:41:55,917 --> 00:41:56,956 - There you go. 820 00:41:56,956 --> 00:41:57,789 - Okay. 821 00:42:01,242 --> 00:42:02,075 - All right. 822 00:42:02,075 --> 00:42:03,242 So, all right. 823 00:42:08,416 --> 00:42:12,083 (speaking foreign language) 824 00:42:25,710 --> 00:42:26,543 Okay. 825 00:42:26,543 --> 00:42:28,410 So we have here this machine, 826 00:42:28,410 --> 00:42:30,600 this is the machine that we're going to attack. 827 00:42:30,600 --> 00:42:32,550 And here we have the relay machine. 828 00:42:32,550 --> 00:42:33,750 This is the Linux machine, 829 00:42:33,750 --> 00:42:36,330 which is going to relay the credentials 830 00:42:36,330 --> 00:42:38,910 of the DC to the ADCS. 831 00:42:38,910 --> 00:42:41,700 And here we have the attacker machine. 832 00:42:41,700 --> 00:42:42,533 This is the one 833 00:42:42,533 --> 00:42:45,363 that is going to trigger the bandwidth that we found, 834 00:42:46,920 --> 00:42:51,153 and we are going to initiate the request. 835 00:42:54,540 --> 00:42:57,570 And as you can see, we receive the certificate 836 00:42:57,570 --> 00:42:59,730 of the DC. 837 00:42:59,730 --> 00:43:02,160 That means that the attack worked. 838 00:43:02,160 --> 00:43:05,280 And now we're going to use the full exploitation. 839 00:43:05,280 --> 00:43:08,070 We are going to use a tool called Rubeus 840 00:43:08,070 --> 00:43:12,263 and use the certificate to request a Kerberos TGT. 841 00:43:15,132 --> 00:43:18,890 Now we are going to just make sure that the Kerberos TGT 842 00:43:18,890 --> 00:43:23,387 was imported into the klist, the local Kerberos, 843 00:43:23,387 --> 00:43:25,006 a digital list. 844 00:43:25,006 --> 00:43:28,777 And now we are going to use the tool, 845 00:43:28,777 --> 00:43:32,027 mimic cats to perform this sync attack. 846 00:43:33,424 --> 00:43:38,424 And now we're going to actually retrieve the NTLM hash 847 00:43:38,640 --> 00:43:41,790 and with the NTLM hash, 848 00:43:41,790 --> 00:43:46,130 we can now perform past the hatch attack using wmiexec 849 00:43:46,130 --> 00:43:50,823 to basically get a shell on the DC machine. 850 00:43:59,400 --> 00:44:00,233 Cool. 851 00:44:00,233 --> 00:44:01,556 So we are running inside the DC. 852 00:44:01,556 --> 00:44:04,389 (audience cheers) 853 00:44:12,471 --> 00:44:13,304 Okay. 854 00:44:13,304 --> 00:44:14,733 So back to presentation. 855 00:44:16,770 --> 00:44:18,390 So to summarize, 856 00:44:18,390 --> 00:44:19,650 we found the security callbacks 857 00:44:19,650 --> 00:44:21,990 to be an interesting attack surface, 858 00:44:21,990 --> 00:44:25,800 specifically those who deal with opnums, 859 00:44:25,800 --> 00:44:28,080 also because of cashing. 860 00:44:28,080 --> 00:44:32,430 We encourage other researchers to look into other services. 861 00:44:32,430 --> 00:44:34,710 Also as SMB over QUIC. 862 00:44:34,710 --> 00:44:36,960 We also believe the RPC runtime 863 00:44:36,960 --> 00:44:39,183 to be under research target. 864 00:44:40,260 --> 00:44:44,490 The blog post and POC will be shortly available 865 00:44:44,490 --> 00:44:46,620 in akamai's blogpost. 866 00:44:46,620 --> 00:44:50,730 Also stay tuned because we have other vulnerabilities 867 00:44:50,730 --> 00:44:52,140 that are still under disclosure. 868 00:44:52,140 --> 00:44:53,670 So once they're fixed, 869 00:44:53,670 --> 00:44:55,803 we will share the details. 870 00:44:56,700 --> 00:44:57,990 And finally, 871 00:44:57,990 --> 00:45:01,680 those are some references to some great blog post 872 00:45:01,680 --> 00:45:03,540 by other autos. 873 00:45:03,540 --> 00:45:07,713 This is also the opportunity to thank them for those. 874 00:45:09,060 --> 00:45:10,233 And that's it. 875 00:45:11,129 --> 00:45:13,962 (audience cheers) 876 00:45:18,240 --> 00:45:21,060 If you have any questions, then feel free to approach us. 877 00:45:21,060 --> 00:45:24,183 So you can also send us a message in Twitter.