 anybody for abusing bleeding edge web standards for app site glory we got Bryant Zadigan and Ryan Lester please give him a big hand. Alright so everyone please take a moment and visit our website. I know it looks scary but trust me it's a part of the hands-on component of our session. So actually hold on for a second Ryan why did you go with this site? The internet was all out of domains I swear this was the last one they had. So um in the something that we noticed in the course of setting this up um if you're using an android phone actually if you're using any phone at all congratulations and on your bravery uh we applaud you um but if you're using an android phone uh with the configuration on this domain for whatever reason um you might get an assert error so all other phones seem not to have a problem with it so there you go. In case you decide not to take the risk this is what you'll see. So moving on. That was much better reception than black hat they didn't get the joke at all. Um anyway so welcome to abusing bleeding edge web standards for app site glory uh my name is Bryant uh and and that's Ryan and we're not used to right we're not used to these mics we're still adjusting from lapel mics. If you didn't hear I'm Ryan. So just some background on me uh I do a lot of app sec related stuff uh I mentor security startups sometimes uh I also mentor others mentor and air quotes others on application security on occasion. Once upon a time I paid a friend a dollar to make Steve Ballmer dance on stage but just once. And I'm uh the CEO of an end to end encrypted communication startup called Scythe uh which is actually the origin of a lot of the research that went into this talk. I'm also more or less the chief architect and primary developer of Scythe uh before Scythe I was a software engineer at a rocket factory called SpaceX and at one point I was sued by Napster for alleged trademark infringement. Are you allowed to talk about that? Uh not in detail no. Okay um okay we'll just leave it at that then. Fair enough. So in talking about bleeding edge web standards I wanna kinda clarify some of like one of the key words here. You'll notice the first word in the title of the talk is abusing. Most people hear the word abusing and they assume hacking in a very like breakery way. But we're speaking not just in terms of hacking and like classical hacking that you and I might be used to but also hacking from like a developer standpoint. So coming up with novel solutions to problems that you know are completely unanticipated and what have you. So very much like developer hacking, dev hacking um as well as classical hacking that many breakers in this room might be used to. So we're going to focus on three web standards that you guys hopefully know about but I'll do like a show of hands as we're going along uh just to see how we are. Um let's see. So first of all we've got sub resource integrity. So a quick show of hands as to who in the room who's familiar with browser side standards might know what SRI is. Not bad. Uh so we're gonna talk about specifically something that we're calling SRI fallback. Uh you can probably anticipate what that means. Uh we'll go through it as we're walking through it. So we're also gonna touch on content security policy. Uh show of hands. Ah nice. Okay that's good. So we're gonna talk about something that we're calling CSP meta hardening here. So we're not really gonna teach anybody what content security policy is. Uh but we will talk about how you can use it in some edge cases that a number of startups might be encountering things like that. And this last one is probably going to be about a half of the talk. Um so we're focusing on HTTP public key pinning. Show of hands. Awesome. Now the thing that we're gonna focus on here is something that we're calling HPKP suicide. So why? Now here's the thing. Uh new standards of being drafted left and right. And if anybody's been keeping track of the creation of of web standards like browser side standards things like that. You'll notice that the pace has kind of seen a bit of an uptick. Uh there are quite a few standards that most people don't actually know about. Uh has anybody heard of CAA? There's like three hands. In the whole room. For a live standard in production that's currently being widely used. Okay. So now that we've established that. Um it's not just the standards that are being created at a rapid pace that are creating unforeseen complications. Uh it's also that the implementations which are you know happening rapidly. Uh these implementations because of the pace at which they're being developed can be a bit screwy. So when you start messing around with standards and especially obscure specs in said standards obscure use cases. Uh you can probably find extremely novel ways of using these standards or extremely novel ways of breaking them. I mean in the course of this talk Ryan and I found we we hit what two bounties on on chrome just completely by accident. We didn't create a fuzzer or anything. We just scored a quick twenty five hundred bucks just in the course of making this talk. So kind of diving into SRI. Now we're actually going to get into the meat of it. Um a lot of this stuff should actually be pretty easy to use. It's once we get to HPKP that things become a bit risky for everybody. So. Sure. Uh yeah so SRI sub resource integrity. It's one of the standards Brian was just discussing. Uh it's just a way for you to assure the integrity of resources hosted outside of your zone of trust. Uh in the example here we've got jQuery gloated from their CDN. Uh we would also be using a fallback source if uh the spec actually provided something like that. So they they mention the possibility and kind of give general guidance on how you might implement it yourself but they don't give you direct way that you can just use it out of the box. So we decided to implement it for you. We have a script called fallback SRC. Uh that's what we call it right. Um anyway fallback uh source script. You just add this X SRI fallback attribute to any of your scripts or style sheets. And in the event that the primary source fails to validate the uh the new one will be injected and validated against the same hashes. So we've got a. Sorry? I think we're actually skipping this demo. Are we? Oh yeah yeah we're skipping this one for the sake of time but it's there if you want to see it. And that's the source code. So we'll also have at the very end on the very last slide we're going to have one link that aggregates all the links that we're going to put on screen today. So if you don't want to have to worry about catching the pictures in time don't worry about it wait until the last slide take a picture of that and you'll get everything. So but while we're here we will just very quickly show about the quick two grand that we knocked off of chrome uh when we were in the midst of creating the talk. And uh so yeah I mean I mentioned very early on that you can actually in the course of testing novel web standards that were just introduced uh or like very recently introduced or what have you maybe there wasn't enough time for testing whichever. Uh you can in the course of testing them out uh very quickly score some quick and easy cash and the one we're going to talk about here is a case where if somebody um manages to hack around with SRI in a same origin use case um in an older version of chrome you actually could have gotten a script to run the second time around and I'll let Brian kind of take on the prescripted demo. Sure uh so like Brian said we found this by accident this was supposed to be the demo that we were going to use uh for an early version of this talk uh just demoing SRI. By by the way um for people that think we can't read it we're actually going to zoom in on the key parts as we go through. Right. Uh so we've got uh just two buttons here one that injects a script with a valid hash one that does invalid. Clicking the invalid hash uh you can see there's an SRI error there as expected so loading the script failed. Then you click the button a second time and it works when it shouldn't. So let's see that one if you wanted a quick use case for how you could have exploited that flaw well if you happen to actually compromise a site especially one that has like infinite page loads and it would be constantly reloading the same script or maybe like the same XSS payload that would be one potential area where you could exploit that. So Google ended up marking that one as a high and giving a quick two thousand dollar payout. So now that one having been discussed we've talked about SRI we've kind of showed off the script and how you can implement a fallback in the event that you want to have some way of loading backup content in the event that your main tr- your main resource that you're loading off site can't load. Now that we've talked about that let's move on to CSP and how you can combine some interesting properties in CSP to do novel things. So we've got something that we're calling CSP meta hardening. Um what this is is you're combining a semi-strict header. What this means is that it's a header that's it doesn't have all the rules you want defined but it has like it has a lot of leeway for you to do things that might otherwise be considered dangerous. And what this allows you to do is it allows you to load trusted complex logic. Uh that being said this trick that we're gonna show because it relies on meta headers there are some verbs that don't work uh frame ancestors report URI or sandbox they they won't work in meta headers. There are others as well um but we'll get into them in a bit. We do I believe uh have yeah we do have a demo for this also prescripted but again if you visit the URLs you can see these demos in practice and see how they actually work just right click dev tools um and actually watch uh watch how it works in the console watch what elements are introduced things like that. So and I'll let Ryan take this one on. Uh so it's the same general format as the UI of the previous demo we've got three buttons here and it shows the current content security policy. So running inline code should work because we have unsafe inline and you can see it did. Non inline code or code from the current origin that also works. And then we have a third button to harden CSP via meta element. So when you click that it actually injects into the DOM uh an HTTP equivalent meta header with uh more restricted CSP. So you can see now unsafe inline is no longer in the CSP. And now running uh inline code will generate a CSP error. And we'll get into some considerations as well but we're gonna talk about the we'll get into some considerations as you're setting this up for your own sites um and we'll also talk about potential use cases. But first of all if you want to use this um if you want to actually use this for your own sites let's say you've got let's say you've put in a lot of development effort into like an MVP you're like typical Silicon Valley shop you've put in a lot of development effort and security maybe wasn't at the front of your mind um and you want to implement this well let's say you're doing your typical like single page app um these are some considerations to make this work perfectly otherwise there are some attacks that could work against this that would defeat your entire use of CSP in the first place. Uh so when we say static content only that means that if the initial response if everybody in this room I hope is familiar with reflected XSS if your initial response from the web server actually contains reflected content from the user in the initial request then you're going to have that content execute during your relaxed content security policies which defeats the point um there is another potential attack we can go through after the talk just for the sake of time um we'll say blindly trust us when we say include this header uh in your in your headers that you're sending to the browser uh the XSS protection uh blocking mode you definitely want this because there are some novel attacks that would work if you don't include this but implement meta hardening in the first place. So in terms of use cases so I mentioned that if you have a semi like let's say a semi recent application you put a lot of time into implementing this and you haven't really taken security into account. Well if you think about your typical really complex single page applications I mean anything I think what the like Google apps I'm just winging at this point based on the UIs but any application that does a lot of pre loading of content like angular based apps things of this sort um this is where this can work really well for you but that being said it should be used as a stop gap towards getting full CSP on your site uh reason being so long as you have relaxed CSP headers you run the risk of anybody being able to get content that you haven't authorized to execute before you harden your headers with the meta tags. So this is the idea your application static content loads first and in loading first while you have the relaxed headers it's all the content that you trust your application does it does all of its pre loading into the DOM and it gets set. Um once it's done being set up at that point you then inject the meta headers into the DOM and then the browser takes up those rules hardens your content security policy and then you can start taking dynamic content from be it other web servers or what have you. Uh you can only do this one way you can't relax headers you cannot relax policies this way you can only strengthen them so you cannot introduce meta headers that then relax content security policy down the road. So now we get to like the meat of the talk this is actually where all the cool stuff happens so anybody that's looking for really breakery stuff we've got a good chunk of stuff at the end that might excite some of you. So let's talk about HPKP. So for those of you that might not be familiar with HPKP uh we have it color coded in red because if you do it wrong you will break your site and you will break your site for up to 60 days uh for for users that are using your site assuming you actually set it up incorrectly uh so we have a sample header set here like a sample uh pin set here for you uh where if you were to implement HPKP uh it would be in report only it wouldn't it wouldn't break anything if if you end up doing it wrong and and it'll have the max age configured perfectly you just need to replace the the keys for your hashes uh well the the hashes for your keys uh with the actual hashes for the keys that you're serving up. My recommendation is if you implement this you want to serve up all the hashes for all the keys you're using across all domains and subdomains that's what the include subdomains uh keyword is there for as well. This is probably the safest way to get started and then once you've had it in place for a while then you can drop off the report only uh and and it's essentially like hard mode so if something goes wrong at that point then that's when people get locked out. So when we talk about HPKP suicide well what do we mean? So here's the thing in a nutshell you're deliberately self-bricking your users. That's what we're talking about here. In the spec itself nobody's ever actually considered the possibility of deliberately breaking your users to enable new functionality and that's what we're going to talk about over the next what 20ish minutes. So we've got some ideas uh there's the possibility of enabling in browser code signing but we'll explain why we scratch this out in a moment. We'll also follow that up with a solution that works almost as well uh by controlling content changes and also hardening SRI. We'll also talk about nuanced web content blocking so if you're familiar with your typical web content gateways like your nanny filters things like that that'd be in like high schools or or corporations that like you know making sure that you don't have malware end up on your clients there are ways that HPKP can be used to further that work and the black hat audience was very very receptive of this it was really interesting I'm pretty sure half of this room will probably hate that. You can also use this to track users this can probably scare you and we'll also talk about how you can use this to be total jerks in ways that we shouldn't really put in print. And before we continue I wanted to give a shout out to Jan Horne at cure 53 uh he was actually the one who put us onto this idea during the course of an audit of Scythe uh last year and did she start as well actually before let's encrypt existed to make this idea easier to implement uh worked with us on making it possible in in Scythe. Uh so here we've got an HPKP suicide based local content pinning scheme uh which intentionally self-bricks your own website to pin an app cache or service worker uh persistently in the browser with the same level of security guarantee that HPKP provides. Uh so first the user is just visiting your website like normal and it's setting an app cache or a service worker then on the back end the server is actually deleting its own TLS private key generating an entirely new key pair and uh requesting a new certificate from the from its CA and then of course changing the HPKP headers to compensate for that. And then the next time the user hits that site uh the TLS handshake will fail and it will be to the browser as though the site the server is literally offline push uh forcing it to fall back on the the cache service worker. So let me put that in human terms. If because this is perfectly understandable for anybody that's familiar with sequence with actual sequence diagrams right? But the basic idea here is this. You're using HPKP suicide to deny your end users access back to the web server after they've already cached some sort of document from that server. And in denying access back to the web server on future visits it's the document that you cached that's then loaded because every subsequent connection back to the web server has to kind of go through that service worker first because that's it's it's been stored in the browser right? So it goes through that service worker first which can then handle the error in the event that the connection fails. But in this case the service worker is deliberately anticipating the connection to fail because the keys will mismatch and therefore that's where you can embed the extra logic for how to for how your application actually wants to run such as loading resources from other sub domains that haven't been pinned within the actual service worker itself. That's the key here and that's how this that's essentially how this entire scheme works and it's enabled by the fact that you're rotating the keys on a very rapid cadence that way you're actually deliberately locking people out as time goes on. So we've actually got a really novel use case here and Ryan's going to talk about it. Yeah so we in the slide earlier you saw we had code signing as a possible application of this crossed out. So I mean why not? In theory you could use this local content pinning scheme to pin your code signing logic. Did it just skip the whole slide? Yeah you skipped the last slide. Go for it. Alright sorry. So yeah in theory that should work more or less getting you trust on first use and so why in theory it sounds like it should work. In fact SIFE employs a mature audited implementation of exactly this that we call WebSign. However it was considered novel enough that we were advised to apply for a patent on it. Purely defensively but no one else can do it now. But you can come pretty close to the benefits of code signing by following the scheme Brian is about to describe. Right so you'll probably get to about 85 ish percent effectiveness of what like the code signing scheme that Ryan just talked about. If you combine HPKP with sub resource integrity and the basic thinking here is this. In that service worker that you've got that you pin in the browser every reference to every other resource on other domains is going to have your integrity checks through SRI right. Now in order to make this work since you're locking users away from accessing the content what you need to do is you need to have the max age the actual counter that says how long this header is valid for dynamically count down to whenever you routinely deploy a new application into production. So let's say you deploy a new app like a new version into prod let's say Sunday at four twenty p.m. right. In that case what you're going to have is you have the actual max age counting down to that date. And every time a person visits the max age is going to be different for all of them but that being said it doesn't make a difference when they're mad when their HPKP headers expire they pull down any new content any new hashes for scripts that are off site things of that sort. And as a result because the other scripts are being checked against the hashes that you've stored you're still I mean it's not really the same as code signing but it gets you pretty close and the reasoning here is that they no attacker can replace the initial content the initial service worker that you've pinned in the browser. They can't replace that because when the browser then tries to connect again to the site it's the connection is going to bomb out. Now of course the only way this will work is if you're rotating the keys let's say once every what is the cadence on let's encrypt like twenty times a week that's like once every eight ish hours maybe. 8.4 hours something like that. So you're re keying once every 8.4 ish hours and that means if a user visits within the first eight like visits and then visits again like nine hours later that connection bombs out that content that they that was pinned the service worker can then never be updated until those headers expire. Now what are you looking at in terms of benefits you're retaining control of front end content between releases right so that means that in the event that let's say your your main web server gets your content servers get compromised be it the ones that have the SRI protected content or the ones serving that initial page the service worker it doesn't matter because the people that are visiting your site will have already pinned the content locally and this also means that you're mitigating the risk of somebody like you know tampering hashes as a part of a much broader attack against your content that that might rely on resources that might have also been compromised in domains that you don't control. So you get some pretty decent security and performance gains but there's a catch. HPKP suicide and SRI it's a bit of a design time decision this isn't as far as we can tell going to work with anything other than a single page app single page app of course like I mentioned earlier being the kind of app that loads everything up front and then dynamically loads everything through web service calls. Here's the thing you also need to include mitigations like halting the distribution of HPKP headers if your site's compromised. Well why because if your site gets popped then now you're serving and pinning malicious content into your into your users browsers so you need to be careful about making sure that your content if you see evidence of tampering isn't actually going to serve back the HPKP headers that pin that content in your browser in your users browsers. So time permitting will actually go ahead and check out a demo on a site what Redskins.io we're both from DC that's kind of the kind of the gag there. Yeah it's not completely random there is actually some some sort of an inside joke there. Now we'll take this one a bit further. Let's say that you've got a web content gateway like blue coat right I love picking on blue coat because I've only ever had to deal with them. So here's what they can do they can actually look any web content gateway that implements HPKP because they're already intercepting connections like they've okay they've got SSL man in the middle like TLS man in the middle they're already seeing all your traffic your your your banking transactions your mail whatever right as part of the design. They can actually lock users out of malicious sites or flagged sites or porn sites or whatever even when they're not even when your users are not on the network like let's say they're using a corporate laptop they try visiting I don't know what's a good x hamster.com short and the and blue coat says oh wait a second this is obviously a porn site we're going to keep you from visiting this well here's the thing for that flag domain it sets the HPKP header for the blue coat cert right think about this for a second it's the blue coat cert it's not going to be available on the public internet but that cert was just pinned for that site so now you take your corporate laptop off of the corporate network and you still can't visit the site now if you're a technical user you can of course blow those pins away but you know I don't think your average accountant really knows how to do that so now optionally if for whatever reason you can't afford blue coat like multiple instances for your own network okay you can rotate the keys weekly at the gateway as well but I figure if you are considering using blue coat you can afford the licensing fees for them so hopefully by us disclosing it this makes it prior art which means that nobody can actually patent this and make filthy money off of it so wait a second so apparently blue coat is now an intermediate certificate authority so we don't actually know how relevant this is to any part of our talk it might not be because a cert path is actually zero but you know do with that knowledge what you will we're kind of hoping somebody can go break around and see what they can do so oh this one's fun this one's fun okay user tracking so we shouldn't really talk about this but you know since this is def con let's track users so here's what we need this is by the way a very buildery talk but because it's kind of sort of tiptoeing on like the edges of ethics we'll call it breakery as well so you need to pin a lot of subdomains we're talking like 32 subdomains that number probably sounds it makes sense if you think about it you also need browsers that pin well that hand that respect HPKP incognito and finally you need that ability to do rapid key rotation to rekey on a routine cadence because you need to be able to lock users out right so actually I gotta go back for a second so we actually need to thank let's encrypt for this and again we love I there might actually be some let's encrypt guys in the room so come on clap let's encrypt is in true has introduced a lot of not like just by automating everything they've allowed us to do a lot of novel things we might have some amount of issue with some of the things we've been able to achieve but at the same time we understand and love the vision for spreading TLS all over the open web so in this case let's encrypt really helped out just by virtue of the fact that you can rekey on a very rapid basis and because it's free and because it's automated and very very easy so I'll let Ryan kind of talk about some of the configuration stuff it's not really going to make all that much sense until you see Ryan's demo right so this will be this explanation will be a little hand wavy and that's by design it'll make a lot of sense when you see the demo so on your server you've got an HPKP server with all of your sub domains start up whatever domain pointing at the same server you've got a set method that returns an HPKP header and the check method that does nothing it's a nil op and you're just routinely rotating your keys on that server then on your job script to set a new ID you're just hitting those sub domains in a random pattern hitting set on them and to check the ID you're iterating through all of them and hitting the check method on all of them so in principle it's pretty similar to the HSTS super cookie that I think Sammy Kamkar came up with okay hopefully don't quote me on that so we've got a demo a super cookie server set up at scythe.wing and went through a quick demo sorry quick demo here in our JS console in Google so Google did not implement this we pasted in our JavaScript into their console so you just run the super cookie JS right there and it'll here you can see it generated a new ID it's just a just a random 32 bit integer four five six five five six six and now we're trying again in an incognito window on a totally different site and in this case you can see a bunch of failed TLS handshakes from those 8 from those HPKP suicides and it reconstructed the exact same ID there four five six five five six six if you look at the sub domains you can see it's just a bunch of numbers that we're using zero through thirty one dot scythe.wing I just as like bits in a 32 bit integer so we're literally iterating through all of them in a for loop so what you just saw was a way to track whether or not a user has hit your site in incognito mode in blatant violation of the fact that incognito or private modes are supposed to give you certain privacy guarantees we've actually I think raised that up as a concern but it's been just deemed as the security benefits of both HSTS and HPKP have been deemed to be a much more significant than the potential privacy loss of doing so I don't actually think either of us have a problem with HSTS in that capacity but HPKP we personally think shouldn't actually be necessarily respected in private modes or incognito modes and in fact there was a time I think in Tor browser so this is our big PSA right there was a time in Tor browser a few versions ago we don't know the exact version but we did confirm it I want to say like two hours before the talk that if you haven't updated Tor browser yet HPKP headers we believe can actually be set in incognito mode and respected in between sessions which means theoretically you could in older versions be tracked across sites assuming sites set this up we don't believe that's the case now we double checked and we believe that if it was actually an issue so again we're not 100 percent certain if it was an issue it's no longer an issue now so if you are using Tor browser please upgrade to the latest version so thank you now you have some risks let's say if you want to implement this you have the risk of somebody else saying well hey this is actually kind of unethical so we're going to try and dust your tracking domains as a public service right we agree this is actually pretty shady like the the actual implementation of a super cookie like this is actually pretty shady so if you really want to implement this you can always whitelist domains that you want to track you know for your own tracking service but if you're going to offer this is like a sold service you can always just you know issue a nonce bat you know a nonce through a back channel to the app that's then serving up the super cookie itself to your users that nonce is then sent back in from your actual clients back into the tracking domains itself and then your domains can say hey wait a second I do expect this nonce let me go ahead and serve up the HPKB headers themselves so there you go some quick mitigations for issues that some people might say hey well wait a second you know I can kind of stop this service from working right now so this pattern is also similar to others that are actually actively discussed in the RFC the only catch here is that in the RFC a lot of the super cookie ideas rely on the report URI construct which as which again isn't supported in Firefox so it's not as effective whereas this one yeah it won't work if you use no script hopefully a lot of people do but it will work against a lot of your average users who don't even know what no script is so we do have the source for it you can of course go and check it out up there or you can grab it again off of the aggregate link alright this is the fun part we got what like 12 13 minutes left so what if you want to be like a total jerk that's like what half the room one person clapped one person I heard it so it really shouldn't talk about this but you know who are we kidding this is Defconn so here's what you need to make what we're about to talk about work and we're not going to give you a novel way to break into a site we're not giving an exploit there's again no exploit here no no unpublished full disclosure thing the last talk we had this whole lecture on responsible disclosure please follow it please but that being said this is a nice attack pattern and that's kind of the fun we're about to have so here's what you need you need a high traffic target I can think of many media organizations that might be covering the elections is a good example you need a way to shell the box and you need a free CA right so and again okay we love let's encrypt again I know there's some people in here we love them give them another round of applause please again just repeat it awesome the absolute worst possible thing you can do with this as Ryan and I have determined is what we're calling it like is taking a site for ransom and we'll explain why in a bit so we decided to call this pattern ransom PKP you know in the culture of arbitrarily naming your attack patterns and vulnerabilities right so what you got to do is you have to determine your target first you have to generate what we're calling a ransom key pair so this is you know just this is the key this is the key pair that you're holding within your control you're not giving away even the public key you're just maintaining this oh people still use PON in hacker lingo today right okay so you have to PON the target web server oh god I just said that all out you have to once you've actually taking control of the web server on the server using cert bot or whatever you want to use your own automated script doesn't really matter generate your generate an actual what we're calling lockout key pair this is a disposable key pair it's by design for it to be disposed and send off the CSR and you get your actual cert back and you mount the cert then there's something else at a question mark are we allowed to use that graphic I think we are and some profit we hope so what's in the box so while owned users is less than n in other words while you have yet to reach a certain number of users that you've predetermined based on the size of the site that you're trying to hit what you're going to try and do is you know what I'm not all that good at explaining I'm just gonna let Ryan do it let's see so yeah I mean in the box while owned users is less than n or just on some static interval like 8.4 hours we mentioned with let's encrypt okay there we go your laptop probably already gotten owned please don't own my laptop so on that interval or after each of those end users you just rekey that you generate a new lockout key you delete the current one generate a new one and throw it in the HPKP header while the ransom key public key hash is still in there is it yeah all right and then each time like I said you blow out the old key port man blow out the old key pair generate a new one this locks out end users however many users hit that site during that interval and that's pretty much it so the idea is that you would go beyond simple defacement of a website and you would actually potentially monetize it did you want to rekey the site now it's already no I already set up a timer so oh so this might actually work hold on so let's actually let's actually see if we're going to be dinged by the demo gods here all right so anyone who went to isis.io at the beginning of our our talk this is what you probably saw or should have seen unless you were on android as Bryant mentioned and now that a rekey has occurred this is what you should see just a TOS key pinning error so let's actually call this out if you actually look we can't zoom into this one but if you actually look the specific error should say pinned key not insert chain assuming that the key is actually rotated on time so essentially what we did here let me clarify how this attack really works you're holding the access of the users of the site hostage that's the idea you're denying access to the many users of the site and you're basically saying look we'll give you the ransom key pair well well yeah actually we will give you literally the ransom key pair if you for instance do whatever we want you to do that's that's essentially the premise here now somebody could that's the worst possible thing we thought of that somebody could do if you gain access to a box then you can do quite a lot of things but let's say all you get access to is just the web server right like okay typical site defacement is probably on your roadmap you're probably going to put I don't know owned by some hackery name uh but why do that when you can also monetize what you just did right so that's essentially what we're concerned about here is now you've got HPKP and not just let's encrypt but other CAs that are going to follow that model down the road that could enable this attack pattern so we have some considerations to think about though like meaning why this isn't a high severity issue so here's the thing let's encrypts rate limit is 20 certs a week we mentioned this earlier uh it's it's kind of an artifact of how they've architected the service originally it was like a five rekey limit but if you reconfigure that cert package that you send for like the actual key uh to get the actual cert you can get it to be 20 for every single given domain uh so given that you can't actually rotate the key like every minute uh you you're still bound to some constraint uh Chrome and Firefox also have HPKP lockout mitigations uh notably both parties have or are in the midst of reducing the max age as I mentioned earlier down from one year to 60 days Chrome originally reduced it because people were bricking themselves left and right implementing HPKP and were bricking access to their users to the site for like a year at a time and of course these guys have no idea how to clear their heaping so they figured you know what two months is probably a lot more palatable and finally you still need to actually compromise the box so ultimately the the conclusion by the teams was pretty much like this uh Chromium they've indicated they won't fix it they'll still keep an eye out but they won't make any other programmatic changes because they've already reduced the max age to 60 days which is fine uh Firefox they've gone ahead and reduced the max age and I think that that's on its way to production right now and let's encrypts as indicated that they won't fix because they believe it's out of scope uh we actually understand this reasoning here the idea here being that spreading TLS is much more important than worrying about what could potentially be an experimental risk so we we totally get it now that being said that puts the onus on all the rest of us for ways to address this just as a reminder to myself how many people have heard of CAA right that hasn't changed okay so what is it uh DNS certification authority authorization uh it's kind of a mouthful it's basically a blacklist whitelist it sounds messed up uh if you have the DN if you have in your DNS record uh the the CAA record then every single CAA that hits your domain in order to you know be able to confirm and make sure that it's authorized to give that domain a cert we'll say oh wait a second it has a it has the CAA record right and it says I will now by default assume I cannot give you a certificate for this domain unless that CAA has been whitelisted within the record so in other words you're basically saying if you have this record for your domain you are permitting certain sites sorry sorry certain CAAs to give you the certificate for your site so if you don't list let's encrypt or you don't list any other free CAA then nobody can use a free CAA or or some other unknown CAA to issue the certificate for your domain now alternatively you could also use HPKP uh we actually had somebody who attended the black hat version of the SOC who said this isn't a complete mitigation but it does buy you time in monitoring uh so if you monitor your headers for changes uh you the only way somebody can attack you if you're already using HPKP is if they inject their own key into your headers and wait until the max age is expired before then dropping your key and beginning the attack so lastly you can also just try not to get popped but that's like the hardest of them all so now what if you're an end user like an accountant that might get might be like a what bystander that gets hit by this uh you can always try visiting uh Chrome net internals uh HSTS um but alternatively you can also clear I believe they fixed this uh this used to be a this was also another vulnerability that we found this is a quick 500 bucks uh you can also clear I believe your cash um and that should also clear your HPKP headers as well uh originally you could clear any aspect of your browsing history including save passwords and because they misplace a curly brace that would also clear your HPKP headers so yeah that's what we mean when we say that a lot of these standards are implemented very quickly and some of the testing isn't always complete and in Firefox if you dip into about config cert pinning enforcement level and you set that to zero you hit the site take the new header and then re-enable you should be fine so I think Ryan you've got the source on yeah yeah and also we just wanted to be clear for any law enforcement agencies in the room uh we did not uh implement or open source actual ransomware this is just the the basic POC that implements the re-keying and the whole lockout process it's like a DOS right so yeah you definitely need to put in a lot of extra effort to make this work the all that's here is just the technical details for how to re-key on a rapid cadence uh we have a lot of hat tips um I'll go ahead and just read all the names out um crap I should probably have remembered how to pronounce some of these names uh Geller Badoia Digicert um twitter handle EL underscore D33 uh John Callahan, Jan Horn and all of cure 53 uh Sammy Kamkar, Jim Manico, Mike McBride, Jim Reni and his superb legal skill uh Garrett Robinson, John Willander, Doug Wilson as well as the Chrome, Firefox and Let's Encrypt security teams for all their contributions to this talk this talk was something like five six months in the making and for those of you that didn't take pictures there you go that's the slide uh take pictures uh go and check out the demos uh you can also check out a lot of the stuff um I have my technical background here as I advise Ryan and his company Scythe on implementing a lot of the app sex stuff that they have there so if you want to see some of the stuff in action you can always just check out Scythe.com or Scythe.i am and see some of the stuff in production so um we actually have for those of you not fleeing the room if anybody has questions since we're the last talk of the day I will gladly come and throw bags of popcorn at your face. And questions can be asked here at the floor Mike. I'm not kidding it's really good popcorn it's like homemade not by me but by some other guy that Microsoft purchased popcorn from they just got way too much. Thank you Microsoft.