 Okay, so my name is Moxie Marlin Spike. I'm here for the Institute for Disruptive Studies. It's like an anarchist think tank I'm gonna be talking about some new tricks for defeating SSL in practice. I Eventually hope to leave you guys with undetectable man-in-the-middle attacks against SSL connections But it's part of a story so I'm gonna start you know, I hate to repeat myself, but I'm gonna start with the old and Eventually come to the new so the story starts with this concept of base basic constraints and That story starts with certificate chaining So when people think about certificates, they usually think about certificates coming in pairs They think of two types of certificates CA certificates, you know, these things that are sort of all powerful They're embedded in your web browser And then site certificates. These are the things that identify Leaf nodes or any given entity But sometimes the picture is a little bit more complicated Instead of just two certificates, there could be more. You could have a certificate chain The idea itself kind of makes sense Perhaps you'd like to delegate signing authority to a third party But that third party doesn't have their certificate embedded in every web browser since 1996 So what do you do you sign the third-party certificate and they in turn sign your certificate? And so, you know when you get one of these things you apply, you know You hand the whole thing to a web browser and the web browser deals with it. Okay, and You know, it could be more than three you can have any number of Intermediate certificate authorities in the chain. I don't think that there's any standard that says how many is the maximum I think it's implementation specific. I know for Firefox. It's like 25 So you could have a certificate chain with 25 intermediate CAs in there So the question is how do we verify these things, you know, you get a certificate chain. What do you do? And what everyone says is You start with a leaf node and you verify that the name on the leaf node is the same as the name of the site You're trying to connect to then you verify that the leaf certificate hasn't expired and then you check its signature And if the signing CA is in your list of trusted route certificate authorities you stop. Otherwise, you move one up the chain and you repeat So here's you know a picture from IBM's website today and you know it has a little graph about Validating these things and you know, they lay it all out and in the same way of you start with a leaf node And you keep going back up. I've said before that I feel like when looking for security vulnerability is a good place to start Places where developers might not understand the full scope of what's going on and yet feel really good about the solutions that they implement So for instance when validating a certificate chain, it's attempting to use a simple recursive function And this is a situation where you know a developer might implement a solution and think man I used recursion today, and it was awesome. You know It was like the same function calling itself over, you know But the results of sort of a naive recursive attempted validation is that you will ensure that a certificate chain is complete But nothing more And here's what I mean by that So let's say you have this picture fairly common picture some Root certificate authority a couple of intermediate CAs and then your leaf node that identifies a website you own like thoughtcrime.org So a website I have So what is to stop me? from doing this creating another certificate for some other website paypal.com and then signing it with my leaf certificate and Then passing that whole chain to any client if you go back and you look at what people say about how you validate these things We haven't really done anything wrong You know all the signatures are valid Nothing's expired The chain itself is intact and the root CA is embedded in The web browser and trusted But we just created a certificate for PayPal and we're not PayPal So the missing piece is this somewhat obscure field called basic constraints The idea is that not all certificates should be able to do all things right like if you have a End entity certificate for a website that should really only be used to identify your website It shouldn't be used to sign other certificates or for key revocation and or anything like that The problem was that back in the day When most certificate authorities would issue certificates, they would just leave this field out And you would think that like if you were writing an SSL implementation And you were sort of checking a certificate if this thing was just absent You would absorb you would assume the conservative thing that this is not a certificate authority certificate But it turns out that whether the field was there or not Most SSL implementations just didn't bother to check it What this meant was that anyone with a valid leaf note certificate for any domain Could create and sign a leaf certificate for any other domain It essentially meant that anyone who had a valid leaf note certificate had a CA cert And when presented with this complete chain Internet Explorer Conqueror Outlook open SSL Many different SSL implementations All considered to be to be completely valid So then back in 2002 Microsoft did something particularly annoying and I blew this up by publishing it and Microsoft claimed okay. This is a real vulnerability, but it's basically impossible to exploit So I published the tool that exploits it That tool is called SSL sniff It works like you'd expect let's say you have a client in a server Clients trying to connect to the server using SSL states trying to connect to PayPal SSL sniff would perform a man in the middle attack. So it intercepts the client's connection request to the server and Generates a certificate for the site that the client is trying to connect to So it generates a certificate for PayPal comm on the fly and then it signs with with any random leaf node certificate That you give it and then it passes the whole chain back to the client Simultaneously on the server side it makes a normal SSL connection to the server and Then starts passing data back and forth between the client and the server The important thing is that in the middle here The data is in the clear and you can log it or modify it or do whatever you want Okay So the question is Post disclosure, you know 2002 was a while ago. Is this thing still useful? Is this tool still useful? So first you'd be surprised who still doesn't check basic constraints The second thing was that even after like browsers had been patched this tool is pretty effective because You would be surprised, you know most of the time users would just click through the dialogues And there's actually some kind of cool stuff you could do or like A lot of SSL implementations or web browsers would start to validate a certificate And then as soon as they something was wrong with the certificate They would pop up a dialogue telling you that something was wrong And like the second thing that they do after checking the name is check the time stamp to see whether it's expired or not So you could like on the fly create certificates that expired 10 minutes ago That the signatures are totally bogus like completely fucked and it would pop up a dialogue That's like something is wrong this certificate expired 10 minutes ago And you know most users would be like well, it only expired 10 minutes ago. I mean, you know, it's not bad bad, you know So, you know, but it wouldn't tell you about the signature problems or whatever, you know Because it would just get right there and stop so yeah, so it was still useful in that sense and And then it's still just useful as a general tool for man in the middle of text on SSL Like the folks that did the empty five hash collision stuff They use this tool to deploy their CA cert right because once you get a CA cert That's nice. But how do you do like on the fly man in the middle of tax, right? Well, you need something that will intercept the connection generate a certificate on the fly sign it with what or What with whatever certificate you give it and then pass the thing back to the client, right? And that's exactly what this does so and So then there's other uses yet to be to be disclosed another day and today More lately I've been talking about SSL stripping I've been talking about a lot lately, so I'll try and be kind of brief But SSL stripping is funnel fundamentally about the concept of bridges, right? So the thing is that SSL is useful, but how it's deployed really matters On the web SSL is almost never encountered directly, right? Very few people type HTTPS colon forward forward slash Something into their URL bar most people type Bank of America comm enter right and so My sort of thesis is that SSL on the web is really only encountered in one of two ways It's either encountered as a 302 redirect from HD from an HTTP URL So it's either encountered by somebody typing Bank of America comm enter into their URL bar Which makes an HTTP request to the server the server responds with a 302 redirect that says please Instead connect to HTTPS colon forward forward slash Bank of America comm and the browser just sort of gets upgraded to SSL And then the second way is they're clicking on links, right? So most users browse along and eventually they encounter a link that says Sign in or shopping cart or check out or whatever and that's the moment where they encounter SSL on the web Both of those points are bridges between an insecure and a secure protocol and They're weak points So the idea is that maybe we can attack SSL before we even get there So in the past, you know SSL sniff would go after the SSL connection itself, right? It's job was to man in the middle the actual SSL connection And so I wrote a different tool called SSL strip and What it does is perform in the middle attacks on the HTTP connections that will inevitably happen before an SSL connection And that's not hard at all because it's not a secure protocol So SSL strip basically just does a man in the middle attack on all the HTTP connections on a network And it watches the traffic go by and in its most basic form It looks for these two points links and 302 redirects And if it sees an HTTPS link it swaps it for an identical HTTP link and it keeps a map of what has changed If it sees a 302 redirect it looks for the location header Which is where the redirect URL will be and if it sees an HTTPS link in there It swaps it for an identical HTTP look-alike and it keeps a map of what has changed Then it continues to watch the HTTP traffic go by and if it sees a request for a URL that it's stripped It proxies that out as SSL to the server, right? So the server never knows anything's wrong It's getting SSL connections on the URLs that it expects to get SSL connections for and You know on the client side it still just happens to be HTTP and then you just keep watching the HTTPS traffic come back from the server and You keep a map of all the relative CSS links JavaScript links You know all that stuff right because that should be those should be SSL connections, too And of course you log everything that you want to log So how does this look right? So the idea behind most of the stuff is that there's been sort of an evolution in the way that Browsers deal with what I would call positive or negative feedback It used to be in the past that browsers I felt had this Strong emphasis on positive feedback, right that little padlock icon was everywhere You know it was in the status bar down on the bottom right, you know firefox's entire URL bar would turn gold You know thought there's all these things telling you this is secure, right? And by contrast if there was a problem it would just pop up a dialogue, you know but today I feel like there's been this evolution of Toning down the positive feedback and ratcheting up the negative feedback So all the little lock icons they're just sort of less and less of them You know there's less things to tell you that things are secure and more things to tell you that things are really bad Right there's not just dialogue boxes anymore like on firefox if there's a problem it actually the page renders out to say There's something really wrong it takes it's something like five clicks or something to get through that I mean, it's not the thing that users just click okay anymore, right? And so the idea is that if you can avoid the negative feedback You're in really good shape right and if you fail to trigger the positive feedback Maybe it's not so bad that most user experiences is just they just browse along until they encounter something that says Look out. There's something very wrong, you know, and until they see that they don't think anything's amiss So okay, so how does this basic attack look this SSL stripping attack, right? So this is like Gmail's log-in page on Firefox 3 You know, this is the secure version This is the strip version. It's pretty subtle. No dialogue boxes. Nothing saying everything is wrong, you know This is Safari, right? This is the secure version This is the strip version Sure to again, so there's the only thing on Safari is if you look at the top, right? There's that little blind embossed padlock That's the thing that disappears So not bad, right? And this evolution of positive and negative feedback really helps this technique, right? So this is I've been talking about this a lot But this is just the starting point for this type of attack once you start to attack this bridge between HTTP and HTTPS There's a whole ecosystem of things that you can do one of the ways that I one of the things I suggested of a different direction you can go from there is adopting homograph attacks to To work in this situation as well But there's a whole bunch of stuff that I've already written about it that if you're interested you can find elsewhere So the question of today is where can we go from here, right? The larger question for me is where do we need to go from here, right? Like I maintain that this stripping attack is deadly in practice and will be deadly for a long time that You know in field testing it has a hundred percent success rate, right? I mean even like seriously even, you know There was some response to this where people like oh, this is a matter of user user education users Don't know what they're doing, right? And so I gave the same talk just about SSL stripping at Black Hat Europe in Amsterdam and for like 20 minutes before the talk I ran SSL strip on the network and I got like a hundred passwords from you know So-called security professionals, right? And so I just you know, I put their passwords up on a slide and it was like see you know if you see your password here You also fell victim to this right? Anyway, so This is deadly in practice, but you know what do we need, right? So there's some there's some places that this technique does not reach, right? One of them is like people that are starting to use bookmarks now for their secure sites, right? So there's you know people that have their Gmail login bookmarked to be HTTPS, right? So they don't expose the bridge And then the other thing is other protocols, right? There's plenty of SSL based protocols like IMAP, IMAPS, SMTPS, POP3S You know IRC SSL over IRC stuff like that and those protocols don't expose this bridge SSL VPNs stuff like that So what we need is a different technique to Attack these these points Okay, so Let's start thinking about that. The first thing is what's up with certificates, right? Everyone always talks about certificates, but what are they really? They're actually these pretty simple structures the basic point of a certificate is to identify some subject and Convey that subject's public key The certificate is thought to be good because it's issued by some issuer that people might think is you know trustworthy and It's known to be authentic based on that issuer signature You know, this is what a certificate looks like This is a Google's certificate and you can see that you know the subject is Google and is issued by thought and you know There's some public key in there, right? now When designing a secure protocol The three big things that you're after are secrecy authenticity and integrity Most people talk about secrecy, you know, they think of encryption and they think secrecy But if you don't have authenticity and integrity, you don't have anything they're they're Critical and we will see why You know the basic SSL Beginnings of a handshake look like this Client sends a message to the server that says hello. I am some client. I use SSL version Whatever these are the cypher suites that I support I also like these compression methods and here's some random a random number and some other information The server responds. Yes, hello. I am the server. I also support this version of SSL. Whatever I think we should use this Cypher suite and this compression method and by the way, here is my certificate so As soon as the client gets the certificate the first thing it's going to do is look at the subject and and it's going to make sure that It's the same thing. That's what it's trying to connect to right? And so it's going to compare the subject with whatever you typed into the to the URL bar on your web browser Or whatever you typed into the mail server field for your IMAP client or whatever you typed into the Server field for your IRC client or for your VPN software or whatever Right, and this is really where the problems for us begin as attackers, right? Because we can perform a man-in-the-middle attack here We can you know intercept the client hello and we can respond with our own server hello That says yes, I am the server whatever but we have to send a certificate And what do we send right? We can't send the real certificate from the actual server because it has a public key in it that we don't have the corresponding Private key for and as soon as they start encrypting things. We won't be able to decrypt them So this is a problem So let's start by looking back into the past So like in you know 2000 the late 90s or whatever things were different When I was applying for like certificates to exploit this basic constraints vulnerability that I talked about I Just needed to get a certificate for a domain that I owned right and back then it was like it was crazy There's notaries. I had to show actual state ID to people There are phone calls with actual people involved I actually remember talking on the phone with this guy at Versailles at one point and he was like grilling me You know and I was thinking to myself my god. How am I gonna prove to this guy that I am me? You know and this was like totally, you know legit just needed to get a cert for my domain, right? That is a bygone era today, it's all about this thing online domain validation and All of this whole process was no the reason all the stuff has been replaced by a website You go to the website and you submit your certificate signing request The certificate signing request is another basic structure. It's defined by the standard pkcs number 10 And it just has a few things in it, right? It's like, you know version number that the thing supports the subject public key And whatever attributes you might want so here again as our old friend the subject This is the exact value that will later be included in the certificate that is issued by the certificate authority, right? You know ideally we might want it to say something like Bank of America comm When you submit a certificate to a certificate authority and it has Bank of America comms the subject The first thing that the certificate authority does is look at the root domain it does a who is look up for that and Pulls out whatever contact information is in the who is record and then it sends an email or makes a phone call or something to Whoever that might be The important thing here is that it only looks at the root domain, right? Because this is where that information is contained, right? It doesn't give a shit about Subdomains, right? It could be it doesn't care if it's dub dub dub Or you know, it could be certificate authorities or a total ripoff dot Bank of America comm, right? If you submit that it will dutifully look up Bank of America comm pull out the who is record and send Whoever some contact email. There's no one to be offended. You know, there's no one looking at this is an automated process Okay, so I am simplifying things a little bit Subjects are not just you know an ASCII string in this thing, right? It's actually this structure called a distinguished name To understand the structure you have to understand that the X 509 standard is a total nightmare There have been three revisions over the course of 20 years parts of the standard have literally been lost and then found again I'm not kidding when the 1988 standard was being like updated to the 1991 standard I think whoever was just like cutting and pasting it over just forgot to cut part of it out and paste it in and then that Was published as the standard and then people implemented the standard based on what was published And then after the implementations were out there people like oh shit We forgot part of the standard and they put it back in But then it was like there's all these implementations that already do it the wrong way But it's kind of the right way because for a second it was the right standard, you know, and so it's like the standard It's crazy, you know, it's like well, okay The standard says you do this but really what you do is this because there's this time where they forgot part of the Standard and like so what you do is you get the thing and you validate it and if that doesn't work You try this other thing and it's insane. It's seriously insane, right? But so the original sort of vision for these distinguished names was that each Distinguished name would fit into this global information directory, right? So, you know, for instance if I were going to get a certificate with a distinguished name in it You know, it's a country United States state Pennsylvania local Pittsburgh Organization Institute for disruptive studies organizational unit research and development common name Moxie Marlin spike In practice when people are filling these things out they get to locale and say what the fuck is locale and then just type Whatever they want in there and you know the whole thing falls apart, right? My favorite quote is from this one guy who was trying to implement x599 And he says there's nothing in any of these standards that would prevent me from including a one gigabit Impeg movie of me playing with my cat as one of the Ardian components of the distinguished name in my certificate and the thing is that he's right it's crazy, right, so, you know Whatever in practice Not none of this stuff really materialized and at the end of the day, especially when we're talking about certificates that are used with SSL basically all all implementations just ignore everything in the distinguished name except for the common name and The convention is that in the common name field you put your domain Whatever domain the certificate is valid for so this is where a bank of America calm would go in this common name of the certificate of the Distinguished name of the certificate So how is the common name represented in a certificate? It's this, you know x599 is Specified by it's an asn.one formatted deal So a common name is basically, you know the sequence that identifies it as the common name and then a string type There are many different string types that are supported But you can imagine one of the most common is just like an ASCII string, right? So an IA 5 string and an IA 5 string looks like there's there's a one byte Value that identifies it as an I5 string 0x16 And then there's a one byte length field That specifies the length of the string to follow and then there's the actual value of the string one byte per character Then you know ASCII byte per character So essentially The common name field is a Pascal string People remember Pascal strings the way it worked was there was a preceding length Field for every string that's x number of bytes and it would specify the length of the string to follow, right? This is different from how C strings are represented in C you know Your pointer to the string is just the pointer to the first character in the string You have no idea how long the string is and then you have to walk through the string until you encounter a null character And the null character Indicates that you've gotten to the end of the string So really the you know, I guess one important thing to notice is that in Pascal strings a null character has no special meaning It's just another character in your character string, and it's not imbued with any special meaning, right? Anyway, so we'd like to get some Certificate with a subject that has a common name of www.paypal.com right the problem is that we don't own paypal.com so we can't do that but I Do own thought crime org So, you know, I could put thought crime org in the common name field of a certificate And you know, it would look up the who has information for me And you know everything would be fine and again, I can put whatever I want I can get www.thoughtcrime.org I can get verisci needs children thought crime.org Even things that are just totally nonsensical It doesn't have to exist, you know, they don't care. They don't give a shit about it. They totally ignore it I can put whatever I want in there even www.paypal.com Null character.thoughtcrime.org So if I submit my certificate signer request for www.paypal.com null character.thoughtcrime.org They will dutifully look up thoughtcrime.org in the who was database pull out my contact information and contact me So then, you know, okay, now we're doing our man in the middle attack. We intercept the client. Hello, we send back server Hello, yes, I am the server whatever and my certificate is www.paypal.com null character.thoughtcrime.org First thing the client's going to do is check the subject Right, so they look in the URL bar. We typed in paypal.com They want to compare it to the subject in the certificate that code might look like this You know char star destination equals get domain we're connecting to Char star common name is get common name from certificate and if everything is okay stir comp destination and common name will be the same and Stir comp is gonna do this right it's you have the pointer to both of these values and it's going to check the first Character in both strings and make sure they're the same And if they are that's going to continue with the next character and it's going to keep going until an encounters a null character Which indicates that this is the end of the string and so it's going to return success What this means is that in the eyes of most SSL implementations this certificate is completely valid for www.paypal.com So what are most SSL implementations right so if you look at the implementations themselves? NSS is vulnerable the Microsoft crypto API is vulnerable GNU TLS is vulnerable and what that means is that all of the products that use those things are vulnerable so every Product that uses the Microsoft crypto API is vulnerable to this attack one valid one validating X5 and answer to be gets You know the popular thing are web browsers. So Firefox is vulnerable because it uses NSS Internet Explorer is vulnerable because of course it uses the MS crypto API Chrome is vulnerable also for the same reason and then you know links is vulnerable curl is vulnerable Mail clients Thunderbird is vulnerable outlook is vulnerable evolution is vulnerable Pigeon AIM ir ssi center IQ IQ even SSL VPNs are vulnerable AEP Citrix a bunch of stuff I couldn't even test them all Basically almost everything Okay, so now we've updated SSL sniff and we have a first cut of this and we perform a man-in-the-middle attack And if we have a null prefix certificate for the the site the client is going to connect to we send that back and complete The man-in-the-middle attack. Otherwise, we just let everything go through right? So how does that look right compared to what we're talking about earlier? So this is Gmail's login page secure site. This is the secure version This is the attack version I'll show that to you again secure version attack version Essentially there is no visible difference Even if the user were to inspect the certificate You know it tells you that it's www.google.com still because again it has to display the C string and when it displays it it null terminates it right even if you were to Look at the view certificate thing and actually look at the values of the certificate again. Everything looks it's Indistinguishable there's nothing that a user can do to know that they have been attacked So what are some disadvantages to this attack right to me the biggest disadvantage is that I think targeted attacks are lame I Think phishing is too much work I don't want to have to get the certificate for this one site or whatever and then try and get everyone to go to that thing Or whatever really what you want to do is Men in the middle an entire network and get everything that everyone is doing You don't have to anticipate, you know, I think they're gonna visit these sites or whatever, you know Sometimes you don't even know right you don't even know what's gonna happen You want to just get everything and sometimes things are valuable that you didn't even know about So okay, maybe there's another trick in here somewhere that we can use to accomplish our goal So the first thing we might try is actually looking at the source of and you know any SSL implementation that does this matching Right, so we can start with NSS, which is the thing that Firefox and all the Mozilla products use right so you can start and look at the source Don't look at it too carefully. Just let your eyes go out of focus Without actually looking at any individual line just look at the shape of it It's terrible right all these nested conditions the like how it arcs out like that. It's too long This thing goes on for like four pages or whatever Just looking at the shape of this code, you know There's a bug in here somewhere. So then your eyes start to clear and you look at the very first line Register int x y Register this must be like 14 year old code, you know, nobody uses register shadowing anymore the compilers just ignore it Right, so that's you know another signal that maybe something is a miss And then you look a little bit further and you get to the wild card matching And you look at that and you're like wow, this is probably the least efficient way that you can do this and Then you realize wow You can get a certificate for Star null character dot thought crime dot org This will match any domain This is actually better than having a ca cert because if you have a ca cert You have to you actually have to like create another certificate and sign it to like present it to someone You can just if you have this thing you can just hand them the same thing over and over again and matches for everything There's although there's also like other really weird stuff in there Like if you don't want to use a null character, you could get star tilde dot thought crime dot org that would also work It supports grouping which is weird So like because wild card certificates are a little extra or they cost more money So if you don't want to shell out for a wild card certificate, you can just get like PayPal dot com or mail dot google dot com or e-train dot com or or bank of america dot com Null character dot thought crime dot org And then you only have to pay for one certificate this way and Of course, here's your mode exploit in here if you look at how it supports the grouping It allocates based on the length of the string, which is you know going to be Calculated based on whatever null character might be in there And then it then loops through the string again looking for clothes per end just ignoring Wherever the null character might be And then it just copies until it hits the null character So if you have a you know a string like this You allocate a buffer that's this big and then you copy this much data And this is actually it's the stars actually aligned to make this exploitable like there are so many things that have should have stopped This from being exploitable, you know the first thing you're like, okay Well, there's no way I can get shellcode past the unicode filters or whatever and then you look at the unicode filters You're like no actually I can't get the shellcode past the unicode And then you know then it's like oh, but they stir-doop on it So that would like terminate the null character thing and you're like no But if you put a tilde in there it just replaces that with a null character, you know So anyway the stars really aligned to make this exploitable which is kind of insane Oh, the other nice things about this is that no signature is required You don't have to get a CA to sign your shellcode because Again when I was talking before about how what you know SSL implementations used to just stop at the first thing that they found That was wrong and pop up a dialog box. I was like this expired 10 minutes ago Whatever so they went to fix that and so now whenever they find anything that's wrong They continue validating and check everything so that they can pop up a dialogue that's like x y and z is wrong You know and so, you know if even if the signature is bad on the certificate that you hand to the browser It's like, okay, the signature is bad But I better check the common name to make sure that I know whether to display an error or not and of course then you You know exploit the the client Anyway, so now we have a second cut of SSL sniff and we perform our man in the middle attack And if there's a null prefix certificate available for whatever the client is trying to connect to we use that Otherwise if the client is NSS then we pass them the universal one card certificate and it just works for everything So now basically we're in a situation where SSL sniff has to fingerprint the network to know what clients are what so that it Knows what to attack in which way so it fingerprints the network and every NSS clients Communication is intercepted and then for the non NSS clients all the certs that you have are used And whatever non-verbal clients exist are left alone so that you don't get detected So what do we have to worry about as attackers right the two things that come to mind for me our certificate revocation and Updates right so the first thing is that it would be unfortunate if some bitter certificate authority audited their System discovered that a bunch of certificates had been issued with null characters in them and then went to revoke those certificates And then updates is that you know, it would be unfortunate if You know some bitter SSL implementation actually fixed their thing and then our tricks stopped working So let's start with certificate revocation These days. It's all about this thing called online certificate status protocol Right and the deal is that whenever an SSL stack sees a new certificate like something that it hasn't seen since it's been running in this session It makes a quick request to the OCSP URL that's embedded in the certificate to check with the signing CA right So basically what happens is every time an SSL stack sees a certificate It makes a quick lightweight request to the certificate authority that says hey is this thing still valid? Have you revoked this yet, right? And the the stack gets assigned response back from the OCSP provider So as attackers this is really deadly for us because if a certificate gets revoked It's it's gone instantly right that the old world of the certificate revocation lists where there was like, you know One per certificate authority and that each one is like 700 megabytes long because it's just a list of every certificate That's ever been revoked ever You know that wasn't working so they went to this model and it's it's a deadly model for attackers who are forging certificates, right? So, you know here's again as Google's certificate And you can see that there's this OCSP URL embedded in the certificate and every time a browser sees this It'll make a quick request out to OCSP thought comm and and see what's up so Let's look at OCSP. How does this thing work right? The basic OCSP response that comes back from the certificate authority looks like this It's basically a one-byte response status and then some response bytes the actual data that Tells you what's going on with the status, right and the response bytes look like this There's you know basically some data that says like this is the deal is what's going on and there's a signature in there and You know as an attacker this could be a problem It might be difficult to forge the certificate which are towards the signature which is you know kind of a drag But if you look at the signature the interesting thing about it is that it only covers some of the response data Notably what it doesn't cover is all this other stuff including the response status and The response bytes themselves are actually optional depending on the status, right? So if we look at you know what the status options are the the status structure looks like this, right? So you can either send, you know one of these things and so ideally we'd like to send if we were like Spoofing the OCSP provider what we'd like to do is send back successful But we can't or it might be difficult to send back successful because if we did we would have to include the optional response Bites and that has a signature in it that might be difficult for us to forge So we can't send back successful, right? But so maybe we could send back something else So if you start to look through these things All right, what else do we got? malformed request And that doesn't sound that good Oh, we could you know we could send internal error That also doesn't sound good because it has the word error in it, you know And then you get try later. Well, that doesn't sound bad at all You know, it's not really implying that there's a problem, you know, definitely not a problem with our certificate It's just saying try back later It's even sort of suggesting that it might be successful at a later date You know try back later and it could work, but So the interesting thing about try later is that you don't have to include the optional response bytes when you send try later So all you have to send back is the response itself Which is a single byte value. That's literally three And actually the ASCII character three so all you have to send back is zero x 3 3 And it turns out that when you send that back for every SSL implementation that I've tried They all agree that it also doesn't sound too bad So what this essentially means is this entire standard this whole OCSP thing can be defeated by the number three So now okay, the third cut we have an OCSP or SSL So if we do everything that we do before and now if we see an OCSP request for any of the URLs that are embedded in the forged certificates that we're using we man in the middle of that and send back three and Yeah, so even if the certificates get revoked No one will ever know Okay, the other thing we got to worry about is updates You know just by talking to you today people are probably going to try and fix this so it used to be that people like downloaded software right and of course it's a rapidly changing world there's you know more and more bugs there's more and more at stake and You want to try and get the the patches into people's hands faster and faster So a lot of people have felt the need to deploy this self-updating software So this is bad news for us right because that means that things get patched quicker There's a lower window for attacking software, but it also seems like their update mechanisms Might be kind of a dangerous idea right you have software out there That's just like connecting somewhere and downloading other stuff and just running it right so maybe there's something we can do about our problem So Let's look at the Mozilla system when you install Firefox or Thunderbird or any of the Mozilla products it comes with this feature called automatic update service and That's enabled by default The way this works is you make an SSL connection or that you know Periodically, I think once a day the browser makes an SSL connection to the update server and it says hello I am you know whatever Firefox version whatever Here's my build ID for my operating system Linux one does whatever my locale and us whatever channel stable nightly Do you have any updates for me and the update server response as a matter of fact I do Here's a totally unsigned blob of data that I would recommend that you just run The deal is that they depend on their SSL connection for all the security of the system, right? The idea is that since all of this is transmitted over SSL. No one could ever possibly You know intercept these requests So, you know, we just send this data back through there and everything should be fine And by default all the minor updates are downloaded and installed silently And they only prompt these are every once everything is done once everything has been downloaded and installed It says hey, we updated your system to restart now You know and the interesting thing is that the update server is the thing that reports the version number of the update So the update server is essentially what determines whether software gets installed silently or not So the problem is the going to be that as vendors start to release patches for this vulnerability The update mechanisms themselves are vulnerable, right? Because all we need is our universal wildcard cert or a null prefix cert for AOS 2.mozilla.org And we can take control of the update mechanism to deliver whatever payloads we want So this could be anything it could be a rootkit that logs keystrokes It could be something that sends all the traffic to you It could be a completely legitimate image that just happens to include our own CA certs for future use Or just to be confusing it could be a totally different app, you know You could like get the update and it's like thank you for updating to Galleon 0.0.3 You know or just like you update and then notepad opens, right? You know, I don't know the other cool things that this this works not just for the Mozilla binaries but for the extensions too So they all the all the add-ons auto update where they connect to add-on stop mozilla.org over SSL And they say hey, do you have anything new for me? And it says yes, here you go run this thing So even if you don't want to mess with like rootkitting the binary You can just rootkit whatever add-on you want which is actually just as good because you can do anything from an add-on I Taught I did a training at black hat called intercepting secure communication and at the end we did an exercise We had like a little malware competition for this vulnerability And the people that one had an add-on that Basically anytime that you posted data to a form it also posted a copy to them So it's like the man in the middle attack that keeps on giving or whatever So anything you know the problem is that in order to patch your system for this effectively You're not going to be able to trust anything that comes through automatic updates or actually at this point anything that has ever come through automatic updates So now SSL sniff I have a the fourth cut is an updated aware SSL sniff so it does everything before does all the fingerprinting OCSP denial all this stuff and now it also watches for update requests and If it sees one you can specify on the command line You know, you know update these platforms with this binary and you know if you see an add-on Update it with this thing or whatever and so it'll just hijack the updates and install code on your computer Okay, as a quick post-grip to all of this stuff Stripping null characters from certificates is not a solution. So there's like a couple of Stacks that aren't vulnerable to the thing that I've been talking about so far like a safari and opera aren't vulnerable to that But they appear to just strip the null character from the common name before they compare it Right, so if you get PayPal comm null character that thought crime dot org they strip it and then compare it So it becomes PayPal comm dot thought crime dot org and So that stops this attack, but it actually opens up an attack vector for a different attack So the weird thing is that like some certificate authorities are vulnerable to this internally, right? So if you submit a CSR for PayPal comm null character dot thought crime dot org the Certificate authority itself trips over the null character and tries to validate the cert against PayPal comm So it thinks that your PayPal comm But the interesting thing is that when you actually get the cert back It gives you the entire thing that was originally in the subject, right? so, you know the problem is that You know, we're not PayPal so we can't you know We would not be able to get a cert that way, but you can do other things, right? So you could register a domain like site key dot BA and Then you get a certificate for site key dot BA null character Inc of America comm And so when the CA is are like internally vulnerable they'll They'll like do the authentication thing against site key dot BA which you own, right? But then what you actually get back is site key dot BA null character Inc of America comm Right and so then when you actually present this to an SSL stack that strips the null character It becomes site key to bank of America comm and that would validate correctly against make America. So basically Every SSL implementation I think is vulnerable to some variation of this So in conclusion, we have a man-in-the-middle attack that will intercept communication for I think almost all SSL and TLS implementations in the case of an SS. We only need a single certificate and we get all the traffic We defeated OCSP is implemented. We can hijack the auto updates for applications and extensions We've got an exploitable overflow. So in short, we've got your passwords your communication and control of the software that runs on your computer so SSL strip the thing that I was talking about in the beginning is available on my website. It's been available for a while SSL sniff the old version is available on my website and the new version that supports all of these new attacks will be available on my website sometime between today and Monday So you can download all that stuff there at thoughtcrown.org Thanks