1 00:00:00,042 --> 00:00:01,999 NEIL SIKKA: Hi, DEF CON. 2 00:00:02,334 --> 00:00:06,042 My name is Neil Sikka, and today I'm going to talking 3 00:00:06,042 --> 00:00:09,209 about EMET 4.0 PKI mitigation. 4 00:00:09,334 --> 00:00:13,999 So EMET is a tool from Microsoft, and it's a free tool 5 00:00:13,999 --> 00:00:19,083 to mitigate different various attack techniques. 6 00:00:19,125 --> 00:00:22,999 So a little bit about me. 7 00:00:23,000 --> 00:00:28,000 So I'm a security engineer on MSRC, Microsoft Security Response Center. 8 00:00:28,125 --> 00:00:32,417 I look at 0days that have been, like, in the wild or privately responsibly 9 00:00:32,417 --> 00:00:34,999 reported vulnerabilities. 10 00:00:35,000 --> 00:00:36,834 I'm an EMET developer. 11 00:00:37,042 --> 00:00:40,000 I like blogging after work and on my free time about technology 12 00:00:40,000 --> 00:00:43,083 and security at Neil's Computer Blog. 13 00:00:43,083 --> 00:00:45,999 And I'm on Twitter if you want to talk to me or something. 14 00:00:47,999 --> 00:00:51,417 So an overview about what I'm going to be talking about today. 15 00:00:51,626 --> 00:00:54,876 So, first, I will be going into what EMET is followed 16 00:00:54,876 --> 00:00:59,209 by new features in EMET 4.0, the architecture of EMET and then I 17 00:00:59,209 --> 00:01:02,542 will be taking a deep dive into the PKI feature 18 00:01:02,542 --> 00:01:07,876 of EMET which was our first non memory corruption mitigation. 19 00:01:07,876 --> 00:01:11,751 And then I will be giving a demo that hopefully works live. 20 00:01:14,250 --> 00:01:16,501 So, first of all, what is EMET? 21 00:01:16,999 --> 00:01:21,083 EMET is a tool that mitigates different exploitation techniques. 22 00:01:21,083 --> 00:01:23,167 It has been historically for memory corruptions 23 00:01:23,167 --> 00:01:28,083 and stopping exploits that take advantage of memory corruptions. 24 00:01:29,083 --> 00:01:31,999 And one thing about it is that it is not signature based, rather it 25 00:01:31,999 --> 00:01:33,751 is behavioral based. 26 00:01:33,999 --> 00:01:35,250 For example, you don't need signatures for it 27 00:01:35,250 --> 00:01:37,834 or anything like that because it just looks for behaviors, 28 00:01:37,834 --> 00:01:40,501 common shell code behaviors, for example. 29 00:01:40,626 --> 00:01:44,667 So it could stop things that people don't know about or even Microsoft doesn't 30 00:01:44,667 --> 00:01:46,209 know about. 31 00:01:46,209 --> 00:01:47,459 So, for example, 0days. 32 00:01:47,459 --> 00:01:52,542 We have used it recommended it to mitigate some advisories in the past. 33 00:01:53,375 --> 00:01:55,876 And because it's dynamically loaded at runtime, it 34 00:01:55,876 --> 00:01:59,792 is like a DLL that gets loaded into your process address base. 35 00:01:59,792 --> 00:02:02,292 So it doesn't require, like, recompiling or redeploying 36 00:02:02,292 --> 00:02:04,250 your application. 37 00:02:04,501 --> 00:02:06,250 And so if you have a million computers or whatever, 38 00:02:06,250 --> 00:02:09,542 you don't have to go and do that for all of them. 39 00:02:09,626 --> 00:02:11,999 And it works on all supported platforms so far. 40 00:02:11,999 --> 00:02:13,918 So right now it's XP is still supported so as far 41 00:02:13,918 --> 00:02:17,999 as XP and it is a way to giving back to the security community and it 42 00:02:17,999 --> 00:02:19,834 is a free tool. 43 00:02:20,834 --> 00:02:23,999 So what applications does it work on? 44 00:02:24,083 --> 00:02:25,999 Like, these are some of them. 45 00:02:25,999 --> 00:02:31,584 So as you can see, like, IE, Skype, Office, Chrome. 46 00:02:31,584 --> 00:02:34,999 It is basically Microsoft and third party applications. 47 00:02:37,918 --> 00:02:41,667 So some changes between EMET 3.0 and 4.0. 48 00:02:42,709 --> 00:02:47,667 First of all, we added the certificate trust PKI mitigation. 49 00:02:47,667 --> 00:02:50,209 So a lot of talks this year at DEF CON have been about man 50 00:02:50,209 --> 00:02:54,083 in the middle and abusing PKI and stuff like that. 51 00:02:54,501 --> 00:02:56,292 I'm not saying that PKI itself is bad or something, 52 00:02:56,292 --> 00:02:58,834 but I'm saying sometimes it can be weakly implemented 53 00:02:58,834 --> 00:03:01,083 or badly implemented if you use short keys or stuff 54 00:03:01,083 --> 00:03:02,834 for your roots. 55 00:03:03,542 --> 00:03:06,876 That was mitigation we added for that. 56 00:03:06,999 --> 00:03:10,918 We added a mitigation for ROP exploits and hardening 57 00:03:10,918 --> 00:03:17,999 for ROP exploitations and so you can have cool skins and stuff like that. 58 00:03:22,083 --> 00:03:24,999 So, I'm going to first go into the memory corruption mitigation 59 00:03:24,999 --> 00:03:26,959 that is we've had. 60 00:03:26,999 --> 00:03:32,999 So we have basically forcing DEP on, which is data execution prevention. 61 00:03:32,999 --> 00:03:35,709 It is basically by calling said process that we are 62 00:03:35,709 --> 00:03:39,292 trying to protect with the DEP protection. 63 00:03:39,292 --> 00:03:42,125 This is so you are not executing code on pages that are not supposed 64 00:03:42,125 --> 00:03:45,999 to be executable, that are supposed to be read and write. 65 00:03:46,459 --> 00:03:48,083 We have the heap spray mitigation which 66 00:03:48,083 --> 00:03:51,667 reserves not commits virtual addresses that are commonly used 67 00:03:51,667 --> 00:03:53,501 by heap sprays. 68 00:03:53,501 --> 00:03:57,999 So yeah, it reserves it using those API. 69 00:03:58,083 --> 00:04:00,918 We have mandatory ASLR which prefers 70 00:04:00,918 --> 00:04:05,876 the module loading base address so the module cannot end 71 00:04:05,876 --> 00:04:08,292 up loading there. 72 00:04:08,292 --> 00:04:11,292 It reserves it so it is not able to load there so it has 73 00:04:11,292 --> 00:04:14,334 to load somewhere else which is effectively ASLR, 74 00:04:14,334 --> 00:04:17,999 but obviously newer techniques on newer versions of Windows 75 00:04:17,999 --> 00:04:21,751 is safer and has higher entropy and stuff. 76 00:04:22,542 --> 00:04:28,292 We have the null page mitigation where it reserves page address zero so you 77 00:04:28,292 --> 00:04:32,918 can't refuse null pointer references or bugs. 78 00:04:34,209 --> 00:04:39,292 Export address table filtering, that's basically if shell coded 79 00:04:39,292 --> 00:04:43,125 for someone is trying to read the address table, 80 00:04:43,125 --> 00:04:48,125 the hardware breakpoint on the export address table makes sure 81 00:04:48,125 --> 00:04:53,999 EIPs, which is an instruction pointer, don't point to some random place 82 00:04:53,999 --> 00:04:59,918 like in the heap, for example, because that's kind of creepy. 83 00:04:59,999 --> 00:05:02,542 And then we also did bottom up randomization where we randomize 84 00:05:02,542 --> 00:05:06,125 different data structures in the process address base. 85 00:05:06,417 --> 00:05:09,999 As I mentioned earlier, these are all memory corruption mitigations. 86 00:05:11,584 --> 00:05:16,792 And so some more memory corruption mitigations are the C hub which 87 00:05:16,792 --> 00:05:19,667 is overwrite protection. 88 00:05:19,751 --> 00:05:24,709 This is where we reverse the exception, the chain of them, looking 89 00:05:24,709 --> 00:05:29,999 for one whose previous pointer is 1 because that's what we expect 90 00:05:29,999 --> 00:05:31,626 to see. 91 00:05:31,626 --> 00:05:33,999 And if we don't see that, then we know that something has been 92 00:05:33,999 --> 00:05:36,417 corrupted and that's bad. 93 00:05:36,792 --> 00:05:40,125 And, finally, our ROP mitigation is new in EMET 4.0. 94 00:05:41,542 --> 00:05:43,792 We have some hardenings for this. 95 00:05:43,792 --> 00:05:45,751 For example, deep hook is where we protect things 96 00:05:45,751 --> 00:05:49,083 like virtual protect and virtual protect EX. 97 00:05:49,083 --> 00:05:53,083 So an API it would call, you can't bypass it. 98 00:05:53,083 --> 00:05:56,999 We have anti detours which is basically preventing an attacker 99 00:05:56,999 --> 00:06:01,918 from jumping over the detoured part of a function, so basically jumping 100 00:06:01,918 --> 00:06:04,334 over our hook kind of. 101 00:06:04,584 --> 00:06:09,125 And band functions where we disallow specifically in this release it 102 00:06:09,125 --> 00:06:14,083 is disallowing calling NTTLs LDR hot patch routine. 103 00:06:14,083 --> 00:06:18,626 That's thanks to Yang Yu from KenSec West this year. 104 00:06:21,876 --> 00:06:26,751 So our ROP mitigation, okay, I'm going to try to explain ROP 105 00:06:26,751 --> 00:06:28,834 in one slide. 106 00:06:28,834 --> 00:06:30,959 We will see if it works. 107 00:06:31,083 --> 00:06:33,876 So return oriented programming. 108 00:06:33,876 --> 00:06:38,667 And it is basically the shiny technique for bypassing DEP. 109 00:06:38,999 --> 00:06:43,626 Basically what happens is the attacker is in a control stack. 110 00:06:43,751 --> 00:06:45,999 As you know, a call stack has return pointers 111 00:06:45,999 --> 00:06:51,918 to where the execution is supposed to return after you get out of a function. 112 00:06:51,999 --> 00:06:53,999 So what the attacker does is they return 113 00:06:53,999 --> 00:06:57,501 they set these return pointers to a few to always point 114 00:06:57,501 --> 00:07:01,584 to loaded modules that are valid to be executed. 115 00:07:02,417 --> 00:07:06,125 A few instructions before a RET instruction so you can 116 00:07:06,125 --> 00:07:11,584 chain these together and then you can try to (beeping) then you can basically 117 00:07:11,584 --> 00:07:14,209 try to achieve the attacker's attention 118 00:07:14,209 --> 00:07:17,501 without actually injecting code. 119 00:07:17,501 --> 00:07:20,459 You are reusing code that's already valid to be executed. 120 00:07:21,083 --> 00:07:25,459 So things like virtual protect, for example, or commonly ROP 121 00:07:25,459 --> 00:07:30,999 to memory protection on pages, that's used by a lot of exploits. 122 00:07:31,083 --> 00:07:36,417 Stack pivot is a pivotal technique inside the ROP exploits 123 00:07:36,417 --> 00:07:42,542 to basically switch the ESP to where it is currently pointing 124 00:07:42,542 --> 00:07:49,542 to on a regular stack to the attacker controlled call stack. 125 00:07:49,542 --> 00:07:52,334 I have more information about this in the presentation I did 126 00:07:52,334 --> 00:07:54,751 at NullCon about ROP. 127 00:07:54,751 --> 00:07:56,083 That was in greater detail. 128 00:07:56,083 --> 00:07:57,918 This is just one slide, like I said. 129 00:07:57,918 --> 00:08:00,959 Hopefully you all got what I am talking about. 130 00:08:00,999 --> 00:08:01,999 Okay. 131 00:08:01,999 --> 00:08:04,918 So some of the ROP mitigations, these are new in 4.0 from 3.0., 132 00:08:04,918 --> 00:08:07,375 include the load library mitigation which 133 00:08:07,375 --> 00:08:10,542 is basically to make sure you are not loading DLLs 134 00:08:10,542 --> 00:08:14,751 from network shares because that's kind of creepy. 135 00:08:15,167 --> 00:08:18,125 The memory protection, we are making sure you are not making 136 00:08:18,125 --> 00:08:20,999 stack pages executable because stack pages are supposed 137 00:08:20,999 --> 00:08:23,999 to be data so read and write, not execute. 138 00:08:24,584 --> 00:08:28,542 The caller mitigation, where we basically make sure that 139 00:08:28,542 --> 00:08:33,542 the return address IS where this current frame's return address points 140 00:08:33,542 --> 00:08:37,792 to a location that's preceded by a call address which calls 141 00:08:37,792 --> 00:08:39,751 this function. 142 00:08:39,792 --> 00:08:43,709 So that's basically so that you're not returning to this function. 143 00:08:43,999 --> 00:08:46,999 The sim exploit where we don't RET to ROP gadgets 144 00:08:46,999 --> 00:08:49,834 after this function returns. 145 00:08:49,999 --> 00:08:53,250 And the stack pivot which is basically where we check 146 00:08:53,250 --> 00:08:57,999 the ESPx86 registry to make sure it is between the stack pivot and 147 00:08:57,999 --> 00:09:03,292 the stack base that's identified by the TEB for our process. 148 00:09:03,292 --> 00:09:05,501 And my co worker did a good presentation 149 00:09:05,501 --> 00:09:08,999 about a deep presentation about the ROP mitigation 150 00:09:08,999 --> 00:09:12,959 in his Recon presentation from this year. 151 00:09:16,083 --> 00:09:17,167 Okay. 152 00:09:17,167 --> 00:09:19,876 So this is the architecture of EMET. 153 00:09:19,959 --> 00:09:23,999 So basically we have the protected processes. 154 00:09:23,999 --> 00:09:26,292 You can see on the bottom the IE process and Acrobat 155 00:09:26,292 --> 00:09:29,459 and anything else you want to protect. 156 00:09:32,334 --> 00:09:36,375 EMET.DLL implements the memory corruption mitigations. 157 00:09:39,167 --> 00:09:42,083 On the bottom, you see that's where we have 158 00:09:42,083 --> 00:09:46,542 the PKI mitigation or a part of the PKI mitigation. 159 00:09:46,542 --> 00:09:48,792 I will go into more detail about that later. 160 00:09:48,792 --> 00:09:50,083 And basically all these DLLs use interprocess 161 00:09:50,083 --> 00:09:53,334 communication to communicate with the EMET agent which you would 162 00:09:53,334 --> 00:09:56,999 see running on your machine if you are running EMET. 163 00:09:56,999 --> 00:09:58,918 And that's basically the one that EMET agent 164 00:09:58,918 --> 00:10:01,999 is the one that implements the tray icon than the logging and 165 00:10:01,999 --> 00:10:03,834 the PKI logic. 166 00:10:04,999 --> 00:10:11,667 The EMET ce.dll is basically loaded into browsers or programs that use 167 00:10:11,667 --> 00:10:15,709 CAPI, Windows CAPI, crypto APIs. 168 00:10:15,709 --> 00:10:16,751 Oh, God. 169 00:10:17,083 --> 00:10:18,292 Okay. 170 00:10:20,501 --> 00:10:26,999 (applause) What's this called? 171 00:10:27,999 --> 00:10:29,667 Shot the n00b. 172 00:10:30,626 --> 00:10:32,459 What's he's going to do? 173 00:10:32,459 --> 00:10:33,459 Drink. 174 00:10:33,459 --> 00:10:34,459 Louder. 175 00:10:34,459 --> 00:10:35,459 Drink! 176 00:10:35,459 --> 00:10:36,459 There we go. 177 00:10:36,459 --> 00:10:37,459 Thank you. 178 00:10:37,459 --> 00:10:39,667 We need someone from the audience first time DEF 179 00:10:39,667 --> 00:10:41,334 CON attendee. 180 00:10:41,334 --> 00:10:42,999 No, no, no. 181 00:10:42,999 --> 00:10:43,999 (laughter). 182 00:10:44,167 --> 00:10:45,959 There we go. 183 00:10:45,959 --> 00:10:46,959 Come on up. 184 00:10:47,792 --> 00:10:50,999 I usually go for the first hand I see up. 185 00:10:50,999 --> 00:10:51,999 Good try, though. 186 00:10:51,999 --> 00:10:54,292 NEIL SIKKA: I have a question. 187 00:10:54,292 --> 00:10:57,000 Do you guys walk around to five tracks every hour 188 00:10:57,000 --> 00:10:59,000 taking shots? 189 00:10:59,000 --> 00:11:00,751 That's a good question. 190 00:11:00,751 --> 00:11:03,083 The first speaker actually asked the question. 191 00:11:03,083 --> 00:11:06,959 So the speaker Goons, are we doing shots with everyone? 192 00:11:06,959 --> 00:11:07,999 Yes. 193 00:11:07,999 --> 00:11:10,626 That's exactly what we're doing. 194 00:11:10,626 --> 00:11:11,626 (laughter). 195 00:11:11,626 --> 00:11:12,667 That's epic, man. 196 00:11:12,667 --> 00:11:17,459 (applause) To InfoSec. 197 00:11:17,459 --> 00:11:27,167 (applause) NEIL SIKKA: Thank you. 198 00:11:27,209 --> 00:11:30,250 Good luck for the rest of the day. 199 00:11:30,542 --> 00:11:33,083 Paul's having a rough morning. 200 00:11:40,209 --> 00:11:42,250 NEIL SIKKA: Okay. 201 00:11:42,667 --> 00:11:46,125 So let's try to pick up right where I left off. 202 00:11:47,999 --> 00:11:48,999 Yeah. 203 00:11:48,999 --> 00:11:49,999 (laughter). 204 00:11:51,083 --> 00:11:55,209 So basically anything that uses CAPI is protected including other browsers, 205 00:11:55,209 --> 00:11:57,584 so Chrome or whatever, could be protected 206 00:11:57,584 --> 00:11:59,918 by this PKI mitigation. 207 00:12:01,083 --> 00:12:02,334 Okay, so. 208 00:12:02,334 --> 00:12:04,334 Now I'm going to be talking the rest of the time about PKI and 209 00:12:04,334 --> 00:12:06,167 the new mitigation. 210 00:12:06,918 --> 00:12:10,375 So PKI stands for public key infrastructure. 211 00:12:11,083 --> 00:12:14,999 It is basically dealing with digital certificates. 212 00:12:14,999 --> 00:12:17,209 Excuse me. 213 00:12:17,250 --> 00:12:21,417 Did he just say at DEF CON I'm going to talk about PKI which stands 214 00:12:21,417 --> 00:12:24,501 for public key infrastructure? 215 00:12:25,999 --> 00:12:28,999 Evidently, we're in the advanced track. 216 00:12:31,417 --> 00:12:32,834 Continue. 217 00:12:32,834 --> 00:12:35,959 NEIL SIKKA: I'm trying to make sure everybody gets my talk. 218 00:12:35,959 --> 00:12:36,959 (applause). 219 00:12:37,292 --> 00:12:41,417 This is basically used to ensure integrity and attribution 220 00:12:41,417 --> 00:12:45,626 online and it is the basis of HTTPS and dealing with, like, 221 00:12:45,626 --> 00:12:50,999 your bank Web site or whatever else or other secure Web sites that you want 222 00:12:50,999 --> 00:12:52,999 to keep secure. 223 00:12:54,918 --> 00:12:56,999 So here's an example. 224 00:12:56,999 --> 00:12:58,876 This is what PKI looks like. 225 00:12:58,876 --> 00:13:02,292 So you can see at the root you have the root certificate obviously 226 00:13:02,292 --> 00:13:05,792 and it basically so every parent signs the certificates 227 00:13:05,792 --> 00:13:08,999 for every certificate underneath it. 228 00:13:08,999 --> 00:13:11,959 So, for example, in this case, the root certificate would sign 229 00:13:11,959 --> 00:13:15,292 the intermediate enters and the intermediate enters would sign 230 00:13:15,292 --> 00:13:17,542 the end certificates. 231 00:13:17,542 --> 00:13:19,334 So the end certificate would be whatever Web site you are trying 232 00:13:19,334 --> 00:13:21,209 to log into over HTTPS. 233 00:13:21,834 --> 00:13:26,417 It is basically a train of trust rooted by the root. 234 00:13:29,083 --> 00:13:32,999 There have been some recent TLS and SSL incidents you might have seen 235 00:13:32,999 --> 00:13:35,125 in the news and stuff. 236 00:13:35,751 --> 00:13:40,999 Starting back as far as 2008 when it was proved that MD5 237 00:13:40,999 --> 00:13:46,918 is harmful in a paper, in 2011 we saw three different attacks 238 00:13:46,918 --> 00:13:48,501 on CAs. 239 00:13:48,501 --> 00:13:51,999 So basically fraudulent certificates being issued. 240 00:13:51,999 --> 00:13:55,999 And then in January of this year, we saw a third trust get compromised. 241 00:13:56,083 --> 00:14:00,083 So in a nutshell PKI is under attack. 242 00:14:00,083 --> 00:14:08,167 I heard a yay from the audience. 243 00:14:08,167 --> 00:14:09,167 (laughter). 244 00:14:09,167 --> 00:14:10,876 So PKI certificate pinning is basically assuring 245 00:14:10,876 --> 00:14:13,999 like enforcing certain assumptions or expectations 246 00:14:13,999 --> 00:14:18,083 about certificates that we get from the Internet. 247 00:14:18,083 --> 00:14:20,083 That's a broad definition. 248 00:14:21,209 --> 00:14:24,876 And there has already been some pretty good work in this space as well. 249 00:14:25,125 --> 00:14:32,542 Moxi, Paran, they may attack and convergence a few others. 250 00:14:32,834 --> 00:14:34,792 But as you can see, all of these require changes 251 00:14:34,792 --> 00:14:36,959 to existing protocols. 252 00:14:37,083 --> 00:14:38,501 So, for example, in the attack case you see 253 00:14:38,501 --> 00:14:39,999 TLS changes. 254 00:14:39,999 --> 00:14:41,999 Convergence has another protocol. 255 00:14:41,999 --> 00:14:49,083 DNS has DNS changes and what they implemented in Chrome had 256 00:14:49,083 --> 00:14:53,417 a new had to change HTTP. 257 00:14:53,918 --> 00:14:56,501 So history has told the industry again and again that 258 00:14:56,501 --> 00:15:00,125 requiring changes to protocols or a new protocol takes forever 259 00:15:00,125 --> 00:15:03,292 to actually be adopted by everybody. 260 00:15:03,292 --> 00:15:05,459 Look at IPv4 and IPv6, for example. 261 00:15:05,459 --> 00:15:07,667 Not everybody is using it all the time. 262 00:15:09,999 --> 00:15:13,876 So our design goals, we had three main design goals. 263 00:15:13,876 --> 00:15:16,334 One is to give control to users, so, like, you can pick 264 00:15:16,334 --> 00:15:20,459 the exact certificate you want to pin to or not pin to. 265 00:15:20,459 --> 00:15:22,083 You can pick domain names and other heuristics that I 266 00:15:22,083 --> 00:15:23,959 will go into later. 267 00:15:24,375 --> 00:15:26,999 Another thing we wanted to do was not require changers 268 00:15:26,999 --> 00:15:30,209 to preexisting or new protocols because as I mentioned that takes 269 00:15:30,209 --> 00:15:32,375 forever to get adopted. 270 00:15:32,417 --> 00:15:35,417 And, finally, we wanted to keep EMET as a stand alone tool 271 00:15:35,417 --> 00:15:37,626 and not depend on any other services 272 00:15:37,626 --> 00:15:40,501 out in the Internet or anything. 273 00:15:40,501 --> 00:15:42,999 It's like its open self contained tool. 274 00:15:43,083 --> 00:15:46,918 So this required us to have make design decisions 275 00:15:46,918 --> 00:15:51,709 and tradeoffs that a lot of other problems couldn't make 276 00:15:51,709 --> 00:15:57,459 for PKI for pinning because we had to conform with what was already 277 00:15:57,459 --> 00:16:02,959 out there and we had to still try to protect stuff. 278 00:16:02,959 --> 00:16:05,667 Our approach was not to require any protocol changes. 279 00:16:05,667 --> 00:16:09,751 And we pinned to root certificates, not intermediate certificates. 280 00:16:09,751 --> 00:16:12,667 So there's in the tree that I showed you earlier, there could be some certificates 281 00:16:12,667 --> 00:16:15,918 in the middle, like the intermediate certificates. 282 00:16:16,125 --> 00:16:17,375 We don't check those. 283 00:16:17,792 --> 00:16:20,083 And we also are pinning to only certificates 284 00:16:20,083 --> 00:16:24,999 in the Windows trusted root certificate authorities store. 285 00:16:24,999 --> 00:16:26,999 Like if you go to MMC, you'll see that. 286 00:16:27,167 --> 00:16:29,999 And we also had to identify certificates. 287 00:16:29,999 --> 00:16:32,876 This was a bigger discussion in our team, to figure out how 288 00:16:32,876 --> 00:16:36,999 to do this, because we were trying to figure out whether we should pin 289 00:16:36,999 --> 00:16:41,876 to assure and serial number tupules or to subject key identifier. 290 00:16:41,999 --> 00:16:43,959 And I'm going to go into more detail about this 291 00:16:43,959 --> 00:16:47,999 because this was kind of a big deal, a big decision for us. 292 00:16:49,542 --> 00:16:53,999 So as the RFC for x509 which is RFC5280 says it identifies 293 00:16:53,999 --> 00:16:56,709 a unique certificate. 294 00:16:58,375 --> 00:17:02,083 It is pretty blatant and obvious. 295 00:17:02,167 --> 00:17:05,501 But that's like really rigid because if you are trying it 296 00:17:05,501 --> 00:17:08,999 is a valid case that two root certificates could have 297 00:17:08,999 --> 00:17:12,125 the same public/private key pair. 298 00:17:12,250 --> 00:17:14,667 Although, yeah, you would be identifying 299 00:17:14,667 --> 00:17:17,999 a unique certificate, you would still have false positives 300 00:17:17,999 --> 00:17:22,083 because you are identifying a certificate, not a key. 301 00:17:22,459 --> 00:17:28,999 So we decided to also add an option to pin to a public key. 302 00:17:28,999 --> 00:17:32,999 So in this case, this would be the SPKI, the subject key identifier 303 00:17:32,999 --> 00:17:35,792 of the root certificate. 304 00:17:35,792 --> 00:17:38,459 And this is thanks to feedback from the community. 305 00:17:38,459 --> 00:17:39,999 Thank you for your feedback. 306 00:17:39,999 --> 00:17:41,167 And this is also from other people giving us feedback 307 00:17:41,167 --> 00:17:43,083 like Google and stuff. 308 00:17:43,083 --> 00:17:45,501 So shoutout to everybody who gave us feedback. 309 00:17:47,334 --> 00:17:51,999 So this is what our architecture looks like for the PKI subsystem. 310 00:17:52,125 --> 00:17:54,501 Basically we had a bunch of pin sites. 311 00:17:54,501 --> 00:17:56,334 In this example, taking the Skype example, we have a bunch 312 00:17:56,334 --> 00:17:58,709 of pin sites at the bottom. 313 00:18:01,709 --> 00:18:06,250 Log in.Skype.com, they are both Skype services. 314 00:18:06,250 --> 00:18:08,083 So they would share the same pin rule which would be 315 00:18:08,083 --> 00:18:09,959 the MS Skype CA. 316 00:18:09,999 --> 00:18:14,292 Those services are expected expectations that we're forcing via 317 00:18:14,292 --> 00:18:17,083 the definition of pinning. 318 00:18:17,125 --> 00:18:20,751 Our pin to things that we expect to see like Baltimore cyber trust, 319 00:18:20,751 --> 00:18:24,083 VeriSign, Globalsign and GTE Cybertrust. 320 00:18:26,876 --> 00:18:31,542 In general, same services under different organizations share 321 00:18:31,542 --> 00:18:34,959 certificates that they pin to. 322 00:18:36,334 --> 00:18:42,417 So we implemented we implemented a crypto API CAPI extension. 323 00:18:42,417 --> 00:18:45,626 This is what is in the EMET 64.dll. 324 00:18:49,083 --> 00:18:52,334 This basically communicates with the EMET agent. 325 00:18:53,751 --> 00:18:56,918 So we are inside the process that uses CAPI and passing 326 00:18:56,918 --> 00:18:59,334 the full certificate chain. 327 00:18:59,334 --> 00:19:01,792 So the end certificate, all the intermediate certificates and 328 00:19:01,792 --> 00:19:04,167 the root certificate to the EMET agent that I 329 00:19:04,167 --> 00:19:06,167 mentioned earlier. 330 00:19:06,501 --> 00:19:08,584 Within the EMET agent, it makes a decision 331 00:19:08,584 --> 00:19:12,834 about whether or not the certificate is okay or not. 332 00:19:12,834 --> 00:19:15,167 And we as you can see on the bottom, we have the little crypto 333 00:19:15,167 --> 00:19:19,292 the crypt registry ODI function, that's a code snippet kind of. 334 00:19:19,292 --> 00:19:22,999 You can see we target SSL over there. 335 00:19:23,292 --> 00:19:26,167 This is specifically for SSL checks. 336 00:19:29,501 --> 00:19:33,999 So, here's some checks that we do on the certificates. 337 00:19:34,083 --> 00:19:37,751 So we, basically, check the end certificate, the subjects, 338 00:19:37,751 --> 00:19:41,334 the DNS name or other things in there. 339 00:19:41,334 --> 00:19:43,167 And we basically make sure that it matches 340 00:19:43,167 --> 00:19:46,375 a pinned site that I mentioned earlier. 341 00:19:46,375 --> 00:19:47,959 That's configured for EMET. 342 00:19:48,626 --> 00:19:52,626 And basically a root certificate is what I showed you earlier 343 00:19:52,626 --> 00:19:55,709 as the root of the tree and the end certificate 344 00:19:55,709 --> 00:19:59,999 is the certificate that the HTTPS server gives us. 345 00:19:59,999 --> 00:20:02,375 And let me check if the pin rule has expired 346 00:20:02,375 --> 00:20:05,125 or not because that expires. 347 00:20:07,626 --> 00:20:10,209 And either depending on the configuration 348 00:20:10,209 --> 00:20:14,959 of that decision I mentioned earlier that we had to make about pinning 349 00:20:14,959 --> 00:20:19,375 to individual certificates or pinning to public keys of certificates, 350 00:20:19,375 --> 00:20:23,918 in all cases root certificates, we either checked if the public key 351 00:20:23,918 --> 00:20:28,250 is a match or the serial number and the subject name. 352 00:20:30,125 --> 00:20:34,999 And so here's some more here's what we call exceptions where we are doing 353 00:20:34,999 --> 00:20:37,999 heuristics on the certificates. 354 00:20:37,999 --> 00:20:40,751 So we checked the public modulus bit length which 355 00:20:40,751 --> 00:20:46,292 is the side of the bit length, it is a measure of the key strength. 356 00:20:46,292 --> 00:20:48,042 So if you have a 512 bit key that could be 357 00:20:48,042 --> 00:20:50,042 considered small. 358 00:20:50,042 --> 00:20:51,999 If you have a bigger key, a bigger key than that, 359 00:20:51,999 --> 00:20:54,626 that could be considered stronger. 360 00:20:54,626 --> 00:20:57,999 It is, like I said, a measure of the strength of the key. 361 00:20:58,250 --> 00:21:01,250 So we have, like, a minimum bound on it so that 362 00:21:01,250 --> 00:21:04,459 the user can also check that. 363 00:21:04,459 --> 00:21:06,667 They can also check the digest algorithm, so if it's 364 00:21:06,667 --> 00:21:10,999 like MD5 which was proven harmful in the past they being disallow that 365 00:21:10,999 --> 00:21:13,999 or roots from different countries. 366 00:21:14,125 --> 00:21:15,959 For example, if they don't think VeriSign should be 367 00:21:15,959 --> 00:21:18,375 in a different country than the U.S. 368 00:21:18,375 --> 00:21:21,250 or something, they can check that and mark that as weird. 369 00:21:21,250 --> 00:21:23,999 In general here, we're basically trying to give a lot of control 370 00:21:23,999 --> 00:21:26,667 to the users so they can decide what they want 371 00:21:26,667 --> 00:21:30,292 to and don't want to check in the certificates. 372 00:21:30,292 --> 00:21:31,999 That was one of the design goals. 373 00:21:34,999 --> 00:21:37,959 So here's some of the default protected domains that 374 00:21:37,959 --> 00:21:39,751 ship with EMET. 375 00:21:39,751 --> 00:21:42,083 So this is in the thirdtrust.xml. 376 00:21:44,999 --> 00:21:49,709 Both third party and Microsoft domains and sites. 377 00:21:49,709 --> 00:21:51,709 So these are basically like you can see Twitter, 378 00:21:51,709 --> 00:21:52,584 Facebook, Yahoo! 379 00:21:52,584 --> 00:21:56,292 , those are basically other companies that wanted to cooperate and be 380 00:21:56,292 --> 00:21:58,125 in this with us. 381 00:21:58,125 --> 00:21:59,999 So we shout out to them. 382 00:22:00,167 --> 00:22:05,250 This is basically various domains we are pinning to. 383 00:22:06,083 --> 00:22:11,584 This can be configured by the wizard in EMET.So I believe it is best 384 00:22:11,584 --> 00:22:16,292 to be upfront and straight up about what the limitations are 385 00:22:16,292 --> 00:22:19,083 and not try to hide it. 386 00:22:19,083 --> 00:22:22,250 So some of the limitations are that we mitigate specifically 387 00:22:22,250 --> 00:22:26,542 for SSL and TLS not for other crypto protocols. 388 00:22:26,584 --> 00:22:29,167 We are pinning to just we are just checking the end 389 00:22:29,167 --> 00:22:32,999 and the root certificates like I mentioned earlier. 390 00:22:32,999 --> 00:22:35,667 We are not checking the intermediate certificates. 391 00:22:35,667 --> 00:22:38,167 So that's a possible limitation. 392 00:22:38,626 --> 00:22:41,999 The pin configuration is statically shipped with EMET so it 393 00:22:41,999 --> 00:22:44,083 is not like a Windows update where we're 394 00:22:44,083 --> 00:22:48,083 pushing down new configuration or something like that. 395 00:22:48,083 --> 00:22:53,083 It is basic my whatever comes with it is what what we have for that release. 396 00:22:53,083 --> 00:22:56,209 So they could be outdated it tomorrow some company decides to change 397 00:22:56,209 --> 00:23:00,083 the root that they chain their certificates to. 398 00:23:00,167 --> 00:23:05,125 And in general EMET's mitigations are not bulletproof. 399 00:23:06,709 --> 00:23:14,999 There is a way to get around it but they raise the bar for the attackers. 400 00:23:14,999 --> 00:23:15,999 Okay. 401 00:23:15,999 --> 00:23:16,999 Demo time. 402 00:23:16,999 --> 00:23:19,876 So do you all want to see a live demo or prerecorded demo? 403 00:23:19,876 --> 00:23:20,876 Live. 404 00:23:20,876 --> 00:23:23,501 NEIL SIKKA: Raise your hand if you want to see live. 405 00:23:23,501 --> 00:23:24,626 Fuck it, do it live! 406 00:23:24,626 --> 00:23:25,626 NEIL SIKKA: Okay. 407 00:23:25,626 --> 00:23:26,792 We'll do it live. 408 00:23:26,792 --> 00:23:28,501 Hopefully this works. 409 00:23:28,999 --> 00:23:31,751 Given the DEF CON network, I don't know. 410 00:23:31,999 --> 00:23:33,125 Okay. 411 00:23:33,375 --> 00:23:36,667 I have a VM here. 412 00:23:37,751 --> 00:23:39,167 Please work. 413 00:23:39,709 --> 00:23:40,709 Unidentified. 414 00:23:40,709 --> 00:23:41,709 Okay. 415 00:23:41,709 --> 00:23:42,709 Hopefully ... 416 00:23:54,667 --> 00:23:59,250 Apparently the DEF CON network is not serving us today. 417 00:23:59,250 --> 00:24:01,209 So okay I will show you guys a video. 418 00:24:06,959 --> 00:24:13,999 (speaker off microphone.) NEIL SIKKA: Okay. 419 00:24:13,999 --> 00:24:15,792 I can't see this but I think you can. 420 00:24:15,792 --> 00:24:22,999 (speaker off microphone.) NEIL SIKKA: It 421 00:24:22,999 --> 00:24:29,083 is to make your day brighter. 422 00:24:29,083 --> 00:24:31,459 Thanks, Microsoft. 423 00:24:31,584 --> 00:24:35,667 (laughter) NEIL SIKKA: For EMET or for the picture? 424 00:24:41,459 --> 00:24:43,083 Both. 425 00:24:48,999 --> 00:24:51,292 NEIL SIKKA: I have no idea what's happening 426 00:24:51,292 --> 00:24:53,959 because I can't see the screen. 427 00:24:53,959 --> 00:24:54,959 Hold on. 428 00:24:54,959 --> 00:24:57,959 It would probably be a better idea if I duplicate my screen. 429 00:25:09,584 --> 00:25:10,999 No, nothing? 430 00:25:15,167 --> 00:25:17,083 Heard of a bunch of random yelling. 431 00:25:17,083 --> 00:25:18,083 Resolution! 432 00:25:18,083 --> 00:25:20,334 Change the resolution. 433 00:25:20,834 --> 00:25:24,501 NEIL SIKKA: Awesome, okay. 434 00:25:32,999 --> 00:25:35,792 I really wanted to do it live but whatever. 435 00:25:35,999 --> 00:25:37,709 So okay. 436 00:25:37,709 --> 00:25:40,584 As you can see this is the configuration for EMET. 437 00:25:40,584 --> 00:25:42,417 So can you all see the text? 438 00:25:42,626 --> 00:25:44,459 No. 439 00:25:44,667 --> 00:25:47,999 NEIL SIKKA: Oh, man. 440 00:25:47,999 --> 00:25:48,999 Okay. 441 00:25:48,999 --> 00:25:50,959 Let me increase the resolution then. 442 00:25:51,250 --> 00:25:52,542 Smaller. 443 00:25:53,999 --> 00:25:55,584 NEIL SIKKA: Smaller? 444 00:25:55,584 --> 00:26:25,250 Can you all see that? 445 00:26:26,792 --> 00:26:27,999 Please? 446 00:26:27,999 --> 00:26:29,959 Does that work? 447 00:26:30,876 --> 00:26:32,667 I hear a bunch of groaning. 448 00:26:33,250 --> 00:26:34,375 Okay. 449 00:26:34,959 --> 00:26:35,999 Okay. 450 00:26:35,999 --> 00:26:38,375 So I'm just going to explain what's happening. 451 00:26:38,375 --> 00:26:40,709 I will change it once more to make it smaller. 452 00:26:46,167 --> 00:26:47,918 I don't have the zoom tool. 453 00:26:53,292 --> 00:26:54,876 Yeah, I can see it, yeah. 454 00:26:54,876 --> 00:27:00,918 Can you see that? 455 00:27:00,918 --> 00:27:01,918 Whatever. 456 00:27:01,918 --> 00:27:04,083 I will just explain what's happening then. 457 00:27:04,083 --> 00:27:07,292 So basically you see the configuration and that was 458 00:27:07,292 --> 00:27:09,999 the EMET configuration. 459 00:27:09,999 --> 00:27:12,834 And now login.live.com is working and the certificate 460 00:27:12,834 --> 00:27:15,584 is good and stuff like that. 461 00:27:15,959 --> 00:27:17,459 So I'm going to fast forward. 462 00:27:23,167 --> 00:27:27,501 So the point here is that we see that the certificate chains 463 00:27:27,501 --> 00:27:32,083 to the VeriSign root which is in our trusted store. 464 00:27:34,209 --> 00:27:37,083 And that's the MMC that I was mentioning earlier. 465 00:27:38,834 --> 00:27:40,083 Okay. 466 00:27:41,834 --> 00:27:44,459 So now on this VM, I was running 467 00:27:44,459 --> 00:27:48,584 a Web server where I was serving up an ACTPS page 468 00:27:48,584 --> 00:27:52,918 but was encrypted with certificates key who chained 469 00:27:52,918 --> 00:27:59,709 to another root in my root store but it wasn't the same VeriSign root. 470 00:27:59,709 --> 00:28:02,584 So this could represent, like, if you're getting man in the middled 471 00:28:02,584 --> 00:28:04,792 or something by a certificate that chains 472 00:28:04,792 --> 00:28:08,999 to another root in your root store, like, for example, this year the third trust 473 00:28:08,999 --> 00:28:12,999 if they got compromised and they are in your root store and you would chain 474 00:28:12,999 --> 00:28:14,834 to them, then you would trust them 475 00:28:14,834 --> 00:28:19,542 because the certificate chains to them and they are in your root store. 476 00:28:19,542 --> 00:28:23,999 So I manually added a certificate to my root store and I'm changing 477 00:28:23,999 --> 00:28:29,501 the host file here to login.live.com, the local host server. 478 00:28:29,834 --> 00:28:32,083 You can see this is not login.live.com. 479 00:28:33,083 --> 00:28:36,292 This is my page. 480 00:28:36,918 --> 00:28:40,083 The bar on top, you don't see it red or anything. 481 00:28:40,083 --> 00:28:40,999 You see a pad lock which would fool you 482 00:28:40,999 --> 00:28:42,999 into thinking it is good. 483 00:28:42,999 --> 00:28:46,999 That's because I have a certificate with login.live.com domain name 484 00:28:46,999 --> 00:28:50,792 chained there to a root in the root store. 485 00:28:50,999 --> 00:28:53,999 It is obviously not good and it is not login.live.com. 486 00:28:57,334 --> 00:29:00,417 So this is just to prove to you guys that I'm not lying. 487 00:29:00,417 --> 00:29:01,417 Here. 488 00:29:01,417 --> 00:29:06,125 So you see the MMC that's open. 489 00:29:06,167 --> 00:29:08,999 You might not be able to see, I don't know. 490 00:29:08,999 --> 00:29:09,999 The MMC, that's open. 491 00:29:10,167 --> 00:29:14,626 That is a certificate that I generated and it was a root that I generated. 492 00:29:14,626 --> 00:29:16,083 So it was not correct. 493 00:29:16,083 --> 00:29:17,083 Okay. 494 00:29:17,083 --> 00:29:18,083 Now the cool part. 495 00:29:18,083 --> 00:29:20,999 So now when we enable the login.live.com rule, 496 00:29:20,999 --> 00:29:23,834 it works as expected. 497 00:29:27,709 --> 00:29:36,792 But when I change the host file to point to my local Web server 498 00:29:36,792 --> 00:29:44,999 and then I run IE, you see that little icon there? 499 00:29:45,125 --> 00:29:50,083 EMET detected there was a problem with the SSL certificate. 500 00:29:50,501 --> 00:29:52,584 It is basically a warning. 501 00:29:52,584 --> 00:29:56,417 Although IE doesn't show the bar is red or anything, that certificate sorry, 502 00:29:56,417 --> 00:29:59,959 that icon pops up saying that there's something weird 503 00:29:59,959 --> 00:30:01,834 going on here. 504 00:30:09,167 --> 00:30:11,083 Now to switch back. 505 00:30:39,501 --> 00:30:40,751 Okay. 506 00:30:40,751 --> 00:30:43,167 That was a demo and I guess we had to do it recorded. 507 00:30:43,167 --> 00:30:44,167 Sorry, guys. 508 00:30:45,334 --> 00:30:47,999 So, yeah, that's basically it. 509 00:30:48,083 --> 00:30:49,626 Some references. 510 00:30:49,999 --> 00:30:54,375 So you can download EMET 4.0 here if you need it, if you want it. 511 00:30:54,709 --> 00:30:56,417 And this is a lot of good work references to a lot 512 00:30:56,417 --> 00:30:59,834 of good work I used when I was making this presentation and when we were 513 00:30:59,834 --> 00:31:02,459 making the design decisions for EMET. 514 00:31:02,999 --> 00:31:06,334 So any questions or anything? 515 00:31:06,667 --> 00:31:08,292 Also, I want to say this was a team effort so thanks 516 00:31:08,292 --> 00:31:09,999 to the whole team, the whole EMET team 517 00:31:09,999 --> 00:31:11,999 for making this possible. 518 00:31:35,751 --> 00:31:37,999 (speaker off microphone.) NEIL SIKKA: So 519 00:31:37,999 --> 00:31:41,501 the mic wasn't on but the question, I think I heard it, was can you pin 520 00:31:41,501 --> 00:31:44,292 a site to multiple root certificates? 521 00:31:44,292 --> 00:31:45,959 Yeah, that's what we're doing. 522 00:31:45,959 --> 00:31:50,999 In that example I gave about Skype, you see like the login.Skype.com. 523 00:31:52,292 --> 00:31:57,667 It had both Cybertrust root and the GTE. 524 00:31:57,667 --> 00:31:59,876 Is there a way to tie that into GPOs or otherwise pushed 525 00:31:59,876 --> 00:32:03,083 down settings to users in a corporate environment? 526 00:32:06,125 --> 00:32:08,584 Or does that have to be done an individual basis 527 00:32:08,584 --> 00:32:11,999 on individual machines to change those settings? 528 00:32:11,999 --> 00:32:13,876 NEIL SIKKA: EMET supports GPOs. 529 00:32:13,876 --> 00:32:16,584 So if you have a million computers, you can set it through GPO 530 00:32:16,584 --> 00:32:19,417 to propagate down to everybody. 531 00:32:20,626 --> 00:32:25,709 I have two questions. 532 00:32:25,709 --> 00:32:30,709 First one was there was recent research that showed that most SSL applications 533 00:32:30,709 --> 00:32:35,999 are not browser based are incorrectly implementing SSL and EMET as far 534 00:32:35,999 --> 00:32:40,626 as I understand protects a specific application. 535 00:32:40,626 --> 00:32:42,999 NEIL SIKKA: EMET what? 536 00:32:42,999 --> 00:32:43,999 Protects a specific application that 537 00:32:43,999 --> 00:32:45,542 you predefine. 538 00:32:45,542 --> 00:32:49,083 There is a way to make EMET work on all applications? 539 00:32:49,083 --> 00:32:52,834 NEIL SIKKA: No. 540 00:32:53,584 --> 00:32:56,918 Well, are you so you are talking specifically about SSL? 541 00:32:56,999 --> 00:32:59,584 Yeah, because this is a problem that would be relevant not 542 00:32:59,584 --> 00:33:02,876 just to browsers but to other applications. 543 00:33:02,876 --> 00:33:05,292 NEIL SIKKA: So in that case, yeah, so I saw, like, 544 00:33:05,292 --> 00:33:10,083 Outlook when I was using Outlook, it had the EMET.dll loaded because it 545 00:33:10,083 --> 00:33:12,417 is looking for KAPI. 546 00:33:12,417 --> 00:33:16,125 In that case, I meant no for if you have memory corruption 547 00:33:16,125 --> 00:33:20,501 like if you have ROP mitigation if you have acrobat or IE. 548 00:33:20,501 --> 00:33:24,999 If you want to do the crypto API, if you are using crypto API 549 00:33:24,999 --> 00:33:28,834 in your application, it protects you. 550 00:33:29,959 --> 00:33:32,999 It registers the DLL. 551 00:33:32,999 --> 00:33:36,542 So it would be loaded to anything that loads encrypted API. 552 00:33:36,542 --> 00:33:40,999 So it works for Chrome or IE or Outlook which is not 553 00:33:40,999 --> 00:33:43,999 a browser obviously. 554 00:33:43,999 --> 00:33:44,999 Okay. 555 00:33:44,999 --> 00:33:45,999 And thank you. 556 00:33:45,999 --> 00:33:48,584 Another question is why don't you integrate this 557 00:33:48,584 --> 00:33:51,709 notification with the regular announcements 558 00:33:51,709 --> 00:33:56,999 or notifications about fraudulent or incorrect certificates? 559 00:33:56,999 --> 00:33:59,250 Why is it a separate notification? 560 00:33:59,250 --> 00:34:00,999 NEIL SIKKA: Separate than what? 561 00:34:00,999 --> 00:34:04,250 Than if I had a fraudulent or incorrect certificate come 562 00:34:04,250 --> 00:34:09,292 into my browser, I would be notified in another way, right? 563 00:34:09,292 --> 00:34:11,999 NEIL SIKKA: You mean with the red bar, for example? 564 00:34:11,999 --> 00:34:12,999 Right. 565 00:34:12,999 --> 00:34:14,667 NEIL SIKKA: So changing so IE is, like, a lot of code and it is huge 566 00:34:14,667 --> 00:34:20,667 and changing, like, the behavior of IE would be, like, really difficult. 567 00:34:20,667 --> 00:34:23,083 And so, like I said, we wanted to be stand alone. 568 00:34:23,209 --> 00:34:25,334 So we just wanted to display this notification just 569 00:34:25,334 --> 00:34:27,626 like we display all the other notifications, 570 00:34:27,626 --> 00:34:30,167 the one that people are used to. 571 00:34:30,167 --> 00:34:32,709 So see the EMET in the tray icon. 572 00:34:32,709 --> 00:34:33,999 We didn't want to be changing the behavior because they have 573 00:34:33,999 --> 00:34:37,083 to go through a bunch of other stuff to change the behavior. 574 00:34:37,083 --> 00:34:39,626 (speaker off microphone.) NEIL SIKKA: No. 575 00:34:45,876 --> 00:34:48,876 So, first, thank you for having the guts to come 576 00:34:48,876 --> 00:34:53,959 before this August group of users to try our hand at explaining this. 577 00:34:54,125 --> 00:34:56,999 But the question is: Is this intended to replace other certificate 578 00:34:56,999 --> 00:34:58,999 validation tools? 579 00:34:59,167 --> 00:35:02,834 Does this provide would it be fair to say this provides a baseline 580 00:35:02,834 --> 00:35:05,709 of certificate validation through Windows where 581 00:35:05,709 --> 00:35:09,542 before previously it was an external suite application or tools 582 00:35:09,542 --> 00:35:12,834 to check to see if roots were valid? 583 00:35:14,999 --> 00:35:18,667 Is this OSCP based, is it Krill based? 584 00:35:18,667 --> 00:35:21,083 NEIL SIKKA: No, it's not. 585 00:35:21,417 --> 00:35:24,999 Basically when you are asking about replacing other tools 586 00:35:24,999 --> 00:35:29,209 or something when you are asking about replacing other tools 587 00:35:29,209 --> 00:35:32,999 and stuff like that, each tool has its own strengths 588 00:35:32,999 --> 00:35:34,999 and weaknesses. 589 00:35:34,999 --> 00:35:37,751 For example, our strength, I think, was that we didn't try 590 00:35:37,751 --> 00:35:40,083 to change any protocols. 591 00:35:40,083 --> 00:35:42,999 So you can use other stuff also that might not have 592 00:35:42,999 --> 00:35:48,167 the same weaknesses as EMET but then the strengths also change. 593 00:35:48,167 --> 00:35:50,999 So what I'm trying to say is that it's not a replacement. 594 00:35:50,999 --> 00:35:53,209 It seems like there's many different solutions 595 00:35:53,209 --> 00:35:55,667 out there right now. 596 00:35:55,667 --> 00:35:58,626 So this is just another one that I think that has some pretty good strengths 597 00:35:58,626 --> 00:36:00,999 with not too bad weaknesses. 598 00:36:01,167 --> 00:36:04,999 Do you have plans for providing EMET protection 599 00:36:04,999 --> 00:36:09,584 as an API for protection for third parties? 600 00:36:09,584 --> 00:36:12,125 NEIL SIKKA: Not that I know of yet. 601 00:36:12,125 --> 00:36:13,125 Why. 602 00:36:13,125 --> 00:36:17,250 NEIL SIKKA: We just released it a few months ago. 603 00:36:17,250 --> 00:36:20,083 No, EMET has been there for two years. 604 00:36:20,083 --> 00:36:22,083 NEIL SIKKA: No, the PKI mitigation. 605 00:36:22,083 --> 00:36:23,083 I understand. 606 00:36:23,083 --> 00:36:24,999 I'm talking about in general as in EMET. 607 00:36:24,999 --> 00:36:26,209 NEIL SIKKA: Oh, okay. 608 00:36:26,209 --> 00:36:26,209 So you are talking about the memory 609 00:36:26,209 --> 00:36:27,626 corruption mitigations. 610 00:36:27,626 --> 00:36:29,083 Among other things, yes. 611 00:36:29,083 --> 00:36:33,375 NEIL SIKKA: So I have talked about that to my co worker. 612 00:36:33,999 --> 00:36:36,999 We're thinking about that still but we have to still have time 613 00:36:36,999 --> 00:36:40,250 to outweigh the benefits and the costs of it. 614 00:36:40,250 --> 00:36:43,542 So, I mean, for example, would it break everybody that's using it 615 00:36:43,542 --> 00:36:48,375 or would it break some really popularly wildly used applications? 616 00:36:48,918 --> 00:36:52,125 Like, if you have a lot of users, for example, you have 617 00:36:52,125 --> 00:36:54,876 to be very mindful about not breaking them 618 00:36:54,876 --> 00:36:57,459 because sometimes they rely on your software 619 00:36:57,459 --> 00:36:59,999 through undocumented methods that are not 620 00:36:59,999 --> 00:37:03,083 according to the software contract. 621 00:37:03,083 --> 00:37:05,626 So you are using undocumented constructs? 622 00:37:05,626 --> 00:37:06,999 NEIL SIKKA: No, we're not. 623 00:37:06,999 --> 00:37:09,584 But I'm saying we are just doing our own we are basically doing 624 00:37:09,584 --> 00:37:12,375 all this stuff is looking at memory corruptions 625 00:37:12,375 --> 00:37:14,792 inside of our own DLL. 626 00:37:14,792 --> 00:37:17,959 We are not using our own undocumented stuff that I'm aware of. 627 00:37:19,501 --> 00:37:22,209 When you change the operating system, you have 628 00:37:22,209 --> 00:37:25,125 to be mindful of who you effect. 629 00:37:25,667 --> 00:37:30,501 This is no different than asking third party vendors to drive 630 00:37:30,501 --> 00:37:34,209 to write software device drivers. 631 00:37:34,209 --> 00:37:36,709 NEIL SIKKA: To what device drivers? 632 00:37:36,709 --> 00:37:37,709 Device drivers. 633 00:37:37,709 --> 00:37:40,751 Anyone who writes device drivers is altering the kernel, 634 00:37:40,751 --> 00:37:45,375 so why don't you will expose those APIs for third parties. 635 00:37:45,626 --> 00:37:48,999 NEIL SIKKA: This is not a part of the operating system right now. 636 00:37:48,999 --> 00:37:50,709 There is no we can't expose Windows APIs 637 00:37:50,709 --> 00:37:54,209 that do this because it is not a part of Windows. 638 00:37:54,209 --> 00:37:56,292 It is a separate stand alone tools. 639 00:37:56,375 --> 00:38:00,125 There are many libraries you are exposing. 640 00:38:00,709 --> 00:38:03,792 NEIL SIKKA: We have DLLs loaded into process 641 00:38:03,792 --> 00:38:07,667 but we haven't talked about, I guess, putting it in, 642 00:38:07,667 --> 00:38:11,083 like so that everybody can use it. 643 00:38:11,083 --> 00:38:13,792 So, yeah, I can take that as a feedback. 644 00:38:14,083 --> 00:38:15,334 I'll bring that up. 645 00:38:15,375 --> 00:38:16,999 Thank you. 646 00:38:16,999 --> 00:38:19,709 You said pinning rules expire. 647 00:38:19,709 --> 00:38:21,125 Could an attacker with local access modify the date 648 00:38:21,125 --> 00:38:24,999 or something to avoid EMET and fall back to standard PKI? 649 00:38:24,999 --> 00:38:28,417 NEIL SIKKA: All that stuff is stored in the registry. 650 00:38:28,459 --> 00:38:31,209 So they would have to have registry access to access 651 00:38:31,209 --> 00:38:33,834 the configuration of it. 652 00:38:33,959 --> 00:38:37,709 Oh, and the question sorry, for those people that can't hear. 653 00:38:37,709 --> 00:38:41,501 So he was saying that can an attacker modify the configuration. 654 00:38:41,501 --> 00:38:42,918 I was saying no, you can't. 655 00:38:42,918 --> 00:38:46,626 Because it's the configuration is stored in a privileged location. 656 00:38:48,999 --> 00:38:50,667 Anything else? 657 00:38:50,834 --> 00:38:51,999 Questions? 658 00:38:51,999 --> 00:38:53,083 Okay. 659 00:38:53,292 --> 00:38:54,292 Thank you.