 Hi, DEF CON. My name is Neil Sika, and today I'm going to be talking about MET 4.0 PKI mitigation. So MET is a tool from Microsoft, and it's a free tool to mitigate various attack techniques. So a little bit about me. So I'm a security engineer on MSRC, the Microsoft Security Response Center. I look at zero days that have been like in the wild or privately responsibly reported vulnerabilities. I'm an MET developer. I like blogging after work and on my free time about technology and security at Neil's computer blog, and I'm on Twitter if you want to talk to me or something. So an overview about what I'm going to be talking about today. So first I'll be going into what MET is, followed by new features in MET 4.0, the architecture of MET, and then I'll be taking a deep dive in the PKI feature of MET, which was our first non-memory corruption mitigation, and then I'll be giving a demo that hopefully works live. Okay. So first of all, what is MET? MET is a tool that mitigates different exploitation techniques. So it's been historically mostly for memory corruptions and stopping exploits that take advantage of memory corruptions. And one thing about it is that it's not signature based, rather it's behavior based. So for example, you don't need signatures for it or anything like that because it just looks for behaviors, common shell code behaviors, for example. So it can stop things that people don't know about also, or even Microsoft doesn't know about. So for example, zero days, we've actually used it to recommend it to mitigate some advisories in the past. And because it's dynamically loaded at runtime, it's like a DLL that gets loaded into your processes address space, so it doesn't require like recompiling or redeploying your application. And so if you have like a million computers or whatever, you don't have to go and do that for all of them. And it works on all supported platforms so far, so right now it's XP still supported, so as far back as XP. And it's a way of giving back to the security community, and it's a free tool. So what applications does it work on? Like these are some of them. So as you can see, like IE, Skype, Office, Chrome, it's basically Microsoft and third party applications. So some changes between MF 3.0 and 4.0. First of all, we added the certificate trust PKI mitigation. So a lot of talks this year at DEF CON have been about man in the middle and like abusing PKI and stuff like that. I'm not saying that PKI itself is bad or something, but I'm saying that sometimes it can be weekly implemented or badly implemented, like if you use short keys and stuff for your roots. So that was a mitigation we added for that. We added a mitigation for ROP exploits and some hardening for those ROP mitigations and a new user interface so you can have skins and cool stuff like that. Okay. So I'm going to first go into the memory corruption mitigations that we've had. So we have the basically forcing DEP on, which is did execution prevention. And it's basically by calling set process DEP policy on the process that we're trying to protect with the DEP protection. So this is basically such that you're not executing code on pages that are not supposed to be executable, like on the heap or something like that. They're supposed to be read and write. We have the heap spray mitigation which reserves not commits virtual addresses that are commonly used by heap sprays. So yeah, so it reserves it using those APIs. We have the mandatory ASLR, which does something where it reserves the preferred module loading base address so that the module cannot end up loading there. It reserves it so that it's not able to load there, so it has to load somewhere else, which is effectively ASLR, but obviously newer techniques of ASLR on newer versions of Windows is safer and has higher entropy and stuff. We have the null page mitigation where we basically we reserve the page zero, page address zero, so that you can't abuse null pointer dereferences or null pointer bugs. The EAF mitigation, which is export address table filtering. So that's basically the if shell code for example is trying to read the export address table. We set a hardware read break point on the export address table to make sure that EIP, which is an x86 instruction pointer, EIP doesn't point to some random place, like in the heap for example, because that's kind of creepy. And then we also do bottom up randomization where we randomize different data structures in the process's address space. So as I mentioned earlier, these are all memory corruption mitigations. And some more memory corruption mitigations are the C hop mitigation, which is structured exception handler overwrite protection. This is basically where we traverse the exception registration structures, the chain of them, looking for one whose previous pointer is negative one because that's what we expect to see. And if we don't see that, then we know that something has been corrupted and that's bad. And finally, our rot mitigation, which is new and M at 4.0. We have some hardening for this, for example, deep hooks, where we protect things like virtual protect and virtual protect EX. So like an API and an API that it would call so you can't bypass it. We have anti detours, which is basically preventing an attacker from jumping over the detoured part of a function. So basically jumping over our hook kind of. And band functions where we disallow specifically in this release is disallowing calling NTDL's LDR hot patch routine, and that's thanks to Yang Yu, NS Focus, from CanSec West this year. So our rot mitigation, okay, so I'm basically going to try to explain rot in like one side. So we'll see if it works. So it stands for return oriented programming. And it's basically the shiny technique for bypassing depth. So basically what happens is the attacker injects an attacker controlled call stack. And as you all know, a call stack has return pointers to where the execution is supposed to return after you get out of a function. So what the attacker does is they set these return pointers to always point to loaded modules that are valid to be executed. And a few instructions before are ret instruction. So you can basically chain these together and then you can try to, okay, so you can basically try to achieve the attacker's intention without actually injecting code. They're just reusing code that's already valid to be executed. And so things like virtual protect, for example, are commonly robbed to change memory protection on pages. That's used by a lot of exploits. And stack pivot, for example, is a pivotal technique inside the rot exploits to basically switch the ESP, which is the stack pointer on x86, from where it's currently pointing to, which is on a regular stack, to the attacker controlled call stack. And I have more information about this in the presentation I did at NullCon about rot. That was in greater detail, because it's just one slide, like I said. Hopefully you all got what I'm talking about. Okay. So some of the rot mitigations, these are new in 4.0 from 3.0, include the load library mitigation, which is basically to make sure you're not loading DLLs from network shares, because that's kind of creepy. The memory protection where we basically make sure you're not making stack pages executable, because as you guys know, stack pages are supposed to be data, so read and write, not execute. The color mitigation where we basically make sure that the return address where this current frame's return address points to a location that's preceded by a call address, which calls this function. So that's basically so that you're not returning to this function. The same exact flow where we make sure we don't ret to rot gadgets after this function returns. And the stack pivot, which is basically where we check the ESP x86 register to make sure that it's between the stack pivot and the stack base that's identified by the tab for a process. And my co-worker Ilyas did a good presentation about a deep presentation about the rot mitigation in his recon presentation from this year. Okay. So this is the architecture of MET. So basically we have the protected processes like you can see on the bottom, the IE process and Acrobat and whatever else you want to protect. And you see MET.dll loaded into there. Those MET.dll implements the memory corruption mitigations. And as you can see on IE, you see the MET CE on the bottom also. That's where we have the PKI mitigation, a part of the PKI mitigation. I'll go into more detail about that later. And basically all these DLLs use inter-process communication to communicate with the MET agent, which you would see running on your machine if you're running MET. And that's basically the one that MET agent is the one that implements the Tray icon and the logging and the PKI logic. The MET CE.dll is basically loaded into the into browsers or programs that use Cappy, Windows Cappy APIs, crypto APIs. And oh, God. Okay. What's this called? Shot the noob. What's he going to do? Louder. There we go. Thank you. I would eat someone from the audience. First time DEF CON attendee. No, no, no. There we go. Come on up. I'm usually going for the first hand I see you up, which is a good try, though. Good try. I have a question. So do you guys walk around to five tracks every hour taking shots? That's a good question. The first speaker has actually asked the question. So the speaker goons are we doing shots with everyone? Yes. That's exactly what we're doing. That's epic. To InfoSec. All right. Thank you. Good luck for the rest of the day. Paul's having a rough morning. You can be up here with me at school. Okay. So let's try to pick up right where I left off. Yeah. So basically anything that uses Cappy is protected, including other browsers, like Chrome or whatever could be protected by this, this PKI mitigation. Okay. So now I'm going to be talking the rest of the time about PKI and the new mitigation. So PKI stands for Public Key Infrastructure, which is, as Wikipedia puts it, basically about dealing with digital certificates. Excuse me. Did he just say at DEF CON, I'm going to talk about PKI, which stands for Public Key Infrastructure. Evidently we're in the advanced track. Continue. I'm trying to make sure everybody gets my talk. So this is basically used to ensure confidentiality, integrity and attribution online. And it's like the basis of like HTTPS and dealing with like your bank website or whatever else or other secure websites that you want to keep secure. So here's an example. This is what PKI looks like. So you can see at the root, you have the root certificate, obviously. And it basically, so every parent signs the certificates for every certificate underneath it. So for example, in this case, the root certificate would sign the intermediate certificates and the intermediate certificates would sign and turn the end certificates. So the end certificate would be like whichever site you're trying to log into over HTTPS. And it's basically a chain of trust rooted by the root. So there's been some recent TLS and SSL incidents that you all might have seen in the news and stuff. So starting back as far as 2008 when Satorov and Stevens proved that MD5 was harmful and their MD5 is harmful paper. And then in 2011, we saw like three different attacks on CAs. So basically fraudulent certificates being issued. And then in January of this year, we saw a third trust get compromised. So in a nutshell, PKI is under attack. I heard a yay from the audience. So some, so PKI certificate painting is basically assuring like enforcing certain assumptions or expectations about certificates that we get from the internet. That's a broad definition. And there's already been some pretty good work in this space as well. Moxie, Moran Spike and Perrin, they made tack and convergence and a few others. But as you can see, all of these require changes to existing protocols. So for example, in the tack case, you see TLS changes, convergence has a new protocol, then TLS has DNS changes and HSTS and what they implemented in Chrome had to change HDP. So history has told the industry again and again that requiring changes to protocols or new protocols takes forever to actually be adopted by everybody. Like look at IPv4 and IPv6 for example, not everybody is using it all the time. So our design goals, we had three main design goals. One is to give control to users. So like you can pick the exact certificate you want to pin to or not pin to. You can pick domain names and then other heuristics that I'll go into later. Another thing we wanted to do was not require changes to pre-existing or new protocols because as I mentioned, that takes forever to get adopted. And finally, we wanted to keep EMET as a stand-alone tool and not depend on any other services out on the internet or anything. It's like its own self-contained tool. So this required us to make design decisions and trade-offs that a lot of other implementations couldn't make for PKI for pinning because we had to conform with what was already out there and we had to still try to protect stuff. So our approach was to not require any protocol changes and we pinned to root certificates, not intermediate certificates. So there's in that tree that I showed you earlier, there could be some certificates in the middle like the intermediate certificates. We don't check those. And we also are pinning to only certificates in the Windows trusted route certificate authorities store. That's like if you go to MMC, you'll see that. And we also had to identify certificates. This was a bigger discussion in our team to figure out how to do this because we were trying to figure out whether we should pin to issuer and serial number tuples or to subject key identifier. And I'm going to go into more detail about this because this was kind of a big deal, a big decision for us. So as the RFC for X509, which is RFC 5280 says, the issuer name and serial number identify a unique certificate. It's pretty blatant and obvious. But that's like really rigid because if you're trying, so it is a valid case that two root certificates could have the same public private key pair. So although you would be identifying a unique certificate, you would still have false positives because you are identifying a certificate, not a key. So we decided to also add an option to pin to a public key. So in this case, this would be the SPKI, the subject key identifier of the root certificate. And this is thanks to feedback from the community. Thank you for your feedback. And this is also from other people giving us feedback like Google and stuff. So shout out to everybody that gave us feedback. So this is what our architecture looks like for the PKI subsystem. Basically, we have a bunch of pin sites. So in this example, I'm taking the Skype example. So we have a bunch of pin sites at the bottom. So for example, login.skype.com and secure.skype.com. And they're obviously both Skype services. So they would share the same pin rule, which would be the MS Skype CA. And those services are expected, the expectations that we're forcing via the definition of pinning are pinned to things that we expect to see like Baltimore, Cybertrust, Verisign, Global Sign, and GTE Cybertrust. So in general, basically different services under the same organization or whatever, share certificates that they're pinned to. So we implemented a crypto API CAPI extension. This is what I said was in the MSE64.dll. And this basically communicates with the MN agent. And so we're passing, so we're inside the process that uses CAPI and we're passing the full certificate change. So the N certificate, all the intermediate certificates and the root certificate to the MN agent that I mentioned earlier. And then the MN agent makes the decision about whether or not the certificate is okay or not. And we, as you can see at the bottom, we have the little crypto, the crypt register OID function, that's a code snippet kind of. And you can see that we specifically target SSL over there. So this is specifically for SSL checks. So we have, here are some checks that we do on the certificates. So we basically check the N certificate and different properties of it, like the subject name, the DNS name, or other things in there. And we basically make sure that it matches a pinned site that I mentioned earlier, that's configured for Emmet. And basically a root certificate is what I showed you earlier as the root of the tree and the N certificate is the certificate that the ACDPS server gives us. And then we check if the pin rules expired or not because that expires. And either depending on the configuration of that decision that I mentioned earlier that we had to make about pinning to individual certificates or pinning to public keys of certificates, in all, in all cases, root certificates, we either checked if the public key is a match or the serial number and the subject name. And so here's some more, here's some, what we call exceptions where we are doing heuristics on the certificates. So we checked the public modulus bit length, which is the size of the length, which is basically a measure, it's a measure of the key's strength. So if you have like a 512 bit key, that could be considered small. And if a bigger key, like a bigger key than that, that could be considered stronger. So it's, like I said, a measure of the strength of the key. So we have like a minimum bound on it so that the user can also do, can check that. They can also check the digest algorithm. So if it's like MD5, which was proven harmful in the past, they can disallow that or they can disallow roots from certain countries if they don't, like for example, if they don't think verisign should be in a different country than the US or something, they can check that and mark that as weird. So in general here, we're basically trying to give a lot of control to the users so they can decide what they want to and don't want to check in the certificates. That was one of the design goals. So here are some of the default protected domains that ship with Emmett. So this is in the certrust.xml. And these are both third-party and Microsoft domains and sites. So these are basically, like you can see like Twitter, Facebook, Yahoo. Those are basically other companies that wanted to cooperate and be in this with us. So shout out to them. And so this is basically various, various domains that we're pinning to. And this can be configured by the wizard in Emmett. So I believe it's just best to be upfront and straight up about what the limitations are and not try to hide it. So some of the limitations are that we mitigate specifically for SSL and TLS, not other crypto protocols. We are pinning to just, we're just checking the end and the root certificates, like I mentioned earlier. We're not checking the intermediate certificates. So that, that's a possible limitation. The pin configuration is statically shipped with Emmett. So we don't, it's not like in Windows update or something, where we're like pushing down new configuration or something like that. It's basically whatever comes with it is what it, what we have for that release. So they could be outdated if tomorrow, like some company decides to change, change the root that they change their certificates to. And in general, like Emmett's mitigations are not 100% bulletproof. They try to raise the bar for the attackers, but there's a way to get around it. So, yeah. So, okay, demo time. So do you all want to see a live demo or pre-recorded demo? Live? Raise your hand if you want to see live. All right, we'll do live. Hopefully this works. Given the DEF CON network, I don't know. Okay. I have a VM here. Please work. Unidentified. Okay. Hopefully. No, apparently the DEF CON network is not serving us today. So, okay, I'll just show you guys a video. Yeah, I know. Okay. Who's tossing the network? Okay. So, okay. I can't see this, but I think you can. Let me, guys, let me, yeah, it's a maker day brighter. For Emmett or for the picture? Okay. Okay. I have no idea what's happening because I can't see the screen. Hold on. I'll probably get a better idea if I duplicate my screen. No, nothing. I heard a bunch of random yelling. I didn't really hear anything. Resolution. Awesome. Okay. Man, I really wanted to do a live, but whatever. So, okay, as you can see here, this is the configuration for Emmett. So, can you all see the text? Let me increase the resolution then. HD. Smaller. Okay. Cool. Can you all see that? Please? It works. Is that good? I heard a bunch of groaning. Okay. Okay. So, I'm just going to explain what's happening. Okay. If I'm trying to make it, change it once more to make it even smaller. 10, 24, 7, 68. Old school. I don't have the zoom tool. Okay. Yeah, I can see it. Okay. Can you see that? Okay, whatever. So, I'll just explain what's happening then. So, basically, you see the configuration and that was that Emmett configuration. And now login.live.com is working and the certificate is good and stuff like that. So, I'm going to fast forward. So, the point here is that we see that the certificate chains to the verisign root, which is in our trusted store. And that's the MMC that I was mentioning earlier. Okay. So, now on this VM, I was running a web server where I was serving up an ACTPS page. But that ACTPS page was encrypted with certificates key who chain to another root in my root store. But it wasn't the same verisign root. So, this could represent, like, if you're getting man in the middle or something, by a certificate that chains to another root in your root store, like, for example, this year the Turk trust, if they got compromised and they're in your root store and you would chain to them and then you would trust them because the certificate chains to them and they're in your root store. So, I manually added a certificate to my root store and I'm changing the hosts file here to point login.live.com to a local host, the web server. So, as you can see here, you see login.live.com. This is my page. And on the bar on top, you don't see it red or anything and you see a padlock there which would fool you into thinking it's good. That's because I have a certificate with login.live.com, domain name listed there that chains to a root in my root store. But it's obviously not good and it's not login.live.com. So, this is just to prove to you guys I'm going to show you the MMC that's open. You might see or might not be able to see. I don't know. The MMC that's open, that is a certificate that I generated and it was a root that I generated. So, it was not correct. Okay, now the cool part. So, now when we enable the login.live.com rule, as you can see there, login.live.com works as expected. But when I changed the hosts file to point to my local web server and then I run IE there. You see that little icon there? So, I detected that there was an SSL, there was a problem with SSL certificate. So, it said that it's basically a warning. So, although IE doesn't show that the bar is red or anything, that certificate, no, sorry, that icon pops up saying that there's something weird going on here. Okay, so now to switch back. Okay, we had to do it recorded. Sorry, guys. So, yeah, so that's basically it. Some references. So, you can download MET 4.0 here if you need it or if you want it. And this is a lot of good work, references to a lot of good work that I used when I was making this presentation and when we were making the design decisions for MET. So, any questions or anything? Also, I want to say that this was a team at the whole MET team for making this possible. So, the mic wasn't on, but the question I think I heard it was can you pin a site to multiple root certificates? Yeah, so that's what we're doing. So, in that example that I gave about Skype, you see like the login.skype.com I think it was. So, that had multiple, it had Baltimore CyberTrust root and GTE. And is there a way to tie that into GPOs or otherwise push it into an environment that does SSL decryption or would want to do that to multiple users or does that have to be done on individual basis on individual machines to change those settings? I'm at support GPOs, so that's why I was saying if you have like a million computers or whatever, you can set it through GPO to propagate down to everybody so that you don't have to go into every computer. Hi, I have two questions. The first one is there was a couple of applications that are not browser based are actually incorrectly implementing SSL. So, and the EMET is as far as I understand protects a specific application. So is it? EMET what? Protects a specific application that you pre-define. Is there a way to make EMET work on all applications on? No. So, are you talking specifically about SSL? Yeah, because this is a problem that would be relevant not just to browsers but to other SSL applications. Yeah, so in that case, yeah, so I saw like Outlook, when I was using Outlook it had the mhce.dll loaded because it's looking for a cappy. So in that case, yes. I meant no for if you have like memory corruption, like rot mitigation or whatever, that would be like for Acrobat or for IE or something. But yeah, if you want to do the crypto API, if you're using crypto API in your application then this would protect you. It loads it into anything. It registers the DLL. So it would be loaded to anything that uses crypto API. So that's why it works for like other browsers also, for like Chrome or IE or Outlook, which is not a browser obviously. Okay, and thank you. Another question is why don't you integrate this notification with a regular announcement or notifications about fraudulent or incorrect certificates? So why is it a separate notification? Separate than what? Then if I had a fraudulent or incorrect certificate coming to my browser, I would be notified in another way, right? Well, I mean with the red bar, for example, yeah. So changing, so IE is like a lot of code and it's huge and changing like the behavior of IE would be like really difficult. And so like I said, we wanted to send alone. So we just wanted to display this notification just like we display all the other notifications, like the one that people are used to, like to see the emet in the little tray icon. We didn't want to be changing the behavior because you have to go through like a bunch of other stuff to change the behavior. No. So first, thank you for having the guts to come before this August group of users to try our hand at explaining this. But the question is, does this provide would it be fair to say this provides a baseline of certificate validation through windows where before previously it was an external application suite or toolset you had to use to check to see if certs are valid for OCSP and other things. In other words, is this OCSP based? Is it Krill based? No. It's not. So basically when you're asking about replacing other tools or something, when you're asking about replacing other tools and stuff like that, each tool has its own strengths and weaknesses. So for example, our strength, I think, was that we didn't try to change any protocols. So you can use other stuff also that might not have the same weaknesses as emet. But then the strengths also change. So what I'm trying to say is that it's not a replacement. It seems like there's many different solutions out there. So this is just another one that I think that has some pretty good strengths with not too bad weaknesses. Do you have plans for providing emet protection as an API for third parties? Not that I know of yet. Why? Well, we just released it a few months ago. No, emet has been there for two years. No, the PKI mitigation. I understand. I'm wondering if it's an emet. Oh, okay. So you're talking about the memory corruption mitigations? Yes. I talked about that to my co-worker. We're thinking about that still, but we have to still have time to outweigh the benefits and costs of it. For example, would it break everybody that's using it? Or would it break some really popularly widely used applications? Because if you have a lot of people, you have to be very mindful about not breaking them with... Because sometimes they rely on your software through undocumented methods that are not according to the software contract. So you are using undocumented constructs? No, we're not. We're just doing our own... We're basically just doing all of our stuff is looking at memory corruptions inside of our own DLL. So we're not going to do that. So what I'm saying is, when you change the operating system, you have to be very mindful about who you're going to affect. I mean, this is no different than asking third party vendors to write software device drivers. To write what device drivers? Device drivers. So anyone who writes device drivers altering the kernel, right? Right now. We can't expose Windows APIs that do this because it's not a part of Windows. This is a separate standalone tool, like I was saying. There are many libraries you are exposing. We have these DLLs loaded into processes and stuff, but we haven't made the decision yet or even talked about putting it in so that everybody can use it. So I can take that as a question. You said pinning rules expire. Could an attacker with local access modify the date or something to avoid it and fall back to standard PKI? So all that stuff is stored in the registry. So they would have to have registry access to access the configuration of it. Oh, and the question, sorry for those people that can't hear. So he was saying that can an attacker modify the date or something like that? Anything else? Questions? Okay, thank you.