NEIL SIKKA: Hi, DEF CON.
My name is Neil Sikka, and today I'm going to talking
about EMET 4.0 PKI mitigation.
So EMET is a tool from Microsoft, and it's a free tool
to mitigate different various attack techniques.
So a little bit about me.
So I'm a security engineer on MSRC, Microsoft Security Response Center.
I look at 0days that have been, like, in the wild or privately responsibly
reported vulnerabilities.
I'm an EMET 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 will be going into what EMET is followed
by new features in EMET 4.0, the architecture of EMET and then I
will be taking a deep dive into the PKI feature
of EMET which was our first non memory corruption mitigation.
And then I will be giving a demo that hopefully works live.
So, first of all, what is EMET?
EMET is a tool that mitigates different exploitation techniques.
It has been historically for memory corruptions
and stopping exploits that take advantage of memory corruptions.
And one thing about it is that it is not signature based, rather it
is behavioral based.
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 could stop things that people don't know about or even Microsoft doesn't
know about.
So, for example, 0days.
We have used it recommended it to mitigate some advisories in the past.
And because it's dynamically loaded at runtime, it
is like a DLL that gets loaded into your process address base.
So it doesn't require, like, recompiling or redeploying
your application.
And so if you have 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 is still supported so as far
as XP and it is a way to giving back to the security community and it
is 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 is basically Microsoft and third party applications.
So some changes between EMET 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 abusing PKI and stuff like that.
I'm not saying that PKI itself is bad or something,
but I'm saying sometimes it can be weakly implemented
or badly implemented if you use short keys or stuff
for your roots.
That was mitigation we added for that.
We added a mitigation for ROP exploits and hardening
for ROP exploitations and so you can have cool skins and stuff like that.
So, I'm going to first go into the memory corruption mitigation
that is we've had.
So we have basically forcing DEP on, which is data execution prevention.
It is basically by calling said process that we are
trying to protect with the DEP protection.
This is so you are not executing code on pages that are not supposed
to be executable, that are 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, it reserves it using those API.
We have mandatory ASLR which prefers
the module loading base address so the module cannot end
up loading there.
It reserves it so it is not able to load there so it has
to load somewhere else which is effectively ASLR,
but obviously newer techniques on newer versions of Windows
is safer and has higher entropy and stuff.
We have the null page mitigation where it reserves page address zero so you
can't refuse null pointer references or bugs.
Export address table filtering, that's basically if shell coded
for someone is trying to read the address table,
the hardware breakpoint on the export address table makes sure
EIPs, which is an instruction pointer, don't point to some random place
like in the heap, for example, because that's kind of creepy.
And then we also did bottom up randomization where we randomize
different data structures in the process address base.
As I mentioned earlier, these are all memory corruption mitigations.
And so some more memory corruption mitigations are the C hub which
is overwrite protection.
This is where we reverse the exception, the chain of them, looking
for one whose previous pointer is 1 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 ROP mitigation is new in EMET 4.0.
We have some hardenings for this.
For example, deep hook is where we protect things
like virtual protect and virtual protect EX.
So an API it would call, 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 it
is disallowing calling NTTLs LDR hot patch routine.
That's thanks to Yang Yu from KenSec West this year.
So our ROP mitigation, okay, I'm going to try to explain ROP
in one slide.
We will see if it works.
So return oriented programming.
And it is basically the shiny technique for bypassing DEP.
Basically what happens is the attacker is in a control stack.
As you 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 return
they set these return pointers to a few to always point
to loaded modules that are valid to be executed.
A few instructions before a RET instruction so you can
chain these together and then you can try to (beeping) then you can basically
try to achieve the attacker's attention
without actually injecting code.
You are reusing code that's already valid to be executed.
So things like virtual protect, for example, or commonly ROP
to memory protection on pages, that's used by a lot of exploits.
Stack pivot is a pivotal technique inside the ROP exploits
to basically switch the ESP to where it is currently pointing
to on a regular stack to the attacker controlled call stack.
I have more information about this in the presentation I did
at NullCon about ROP.
That was in greater detail.
This is just one slide, like I said.
Hopefully you all got what I am talking about.
Okay.
So some of the ROP mitigations, these are new in 4.0 from 3.0.,
include the load library mitigation which
is basically to make sure you are not loading DLLs
from network shares because that's kind of creepy.
The memory protection, we are making sure you are not making
stack pages executable because stack pages are supposed
to be data so read and write, not execute.
The caller mitigation, where we basically make sure that
the return address IS 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 sim exploit where we don't RET to ROP gadgets
after this function returns.
And the stack pivot which is basically where we check
the ESPx86 registry to make sure it is between the stack pivot and
the stack base that's identified by the TEB for our process.
And my co worker did a good presentation
about a deep presentation about the ROP mitigation
in his Recon presentation from this year.
Okay.
So this is the architecture of EMET.
So basically we have the protected processes.
You can see on the bottom the IE process and Acrobat
and anything else you want to protect.
EMET.DLL implements the memory corruption mitigations.
On the bottom, you see that's where we have
the PKI mitigation or a part of the PKI mitigation.
I will go into more detail about that later.
And basically all these DLLs use interprocess
communication to communicate with the EMET agent which you would
see running on your machine if you are running EMET.
And that's basically the one that EMET agent
is the one that implements the tray icon than the logging and
the PKI logic.
The EMET ce.dll is basically loaded into browsers or programs that use
CAPI, Windows CAPI, crypto APIs.
Oh, God.
Okay.
(applause) What's this called?
Shot the n00b.
What's he's going to do?
Drink.
Louder.
Drink!
There we go.
Thank you.
We need someone from the audience first time DEF
CON attendee.
No, no, no.
(laughter).
There we go.
Come on up.
I usually go for the first hand I see up.
Good try, though.
NEIL SIKKA: I have a question.
Do you guys walk around to five tracks every hour
taking shots?
That's a good question.
The first speaker actually asked the question.
So the speaker Goons, are we doing shots with everyone?
Yes.
That's exactly what we're doing.
(laughter).
That's epic, man.
(applause) To InfoSec.
(applause) NEIL SIKKA: Thank you.
Good luck for the rest of the day.
Paul's having a rough morning.
NEIL SIKKA: Okay.
So let's try to pick up right where I left off.
Yeah.
(laughter).
So basically anything that uses CAPI is protected including other browsers,
so Chrome or whatever, could be protected
by 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.
It is basically 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.
NEIL SIKKA: I'm trying to make sure everybody gets my talk.
(applause).
This is basically used to ensure integrity and attribution
online and it is the basis of HTTPS and dealing with, like,
your bank Web site or whatever else or other secure Web sites 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 enters and the intermediate enters would sign
the end certificates.
So the end certificate would be whatever Web site you are trying
to log into over HTTPS.
It is basically a train of trust rooted by the root.
There have been some recent TLS and SSL incidents you might have seen
in the news and stuff.
Starting back as far as 2008 when it was proved that MD5
is harmful in a paper, in 2011 we saw 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.
(laughter).
So PKI certificate pinning is basically assuring
like enforcing certain assumptions or expectations
about certificates that we get from the Internet.
That's a broad definition.
And there has already been some pretty good work in this space as well.
Moxi, Paran, they may attack and convergence a few others.
But as you can see, all of these require changes
to existing protocols.
So, for example, in the attack case you see
TLS changes.
Convergence has another protocol.
DNS has DNS changes and what they implemented in Chrome had
a new had to change HTTP.
So history has told the industry again and again that
requiring changes to protocols or a new protocol takes forever
to actually be adopted by everybody.
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 other heuristics that I
will go into later.
Another thing we wanted to do was not require changers
to preexisting 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 in the Internet or anything.
It's like its open self contained tool.
So this required us to have make design decisions
and tradeoffs that a lot of other problems 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.
Our approach was not to require any protocol changes.
And we pinned to root certificates, not intermediate certificates.
So there's in the 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 root certificate authorities store.
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 assure and serial number tupules 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 RFC5280 says it identifies
a unique certificate.
It is pretty blatant and obvious.
But that's like really rigid because if you are trying it
is a valid case that two root certificates could have
the same public/private key pair.
Although, yeah, 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 shoutout to everybody who gave us feedback.
So this is what our architecture looks like for the PKI subsystem.
Basically we had a bunch of pin sites.
In this example, taking the Skype example, we have a bunch
of pin sites at the bottom.
Log in.Skype.com, they are both Skype services.
So they would share the same pin rule which would be
the MS Skype CA.
Those services are expected expectations that we're forcing via
the definition of pinning.
Our pin to things that we expect to see like Baltimore cyber trust,
VeriSign, Globalsign and GTE Cybertrust.
In general, same services under different organizations share
certificates that they pin to.
So we implemented we implemented a crypto API CAPI extension.
This is what is in the EMET 64.dll.
This basically communicates with the EMET agent.
So we are inside the process that uses CAPI and passing
the full certificate chain.
So the end certificate, all the intermediate certificates and
the root certificate to the EMET agent that I
mentioned earlier.
Within the EMET agent, it makes a decision
about whether or not the certificate is okay or not.
And we as you can see on the bottom, we have the little crypto
the crypt registry ODI function, that's a code snippet kind of.
You can see we target SSL over there.
This is specifically for SSL checks.
So, here's some checks that we do on the certificates.
So we, basically, check the end certificate, the subjects,
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 EMET.
And basically a root certificate is what I showed you earlier
as the root of the tree and the end certificate
is the certificate that the HTTPS server gives us.
And let me check if the pin rule has expired
or not because that expires.
And either depending on the configuration
of that decision I mentioned earlier that we had to make about pinning
to individual certificates or pinning to public keys of certificates,
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 what we call exceptions where we are doing
heuristics on the certificates.
So we checked the public modulus bit length which
is the side of the bit length, it is a measure of the key strength.
So if you have a 512 bit key that could be
considered small.
If you have a bigger key, a bigger key than that,
that could be considered stronger.
It is, 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 check that.
They can also check the digest algorithm, so if it's
like MD5 which was proven harmful in the past they being disallow that
or roots from different countries.
For example, if they don't think VeriSign should be
in a different country than the U.S.
or something, they can check that and mark that as weird.
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's some of the default protected domains that
ship with EMET.
So this is in the thirdtrust.xml.
Both third party and Microsoft domains and sites.
So these are basically like you can see Twitter,
Facebook, Yahoo!
, those are basically other companies that wanted to cooperate and be
in this with us.
So we shout out to them.
This is basically various domains we are pinning to.
This can be configured by the wizard in EMET.So I believe it is 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 for other crypto protocols.
We are pinning to just we are just checking the end
and the root certificates like I mentioned earlier.
We are not checking the intermediate certificates.
So that's a possible limitation.
The pin configuration is statically shipped with EMET so it
is not like a Windows update where we're
pushing down new configuration or something like that.
It is basic my whatever comes with it is what what we have for that release.
So they could be outdated it tomorrow some company decides to change
the root that they chain their certificates to.
And in general EMET's mitigations are not bulletproof.
There is a way to get around it but they raise the bar for the attackers.
Okay.
Demo time.
So do you all want to see a live demo or prerecorded demo?
Live.
NEIL SIKKA: Raise your hand if you want to see live.
Fuck it, do it live!
NEIL SIKKA: Okay.
We'll do it live.
Hopefully this works.
Given the DEF CON network, I don't know.
Okay.
I have a VM here.
Please work.
Unidentified.
Okay.
Hopefully ...
Apparently the DEF CON network is not serving us today.
So okay I will show you guys a video.
(speaker off microphone.) NEIL SIKKA: Okay.
I can't see this but I think you can.
(speaker off microphone.) NEIL SIKKA: It
is to make your day brighter.
Thanks, Microsoft.
(laughter) NEIL SIKKA: For EMET or for the picture?
Both.
NEIL SIKKA: I have no idea what's happening
because I can't see the screen.
Hold on.
It would probably be a better idea if I duplicate my screen.
No, nothing?
Heard of a bunch of random yelling.
Resolution!
Change the resolution.
NEIL SIKKA: Awesome, okay.
I really wanted to do it live but whatever.
So okay.
As you can see this is the configuration for EMET.
So can you all see the text?
No.
NEIL SIKKA: Oh, man.
Okay.
Let me increase the resolution then.
Smaller.
NEIL SIKKA: Smaller?
Can you all see that?
Please?
Does that work?
I hear a bunch of groaning.
Okay.
So I'm just going to explain what's happening.
I will change it once more to make it smaller.
I don't have the zoom tool.
Yeah, I can see it, yeah.
Can you see that?
Whatever.
I will just explain what's happening then.
So basically you see the configuration and that was
the EMET 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 was encrypted with certificates key who chained
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 middled
or something by a certificate that chains
to another root in your root store, like, for example, this year the third trust
if they got compromised and they are in your root store and you would chain
to them, then you would trust them
because the certificate chains to them and they are in your root store.
So I manually added a certificate to my root store and I'm changing
the host file here to login.live.com, the local host server.
You can see this is not login.live.com.
This is my page.
The bar on top, you don't see it red or anything.
You see a pad lock which would fool you
into thinking it is good.
That's because I have a certificate with login.live.com domain name
chained there to a root in the root store.
It is obviously not good and it is not login.live.com.
So this is just to prove to you guys that I'm not lying.
Here.
So you see the MMC that's open.
You 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,
it works as expected.
But when I change the host file to point to my local Web server
and then I run IE, you see that little icon there?
EMET detected there was a problem with the SSL certificate.
It is basically a warning.
Although IE doesn't show the bar is red or anything, that certificate sorry,
that icon pops up saying that there's something weird
going on here.
Now to switch back.
Okay.
That was a demo and I guess we had to do it recorded.
Sorry, guys.
So, yeah, that's basically it.
Some references.
So you can download EMET 4.0 here if you need it, if you want it.
And this is a lot of good work references to a lot
of good work I used when I was making this presentation and when we were
making the design decisions for EMET.
So any questions or anything?
Also, I want to say this was a team effort so thanks
to the whole team, the whole EMET team
for making this possible.
(speaker off microphone.) NEIL SIKKA: 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, that's what we're doing.
In that example I gave about Skype, you see like the login.Skype.com.
It had both Cybertrust root and the GTE.
Is there a way to tie that into GPOs or otherwise pushed
down settings to users in a corporate environment?
Or does that have to be done an individual basis
on individual machines to change those settings?
NEIL SIKKA: EMET supports GPOs.
So if you have a million computers, you can set it through GPO
to propagate down to everybody.
I have two questions.
First one was there was recent research that showed that most SSL applications
are not browser based are incorrectly implementing SSL and EMET as far
as I understand protects a specific application.
NEIL SIKKA: EMET what?
Protects a specific application that
you predefine.
There is a way to make EMET work on all applications?
NEIL SIKKA: No.
Well, are you so you are talking specifically about SSL?
Yeah, because this is a problem that would be relevant not
just to browsers but to other applications.
NEIL SIKKA: So in that case, yeah, so I saw, like,
Outlook when I was using Outlook, it had the EMET.dll loaded because it
is looking for KAPI.
In that case, I meant no for if you have memory corruption
like if you have ROP mitigation if you have acrobat or IE.
If you want to do the crypto API, if you are using crypto API
in your application, it protects you.
It registers the DLL.
So it would be loaded to anything that loads encrypted API.
So it works for 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 the regular announcements
or notifications about fraudulent or incorrect certificates?
Why is it a separate notification?
NEIL SIKKA: Separate than what?
Than if I had a fraudulent or incorrect certificate come
into my browser, I would be notified in another way, right?
NEIL SIKKA: You mean with the red bar, for example?
Right.
NEIL SIKKA: So changing so IE is, like, a lot of code and it is huge
and changing, like, the behavior of IE would be, like, really difficult.
And so, like I said, we wanted to be stand alone.
So we just wanted to display this notification just
like we display all the other notifications,
the one that people are used to.
So see the EMET in the tray icon.
We didn't want to be changing the behavior because they have
to go through a bunch of other stuff to change the behavior.
(speaker off microphone.) NEIL SIKKA: 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: Is this intended to replace other certificate
validation tools?
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 suite application or tools
to check to see if roots were valid?
Is this OSCP based, is it Krill based?
NEIL SIKKA: No, it's not.
Basically when you are asking about replacing other tools
or something when you are asking about replacing other tools
and stuff like that, each tool has its own strengths
and weaknesses.
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 right now.
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 protection for third parties?
NEIL SIKKA: Not that I know of yet.
Why.
NEIL SIKKA: We just released it a few months ago.
No, EMET has been there for two years.
NEIL SIKKA: No, the PKI mitigation.
I understand.
I'm talking about in general as in EMET.
NEIL SIKKA: Oh, okay.
So you are talking about the memory
corruption mitigations.
Among other things, yes.
NEIL SIKKA: So I have 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 the costs of it.
So, I mean, for example, would it break everybody that's using it
or would it break some really popularly wildly used applications?
Like, if you have a lot of users, for example, you have
to be very mindful about not breaking them
because sometimes they rely on your software
through undocumented methods that are not
according to the software contract.
So you are using undocumented constructs?
NEIL SIKKA: No, we're not.
But I'm saying we are just doing our own we are basically doing
all this stuff is looking at memory corruptions
inside of our own DLL.
We are not using our own undocumented stuff that I'm aware of.
When you change the operating system, you have
to be mindful of who you effect.
This is no different than asking third party vendors to drive
to write software device drivers.
NEIL SIKKA: To what device drivers?
Device drivers.
Anyone who writes device drivers is altering the kernel,
so why don't you will expose those APIs for third parties.
NEIL SIKKA: This is not a part of the operating system right now.
There is no we can't expose Windows APIs
that do this because it is not a part of Windows.
It is a separate stand alone tools.
There are many libraries you are exposing.
NEIL SIKKA: We have DLLs loaded into process
but we haven't talked about, I guess, putting it in,
like so that everybody can use it.
So, yeah, I can take that as a feedback.
I'll bring that up.
Thank you.
You said pinning rules expire.
Could an attacker with local access modify the date
or something to avoid EMET and fall back to standard PKI?
NEIL SIKKA: 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 configuration.
I was saying no, you can't.
Because it's the configuration is stored in a privileged location.
Anything else?
Questions?
Okay.
Thank you.