 My name's Alex Shatman, this is Poolstone, and this is our talk, Toxic Proxies, Bypassing, HTTPS and VPNs, to poem 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 the demo, assuming this works. So, this is what we're, this is an example of the 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 who we are, 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 Shatman, my colleague Poolstone. We both work for Context Information Security in the UK. 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 will 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 the attack 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 use to 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 the fixes that have been placed by various vendors around these issues. So, where are we 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 or the rest of it. So you're already in a position where you can monitor and intercept data. So, back in the day, 1993, no encryption, right? So we're here, we're on a 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 often encryption. So we're talking SSL here. So let's get to ship with SSL in 1995. So, again, a good 20 years ago. These are somewhat safe 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 HTTPS and HTTPS. People connect to HTTPS first because who writes in the S when they're putting in the URLs, who even puts in the schema. And evil man on 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 Mullinsbite demonstrated this in 2009 with SSL strip, great tool for the sign, for man in the middleing these connections, downgrading them all to HTTPS, and the only indication to the user was the kind of padlock in the corner of the screen wasn't there. And again, a lot of users wouldn't be checking that anyway. Just a quick example of SSL strip for those who haven't seen it before. Browse to a HTTPS site. What it's supposed to do is redirect to the HTTPS with the 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 Browse vendors obviously had to do something about this to make their connections and connections to websites much more secure. So this is where we introduced HTTPS 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 HTTPS. So it's taking a while, but it is going there. And HTTPS essentially prevents browsers from requesting the plaintext 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. HTTPS is doing a pretty good job. So nearly all traffic to the sites we use on a daily basis is encrypted HTTPS, HTTPS 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 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. So Alex is giving you a bit of history and I'm going to give you a little bit more history. So just bear with this until we get onto the fun new stuff. So just to introduce pack files for people who haven't heard about them before. So pack files exist 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 use and it returns a proxy as a string. And this was invented in 1996 by Netscape. So it's their fault. So the other piece of the puzzle, the kind of compliments 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 or where to go and get the pack file. So yeah, so WPAD was invented in 1999 and Microsoft's name is on this ITF draft, so it's kind of their fault. So there's a few ways to do WPAD. You can do it via DHCP. The gateway can push it to the browser after it fetches an IP. And there's various other things as well. So DNS look-ups, it will use the DNS suffix and look up WPADs.internal.company or whatever. And there's also NetBIOS, LL, MNR and all that as well. So there's a few 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, their web traffic through your malicious proxy. That means that all plain text non-HTPS 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. It's kind of famous last words there. Do you want to do this? So 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 pack file that the system will then go download and use as its pack file for choosing proxies to get out to the internet. Alternatively, if it doesn't receive a pack file through that, it'll do a DNS lookup for WPAD.search domain. That was either pre-configured or was pushed out over DHCP. If the router's response to that, it can then respond with the IP of a host, which can serve a pack file and in this case will obviously be serving malicious pack 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 pack file, it'll send out a link local multicast name resolution request for WPAD. So if you've ever opened up Y-Shark 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 pack 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, I pulled a link to it earlier. But fortunately, again, with these HTTPS and HSTS traffic, 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 wanted to follow the trend of naming our vulnerabilities, and we've got a few rejected titles, and this was one of my favourite, Breaking WPAD. Paul actually did the posters for us, and I think he probably spent more time on that than his actual talk. Hand back. OK, a little bit more theory before we get to the really fun stuff. So what does a pack script look like? So a typical pack script 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 pack 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 pack 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 findproxyforurl. 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 pack script, which is potentially a malicious pack script. Can anyone see the problem yet? So the full HTTPS URL is now known by this attacker's piece of code. It's potentially malicious. So what can it do with that and why is that kind of bad? So JavaScript in the pack file isn't like JavaScript on a website. It doesn'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 pack scripts have access to. And the two that really stand out to us is dnsresolve and isresolvable. So dnsresolve, as you might expect, takes a host name and returns an IP address, and isresolvable takes a host name and returns to a force. So these are interesting because they let the pack 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 pack 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 .. 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 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 HTTPS traffic. But if we now are leaking every single HTTPS URL, so the malicious gateway tells your laptop to use a malicious pack 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, pack files allow attacker control JavaScript to see every single HTTPS URL before it gets requested by the browser. The pack 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, with W-pad and pack, and attacker essentially can do an end run around HTTPS. This is the second title we came up with. This is my favourite one, a pack ellipse now. I'm quite pleased with that one. OK, so demo time. Right, we might have to bear with us on this. We didn't realise we wouldn't have an Ethernet 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. 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 pack file, and you can see at the bottom here we've got already getting 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 browse around Wikipedia, and you get so much traffic here at the bottom, all the URLs being leaked, and at the top it's pulling out the interesting stuff, the actual pages that you're visiting. So that's that, and we can search for something else. So again, Defconn's site is HTTPS. Yeah, so there we go. So that's what we can do, literally just by leaking everything. Thank you. So yeah, most websites these days are HTTPS, and we can see that stuff now with this attack, which is quite nice. Right, now I'm going to hand over to... No, not yet. Okay, so passively seeing this data as user browsers is quite nice, but 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 using only URLs. Now remember, this attack doesn't let us completely break HTTPS. We can't see everything. We can only see the URLs, including the path and the query string. We don't get any post data, we don't get any cookies, any headers, we don't get the responses, the response bodies. So we have this superpower, but it's a really limited superpower. But limitation is good, and it lets us be creative. One of the key things is that because the web isn't 100% HTTPS yet, the malicious gateway can still inject stuff into the HTTP pages, so we can get the user to visit our malicious web page and then start messing with their browser. For example, captive portal pages, which I'm sure everyone has encountered since they've been in Vegas. Okay, so we came up with a few basic techniques that led us to pretty much everything that you've seen in the demos so far, and then the demos we're going to show you. So the idea is that we make the user's browser visit a known URL, that's not sensitive, and then that URL redirects to a sensitive URL with sensitive information in, we can then steal. So, for example, if you're logged into Google and you go to this URL, so plus.google.com, slash me slash posts, if you're logged in, it will redirect to a URL with your user ID in it. So now we're going to go to Google and we're going to go to Google and we're going to go to Google and we're going to request that URL with your user ID in it. So now we know who you are on Google. The same goes for Reddit. We can get your Reddit username if you're logged in there. And the very simple way to do this is literally just to put, say, an image tag on a page. It won't be visible, and it's not even an image, but the browser doesn't care, or go and request that URL and then we can leak that via DNS. So, for example, we're going to go to Google and we're going to request that URL with your user ID in it. So that's the first technique. The second technique we're going to use, which you'll see in the demos soon, is for dealing with one-time all tokens. So perhaps we do this redirect, so the user's browser redirects to a URL and 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, we want to stop the victim browser from requesting it. So the pack script, as well as just leaking the data, we can say, actually, if the URL matches this exact pattern, then return a proxy that doesn't exist, the user's browser won't be able to 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, which was quite fun, is essentially what we want to do is get load a page that the user is logged into and that page will have loads of stuff on it we want to get and it will be loading lots of URLs that we want to leak. But we don't want the user to know that this is happening. So in the past, things like iframes would be really good for this. We could create a tiny invisible iframe, load a URL in there and we'd get all this stuff loaded. But iframes tend not to work these days because most sites use X-frame options that don't allow this site to be framed. So we came across something called prerender. Prerender is something that Chrome invented first, and it's now in edge as well, and essentially what it does is this HTML tag here and what it says is completely load this page in a hidden window off-screen, load it so it's ready so when the user actually clicks that link it will be prerendered and ready to go and it will appear really quickly. Like Google uses this, often the first hits on a Google search result will be prerendered, so when you click it it looks like it just magically appears really quickly. So what this lets us do is load a known URL that fetches other sensitive stuff. So for example, if I load your Facebook photo album or your Google photos page it will go and request all the thumbnails now these these URLs are always on 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 but if we take that URL and load it in another browser you don't need any cookies, you don't need to be logged in you can get that data. So prerender is good for that and you'll see some demos of that in a sec. Right, over to you. Let's see if we can see this in practice. Find our VM again. So in this case we have the same as before, the users there but we've managed to force them to a web page we control and are able to inject content to. So we've chosen a particularly complicated captive portal so it will be on there for a little while. On the attacker side we can start the attack and hopefully if I click this button here we'll start to see information coming back from that user's browser session so we've already been able to grab their Google ID, Facebook ID and name from Google. This is where we cross our fingers and hope the next bit works. So it looks like pulling the Google images hasn't worked this time. I might rerun it see if we can read it. But you can also see we can also get their Twitter ID LinkedIn ID and their employment from LinkedIn GitHub ID. This is just a really small subset of services that we were querying here but there's a lot, lot more we could do with that. I'll try just rerunning it see if we get anything else or not. But essentially that allows any captive portal to completely anonymise the user. Here we go. The images as well. Do you anonymise the user that's connected to their gateway and get all sorts of what we would call I guess public but sensitive information about that user. And you can see we can also go into these images. We can actually get the full sized image just because it's served from a CDN they're all there and we can just grab those files and get all that offline data from them. So demo number 2 We've been doing well so far. So to summarise that so if we force the user to request a web page or URL we can get identifying information from it. We can then use those ID's and usernames to kind of get further information. So further public information but 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 the DNS server we're using for leaking information and the web server that we're using to control all of this. So the first thing we have to consider is DNS. So leaking data over DNS DNS actually has a limited character set so we can't just throw in any data we want it's got to be within the kind of AZ0-9 underscore and hyphen range obviously periods. You can have a maximum of 63 characters per subdomain on a DNS lookup and a total maximum of 253 characters and that's just to do with the way that DNS has been set up. So what we ended up doing was base 36 encoding all of the data not the most efficient but very easy to do splitting long data into multiple hostnames so multiple subdomains and hostnames and then performing those lookups or more than one lookup for each leaked URL if the resulting DNS query was more than 253 characters and then this is decoded and reassembled on the attackers DNS server. So that's how we get the information out we implemented an API interface between the victims web browser and the pack script running on their system so the pack script decodes and JavaScript evals any domains that end in the .e tld it will encode the eval results of .r tld hostnames and send that back to the server and it will leak all URLs by default. We added a small number of functions just to help out what we're doing here so add block URL so tell the pack script to block all requests to a specific regex URL add a leak URL so if the URL matches the regex there it will leak it to our server and then clear everything in case we need to clear everything down and return the pack to a known good state and this is kind of how all of that looks so the top two portions on the user system so the injector JavaScript running in their browser is communicating to the pack script running on their system by DNS lookups the pack file leaks encoded data to our DNS server and the DNS server passes that data back to our control web server and we can serve commands to the browser from our control web server so it's a bit of a cycle going on there but that's kind of the overview of how what we're doing works so getting information about who somebody is was good and we were chuffed with that we thought right we're really onto something but we can do better and so we're kind of doing this research over a period of months and kind of just these things ideas are coming up to us as we as we're going through and one of the things we were quite interested to look at is OAuth so OAuth for those who don't know is a way of allowing a third party to authenticate users to your website so there's some really big authors so Facebook seems to be one of the biggest twitter linked in Google, Yahoo and Microsoft and these services allow websites to hand off the authentication to these central authorities so you would have all of seen it signing into the site signing with Facebook signing with Google 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 great from a usability perspective don't need to remember another set of credentials it just all works theoretically anyway OAuth has a number of ways of passing tickets and tokens between the client application and the central OAuth server but one of the more common implementations is using URL parameters via 302 redirects over HTTPS so we thought can we force this user to attempt to OAuth authenticate to a large range of services intercept the final authentication token and replay that ourselves and that's going to be something that I'm also going to attempt to demonstrate so again users still here trying to fill out their their form password they're going to be there a while so 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 is going quick, lightning fast from the attackers console we've now all of these potential OAuth sessions so if I for example open co-pen in a new incognito window theoretically good that bit works, yep brilliant I'm now logged into co-pen I'm being their icon there keep going we've got loads of other services so for example developer.mosello got that account someone's of interest so we've done if anyone's used foreshed before but it's a cloud storage platform so we can grab that and then start grabbing their files from that platform and we've got full control of these accounts at this point so we're just logged in as if we were those users don't know who's going well now back to the slides so this is this could be done passively we could wait for a user to log in but as Paul mentioned we're kind of impatient so we can force this and if you're only using the 302 lookups you can actually force a large number of authentication attempts against a large number of services very very quickly the user won't see anything necessarily when they go to log back into that service but in our experience they won't see failed login attempt to this or anything else so it's pretty blind from the user side of things and it does allow attackers to gain full control over the victim account okay so we've shown you a few demos which we're quite pleased with but we want to go even further so we've still learned some of the kind of accounts that most people don't care about I mean you tend to use a wolf for things you can't be bothered to create an account but we want to go off to the good stuff so we're going to attempt to get into your google account now so the way that google works is quite interesting they have lots of different domains so you can't share cookies between top level domains so what happens is that when you log into google most of your cookies go on to the main google.com domain and when you go to another website like youtube or blogger or one of the regional google search sites then there will be a first party SSO so it will use say google.co.uk it will ask the main site for an all token and it will use a three or two redirects so we can steal that so like this so it will go accounts.google.com please log me into google.co.uk and it will say okay you're logged in that's fine here's a redirect here's an all token and it will go and set the cookies on the local site so and then it will log into google.co.uk the second thing the second demo we're going to see is stealing stuff from google drive so again when you download stuff from google drive there's a few different ways it works depending on how you got the file so we're looking in this case at files which have been emailed to you and that you saved to your google drive so what happens when you click to download the document is you start off from drive.google.com and then it will redirect it will redirect to googleusercontent.com which is unauthenticated but uses an all token and it kind of does this a couple of redirects back and forth between the two different sites but eventually we can get the all token essentially and download the documents so I'm going to show you that demo I should point out that none of these are vulnerabilities in like google or any of those are all sites this is just because we can steal the HTTPS URLs okay so I'm going to click this button and we'll see there we go so we can see the URL here it's got the all 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.co.uk oop so like I said this isn't your main google account so we haven't got like the crown jewels but we can still do quite a lot of stuff so if I search for like my email I can't type 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 a summary I can do my photos I can do my home address there we go I can do my location my location is working okay but another thing we can do if you happen to have location history turned on on your phone then google is basically tracking everywhere you go because google maps is again regional it's not the main google.com site you can go to your timeline come on stop working it's taking a while you can see everywhere we've been in Vegas all the various places we've been so and where do we go today that's being a bit slow but anyway we thought that was quite nice right we've got to get on okay so I'll hand it back to Google Drive demo quickly oh Google Drive yes thank you right okay 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 the bottom and now the attacker server is going to download those to the server and then we can load some of these things how do you middle click right so yeah so you know if you save some passwords to your account that's a pdf that's someone else and that's some passwords there great so that last demo that was all Paul's work he spent ages doing that and I thought well I can't let him have the best demo this talk so I spent a little while looking around thought I'd target Facebook it's got to be aware 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 so I don't have a demo 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 signed up to Facebook with a Microsoft account you can hit forgot 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 let's just gateway with the user connection 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 HTTPs URLs or they can't insert traffic 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 up 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 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 proxy so if we stick our proxy server on the internet as well we've now got the users traffic coming out of their VPN endpoint leaking the HTTPs URLs to our 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 traffic is tunneled all the way from the VPN endpoint through our proxy on the internet before it hits the intended destination so the effect of software on this OpenVPN is effected, 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 OpenVPN 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 OpenVPN they have fixed it their clients based on OpenVPN but they've implemented a client side fix to disable WPAD to fix this and more corporate VPN solutions for example Cisco AnyConnect actually have an option to say push your own proxy or completely wipe all proxy settings before coming this way the windows built in VPN clients aren't vulnerable to this they actually look like they've thought about this issue and have disabled WPAD by default on these LTTP and PPTP connections speaks for itself so Paul's third work of art they are the rejected vulnerability title for this issue so the next response so I don't use windows yeah actually other operating systems do use WPAD 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 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 organisations will need to do turn off WPAD and configure an explicit URL for your PAC script 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 put 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 then it effectively misgates this issue we can't chain proxies using PAC as far as we're aware or if the VPN server pushes an 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 it so Apple came out pretty quick releasing fixes for OSX and iOS and Apple TV didn't know they still did that but 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 on Windows 10 it does some really funky caching stuff so it's really not quite as big as a deal with that how long we got run 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 hope I'm pronouncing that right Bass Venice sorry reported this issue to Google and Firefox literally two weeks after we did so plenty of people looking 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 and there was a stack overload question from May last year outlining this issue lots of people have found this nobody reported it to the vendors interesting not sure if we've got time for that slide so to summarise network-based attackers can inject pack scripts into browsers pack scripts can leak all H2S URLs via DNS to an attacker at least on un-packed systems we showed how to de-anonymise users steal our auth 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 so we'll be on github just watch our Twitter feeds and we'll let you know when we've released it if you're interested