My name's Alex Chapman, this is Paul Stone, and this is our talk, Toxic Proxies, Bypassing HTTPS and VPNs to Pwn Your Online Identity.
So first off, thank you all for coming here on a Sunday afternoon. Really good to see so many people turning out for this, so thank you very much, and we'll get started.
So, first we're going to start with a demo. Well, demo video, assuming this works.
So, this is what we're, this is an example of this thing we're going to be talking to you about today, and this is actually about being able to extract information from HTTPS streams on a local network.
You'll see some of the information there, so instead of just the boring, here we are slide, that's kind of just a very quick demo of the sort of thing we're going to be showing you.
So, as I said, my name's Alex Chapman, my colleague Paul Stone. We both work for Context Information Security in the UK.
I'm...
I'm Noxinet on Twitter, and PDJ Stone standing next to me.
I'll explain that demo in a little bit more detail as we go through.
So, this is our talk. The exciting introduction, which you all just saw. I hope everyone else found it as exciting as I did.
We're going to start with some history. This is a 101 track. We're going to talk a little bit about the problem space, what's been going on there, how we got to where we are today, and how our, kind of, how the attack we're going to describe kind of fits into all of that.
So, then we're going to explain the attack, we're going to show how you can sniff data from HTTPS streams, we're going to steal that data, we're going to actually do something with it, and we're going to show how it can ultimately be used to, kind of, steal your online accounts.
We're then going to talk a little bit about VPNs and how they protect us or not against this, and then put in place some real mitigations about what we should be doing on these systems to help make them more secure.
And then we'll talk a little bit about...
We'll talk a little bit about the fixes that have been put in place by various vendors around these issues.
So, where we're starting. This is a kind of attack that we're looking at from a rogue access point perspective.
So, rogue access points tend to have reasonably privileged access to a network anyway. You control the DNS, DHCP, all the rest of it, so you're already in a position where you can kind of monitor and intercept data.
And then we've seen the
So, back in the day, 1993, no encryption, right, so we're here, we're our mosaic browser, browsing away, everyone can see everything that's going on, and then somebody, kind of, thought, well, what if I want to do something sensitive over this?
So, we added opt-in encryption.
We're talking SSL here.
So, Netscape, too, shipped with SSL in 1995.
So, again, a good 20 years ago.
It uses somewhat, say, from passive sniffing attacks.
We obviously know nowadays that the SSL back then
was awful and terribly, terribly broken,
but at the time, it was what we needed it to be.
But SSL wasn't perfect,
so a lot of websites allow connecting over both HTTP and HTTPS.
People connect to HTTP first,
because who writes in the S when they're putting in their URLs?
Who even puts in the schema?
And even man-in-the-middle attacks
can prevent users from reaching the HTTPS sites
and having to fall back to the unencrypted sites.
So it wasn't great.
And Moxie Mullins-Bike demonstrated this in 2009 with SSL Strip,
a great tool for the sign,
for man-in-the-middling these connections,
downgrading them all to HTTP,
and the only indication to the user
was the padlock in the corner of the screen wasn't there.
And again, a lot of users wouldn't be checking
that out.
So they wouldn't be checking that anyway.
Just a quick example of SSL Strip
for those who haven't seen it before.
Browse to a HTTP site.
What it's supposed to do is redirect to the HTTPS
with a 302 redirect.
SSL Strip in the middle of that
will actually prevent that redirection from happening.
So SSL Strip broke HTTPS connections
by simply ignoring them
and stripping them out of the screen.
And browser vendors obviously had to do something about this
to make their connections work.
To make their connections and connections to websites
much more secure.
So this is where we introduced HTTP Strip Transport Security.
And this is somewhere around 2010.
So again, a good six years ago.
That's now been picked up by a lot of major websites.
A big news article the other day about Google.com going HSTS.
So it's taking a while, but it is going there.
And HSTS essentially prevents browsers
from requesting the plain text HTTP resource in the first place.
So we don't have the option of doing the SSL Strip.
That's kind of where we are in the present day.
HSTS is doing a pretty good job.
So nearly all traffic to the sites we use on a daily basis
is encrypted with HTTPS, HSTS protected.
So theoretically, now we're in the coffee shop,
in the pub, on our laptops.
We should be fine.
Right?
We need a new style of attack.
And this is where we're going.
So this is something we came across about six months ago now.
And show the attack to you.
Show how it can be used.
And what we've been able to do with it.
So I'll hand over to Paul to start the explanation.
Okay.
Hello.
So Alex has given you a bit of history.
And I'm going to give you a little bit more history.
So just bear with us until we get into the fun new stuff.
So just to introduce Pack Files for people
who haven't heard about them before.
So a Pack Files exists because large companies
have very complex internal networks,
lots of different proxies.
And they need some way to be able to figure out
which proxy to connect to, depending on the site
that you want to visit.
So a Pack File is simply a small bit of JavaScript
that the browser asks the JavaScript says,
I want to visit this URL.
And the JavaScript figures out which proxy to visit,
which proxy to use.
And it returns a proxy.
It's a string.
And this was invented in 1996 by Netscape.
So it's their fault.
So the other piece of the puzzle that kind of complements Pack
is WPAD.
So WPAD is essentially, if your browser doesn't have a Pack
File, then WPAD tells it which Pack File to use
and where to go and get the Pack File.
So yeah.
So WPAD.
.
It was invented in 1999.
And Microsoft's name is on this IETF draft.
So it's kind of their fault.
So there's a few ways to do WPAD.
You can do it via DHCP.
You can kind of, the gateway can push it to the OS
or to the browser after it fetches an IP.
And there's various other things as well.
So DNS lookups with this, it will use the DNS suffix
and look up, like, WPAD.
.
Internal.
.
Company or whatever.
And there's also NetBIOS, LL, MNR, and all that as well.
So there's lots of ways that WPAD can work.
So WPAD attacks are very well known.
There are a whole bunch of tools that will make it very simple
to inject or spoof WPAD responses.
And if you can do that, you can then target one machine
or a whole bunch of machines and hijack all their traffic
and route their traffic.
They will be able to do that.
They will be able to track your web traffic
through your malicious proxy.
So that means that all plain text, non-HTTPS traffic
can be modified and viewed by the attacker.
So there's a bit we quite enjoyed reading the WPAD spec.
It says, minimally, it can be said that the WPAD protocol
does not create any new security weaknesses.
Kind of famous last words there.
Do you want to?
Yes.
So yeah, just really quick overview of how these things
get pushed out.
So a laptop on a network asks the router for HTTP options.
The router can then respond with option 252,
which is the URL to a PAC file that the system will then
go download and use as its PAC file for choosing proxies
to get out to the internet.
Alternatively, if it doesn't receive a PAC file through
that, it'll do a DNS lookup for WPAD dot search domain.
So the search domain that was either pre-configured or was
pushed out over DHCP.
If the router responds to that, it
can then respond with the IP of a host, which
can serve a PAC file.
And in this case, we'll also be serving malicious PAC files.
The last method is on a network with a malicious actor that's
on the same network as you, so not actually on the router.
So if the system still hasn't got a PAC file,
it'll send out a link local multicast name resolution
request for WPAD.
So if you've ever opened up WPAD,
on a Windows network, you'll see loads of requests for things
like WPAD just being broadcast to other systems on network.
If any other system on that network responds,
that system, sorry, the user system
will use that response to go and grab the PAC file
from the IP address given there.
I think that held back to you.
So Windows has had WPAD turned on by default.
And this is even in home edition.
So this is a very kind of.
Corporate thing.
There's no reason to have this on your home network.
But it's still in Windows 10 enabled by default.
Local network attackers can exploit this.
And there are tools there.
Paul shared a link to it earlier.
But fortunately, again, with these HTTPS and HSTS traffic,
there's theoretically, at this point, nothing the attacker
should be able to do to our connections
to get at our data.
And that's what we're going to show you next.
So throughout this.
Research, we kind of wanted to follow the trend of naming
our vulnerabilities.
And we've got a few kind of rejected titles.
And this was one of my favorite, breaking WPAD.
Paul actually did the posters for this.
And I think he probably spent more time on that
than this actual talk.
But hand back.
OK, a little bit more theory before we
get to the really fun stuff.
So what does a PAC strip look like?
So a typical PAC strip might look a bit like this.
So the idea is that there's three different proxies.
And depending on what the host name ends in,
it will route the browser to one of the three proxies.
So every PAC script has to define this function
with this exact name called find proxy for URL.
And it takes two parameters, the full URL and the host name.
So most PAC scripts will just look at the host
and make a decision based on the suffix
and say, use this proxy or this proxy.
Very simple.
So like I said, it's this one function called
find proxy for URL.
And according to the spec, it takes the full URL
and the host name as parameters and returns a string.
In this case, it returns direct, which means
don't use any proxy.
So it's the full URL that gets passed
into this PAC script, which is potentially a malicious PAC
script.
Can anyone see the problem yet?
So the full HTTPS URL is now known by this.
The tag is a piece of code.
It's potentially malicious.
So what can you do with that?
And why is that kind of bad?
So JavaScript in the PAC file isn't
like JavaScript on a website.
You don't have the full range of functions
to put stuff on the screen and talk to the DOM
and all that kind of stuff.
These are all the functions.
This is essentially the API that PAC scripts have access to.
And the two that really stand out to us is DNS resolve
and isResolvable.
So DNS resolve, as you might expect,
takes a host name and returns an IP address.
And isResolvable.
It takes a host name and returns true or false.
So these are interesting because they let the PAC scripts
talk to the outside world.
So we have sensitive data going in,
and we now have a way to communicate
with the outside world.
So putting it all together, here
is our very simple malicious PAC script.
And what it does is it takes the URL,
checks if it's HTTPS, and therefore potentially
sensitive.
It then appends .leak onto the end.
So in this case, .leak is a domain that's
controlled by the attacker.
And then it replaces all the special characters with this dot.
So for example, we have a sensitive URL there
with a nice auth token in.
And the script will convert it into this string
and then do a DNS lookup.
And the attacker receives this sensitive token
back to their DNS server.
So that's the attack.
And of course, if it can't fit in the tweet,
then it's not a real vulnerability.
And it fits very nicely.
It fits very nicely into a tweet there.
So going back to the overall attack, the malicious gateway.
So as we said before, malicious gateway
can intercept any plain text HTTP traffic easy.
But if we're talking HTTPS, then the attacker
can't intercept that HTTPS traffic.
But if we now are leaking every single HTTPS URL,
so the malicious gateway tells your laptop
to use a malicious PAT script.
And now it's leaking all the HTTPS URLs.
And then the HTTPS traffic is going to the server.
So we can sniff HTTPS URLs and modify plain text HTTP traffic.
So just to kind of sum this up in a nutshell,
PAC files allow attacker-controlled JavaScript
to see every single HTTPS URL before it
gets requested by the browser.
The PAC file can then leak that data to an attacker via DNS.
So.
The whole point of HTTPS is to protect sensitive data
on untrusted networks.
But with WPAD and PAC, an attacker essentially
can do an end run around HTTPS.
This is the second title we came up with.
This is my favorite one, Apocalypse Now.
I'm quite pleased with that one.
OK.
So demo time.
Right.
You might have to bear with us on this.
We didn't realize we wouldn't have an internet connection
up here.
So we're actually trying to do these
demos live through the Wi-Fi on my phone.
We'll see if it works.
If it works, it will be a miracle.
OK.
So the setup we have is on the right,
we have a VM, which is the victim.
And on the left, we have our attacker
with a fancy control panel.
So I'm going to open up Chrome.
So at this point, the malicious gateway
has already sent the malicious PAC file.
And you can see at the bottom here, we're already getting, uh,
tons of URLs being leaked by Chrome.
So I'm now going to search for something.
So everything you do on Google, it goes over HTTPS.
And as you can see, as I was searching,
literally as I was typing, it's being leaked to the attacker.
And it's appearing on their site.
And now I can browse to Wikipedia, which is HTTPS.
I can just browse around Wikipedia.
And, uh, I'm going to do this.
And, uh, the, there's low, you get so much, so much traffic
here at the bottom, all the URLs being leaked.
And the, at the top is just pulling out
the kind of interesting stuff, the actual, uh, pages
that you're visiting.
So that's that.
And we can, uh, search for something else.
So again, DEF CON sites is HTTPS.
Yeah.
So there we go.
That's, uh, so that's what we can just do literally
just by leaking, uh, leaking everything.
OK.
And, uh, thank you.
So yeah, most websites these days are HTTPS.
And, uh, we can, we can see that stuff now with this attack,
which is quite nice.
Right.
Um, now I'm going to hand over to, uh, no, not yet.
You can go.
OK.
So, uh, passively, uh, seeing this data as user browsers
is quite nice.
Um.
But, uh, we're impatient.
As an attacker, they may be connected to our malicious hotspot
only for a short amount of time.
So the challenge we set ourselves was to actively steal
as much data as possible, uh, using only URLs.
Now remember, this attack doesn't let us completely break HTTPS.
We can't see everything.
Um, we can only see the URLs, uh, including
the path and the query string.
We don't get any, uh, post data.
We don't get any cookies, any headers.
We don't get the responses, uh, uh, uh, response bodies.
Um.
Uh.
So, we have this, uh, kind of superpower,
but it's a really limited superpower.
Um.
But, you know, limitation is good, uh,
and it lets us be creative.
Uh.
And the, one of the key things is that because the web isn't
100% HTTPS yet, uh, the, uh, malicious gateway
can still inject, uh, uh, stuff into, into the HTTP pages.
So we can, we can get the user to visit our malicious web
page and then start messing with their browser.
Uh, for example, captive portal pages,
which I'm sure everyone has encountered, um,
since they've been in Vegas.
Okay.
So, we came up with a few basic techniques, um,
that let us do pretty much everything that you've seen
in the demos so far and in the, the demos we're gonna show you.
So, one of the simplest ones, uh, which works really,
really well is taking advantage of three, two redirects.
So, um, the idea is that we, uh, make the user's browser
visit a known URL, um, that's not sensitive,
and then that URL redirects to a sensitive URL
with sensitive information in, which we can then steal.
So, for example, um, if you're logged into Google
and you go to this URL, uh, so plus.google.com
slash me slash posts, if you're logged in,
it will redirect to a, a, a, a URL with your user ID in it.
So now we know who you are on Google.
Uh, the same goes for Reddit.
We can get your Reddit username if you're logged in there.
Um, and the very simple way to do this, um,
is literally just to, uh, put, say, an image tag, uh, on a page.
Um, it's, uh, won't be visible, um, and it's not even an image,
but the browser doesn't care.
It will go and request that URL,
and then we can, uh, leak that via, uh, via DNS.
So, for example, um, that would be sent to the attacker
and would get the username for Facebook.
So that's the first technique.
The second technique, uh, we're gonna use, um,
which you'll see in the demos, uh, soon,
is for dealing with kind of one-time-all tokens.
So perhaps we, you know, we do this, uh, redirect, um,
so the user's browser redirects to a URL.
We can leak the token, but the problem is that
the attacker wants to use that token,
and if the user's browser gets there first,
then that token's no good to us anymore
if it's a one-time token.
So the attacker wants to use it,
but we want to stop the, the, the victim, uh, browser
from requesting it.
So the PAC script, um, as well as just leaking the data,
we can say, actually, if the URL matches this, uh,
exact pattern, um, then return a proxy that doesn't exist.
The user's browser won't be able to, um,
resolve the proxy, that URL won't get fetched,
but we can still leak it to the attacker to use that data.
Now the third trick we came up with, um,
which was, which was quite fun, is, um,
essentially what we want to do is get, uh,
load a page that the user is logged into,
and that page will have loads of, uh,
stuff on it we want to get,
and it will be loading lots of URLs that we want to, to leak.
But we don't want the user to know that this is happening.
Um, so, uh, in the past,
things like iframes would be really good for this.
We could create a, a tiny invisible iframe,
load a URL in there, and we'd get all this, uh, stuff loaded.
Um, but iframes tend not to work these days,
uh, because most sites use xframe options,
which says, uh, don't allow this site to be framed.
So we came across, uh, something called prerender.
So prerender is something that Chrome, um,
uh, invented first, uh, and it's now in Edge as well.
Um, and essentially what it does, uh,
is this HTML tag here, and what it says is,
uh, completely load this page in a,
in a hidden, in a hidden window, um, off-screen.
Um, load it so it's ready for,
so when the user actually clicks that link,
it'll all be prerendered and ready to go,
and it'll appear really quickly.
So, um, like Google uses this, uses this,
so the first, often the first hits
on a Google search result, um, will be prerendered.
So when you click it, it looks like
it just magically appears really quickly.
Um, so what this, what this lets us do is, uh,
load a known URL, um, that fetches other sensitive stuff.
So for example, if I load, um, your Facebook photo album,
or your Google Photos page, um, it will go and request, um,
all the thumbnails of all your photos.
Um, now these, uh, these URLs, um, are always on,
kind of CDNs, so they're over HTTPS,
but they're not authenticated at all.
So they have these long, random-looking URLs,
which are impossible to guess.
Um, but if we take that URL, and, uh,
load it in another browser, uh,
you don't need any cookies, you don't need to be logged in,
you can see, you can, you can get that data.
Um, so prerender's good for that,
and you'll see, uh, some demos of that in a sec.
Right, over to you.
Let's see if we can, uh, see this in practice.
So, find our VM again.
So in this case, we have the, um, same as before,
the user's there, but they've, um,
we've managed to force them to a, a web page we control,
uh, and are able to inject content to.
So we've chosen a particularly complicated secure, uh,
captive portal, so they'll be on there for a little while.
On the attacker side, we can, uh, we can start the attack.
So hopefully, if I click this button here,
we'll start to see, um, information coming back
from that user's browser session.
So we've already been able to grab their, um, Google ID,
Facebook ID, and name from Google.
This is where we cross our fingers
and hope the next bit's, next, next bit works.
Oh, yeah.
Uh, uh, fine.
So it looks like, um, pulling the Google images
hasn't worked this time.
Show the video.
Um, I might rerun it, see if we can.
But we can also, so you can also see,
we can also get their Twitter ID, uh, LinkedIn ID,
and their, uh, employment from LinkedIn, GitHub ID.
This, I mean, this is just a really small subset of,
of services that we were querying here.
Um, but there's a, a, a lot, lot more we could do with that.
I'll try just rerunning it, see if we,
see if we get anything else or not.
But essentially, that allows any captive portal
to completely denom, de-anonymize the user.
Here we go, the images as well.
De-anonymize the user that's connected to the,
to their gateway and get all sorts of what we would call,
I guess, public but sensitive information about that user.
Uh, and you can see we can also go into these images.
Uh, oops.
We can actually get the full-size image just cause it,
cause it's served on a, from a CDN.
They're all there and we can, we can just grab those files
and, and kind of get all that offline data from them.
So.
That's demo number two.
We've, we've done well so far.
So, to, to summarize that, so, um,
if we force the user to, uh, request a web page or URL,
we can get identifying information from it.
We can then use that, uh, those IDs and usernames
to kind of get further information.
So further public information,
but information that's, that's, uh,
information that we wouldn't otherwise have.
So, in order to do this, we need to create a bit of a C2
infrastructure between the user's browser,
the pack JavaScript that's running on their system,
um, the DNS server we're using for leaking information,
and the, uh, malicious, and the web server that we're using
to kind of control all of this.
So, the first thing we have to consider is, is DNS.
So, leaking data over DNS.
Um, DNS actually has a kind of limited character set,
so we can't just throw in any, any, any, any, any, any, any, any,
any data we want.
It's gotta be within the kind of 8z0to9 underscore and hyphen range,
I believe, and obviously periods.
Um, you can have a maximum of 63 characters per subdomain
on a, on a DNS lookup, and a max, and a max,
total maximum of 253 characters.
Uh, and that's, that's just through with the way that DNS is,
um, has been, has been set up.
So, what we ended up doing was, uh, base 36 encoding all of the data,
not, not the most efficient, but, but very easy to do.
Uh, splitting long data into multiple host names,
so multiple sub, subdomains and host names,
and then forming those lookups or more than one lookup,
um, for each leaked URL if the, um, resulting DNS query
was more than 253 characters.
Uh, and then this is decoded and, um, reassembled on the,
on the attacker's DNS server.
Uh, so that's, that's how we get the information out.
Um, we implemented a, an API interface between the attacker,
sorry, between the victim's web browser and the,
the PAC script running, uh, running on their system.
So, the, the PAC script, this, uh, decodes and JavaScript evals
any domains that end in the .e TLD.
Um, it'll encode, uh, the eval results of .r TLD host names,
uh, and send that back to the server,
and it'll leak all URLs by default.
We added a small number of functions,
just, just to help out what we're doing here.
So, add, add block URL, so tell the PAC script
to block all requests to a specific, uh, regex URL.
Add a leak URL, so if it, if the URL matches the regex there,
it'll leak it to our server.
And then clear everything if, just in case we need
to clear everything down and return the, the PAC, uh,
to a, a known good state.
And this is kind of how all of that looks.
So, the top two, um, portions are on the user system.
So, the injected JavaScript running in their browser
is communicating to the PAC script running on their system
by DNS lookups.
Uh, the, the PAC file leaks encoded data to our DNS server.
Uh, the DNS server passes that data back to our control, uh,
web server, and we can serve, um, commands to the,
to the browser from our control web server.
So, it's a bit of a, bit of a cycle going on there.
But that, that's kind of the overview of,
of how what we're doing works.
So, kind of getting information about who somebody is was good.
I mean, we, we were chuffed.
We thought, right, we're really on to something.
But we can do better.
And so, we're kind of doing this research every period of months.
And kind of just these things, ideas are coming up to us as we,
uh, as we're going through.
And one of the things we were quite interested to look at is,
is OAuth.
So, um, OAuth, for those who don't know,
is, uh, a way of allowing a third party
to authenticate users to your website.
So, there's some, some really big OAuth providers.
So, Facebook seems to be one of the biggest.
Uh, Twitter, LinkedIn, Google, Yahoo, and Microsoft.
And these services allow websites to hand off
the authentication to these central authorities.
So, you would've all have seen it sign into this site,
sign in with Facebook, sign in with Google.
Uh, you just click those buttons.
If you're logged into Facebook or Google,
automatically you're logged into that site
without having to type in your username and password.
This is, this is great from a user,
usability perspective.
Don't need to remember another set of credentials.
It just all works, theoretically, anyway.
Um.
OAuth has a number of ways of, uh, passing tickets
and, and tokens between the, the, I guess,
the client application and the central OAuth server.
Uh, but one of the more, um, common implementations
is, uh, using URL parameters via 302 redirects over HTTPS.
So, we thought, can we force this, uh, user to attempt
to OAuth authenticate to a large range of services,
intercept the, um, the final authentication
token and replay that ourselves?
And that's gonna be something that I'm also gonna attempt
to demonstrate.
So, again, user's still here trying to fill out their, um,
their, their, their form password.
Okay, they're gonna be there a while.
Um, so we, we kick off the next attack.
And you can see this one's particularly quick
because we're only using 302 redirects.
We're not trying to do the pre-render pages,
which we have to do in serial, so only one at a time.
This, this is, this is going quick, lightning fast.
Um, from the attacker's
console, we've now got all of these potential, um,
OAuth sessions, so if I, for example,
open Copen in a new incognito window, theoretically.
Good, that bit works.
Yep, brilliant.
I'm, I'm now logged into, to Copen as that user with that,
uh, Bing, Bing their icon there.
Keep going, we've got, we've got loads of other services.
So, for example, developer.mozillo.com.
We've got that account.
Uh, someone's of interest, so I don't know if anyone's used
Foreshed before, but it's a, um, cloud storage platform,
so we can, we can grab that and then start,
start grabbing their files from, from that platform.
And we've got full control of these accounts at this point.
So, um, we're just logged in as if we were those users.
That is going well now.
Right.
Back to the slides.
So, this is, this could be done passively.
We could wait for a user to log in, but as, as, as, as, as, as,
as Paul mentioned, we're kind of impatient.
So, we can force this, and you, um, if you're only using the
three or two lookups, you can actually force, um, a large
number of, uh, authentication attempts against a large number
of services very, very quickly.
Um, the user won't see anything necessarily when they, um, go to
log back into that service.
Uh, they, in our experience, they haven't, uh, they won't
see failed login attempt to this or, or anything else.
So, it's, it's pretty blind, um, from the user side of things.
Um, and it does allow attackers to gain full control over the
victim account.
Okay.
So, uh, we've shown you a few demos, uh, we, which we're quite
pleased with, but we want to go even further.
So, um, we want to, so we, we've stolen some of the, uh, kind of,
uh, accounts that most people don't care about.
I mean, you tend to use OAuth for things that you just can't be
bothered to create an account, but we want to go after the, the
good stuff.
So, we're going to attempt to, uh, get into your Google account
now.
So, uh, the way that, uh, the way that, uh, the way that, uh, the
way that, um, Google works is quite interesting.
They have lots of different domains, and you can't share cookies
between top-level domains.
So, what happens is that when you log into Google, uh, most of
your cookies, um, go onto the main Google.com domain, uh, and
when you go to another website like YouTube or Blogger or one of
the regional, uh, Google search sites, um, then, uh, there will be
a kind of first-party SSO.
So, uh, they will use, um, uh, the, say, Google.co.uk will ask the
main site, uh, for an OAuth token, and it will use a three, three or
two redirects.
So, we can steal that.
So, like this, um, so it will go accounts.google.com, please log me
into, uh, google.co.uk, and it will say, okay, uh, you're logged in.
That's fine.
Uh, here's a redirect.
Here's an OAuth token.
And then it will go and set the cookies on the, on the local site.
So, um, and then you're logged into Google.co.uk.
Okay.
And, uh, actually, let's do this together.
Uh, the second thing, the second demo we're going to see, um, is, uh,
stealing stuff from Google Drive.
So, again, um, when you download stuff from Google Drive, uh, there's a few
different ways it works, depending on how you got the file.
Um, so we're looking, in this case, at files which have been emailed to you and
that you, um, saved to your Google Drive.
Um, so, uh, what happens when you, uh, click to download the document, uh, is
you start off on drive.google.com, um, and then it will redirect, do a redirect
to googleusercontent.com, which is, um, uh, kind of unauthenticated, but it
uses an OAuth token, um, and it kind of does this, uh, couple of
redirects back and forth between the two different sites, uh, but eventually we
can get the OAuth token, essentially, um, and download the documents.
So, I'm going to show you, uh, that demo.
Um, I should point out that none of these are vulnerabilities in, like, Google or
any of those are all sites.
Um, these are, this is just because, uh, we can, uh, steal the HTTPS URLs.
Okay.
So, I'm going to click this button, and we'll see.
There we go.
So.
We, you can see the, the URL here, it's got the, uh, uh, the OAuth token in it, and
what I'm going to do is literally just open that URL in the private browsing window.
So, there we go.
I'm now logged in to google.uk.
So, like I said, this, this isn't your main Google account, um, so we, we haven't got,
like, the crown jewels, but we can still do quite a lot of stuff.
So, if I search for, like, uh, my email, I can't type.
Um, so we get a summary of what's in your Gmail inbox.
I can't click on those, but, you know, I can still see, uh, some, a summary.
I can do my photos.
Uh, I can do my home address.
There we go.
Uh, I can do my location.
Uh, my location isn't working.
Okay.
Uh, but another thing we can do is if you, if you happen to have, um, location history
turned on in your phone, um, then Google is basically tracking it everywhere you go.
And we, because, um, Google Maps is kind of, again, regional, it's not the main google.com
site, you can go to your timeline.
Come on.
It's going to stop working.
Oh, no.
It's getting there.
It's just, it's just taking a while.
So, there we go.
So, you can see everywhere we've been in, uh, Vegas, all the various places we've been.
Um, so, and, uh, where did we go today?
Ah, it's being a bit slow.
But anyway, uh, we thought that was quite nice.
Thank you.
Yeah.
Okay.
Uh, right.
We've got to get on.
Okay.
Uh, so I'll hand it back to you.
Do you want to do the Google Drive demo quickly?
Oh, Google Drive.
Thank you.
Thank you.
Uh, okay.
Get rid of that.
So, Google Drive.
Click the last button.
And hopefully we'll see some stuff pop up.
There we go.
So, you can see all the URLs going through at the bottom.
Uh, and now the, uh, attacker server is going to download those, uh, to the server.
And then we can load some of these things.
Okay.
So, we're going to do a quick test.
So, how do you middle click?
Right.
So, yeah.
So, you know, if you save some passwords to your account.
That's a PDF.
Uh, that's someone else.
And that's some passwords there.
Right.
Great.
Uh,
So that last demo there, that was all Paul's work. He spent ages doing that and I thought,
well, I can't let him have the best demo of this talk. So I spent a little while looking
around, I thought, well, target Facebook. I was like, right, there's got to be a way of
getting somebody's Facebook account, right? And there was. And up until about three days
ago, this worked. It was only when I went to record a video of showing stealing somebody's
Facebook account using OAuth that it all stopped working and Facebook broke it. So I don't
have a demo of that, I'm afraid. Facebook didn't break it in the sense that they fixed it,
they just broke it. So the attack was through the forgotten password functionality.
There's an implicit authorization between Facebook and Microsoft's OAuth. So if you've
signed up to Facebook with a Microsoft account, you can hit forgotten password,
drop my password, type in your email address, and there's an option to just reset it via the
OAuth authentication to Microsoft. But that now asks you to log back into your Facebook
account. So to reset your password, you have to log into your Facebook account. Anyway. So
I'll move on from that. So one of the kind of key points we thought we were going to get from
this was people turning around and saying, so what? I use a VPN. VPNs allow us to kind of
travel safely over hostile networks and kind of should protect us in this area. Right? So just to
go back to our previous example, so a malicious gateway with users connecting over a VPN, user
tunnels through to their VPN server and then all traffic goes out to the Internet from that VPN
server. So the attacker can't sniff HTTP URLs or they can't intercept traffic. Using the pack
leak,
similar sort of thing. We tell them where the pack file is. They've got their secure tunnel set
up. But the pack file is situated in the local network. There's no route from the VPN server to
where we're hosting the pack file. And then the user, so because the browser can't find the pack
file, it will just ignore it and just connect directly out to the Internet. So what if we move
the web server hosting the pack file to the Internet? So we tell the client that the pack
file is on an Internet accessible server. They connect to their VPN server. They can now access
that pack file and connect to the Internet. So at this point we are sniffing the URLs as we were
before. But we can go one better than this. What are pack files supposed to do? They're
supposed to specify a proxy. So if we stick our proxy server on the Internet as well, we've now
got the user's traffic coming out of their VPN endpoint leaking the HTTPS URLs to the
DNS server, proxying all of their HTTP traffic before it's even hitting the intended target.
This kind of blew our minds. This is really quite cool. Yeah. It shouldn't work like that,
should it? So many VPN clients do not actually clear the proxy settings obtained via WPAD. We
tried a few and I'll run through those shortly. The first thing we did was we looked at the
traffic tunnel all the way from the VPN endpoint through our proxy on the Internet before it hits
the intended destination. So the effect itself on this. Open VPN is affected. They are working on a
fix. But to this point it has not been released. So there's no way of mitigating this through an
open VPN server configuration. Private Internet access. I don't know who uses private Internet
access in this room for VPN configuration. We reported this issue to them as well as open VPN.
They have fixed it. So they are clients based on open VPN. But they've implemented a client-side fix
to disable WPAD to kind of fix this. And kind of more corporate VPN solutions, for example, Cisco
AnyConnect, actually have an option to say push your own proxy or kind of completely wipe all
proxy settings before coming this way. The Windows built-in VPN clients aren't vulnerable to this.
They actually looks like they've thought about this issue and have disabled WPAD by default.
On these LTP and PPTP connections. Yeah. Oh, yeah. It speaks for itself. So Paul's third work of art
there. The rejected vulnerability title for this issue. So the next response. So what? I don't use
Windows. Yeah. Actually other operating systems do use WPAD and PAD. So OSX does. IOS does.
Android does. Okay. Not by default.
So it's not quite as bad as on Windows. But you do need to be aware of it. I think that's pretty much
everything I covered. Four minutes left. Yeah. Fine. So to mitigate this, first thing you do on a Windows
system is turn off WPAD. Seriously turn off WPAD. There's no good reason to have it on. So if you still
need to use PAC, which a lot of organizations will need to do. Turn off WPAD. And configure an explicit
URL for your PAC. So you can see it's a little bit more complex. So you can see it's a little bit more
complex. So you can do this securely over HTTPS to an internal server. Or you can actually serve it from a
local file on Windows if you specify another registry key. So we'll just pull it from the disk. And
those are really the only two secure ways of doing or distributing PAC files. To mitigate VPN, turn off
WPAD. Only so many times I can say that. VPN is safe if WPAD is enabled. If the VPN environment requires a
proxy server to get out to the internet, it's safe to use WPAD. If the VPN environment requires a
proxy server to get out to the internet, then it effectively mitigates this issue. We can't chain
proxy using, using PAC, as far as we're aware. Or if the VPN server pushes and explicit proxy
configuration, then this won't be an issue and that's certainly an option on a lot of the enterprise
level VPN solutions.
So the good news. We reported this issue to vendors back in March and a lot of them have fixed . So Apple
came out pretty quick. Related to what you just talked about, this issue was brought over to the
some fixes for OSX and iOS. And Apple TV. Didn't know they still did that. Google Chrome
patched just a few weeks ago. In fact, I was setting up these demos and I couldn't work
out why they weren't working the other day. It's because my Chrome had automatically updated
and I just had to kind of downgrade it again. Android patched in July. Firefox waiting on
a patch for this issue. But it's also not the default configuration in Firefox. So it
has to be explicitly enabled. And Microsoft have a patch pending. Again, slightly different
on Microsoft. Certainly on Edge and Windows 10. It does some really funky caching stuff.
So it's really not quite as big as a deal with that. How long have we got? Running through.
Two minutes. So we were actually not the first people to spot this issue. But we were the
first to report it. So there was a talk at Black Hat this year, literally last week,
on this exact same issue.
The guys didn't report it to any vendors for some reason. Ben Venice, I hope I'm pronouncing
that right, reported this issue to Google and Firefox literally two weeks after we did.
So plenty of people looking at the same place. There was a master's thesis from May this
year which outlined this issue. There was a Russian blog post from June last year outlining
this issue.
There was a Stack Overload question from May last year outlining this issue. Lots of people
found this. Nobody reported it to the vendors. Interesting. Not sure if we've got time for
that slide. So to summarize, network based attackers can eject Pax Scripts into browsers.
Pax Scripts can leak all HHS URLs via DNS to an attacker at least on unpatched systems. we
showed how to de-anonymize users, steal OAuth tokens, and hack HSS URLs. Then in the third
tokens, access photos, location data, and documents. A VPN won't necessarily protect
you against a malicious proxy. Now go turn off WPAD.
Very quickly, I'll just say, we're going to be releasing all the code for all the
demos, like, as soon as we get back home and have had some sleep. So it will be on GitHub.
Just watch our Twitter feeds and we'll let you know when we've released it, if you're
interested.