A Glance through the VPN Looking Glass:IPv6 Leakage and DNS Hijacking inCommercial VPN clientsAbstract: Commercial Virtual Private Network (VPN) ser-vices have become a popular and convenient technology forusers seeking privacy and anonymity. They have been appliedto a wide range of use cases, with commercial providers of-ten making bold claims regarding their ability to fulfil eachof these needs, e.g., censorship circumvention, anonymity andprotection from monitoring and tracking. However, as of yet,the claims made by these providers have not received a suf-ficiently detailed scrutiny. This paper thus investigates theclaims of privacy and anonymity in commercial VPN services.We analyse 14 of the most popular ones, inspecting their inter-nals and their infrastructures. Despite being a known issue, ourexperimental study reveals that the majority of VPN servicessuffer from IPv6 traffic leakage. The work is extended by de-veloping more sophisticated DNS hijacking attacks that allowall traffic to be transparently captured. We conclude discussinga range of best practices and countermeasures that can addressthese vulnerabilities.Keywords: VPN, IPV6, DNS hijacking1 IntroductionRecent revelations regarding massive surveillance projects [1]and the restrictions that some governments impose on theircitizens [2–4] have increased the general public’s concern re-garding untrusted or malicious parties observing and/or ma-nipulating user communications. This has contributed to a*Corresponding Author: Vasile C. Perta: Sapienza University ofRome, E-mail: perta@di.uniroma1.itMarco V. Barbera: Sapienza University of Rome, E-mail: bar-bera@di.uniroma1.itGareth Tyson: Queen Mary University of London, E-mail:gareth.tyson@qmul.ac.ukHamed Haddadi1:Queen Mary University of London, E-mail:hamed.haddadi@qmul.ac.uk. This work was done while the author wasat Qatar Computing Research Institute.Alessandro Mei2:Sapienza University of Rome, E-mail:mei@di.uniroma1.it. This work has been partially supported by a GoogleFaculty Research Grant 2013.rise in the popularity of tools promising end-users a pri-vate and/or anonymous online experience [5–9]. Among them,VPN-based solutions are receiving an increasing amount of at-tention [8, 10, 11]. In fact, the market today is littered with anumber of low-cost commercial VPN services, claiming to beable to enhance user security and privacy, or even to provideanonymity, by tunneling their Internet traffic in an encryptedform to an (ideally) trusted remote endpoint.There are several use cases that may have contributed tothis spike in popularity. For example, the use of public net-works has increased dramatically in-line with the expansionof the mobile device market. Such infrastructures are ripefor attack (e.g., stealing credentials, snooping, session hijack-ing [12–14]), leading some users to securely direct their traf-fic through a VPN tunnel as a solution for safeguarding theirinteractions [15]. Other users may be attracted by VPN tun-nel encryption as a way to avoid unwanted attention, or sim-ply to hide their actions from their ISP or other passive ob-servers. Others turn to VPN services for more pragmatic rea-sons, wishing to circumvent Internet censorship by tunnel-ing through firewalls [16], or accessing content that is eitherblocked by their ISP or restricted based on a country’s IP ad-dresses (e.g., BBC iPlayer, Hulu, Netflix). In response to thelatter, many VPN services allow users to select their exit pointsso that they can gain IP addresses in a number of differentcountries or administrative domains. Finally VPN services arewidely used by citizens facing government-supported large-scale Internet censorships events, as revealed by recent stud-ies [3, 4].All commercial VPN service providers support the aboveuse cases to some extent, although their capability to preserveuser privacy and anonymity has already raised some ques-tions [17]. In fact, a common misconception is that the word“private” in the VPN initialism is related to the end-user’s pri-vacy, rather than to the interconnection of private networks.In reality, privacy and anonymity are features that are hardto obtain, requiring a careful mix of technologies and bestpractices that directly address a well-defined adversarial/threatmodel [5, 17]. In other words, there is no silver bullet withinthis domain. For instance, it is clear that simply tunneling traf-fic through a VPN cannot provide the same anonymity guar-antees of more rigorous (and vetted) systems such as Tor [5].A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 2This does not come as a surprise, as VPNs were not originallyintended to provide anonymity and/or privacy.Still, the appeal that these services have for the generalpublic is very high, perhaps because of their ease of use, theirrelatively high performance, their effective marketing strate-gies, and the bold statements the providers make, though inabsence of objective evidence in their support. The resultingblind faith that uninformed users may put into these servicesis thus a worrisome problem that has to be tackled effectivelyand rapidly.Within this context, we contribute by shedding light onthe privacy and anonymity features of the popular commercialVPN services available today on the market. We use an ex-perimental approach, subscribing to 14 services, downloadingtheir recommended clients on both desktop and mobile sys-tems, and testing them in our lab. Our findings confirm thecriticality of the current situation: many of these providers leakall, or a critical part of the user traffic in mildly adversarial en-vironments. The reasons for these failings are diverse, not leastthe poorly defined, poorly explored nature of VPN usage, re-quirements and threat models.This paper is organised as follows. We first survey thetunneling technologies most commonly used by VPN serviceproviders (§ 2), finding that many still rely on outdated tech-nologies such as PPTP (with MS-CHAPv2), that can be easilybroken through brute-force attacks [18]. We then show thatthe vast majority of commercial VPNs clients suffer from dataleakage in dual stack networks (i.e., those supporting bothIPv4 and IPv6), sending large amounts of traffic over the nativeinterface, unbeknown to the user (§ 3). By exploring variousapplications, websites and operating systems, we show thatsignificant amounts of traffic are therefore exposed to publicdetection, while users retain the belief that all their interactionsare securely occurring over the tunnel (§ 4). Most importantly,we find that the small amount of IPv6 traffic leaking outside ofthe VPN tunnel has the potential to actually expose the wholeuser browsing history even on IPv4 only websites. We furtherextend this analysis by delineating a DNS hijacking attack thatexploits another key vulnerability in many VPN configurations(§ 5). Through this attack, a substantial amount of IPv4 trafficcan be leaked from the VPN tunnel too.It is important to note that, worryingly, the insecurity ofPPTP (with MS-CHAPv2), as well as IPv6 and DNS leakagein VPNs are not new to the community [17–20]. Despite this,our study reveals that many commercial VPN services still failto properly secure user traffic. These low-cost solutions there-fore raise many questions in terms of trust and reliability. Tothe best of our knowledge, we are the first to offer quantifiedinformation on the severity of this issue, as well as straightfor-ward countermeasures (§ 6).2 Commercial VPN servicesWe begin by surveying a number of commercial VPN servicesto understand their infrastructures and technologies.2.1 Overview of Commercial VPN serviceprovidersA large range of commercial VPN services exists today. Wetherefore begin our study by performing an analysis of themarket, registering credentials with 14 services. This set hasbeen selected due to their widespread popularity and adver-tised features. All the experiments were carried out during theperiod September – December, 2014. Given the impossibilityof objectively measuring it, popularity was approximated withthe number of times each VPN service was mentioned in thefirst 20 Google results corresponding to queries such as “BestVPN” or “Anonymous VPN”. The idea was to identify the sub-set of providers that the average user would be most likely topurchase, based on public reviews, forum mentions, and so on.Our selection was further augmented with VPN services that,although not among the most popular, advertised distinctivefeatures that were relevant to our study. These include Mull-vad, which to the best of our knowledge is the only providermentioning IPv6 leakage protection; Hotspot Shield, promis-ing WiFi security in untrusted hotspots; and TorGuard, whichexplicitly targets BitTorrent users. Table 1 lists the providersselected.2.2 VPN service infrastructureWe next briefly explore the infrastructures used by commercialVPN services, as observed from our experiments. As Table 1shows, the number of available servers (exit points) can varysignificantly across providers, ranging from several hundredsof the top 4 down to less than 10 (a small number of serverscould indicate the capability of dynamically adding more re-sources, based on the service utilisation). Figure 1 presents thedistribution of exit points across countries, highlighting a sig-nificant bias towards the United States (US). This is probablyrelated to the amount of content that is only accessible fromthe US, e.g., Hulu, Showtime Anytime, HBO GO. Countrieswith strict privacy laws (e.g., Netherlands) also seem attractiveas VPN tunnel exit points, perhaps driven by users concernedabout anonymity.The distribution of servers across Autonomous Systems(ASes) can also be inspected. A large number of ASes andhosting services are involved in VPN provision. In total, thereA Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 3Provider Countries Servers Technology DNS IPv6-leak DNS hijackingHide My Ass 62 641 OpenVPN, PPTP OpenDNS Y YIPVanish 51 135 OpenVPN Private Y YAstrill 49 163 OpenVPN, L2TP, PPTP Private YNExpressVPN 45 71 OpenVPN, L2TP, PPTP Google DNS, Choopa Geo DNS Y YStrongVPN 19 354 OpenVPN, PPTP Private Y YPureVPN 18 131 OpenVPN, L2TP, PPTP OpenDNS, Google DNS, Others Y YTorGuard 17 19 OpenVPN Google DNS NYAirVPN 15 58 OpenVPN Private Y YPrivateInternetAccess 10 18 OpenVPN, L2TP, PPTP Choopa Geo DNS NYVyprVPN 8 42 OpenVPN, L2TP, PPTP Private (VyprDNS) NYTunnelbear 8 8 OpenVPN Google DNS Y YproXPN 4 20 OpenVPN, PPTP Google DNS Y YMullvad 4 16 OpenVPN Private NYHotspot Shield Elite 3 10 OpenVPN Google DNS Y YTable 1. VPN services subject of our study 0 100 200 300 400 500 600 700 800US GB NL CA DE SE FR SG CH LU RU NO IT HK ZA#ServersFig. 1. Countries with most VPN exit locationsare 244 ASes used by just 14 providers. We find that providerstend to place their exit points in a number of different ASes,even on a per-country basis. This might be a resilience de-cision, since it would be non-trivial for snoopers to monitorall exit points. That said, we notice that there is significantco-location in some countries, with several different providersplacing their exit points in a very small number of ASes. Forexample, in Switzerland, 60% of all exit points can be foundin a single AS; investigation of this hosting service revealedvery strong privacy guarantees which may attract VPN ser-vice providers concerned about monitoring issues. Overall,however, the dominant countries (e.g., the US and UK) tendto avoid this level of co-location, perhaps favouring more re-silient placement strategies.2.3 Anonymity featuresWe found the most commonly advertised features to be “Ac-cess to restricted content” and “Anonymity”. Regarding theformer, all providers offer similar capabilities by tunnelinguser traffic towards different countries, although performance,price, and destination numbers may vary. The anonymityclaims, however, seem to be exceedingly vague, which is incontrast with the inherently limited anonymity these servicesare actually capable of providing. This does not come as a sur-prise, as VPNs, as opposed to Tor, were not originally intendedto provide anonymity and/or privacy.More specifically, if the only objective is to conceal theuser IP address from a website, then a VPN may be a viablechoice. For multiple reasons, however, it is questionable thatthese services provide anonymity beyond this minimal objec-tive. First, it is clear that users are not anonymous from theirVPN service provider, which must be blindly trusted to notbe malicious, and to not disclose the user traffic to third par-ties (e.g., through subpoena). The data these providers retainabout their customers exacerbates this problem further. For in-stance, we observed that, at registration time, many VPN ser-vices (even some of those supporting the more anonymous Bit-coin payments) ask for the user’s personal information, or evenfor a valid mobile number. Similarly, a number of them admitthey retain timestamps, the amount of data transmitted, andthe client IP address of each VPN connection. In contrast, inTor no single relay is able to observe traffic at both ends ofa circuit. Also, Tor does not require registration or the pro-viding of any identifying information to download or use itssoftware or network, and Tor nodes promptly remove sessionkeys and any other information about a connection once theconnection is closed. Most importantly, Tor users are not ex-pected to trust the single relays, but, rather, the fact that themajority of resources of the Tor network are not controlled bya single malicious entity.Another way user anonymity may be compromised isthrough end-to-end attacks (e.g., traffic correlation), whichdo not require collaborating with or compromising the VPNservice provider [21–24]. While not sufficient, Tor’s use ofshared, geographically distributed exit points, in combinationwith an exit point rotation policy, has the potential to makeend-to-end attacks harder [24–29]. On the other hand, the com-A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 4mercial VPN services within this study are much easier prey.For instance, in terms of the geographical diversity of their in-frastructure, the sum of all VPN services providers still doesnot match Tor, whose nodes are, as of today, spread across 468different autonomous systems (against 244). Also, we note thatthe client interfaces of the VPN services we tested tend to en-courage users to give priority to connection quality over lo-cation diversity, offering automated server selection based ongeographic proximity and/or network speed, remembering thelatest server used, or even presenting the random server se-lection as an available but “not recommended” option. It istherefore likely that a user will always rely on the same smallsubset of exit servers, making end-to-end attacks far easier.While a thorough analysis of these issues falls outside thefocus of this paper, we wish to highlight the limited practicalprotection that these services are capable of offering againstuser information disclosure or simple traffic correlation at-tacks.2.4 Tunnel setupThe clients of the VPN services we screened support one ormore of the following tunneling protocols: OpenVPN, L2TP(with IPsec) and PPTP. Users are typically given free choiceof the VPN technology to use, except in some cases, wherethe technology of choice is driven by the plan purchased. Forinstance, the cheapest VyprVPN plan only allows PPTP tobe used. We found the relatively large number of providersthat use PPTP to be worrying, as PPTP’s authentication pro-tocol, MS-CHAPv2, is affected by serious security vulner-abilities that have been well-known in the community foryears [18, 30].Once the VPN client has initiated the tunnel using one ofthe above technologies, it creates a virtual network interface(e.g., ppp0 or tun0) and manipulates the host routing tablein order to redirect all the traffic towards it. Traffic that passesthrough the virtual interface gets encrypted and forwarded tothe VPN remote entry point via the host’s active network in-terface (e.g., WiFi or Ethernet). Once these steps have com-pleted, the tunnel is fully initiated and all user traffic shouldbe sent via the VPN in an encrypted form. The above mech-anism holds true across all providers surveyed. The tunnelingprotocols described have already undergone thorough securityanalysis. The remainder of this paper focuses, instead, on thesecond stage of the VPN client’s operation: traffic redirection.Although its use of routing table modification is simple, wenote it exposes VPN users to a number of subtle, but criti-cal, privacy vulnerabilities. The problem stems from the factthat routing tables are a resource that is concurrently managedby the operating system, which is unaware of the security re-quirements of the VPN client. Specifically, small changes tothe routing table (both malicious and accidental) could resultin traffic circumventing the VPN tunnel, creating serious dataleakage over other interfaces. The rest of this paper shows howthis fact is sufficient to reconsider many of the claims that VPNservice providers make about their security and anonymityprovisions.2.5 Commercial VPN adversary modelsIn our study, we consider two general types of adversaries forcommercial VPN users. Importantly, both represent the typeof adversary a user would likely wish to avoid via their use ofa VPN service. These are:1. Passive Observer: The adversary operates monitoringpoints within the native network provider used by the vic-tim (or another pertinent location). They wish to gain ac-cess to the traffic, but do not take proactive steps to cir-cumvent the VPN.2. Active Attacker: The adversary controls the point of at-tachment that the victim connects to. This could be theInternet Service Provider (ISP) or, alternatively, a thirdparty offering connectivity (e.g., in a cafe or hotel). Suchan adversary could also masquerade as a trusted WiFi net-work by faking its SSID [12]. They wish to gain accessto the traffic and would take proactive steps to circumventthe VPN.In all cases, the adversary’s objective is to monitor the traf-fic exiting the host, or even manipulate it (e.g., rate limiting,censorship). Several instantiations of these adversaries are fea-sible. For example, governmental agencies wishing to moni-tor civilian activities would be strongly motivated to take onone of these roles. Also, the very same Internet-based servicesaccessed through VPNs (e.g., search engines, social networksites, forums, IRC servers, and so on) may wish to collect iden-tifying attributes of their users, or build a profile of their activ-ities. These adversaries do not represent a comprehensive setof attackers but, rather, a representative sample of importantstakeholders. We use them throughout the rest of the paper tohighlight the uses of the vulnerabilities we have discovered.3 IPv6 VPN Traffic LeakageAll VPN services surveyed rely on the correct configurationof the operating system’s routing table (§ 2.4). Worryingly, noattempt is made to secure this operation, for instance throughmonitoring the routing table to ensure that their initial con-A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 5figuration is not changed. Small changes could therefore un-dermine the security offered by the VPN tunnel. We delay thediscussion of more sophisticated routing table attacks to later(§ 5). Here, we delineate a more alarming vulnerability, requir-ing no accidental or malicious changes to the configuration.The vulnerability is driven by the fact that, whereas allVPN clients manipulate the IPv4 routing table, they tend toignore the IPv6 routing table. No rules are added to redirectIPv6 traffic into the tunnel. This can result in all IPv6 traf-fic bypassing the VPN’s virtual interface. Although not a seri-ous issue some years ago, increasing amounts of traffic is nowIPv6, bringing the problem to criticality [31]. This attack couldbe performed by both adversaries detailed in § 2.5.3.1 Why does IPv6 leakage occur?The vulnerability relies on the nature of IPv4/6 dual stackimplementations on common operating systems. Dual stackshave been introduced to smoothly transition between the twoprotocols (RFC 4213), allowing a network and host to simul-taneously operate both IPv4 and IPv6. The problem emergesbecause common dual stack implementations show preferenceto IPv6 when available (in line with RFC 6724).On dual stack hosts, applications can connect to any re-mote socket using both IPv4 and IPv6 addresses, dependingon which protocol version the remote host supports. To decideupon which to use, the host’s DNS resolver should attempt toretrieve both address types from the DNS server (i.e., both Aand AAAA records). This is what modern address resolutionroutines, such as POSIX’s getaddrinfo [32] do, allow-ing both protocols to coexist (in compliance with RFC 3493).When both IPv4 and IPv6 addresses are returned, the oper-ating system nearly always shows preference to IPv6. Thereare also other techniques that select the best of the two con-nections [33]. However, IPv6 will usually be preferred as theIPv4 VPN tunnel introduces overheads that increase the reso-lution delay. In such cases, the operating system refers to theIPv6 routing table to select the first-hop router, bypassing thechanges made to the IPv4 routing made by the VPN client. AllIPv6 traffic will therefore exit the host via the native (IPv6)network interface, rather than through the VPN tunnel. Thissimple observation is the crux of IPv6 leakage.The above vulnerability occurs whenever a host is con-nected to an IPv6-enabled network. It is important to acknowl-edge two scenarios in this regard. First, a point of attachmentcould accidentally support the leakage by providing IPv6 con-nectivity to a client. This is, of course, dangerous, but the pointof attachment is not actively trying to subvert the VPN tunnel(e.g., this could be a Passive Observer, such as the ISP). Sec-ond, a point of attachment aware of the vulnerability couldintentionally enable the leakage by offering IPv6 connectiv-ity and recording all traffic (e.g., an Active Attacker adversary,such as a malicious WiFi AP). The latter is a serious threat,as the attack can be carried out with modest resources. In fact,an AP with no IPv6 connectivity can be easily configured tocreate a dual-stack WiFi network, as we are going to showshortly (§ 3.2). In reality the adversary does not even need tocontrol the AP. In fact, any malicious client connected to apublic WiFi can easily create a dual-stack network and inject arogue Router Advertisement [34] to attract and record all IPv6traffic.3.2 Which VPN services are vulnerable?To explore how different providers react to the above vulner-ability, we create a simple testbed. A campus dual stack WiFiLAN is used to connect a variety of hosts running the fol-lowing operating systems: Linux (Ubuntu 14.04), Windows(8.1 Pro), OSX (Mavericks), iOS 7, and Android (JellyBean,KitKat). The WiFi access point used is an OpenWrt routerrunning IPv6 through an IPv4 tunnel provided by HurricaneElectric’s Tunnel Broker service [35]. A /64 IPv6 prefix pro-vided by the tunnelbroker is then advertised on the LAN,enabling the clients to configure an IPv6 address throughSLAAC (Stateless Address Autoconfiguration). This config-uration, which may very well be used by a malicious WiFirouter, allows us to transparently monitor all traffic in the net-work in the same way an adversary would.After setting up the network, we test every combinationof operating system and VPN client. Each test is performedby executing a small measurement tool simulating a genericIPv6-enabled web application. The tool connects to port 80 ofthe first address returned by the operating system’s resolverfor the wwww.google.com domain, which is available bothvia IPv4 and IPv6. This is sufficient to explore how IPv6 traf-fic is treated by the operating system and VPN. Under perfectcircumstances, the connection will be performed through theVPN tunnel, and the WiFi access point will only see encryptedVPN traffic.Our tests reveal that all desktop VPN clients tested, exceptfor Private Internet Access, Mullvad and VyprVPN, leak theentirety of IPv6 traffic (Table 1). We confirm that the reasonfor this is the combination of the operating system’s resolverpreference for IPv6 (when available) and the host’s IPv6 rout-ing table being left unchanged by the VPN client. One client,TorGuard, acknowledges this problem by offering the possi-bility of disabling IPv6 traffic (through the advanced settings).However, the option is not enabled by default.Interestingly, we also notice that even VPN clients thatexplicitly change the system’s DNS server to one they controlA Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 6(Table 1), still allow for IPv6 addresses to be returned to theend-host, thus supporting the leakage. In other words, the stepsso far taken by nearly all providers to deal with this problem,if any, are ineffectual. As already mentioned, the only servicesthat are not affected by IPv6 traffic leakage on desktop OSesare Private Internet Access, Mullvad, VyprVPN, and, if explic-itly enabled by the user, TorGuard. During the tunnel setup,their clients completely disable IPv6 on the hosts’ network in-terface(s). This is a rather drastic approach, but it turns out tobe very effective, given the possibility of falling back on IPv4in dual stack networks.A separate discussion must be presented for mobile OSes.We experimentally observed that, on iOS, all tested VPN ser-vices are immune to IPv6-leakage, as IPv6 is completely dis-abled during the VPN tunnel lifetime. On the other hand,we found that the leakage affects all VPN services on An-droid, including Private Internet Access, Mullvad, TorGuardand VyprVPN.4 Measuring the Criticality ofIPv6 LeakageWe quantify the criticality of IPv6 leakage by investigatingthe extent to which actual applications (e.g., Web browsers)are exposed to the attack. We combine a number of datasets toinvestigate this issue from multiple angles. Note that, althoughthis vulnerability only emerges when a host has IPv6 connec-tivity, recent work highlights a significant upward trend, withIPv6 prefixes constituting 60% of new allocations [31]. Enter-prise networks are particularly driving this, yet home networksalso have increasing uptake [36].4.1 How exposed are websites toleakage?Web traffic forms the bulk of Internet transactions. Ar-guably, it is also the most sensitive. The most popular webbrowsers (e.g., Google Chrome, Firefox, Internet Explorer, Sa-fari, Opera) have been natively supporting IPv6 for a while,exposing the browsing of users of vulnerable VPN services.Thus, we begin our analysis by inspecting the Alexa rankingsfor popular websites that are IPv6-enabled. To do so, we per-form AAAA DNS queries against the top 500 websites for ev-ery country. Figure 2 presents the list of top IPv6 websites,alongside how many countries count them among their top500. Overall, we find that 19% of websites support IPv6.A variety of sites are present. Deciding which ones aresensitive (i.e., the ones users would wish to remain anonymous 0 5 10 15 20 25 30 35youtube.comwikipedia.orggoogle.comfacebook.comblogspot.commozilla.orgwikimedia.orgxhamster.comblogger.comgmail.comvk.comgoogle.co.ukprivatehomeclips.comfbcdn.netgoogle.deeuropa.eujava.comgoogle.fryts.rewiktionary.orgnih.govgoo.glfree-tv-video-online.memobile.degoogle.itgoogle.esgoogle.com.trworlddaily.comeztv.itbinarypilot.co#CountriesFig. 2. Topmost popular IPv6-enabled websites, alongside howmany countries count them among their top 500from) is a subjective process. However, we observe variousintuitively sensitive IPv6 websites. These include search en-gines, social networks, blog platforms, adult content providersand illegal video services. It is likely that some users may wantto leverage VPNs to stop these sites from knowing their iden-tity, or from tracing their activities. This wouldn’t be possiblein the case of IPv6 leakage, as all interactions with these siteswould circumvent the VPN tunnel and silently occur over theopen native interface. One solution to intermediate snoopingmight be to use a secure protocol (e.g., HTTPS); in fact, 84%of the domains studied support HTTPS. However, this wouldnot protect the user’s identity from the website owner. Further,even HTTPS traffic may be susceptible to de-anonymisationby analytics tools [37, 38], or man in the middle attacks en-abled by the data leakage (e.g., sslstrip [39]). At the veryleast, this would allow a passive observer to discover whichHTTPS websites the user is viewing (with 90% accuracy [37]).4.1.1 IPv4 browsing history leakageSo far, the discussion has exclusively focused on websites thatoperate over IPv6. Although these are often big players (e.g.,Google, Facebook, Wikipedia), one could argue that they onlyrepresent a relatively small portion of the web, which stillsolely relies on IPv4. Unfortunately, this leaked IPv6 trafficcan be extremely harmful for the user privacy, as we discussnow.During our experiments we observed that the majorityof websites also embed a number of third party “plug-ins”(e.g., ad brokers, trackers, analytics tools, social media plug-ins). The large diffusion of these objects has already raisedconcerns about a decreasing number of external, large entitiesbeing able to get a detailed view of the web browsing activ-ity of all the Internet users [40–42]. A substantial contributionto this leakage is the Referer HTTP header, disclosing theexact URL of the visited page in the fetches of each of thethird party objects embedded in it. If just a single one of theseA Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 7 0 50 100 150 200 250 300 350 400google-analytics.comgoogleads.g.doubleclick.netpagead2.googlesyndication.comconnect.facebook.netstatic.ak.facebook.comfacebook.comajax.googleapis.comgoogle.comgoogletagservices.comfonts.googleapis.comgstatic.comgoogle.co.ukads.yahoo.comgoogletagmanager.commc.yandex.rui1.ytimg.coms.ytimg.comyoutube.comtns-counter.ruvk.com#Leaked websitesFig. 3. Top third-parties that leak IPv4-only websites through theReferer header. 92% of the Alexa top 1K IPv4-only websitesembed objects of at least 1 of these third parties.fetches were to happen outside of the VPN tunnel (throughIPv6 leakage), the actual user IP would be revealed to the rele-vant third-party, and, perhaps most importantly, the Refererheader would reveal the page the victim is visiting to any otherPassive Adversary.To quantify this phenomenon, we study the number ofIPv6 third party objects that the Alexa [43] top 1K IPv4-onlywebsites embed. The crawling was automated using the Sele-nium WebDriver [44]. The results reveal that IPv6 third partyobjects are extremely common. In fact, 92% of the pages westudied contained at least one of them, exacerbating the leak-age hugely. Figure 3 presents the top third parties these objectsbelong to. As expected, these include various mainstream or-ganisations, such as Google, Facebook, and Yahoo, which areamong the early IPv6 adopters.4.2 How exposed is mobile traffic toleakage?Considering the amount sensitive data stored in smartphones,it is critical to understand the level of exposure that mobileusers have to IPv6 leakage. The issue is even more criticalconsidering that, according to our experiments, all of the VPNservices we tested on Android leak IPv6 (§ 3.2). The sameobservations about web browsing leakage we did in § 4.1 thusapply to Android web browsing too.In order to investigate the existence of other, less obvi-ous sources of leakage, we test the top 100 most popular ap-plications available on the Android Market, fetched using anunofficial Google Play API [45]. In our experiments, we usethe dual stack OpenWrt testbed described in § 3.2: We con-nect an Android device running a VPN client and monitor, inturn, the network traffic generated by each app for 5 minutes.Note that we only use one exemplary VPN service becauseour experiments show that they all leak in the same manner.Our measurements revealed that, similar to what we observedfor websites, almost all apps we tested (80%) indirectly leaksensitive information through third party plug-ins: namely, theembedded advertisements. It is interesting to note that, amongthe apps surveyed, we found that Google’s DoubleClick is theonly advertisement engine that supports IPv6. This does notmitigate the leakage, though, as, recently, Viennot et al. [46]found that 75% of all Android apps include Google ad li-braries, which suggests that all these apps are exposed to theleakage. Also, unlike other Google traffic, advertisements arealways served in the clear via HTTP, allowing passive moni-toring to easily occur.Unlike web-based advertisements, we also observe a re-markable amount of information contained with mobile adfetches. For instance, depending on the application requestingthe advertisement, various sensitive data is exposed, includingapplication name, language, location, mobile carrier used, etc..In addition, the ads are sent very frequently (e.g., every 10 sec-onds) which may even make it possible to monitor app usageover time, and accurately profile the user. Moreover, Castellu-cia et al. [47] show that by just observing Google advertise-ments, an attacker can reconstruct a target user profile withhigh accuracy.4.3 How exposed is peer-to-peer toleakage?Anecdotally, VPN services are popular among peer-to-peerusers wishing to anonymise their downloads. The open natureof these systems allow us to explore this hypothesis by measur-ing how many BitTorrent IP addresses belong to VPN serviceprovider exit points. Note that we do not collect any sensitivedata that could be attributed to individual users (particularly asuser IP addresses often change over time). Our analysis onlyfocuses on aggregated statistics rather than individual user ac-tivity. To further ensure this, the exact content shared by userswas not recorded. Rather, we used the tracker’s labels to cate-gorize each torrent to a particular content (e.g., “Movies”). Inaddition, all collected data was deleted after the analysis.We have performed several crawls of the most popularBitTorrent site, Piratebay, collecting information on 33.5K tor-rents. Whenever a new torrent was published, we repeatedlydownloaded its peer list every 5 minutes from the tracker.This collected 2.7M unique IP addresses. We then checked ifthese addresses were registered with any of the VPN serviceproviders presented in § 2. Note, however, that this is a lowerestimate because we do not possess a comprehensive list of allVPN exit points in the world.A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 8 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.02 0.04 0.06 0.08 0.1CDFFraction of IPs in Torrent from VPNAllAudioPornVideoApplicationsOtherFig. 4. Fraction of VPN users in swarmsCountry # IPv6 # Peers % IPv6 # IPv6 # Peers % IPv629-06-2014 04-03-2014US 4281 31429 13.62% 10148 33212 30.56%Germany 29 303 9.57% 90 239 37.66%Malaysia 111 2137 5.19% 97 989 9.81%France 95 2516 3.78% 631 2011 31.38%Japan 12 400 3% 31 197 15.74%China 13 557 2.33% 59 305 19.34%Table 2. Top Countries for Native IPv6 Deployment in BitTorrentFigure 4 presents the fraction of IP addresses in eachswarm that originate from a known VPN exit point (as a CDF).The number of VPN users varies heavily across the differentswarms: Diversity can be observed between different contentcategories, as well as within individual categories. In total, wefind that 1.2% of trace entries come from known VPN exitpoints. We also note that some categories have a higher ten-dency towards VPN services than others. For example, ap-proximately half of all pornographic torrents contain at leastone VPN user. Another interesting point is that VPN users par-ticipate in BitTorrent swarms for longer than non-VPN users.As a proportion, they are witnessed in our logs more than 3times as often as non-VPN users.All of these VPN service users are therefore potentiallyleaking IPv6 traffic, via both BitTorrent and HTTP. Unfortu-nately, our traces cannot reveal which users also use IPv6, aswe only observe their VPN tunnel exit address at the tracker.Consequently, we turn to [48], which publicly reports the num-ber of IPv6 BitTorrent peers per country, using the methodol-ogy detailed in [49]. Table 2 presents the results for the lasttwo measurement periods. It shows that some countries havea significant IPv6 presence, most notably the US. Such re-gions would therefore be extremely vulnerable to IPv6 leak-age. Many popular clients, including Vuze and µtorrent, al-ready support IPv6, which means this value will increase assoon as native networks introduce support.5 Strong Adversary: Hijackingthe DNSA key assumption of the above vulnerability is that the host isconnected to an IPv6-enabled network. This network could bean unaware ISP or, alternatively, a malicious access point con-sciously trying to acquire leaked IPv6 traffic. In either case,only IPv6 traffic is vulnerable. We next discuss a more con-certed attack, which attempts to create DNS leakage, subvert-ing the resolution of a host’s DNS queries. Through this, theadversary can resolve all DNS queries to its own local proxies,bypassing the VPN tunnel and gaining control over both IPv4and IPv6 traffic.To date, in the context of VPNs, DNS leakage has mostlybeen related to Windows systems. In particular, Windows doesnot have the concept of global DNS settings, rather, each net-work interface can specify its own DNS. Due to the way Win-dows processes a DNS resolution [50], any delay in a responsefrom the VPN tunnel may trigger another DNS query from adifferent interface, thus resulting in a leak. In this section, weextend this vulnerability to other platforms (Linux, Android,OSX, iOS) and define a novel attack that allows an adversaryto hijack the DNS traffic of many VPN services, even for thosewhose client explicitly sets a custom DNS server.5.1 DNS configuration primerThe DNS hijacking attack works by manipulating a host intoredirecting its DNS queries to an adversary-controlled server.Despite the criticality of the DNS resolution process, we foundthat most VPN services do not take significant steps to secureit. We broadly classify the observed DNS configurations intothree types (see Table 1):1. Default: Under certain configurations, some VPN clientsdo not change the DNS settings, leaving the host’s exist-ing DNS server as the default. For instance, we observedthat the desktop version of HideMyAss (v1.17) does notset a custom DNS when using OpenVPN.2. VPN Managed - Third-party DNS: Most VPN clientsoverride the DNS server settings during setup. Among the14 VPN service providers we analysed, we found that 8use third party DNS servers, namely OpenDNS, GoogleDNS and Choopa Geo DNS.3. VPN Managed - Private DNS: We found that 6 VPN ser-vice providers operate their own private DNS service.From the perspective of an attacker, these three configurationsrepresent varying levels of difficulty. However, as shown be-low, all can be overcome. In this attack we assume the ad-A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 9Fig. 5. Hijacking the DNS through a route injection attack (OpenVPN tunnels)versary controls the network’s gateway (e.g., the WiFi accesspoint). Note that this assumption is not restrictive, as it fallswithin the typical threat model of commercial VPN services(e.g., securing communications in an untrusted wireless net-work).5.2 Hijacking default DNS configurationsThe simplest scenario is where the VPN client does not changethe victim’s default DNS configuration (e.g., HideMyAss overOpenVPN). In this case, subverting DNS queries is trivial. Theaccess point can simply use DHCP to set the victim’s DNSserver to one that it manages itself. The adversary will thenreceive all DNS queries generated by the host.5.3 Hijacking VPN managedconfigurationsThe next scenario occurs when the VPN client overwrites theexisting DNS configuration with a DNS resolver specified bythe VPN server during the tunnel setup. In such a case, theadversary must take extended steps to hijack the victim’s DNSresolver, this time targeting its routing table. The idea is to trig-ger a configuration change that will make the DNS a local net-work resource, accessible via the LAN rather than through theVPN. This is possible because the VPNs studied operate un-der a split-tunneling mode, where only traffic directed towardsthe public Internet gets forwarded through the VPN tunnel; alllocal hosts (e.g., network printers) are accessed directly. Theway the attack is actually implemented depends on the VPNtunneling protocol used, as they modify the client’s routing ta-ble in different ways. In particular, we found that OpenVPNclients and PPTP/L2TP clients have different ways of config-uring the default routes used to forward the traffic through theVPN tunnel. We therefore discuss the two possible implemen-tations (OpenVPN or PPTP/L2TP tunnels) separately below.5.3.1 OpenVPN tunnels - Route Injection AttackOpenVPN supports both layer-2 and layer-3 tunnels, imple-mented through the tap ant tun virtual interfaces, respectively.Upon tunnel setup, the VPN client needs to set a default route,forwarding the traffic through the secure tunnel. Rather thandeleting the existing default route (set via DHCP), the VPNclient manipulates the host’s routing table by inserting twoprefixes: 0/1 and 128/1, as recommended by the OpenVPNmanual [51]. As these are more specific than the 0/0 defaultroute, all traffic is sent through the tunnel’s virtual interface(usually tun0 or tap0) instead of the host’s native networkinterface. With this configuration, all user DNS queries are se-curely sent to the correct DNS server via the VPN.An outline of the DNS hijacking, through a route injec-tion attack, is depicted in Figure 5. The attacker, who controlsthe access point, first sets a low DHCP lease period (Step 1),forcing the victim to periodically re-request new DHCP in-formation (e.g., after 60 seconds). Through this, the adversarycan use DHCP renewals to manipulate the end-host routingtable at anytime after the VPN tunnel is established. In partic-ular, the gateway option in the DHCP configuration formsA Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 10Fig. 6. Hijacking the DNS (PPTP and L2TP tunnels)the basis of the attack. The access point first creates a new vir-tual interface using the IP address of the VPN’s DNS server.Detecting the VPN service provider used is trivial by passivelymonitoring the remote IP of the tunnel. The provider can thenbe mapped to the DNS server used by that particular serverlocation.After this, when the victim performs a DHCP renewal,the access point sets the victim’s default gateway to thatof the newly created interface (i.e., the DNS server’s IP ad-dress). Upon receiving the new DHCP configuration, the vic-tim first checks if the specified gateway is locally reachable.Using ARP, the client will discover the available (virtual) in-terface created by the access point that has mirrored the DNSserver’s IP address. Following this, the client’s routing tablewill be updated. However, since the new gateway is on a dif-ferent subnet, a new entry is added for this specific IP address(e.g., 209.99.22.53/32 in Step 5). From now on, all DNSqueries will be forwarded directly to the fake interface on theaccess point, rather than through the tunnel. We have con-firmed that this occurs without the VPN clients detecting thechanges.5.3.2 PPTP and L2TP tunnelsWe found the above attack to be ineffectual for PPTP andL2TP tunnels with all VPN service providers studied. The rea-son is that clients set only one default route, 0/0, as opposedto the two routes — 0/1 and 128/1, in the case of OpenVPN.Importantly, before doing this, the existing default route is ei-ther removed or de-prioritised by binding it to the local net-work interface. As such, we find that any route subsequentlyinjected into the routing table by DHCP gateway option getsignored (as it has a lower priority with respect to the defaultroute to the tunnel).A different strategy (depicted in Figure 6) must there-fore be used: The access point assigns the victim an addressin a small bogus subnet that includes the DNS server usedby the VPN. For instance, if the VPN’s DNS server were208.67.222.222, then the victim would be assigned anaddress in the 208.67.222.0/24 subnet (e.g., 208.67.-222.10). This bounds all the traffic towards the subnet, in-cluding that towards the DNS server, to the actual networkinterface (e.g., wlan0) of the victim host. This interface wouldtherefore get priority over the default rule imposed by the VPNclient.Note that this hijacking attack works as well with Open-VPN, although it is more intrusive. In fact, a key differencewith respect to the previous attack is that changing the ad-dress of the victim through a DHCP renewal will temporar-ily disconnect the host from the VPN. This side-effect maybe avoided if the adversary launches the attack pre-emptively,i.e., before the VPN tunnel is actually established, whichwould negate the need to leverage DHCP renewals.Finally, note that the adversary has to be careful in exclud-ing the entry point of the VPN tunnel from the bogus subnet.If that wasn’t the case, the creation of the VPN tunnel wouldfail, increasing the chances that the victim notices the attack.While selecting the bogus subnet is trivial when a third-partyDNS service is being used (e.g., Google DNS in Figure 6),it becomes tricky if the provider uses a private DNS server,as the subnet must contain at least three IPs (i.e., the DNSserver, the gateway, and the victim host). For instance, we ob-served VyprVPN to use custom DNS servers whose addressA Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 11is very close to the VPN entry point (e.g., 138.199.67.53 forthe DNS, and 138.199.67.18 for the entry point). This config-uration makes it impossible to split the two IPs into two dif-ferent subnets, thus thwarting the attack (although perhaps in-voluntarily). Interestingly, no other VPN service using privateDNSes (Table 1) appears to be using this kind of configura-tion. Further, noe that VyprVPN is still vulnerable to the routeinjection attack when OpenVPN is used.5.3.3 Advanced DNS configurations - VyprDNSA separate discussion has to be made for VyprVPN, whoseDNS service – VyprDNS – provides extra security measuresto make sure the configuration is working correctly. In particu-lar, we observed that the tunnel setup fails if the client is usinga different DNS server than the one managed by VyprVPN.By inspecting the traffic with tcpdump, it appears that im-mediately after the secure tunnel is configured, the VPN clientgenerates 3 random domain name lookups, with all of themreturning an error (NXDOMAIN). Importantly, we observedthat whenever these queries are sent to a different DNS server,the VPN connection will be immediately closed. This suggeststhat the client separately contacts the VyprDNS server (usinga bespoke protocol) to verify that the queries were properly re-ceived and answered, and if this is not the case, the VPN clientreports an error and the tunnel setup fails.Despite implementing this advanced DNS feature, we findthat the check is only performed directly after the tunnel hasbeen established. Therefore simply delaying the attack for 60seconds (using the DHCP lease time), these checks can be cir-cumvented. We experimentally confirmed the efficacy of theroute injection attack on VyprVPN when using this delay.5.4 Attack feasibilityBoth versions of the DNS hijacking attack we presented re-quire the adversary to control the DHCP server used by thevictim host (e.g., the WiFi router). We do not deem this as-sumption to be particularly restrictive, as it falls within the typ-ical threat model of commercial VPN services (e.g., securingcommunications in an untrusted wireless network).A second, more restrictive requirement is to know the IPaddress of DNS server in use by the VPN at the victim host.To tackle this, the adversary could passively monitor the client-side IP of the VPN tunnel. This would reveal the VPN serviceused, which could then be mapped to the relative DNS server(e.g., column “DNS” in Table 1). Note that the mapping mayneed to take into consideration location too, as we observedsome providers to use different DNSes in different servers.In the case of PPTP/L2TP DNS hijacking the adversarymay need to guess the DNS server before the VPN is estab-lished. Google DNS and OpenDNS are typically good can-didates, given their popularity (§ 1). This is more challeng-ing when the VPN service provider manages its own privateDNS service. In these cases, historical information about thevictim’s preferred VPN service (and about the correspondingDNS) can be leveraged if the victim has been previously en-countered.Once the victim has been configured to forward its DNSqueries to an adversary-controlled DNS server, traffic to all thedomains resolved by the victim can be circumvented from theVPN. For instance, the adversary can resolve all the domainsto a set of local web caches it operates, thus allowing the ac-cess point to seamlessly monitor all web traffic. Approachessuch as DNSSEC have attempted to mitigate these risks, yetthey are not widely deployed (under 3% of resolvers supportDNSSEC [52]). To avoid detection, the access point couldeven use its own VPN (with the same provider) and forward alltraffic; web-based checks (e.g., using whatismyip.com) wouldtherefore show the VPN exit point’s IP address (limiting sus-picion).5.5 Experimental resultsWe have tested the DNS hijacking against all the VPN clientslisted in Table 1, confirming their efficacy. There were, how-ever, some exceptions. The first one relates to Windows 8,which we found to be resistant to the OpenVPN route injec-tion attack (§ 5.3.1) as a side effect of the way it manages itsrouting tables. More specifically, the gateway option in theDHCP renewal message does not result in a custom rule for theDNS server in the routing table (as opposed to Step 5 in Fig-ure 5). For this reason, DNS queries will still be routed throughthe VPN, thus thwarting the attack. We believe other versionsof Windows to be immune to this attack. Note, however, thatWindows is still vulnerable to the PPTP/L2TP DNS hijacking(§ 5.3.2).More recent versions of Android deserve special atten-tion too. Starting from KitKat (Android 4.4.x), we discoveredthat Android uses firewall rules [53] instead of routing tablechanges to force traffic to be routed through the VPN tunnel.The firewall rules completely cut the device off from the localnetwork, allowing traffic to be only routed through the VPNtunnel, thereby preventing the attack. We stress that, in anycase, Android versions prior to KitKat (e.g., JellyBean) arevulnerable to the DNS hijacking attack, whereas both Jelly-Bean and KitKat (thus, potentially, earlier versions too) arestill vulnerable to IPv6-leakage (§ 3).A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 12Finally, besides VyprVPN (immune to the PPTP/L2TPDNS hijacking § 5.3.2), Astrill VPN deserves a special men-tion too, as it is the only VPN service we tested that is notvulnerable to both versions of DNS hijacking (i.e., OpenVPNand PPTP/L2TP). The reason is that Astrill, by default, sets thesame IP address for both, the DNS server and the VPN tunnelgateway, which makes it impossible for the adversary to pro-duce a split tunnel and fool the victim host into believing thatthe DNS resides in the local network.6 CountermeasuresWe now discuss possible countermeasures for the two vulner-abilities.6.1 IPv6-LeakageThe simplest countermeasure to IPv6 leakage is disabling IPv6traffic on the host. Although feasible in some cases, not allOSes (e.g., Android) allow applications to do this. Further,this can only be a short term solution in the face of expand-ing IPv6 adoption. More sensibly, VPN clients could alter theIPv6 routing table to capture all traffic. As previously men-tioned, the DNS resolver also plays a crucial role; disablingAAAA queries would likely have a similar effect (althoughthis would leave other resolver systems vulnerable, e.g., Bit-Torrent trackers that support IPv6). Servers can also assist byexclusively using encrypted communications; this, for exam-ple, is the trajectory of Google [54]. However, this would notdeal with all threats, as leakage would still occur.6.2 DNS hijackingTo detect DNS hijacking attacks, an approach similar to theSmartDNS could be used. Unlike VyprVPN, though, the clientshould check the correct functioning of the DNS repeatedly(e.g., every minute), instead of just at the tunnel’s initiation.Still, there is always a chance for the client to detect the at-tack after user information has already leaked (even with finegrained intervals). A similar issue might affect any solutionthat monitors the host’s routing tables for changes. We thusargue VPN clients should adopt more proactive solutions.A viable option is that implemented on Android KitKat,that is, the use of firewall rules instead of the routing table totunnel packets through the VPN tunnel. However, completelyisolating the end-host from the local network, like KitKat does,may negatively impact the user experience (e.g., this wouldleave the device unable to access any local network resource).Plus, the device would not be able to handle DHCP lease re-newals, possibly disconnecting it from the Internet.Another effective solution could be to take complete con-trol of the DNS queries by making sure the DNS server canonly be accessed through the tunnel. Configuring the gatewayof the virtual interface to be also the DNS resolver (like As-trill does § 5.5) would make it impossible for the adversary tohijack the DNS queries with our attacks.6.3 TorA solution to the attacks presented in this paper would be thatof preferring Tor over a VPN. To securely tunnel client traf-fic, Tor sets up a local proxy that client applications must beexplicitly configured to use, instead of using virtual networkinterfaces (like VPN clients do § 2.4). Client-to-proxy com-munications happen through the local loop, whereas connec-tions between the local proxy and the Tor network always hap-pen through secure and authenticated TCP sessions (i.e., TLS).DNS queries can be performed directly through Tor, bypass-ing any locally configured DNS server. This operational modethwarts all the attacks presented in this paper. For instance,in the case of dual-stack networks, proxy-to-Tor connectionsthat happen through IPv6 would be secured, preventing pri-vate data leakage in the clear. Similarly, malicious attempts tohijack the host DNS configuration would be ineffective, as Tordoes not use the address resolution mechanism at the host.A key requirement, however, is that client applicationsmust be correctly configured to use the Tor local proxy forall traffic. For instance, if the web browser does not forwardaddress resolution requests to the proxy, an external observerwill learn the user browsing history. For this reason, the rec-ommended Tor client software distribution (the Tor BrowserBundle) includes a pre-configured Firefox that greatly reducesthe risk for accidental leakage. Whether other applications canbe properly “Torified” to achieve strong anonymity must bedecided on a case-by-case basis [55]. In fact, even tunnelingall the application traffic through Tor may not be sufficient toensure anonymity. For instance, some BitTorrent clients areknown to disclose the host IP address directly into the infor-mation they send to the tracker and/or to other peers [56], in-dependently of any attempt to conceal it through Tor or a VPNtunnel.Noteworthy projects are Tails and Whonix [57, 58]. Theselive Linux distributions transparently tunnel all Internet con-nections through Tor, and feature a range of applications(e.g., browser, instant-messenger, mail client) selected andpre-configured with privacy and anonymity in mind. Thesedistributions also aim to leave no trace of user activity on thehost machine, thus thwarting threats such as cold-boot attacksA Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 13and various memory forensic techniques. As such, they rep-resent a viable and vetted option for users looking for hassle-free, system-wide online privacy and anonymity.6.4 Enterprise VPNsDifferently from the commercial VPN services surveyed inthis paper, an enterprise VPN gives individual employees se-cure access to their company network. Although enterpriseVPNs might be exposed to these attacks, we argue that theirimpact is rather limited compared to commercial VPN ser-vices. Importantly, in this scenario, access to corporate re-sources is only possible via the secure tunnel. IPv6 traffic leak-age is therefore not possible, as connections to the corporatenetwork outside the VPN tunnel are not allowed (assuming allconfigurations are done correctly). Instead, hijacking the DNScould leak the names of the resources being accessed withinthe private enterprise network. However, unless the attackerhas detailed knowledge of the corporate network, the nameresolution will fail, and the user will notice the error and even-tually stop using the VPN.7 Related WorkTo the best of our knowledge, Appelbaum et al. [17] were thefirst to provide a taxonomy of design issues that should dis-courage the use of VPN services for achieving privacy andanonymity on the Internet. Among other things, they exper-imentally observed the problem of IPv6 leakage in certainVPNs. We have built on their work to quantify the exact impactof their observations across multiple applications and VPNservice providers. Fazal et al. [59] describe an attack that al-lows a rogue client to penetrate a VPN, exploiting VPN clientswith a dual-NIC (i.e., a WiFi and an Ethernet adapter) in aWiFi LAN. Gont et al. [60] describe a number of practices toprevent security exposures in IPv4 enterprise networks result-ing from the native IPv6-support of general purpose operatingsystems. Among them, they show how a rogue client can im-personate an IPv6 router through Router Advertisement mes-sages, and they discuss the potential of VPN traffic leakage onIPv6 [19].Related to our study about IPv6 leakage (§ 4), Krish-namurthy et al. [40] examine how interconnections betweenvisited sites represent a potential transparent leakage of per-sonal information to third parties. Castelluccia et al. [47] in-stead show how targeted ads expose private user data, allow-ing the accurate reconstruction of user interest profiles. Ole-jnik et al. [61] experimentally study the uniqueness of webbrowsing histories, revealing that a large percentage of usershave unique browsing histories. Perito et al. [62] investigatehow usernames allow multiple service profiles belonging tothe same user to be linked. Eckersley [63] studies web browserfingerprinting. To the best of our knowledge, we are the firstto experimentally show how the most popular VPN servicesavailable today are vulnerable to this attack (§ 3.2), to quan-tify the leakage of popular applications (§ 4), and to study theeffectiveness of two new DNS hijacking attacks (§ 5).8 Conclusions, lessons learnedand future workIn this paper we have presented an experimental evaluation ofcommercial VPN services. Whereas our work initially startedas a general exploration, we soon discovered that a serious vul-nerability, IPv6 traffic leakage, is pervasive across nearly allVPN services. In many cases, we measured the entirety of aclient’s IPv6 traffic being leaked over the native interface. Afurther security screening revealed two DNS hijacking attacksthat allow us to gain access to all of a victim’s traffic. Themost alarming situation is where individuals use VPN servicesto protect themselves from monitoring in oppressive regimes.In such cases, users who believe themselves to be anonymousand secure will be in fact fully exposing their data and onlineactivity footprint. In countries with state-maintained networkinfrastructures, it is likely that such monitors could take on therole of any of our adversarial models.Throughout this study we realised that another worryingaspect of today’s market of VPN services is the large misinfor-mation end users are exposed to, which makes it hard for themto properly tell apart vague and bold claims typical of prod-uct advertisement campaigns with actual facts. For instance,a simple Google query such as “Tor vs VPN” returns, on thetopmost positions, a number of web pages that are not affili-ated with the Tor community in any way, even including onefrom a commercial VPN service provider website stating that,to achieve better privacy protection, a VPN service is likely abetter option with respect to Tor.In order to improve the current situation it is of primaryimportance to better reach out to the general public throughactive information campaigns. We believe that a more privacyconscious customer base would force VPN service providersto take serious actions towards securing their services andclients against issues that have been known to the communityfor a long time [17, 18]. At the same time, users would be ableto choose the combination of technologies that better suit theirneeds.A Glance through the VPN Looking Glass: IPv6 Leakage and DNS Hijacking in Commercial VPN clients 14We believe providing end-users with easily understand-able proof of the security (or insecurity) of their VPN servicesmay help mitigate this issue further. We will therefore con-tinue analysing the interconnection between the VPN clientand the host operating system, looking for other unusual andunpredictable interactions. In parallel, we will devise new at-tack strategies, so as to better understand how a concerted ef-fort could undermine VPN security. Our long term goal is tointegrate these findings into a user-friendly testing toolkit al-lowing end users to directly and independently measure the“quality and reliability” of their providers.Ethical ConsiderationsMost data we have collected does not raise ethical concerns,as we have primarily probed public services via our own VPNservice accounts. The only exception is our collection of Bit-Torrent users’ IP addresses. This was necessary to quantifythe ubiquity of VPN users; collecting user IP addresses couldnot be avoided as it was our only means to measure the usageof VPNs (by comparing against exit point IPs). Although notideal, we believe it has provided valuable insight into widerprivacy issues amortising the risk. To mitigate this issue, alldata was securely stored and used solely for the aggregatedanalysis shown in Figure 4. All data was subsequently deleted

Python is een krachtige programmeertaal met een grote gebruikersbasis die in veel sectoren wordt gebruikt, waaronder cyberbeveiliging en ethisch hacken.

Hoewel Python niet intrinsiek gebouwd is voor hacken, is het een populaire keuze onder hackers en beveiligingsexperts voor het maken van tools en scripts die helpen bij beveiligingstesten, onderzoek naar kwetsbaarheden en penetratietesten vanwege de eenvoud, rijke bibliotheekondersteuning en grote community.

Hier zijn enkele voorbeelden van hacktoepassingen voor Python:De eenvoudige syntaxis en robuuste bibliotheken van Python maken het de perfecte keuze voor het maken van scripts en het automatiseren van een verscheidenheid aan bewerkingen op het gebied van cyberbeveiliging. Met Python kunnen hackers effectief operaties uitvoeren, van netwerkscanning en verkenning tot het automatiseren van repetitieve taken.