Alrighty, buddy. For abusing bleeding edge web standards for AppSec Glory, we got
Brian Zadigan and Ryan Lester. Please give them a big hand. Uh, alright, so everyone
please take a moment and visit our website. I know it looks scary, but trust me, um, it's
uh, part of the hands-on component of our session. So. 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 AppSec Glory. Uh, my name is Bryant, uh, and. I'm Bryant. And
that's Ryan. Uh, we're not used to. Oh, sorry, I forgot 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 AppSec related stuff. Uh, I mentor security startups
sometimes. Uh, I also mentor others, mentor in 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, uh, 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. Scythe only, Boston stuff.
Fair enough. So, in talking about bleeding edge web standards, I want to 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. Show of, a quick
show of hands as to who in the room was familiar with breaking edge web standards. So, we're going to
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
going to touch on content security policy. Uh, show of hands. Ah, nice. Okay, that's good. So,
we're going to talk about something that we're calling CSP meta-hardening here. So, we're not
really going to 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
going to focus on here is something that we're calling HPKP suicide. So, why? Now, here's the
thing. Uh, new standards are 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 a
hand back there. 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,
uh, 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 CAA? Uh, we, we hit, uh, two bounties on, on, uh,
Chrome, just completely by accident. We didn't create a fuzzer or anything. We just scored a
quick 2,500 bucks just in the course of making this talk. So, kind of diving into SRI, now we're
actually gonna 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, 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 a 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, well, anyway, fallback, uh, source script.
You just add this X SRI fallback attribute to any of your scripts or stylesheets 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, um, 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, uh, we've got, uh, we've got, uh, we've got, uh, we've got, uh, we've got, uh, we've
got a couple of links here, and that's the source code. So, we'll also have at the very end on the
very last slide, we're gonna have one link that aggregates all the links that we're gonna put on
screen today, so if you don't wanna 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 cache 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 Ryan kind of take on the pre-scripted 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 so. 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 flaw. So if you wanted a quick use case for how you
could have exploited that. So Google ended up marking that one as a high and 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 I'm going to talk a
little bit more about this. So we've got something that we're calling CSP meta-hardening. Um and
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
going to 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 pre-scripted 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. Sure. 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 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 if you click this button it actually injects into the DOM uh an
HTTP equivalent meta-header. So 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 your typical Silicon Valley shop. You've got an
app. 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 I'm just winging at this point based on the UIs. But any application that does a
lot of preloading 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's 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 preloading 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 in
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 HBKP. So for those of you that might not be familiar with
HBKP uh we've got a bunch of stuff that might excite some of you. So let's talk about HBKP. So for those of you that might not be familiar with HBKP uh we're
going to go over the basics of HBKP. So let's talk about HBKP. So let's talk about HBKP. So let's talk about HBKP. 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 he uh like a sample uh pin set here for you uh where if you were to implement
HBKP uh it would be in report only it wouldn't it wouldn't break anything if if you end up doing it
wrong. Uh and and it'll have the max age configured perfectly you just need to replace the the key
for your hashes uh well the the hashes for your keys uh with the actual hashes for the keys that
you're serving up. So 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 HBKP 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 bricking 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
would 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 HBKP can be used to further uh
that work. And the black hat audience was very very receptive to 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 Horn at Cure53. Uh he was actually the one who put us on to this idea
during the course of an audit of Scythe uh last year. And uh he was actually the one who
put us on to this idea. And DigiCert 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 HBKP 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 level of security guarantee that HBKP provides. Uh so first the users 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 HBKP 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 uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh uh
forcing it to fall back on the the cache service worker. So let me put that in human terms.
If cause 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 HBKP 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 to that server you're actually using the
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
subdomains that haven't been pinned within the actual service worker itself. That's the key here and
that's how this that's 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
gonna talk about it. Yeah. Uh so we uh in the slide here uh we've got a really novel use case here.
And in the slide earlier you saw we had code signing as a possible application of this crossed out.
Uh so I mean why not? Um in theory you could use this local content pinning scheme to pin your code
signing logic. Um oop. Did it just skip the whole slide? Yeah you can skip the last slide.
Ah. Go for it. Alright sorry. Uh so yeah in theory that should work more or less getting you
trust on first use. And um so why in theory it sounds like it should work. In fact it's not
exactly true. In fact Syph employs a mature audited implementation of exactly this that we call
WebSign. Uh however it was considered novel enough that we were advised to apply for a patent on
it. Uh purely defensively but um no one else can do it now. Uh but you can come pretty close to the
benefits of code signing by following uh 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 can hire a code signing scheme and you can code sign your code
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 420 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 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 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's 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 20 times a week? So it's like once every eight-ish hours,
maybe? 8.4 hours? 8.4, something like that. Um, so you're re-keying once every 8.4-ish
hours, and that means if a vis, 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, uh, will have already pinned the content locally. Uh, 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. Uh, 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 user's 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, uh, in your user's browsers. So,
time permitting, we'll 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. It's not completely random. 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 Bluecoat, right? I, I love picking on
Bluecoat because I've only ever had to deal with them. So, here's what they can do. They can
actually, 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? That's part of the design. Uh, they can actually lock users out of malicious
sites or flag sites or porn sites or whatever, uh, 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, I
don't know, what's a good, xhamster.com, sure. Uh, and the, and Bluecoat says, oh, wait a
second, this is obviously a porn site, we're gonna keep you from visiting this. Well, here's the
thing, for that flagged domain, it sets the HPKP header for the Bluecoat cert, right? Now, think
about it, it's the Bluecoat cert. It's not gonna 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, if for whatever reason you can't afford Bluecoat, like
multiple instances for your own network, okay, you can rotate the keys weekly at the gateway as
well. Um, but I figure if you are considering using Bluecoat, you can afford the, the, 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, uh, so, apparently Bluecoat is, uh, now an intermediate certificate
authority, so we don't actually know how relevant this is to any part of our talk. Um, it
makes sense. Um, 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, oh, this one's fun. This one's
fun. Okay. User tracking. So, we shouldn't really talk about this. Uh, 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
builder-y talk, but because it's kind of, sort of tiptoeing on, like, the edges of ethics, we'll
call it breakery as well. Uh, so, you need to pin a lot of subdomains. We're talking, like, 30,
32 subdomains. That number probably sounds, it makes sense if you think about it. You also need
browsers that pin, well, that, 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 has intru-, has introduced a lot of nov-, like, just by automating
everything, they've, it allowed us to do a lot of novel things. Um, we might have some amount of
issue with some of the things we've been able to achieve, uh, but at the same time, we
understand and love the vision for spreading TLS all over the open web. So, T, in this case,
Let's Encrypt really helped out, uh, 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
kinda 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'll be, this explanation will be a little
hand-wavy, and that's by design. Uh, it'll make a lot of sense when you see the demo. So, on your
server, you've got, uh, an HPKP server with, uh, all of your subdomains, uh, star dot, 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 no-op, and, um, you're just retun-, routinely
rotating your keys on that server. Then on your, uh, JavaScript, to set a new ID, you're just
hitting those subdomains in a random pattern, uh, hitting set on them, and to check the ID,
you're iterating through all of them and hitting the check method. So, uh, you can see that, uh,
the check method on all of them. So, in principle, it's pretty similar to the HSTS super
cookie that I think Sami Kamkar, uh, came up with? Yeah. Okay. I think so. Hopefully. Don't
quote me on that. So, we've got a demo, uh, super cookie server set up at syph dot wing, and,
um, just went, went through a quick demo, sorry, quick demo here in, 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.
Uh, JS right there. And, uh, it'll, here you can see it generated a new ID. It's just a, just a
random 32-bit integer, 4565566. And now we're trying again in an incognito window on a
totally different site. And, in this case, um, it, you can see a bunch of failed TLS
handshakes, uh, from those eight, uh, what, from those HPKDs. It was, it was, it was a
bunch of HPKD suicides. And it re-gent, reconstructed the exact same ID there. 4565566.
If you look at the subdomains, you can see it's just a bunch of numbers dot syph dot wing.
We're using zero through 31 dot syph dot wing, uh, 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 on the website. You're working on a site that's not
in incognito mode. In blatant violation of the fact that incognito or private modes are
supposed to give you certain privacy guarantees. Uh we've actually I think raised that up as a
concern but it's been just deemed as the the security benefits of h of both HSTS and HPKP
have been deemed to be much more significant than than the potential privacy loss of doing
so. Um I don't actually think either of us have a problem with HSTS in that capacity but
HPKP uh we personally think shouldn't actually be uh necessarily respected in private modes
or incognito modes. And in fact uh there was a time I think in Tor browser so this is our big
PSA right? Um 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 uh 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. Um we don't believe that's the case now. Uh we
double checked uh and we believe that if it was actually an issue so again we're not 100%
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 I'm not going to go into too much detail on this
but uh you have some risks. Let's say if you want to implement this uh you have the risk of
somebody else saying well hey this is actually kind of unethical so we're going to try and DOS
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 as like a sold service uh you
can always just you know issue a nonce back you can always just you know issue a nonce back
you know uh 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've I do expect this
nonce let me go ahead and serve up the HPKP 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 thing I'm going to do is I'm going to do a
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 um 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 um you
can of course go and check it out uh up there or you can grab it again off of the aggregate link.
Alright this is the fun part we got one more.
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. Um so we really shouldn't talk about this but you know who are we
kidding this is DEF CON. 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. Uh 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. Uh you need a way to shell the box and you need a free CA. Right. So
and again okay we we love let's encrypt again I know I'm not going to go into too much detail here.
There's some people in here we love them give them another hand 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 like is taking a site for ransom and we'll explain why in a bit.
So we're we decided to call this pattern ransom PKP you know in the culture of arbitrarily naming
your attack patterns and vulnerabilities right. Uh 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 pwn in hacker lingo today right? I hope so. Okay so you have to pwn the target
web server. Oh god I just said that out loud. Uh you have to uh once you've actually taken
control of the web server on the server using cert bot or whatever you want to use your own
automated script it doesn't really matter. Uh generate your uh your own uh your own uh your own
key pair. 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. Then 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. Uh 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 it. I'm just gonna let
Ryan do it. That's fine. Um let's see. So uh yeah I mean in the box uh while owned users is uh
less than N or just on some static interval like 8.4 hours we mentioned with Let's Encrypt. Uh it's
okay there we go. Your laptop's probably already gotten owned. Oh. Um please don't own my
laptop. Um so uh on that interval or after each of those end users you just um rekey that you
generate a new uh lockout key, delete the current one, generate a new one and throw it in the
HPKP header while the ransom uh key public key hash is still in there. Is it? Yeah just go with
that. Alright. Um and then each time uh like I said you blow out the old lockout key and then
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 uh during that interval. And um 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 though? Uh 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 gonna be uh dinged by the demo gods here. Alright so uh anyone who went to
ISIS.io at the beginning of our um our talk. Uh this is what you probably saw or should have
seen unless you were on android as Bryant mentioned. And uh now that a rekey has occurred
this is what you should see. Uh TOS key pinning error. So let's actually call this out. If you
actually look uh we can't zoom in to 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. When we were talking about the uh uh the uh uh uh uh uh uh uh uh uh our our uh our
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 yeah actually we will give you
literally the ransom key pair if you for instance do whatever we want you to do. Uh that's
that's essentially the premise here. Now somebody could that's the worst possible thing we've
thought of that somebody could do. Um if you gain access to a box uh then you can do quite a
lot of things. Uh but let's say all you get access to is just the web server. Right? Like
okay typical site defacement is probably on your road map. You're probably gonna put I don't
know uh uh 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 the web server. Uh but you can also monetize what you just did. Right? So
here's the thing. Let's Encrypt's rate limit is twenty certs a week. We mentioned this
earlier. Uh it's it's kind of an artifact of uh how they've architected the service. Uh
originally it was like a five rekey limit but if you reconfigure that cert package that you
you send for like the actual key 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 1 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 key pins so they figured you know what 2 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
Encrypt has 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 us in a situation where we're in the middle of a
crisis and we're not able to get a lot of data. So I'm not going to put 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 black list white list. 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 person who
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 will 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 white listed 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 CAs 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 certificates for
your domain. Now alternatively you could also use ASPKP uh we actually had somebody who
attended the black hat version of this talk 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 ASPKP 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 could 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? You know like an accountant that might
get might be like a what bystander that gets uh hit by this? Uh you can always try visiting uh
Chrome, Netinternals, uh HSTS. Uh you can always try visiting uh Chrome, Netinternals, 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 cache um and that should also clear your ASPKP headers as well. Uh originally you
could clear any aspect of your browsing history including save passwords and because they
misplaced a curly brace that would also clear your ASPKP 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 is
not 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. Uh yeah. Uh yeah. Uh yeah. Uh yeah. Uh yeah. Uh yeah. Uh yeah. Uh yeah. Uh yeah.
Yeah. 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 remember how to pronounce some of these names. Uh Geller Bedoya, DigiCert, um Twitter
handle EL underscore D three three. Uh John Callahan, Jan Horne, and I'm going to give you a
couple more names that we can find. Uh I will give you a list of all the names in here. Um
Sammy Kampkar, 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 5, 6 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 this stuff. Um I my
technical background here is I advise Ryan and his company Syf on GitHub and on Google. I'm a
implementing a lot of the AppSec stuff that they have there. So if you want to see some of
this stuff in action you can always just check out syph.com or syph.im and see some of this
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 mic.
I'm not kidding there'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.
Thank you.