Silently Unmasking Virgin Media VPN Users in Seconds (CVE-2019-16651)
Introduction
Fidus’ R&D team identified a vulnerability within Virgin Media Super Hub 3 routers that permitted for exfiltration of sensitive information remotely, which, among other things, can be used to determine the actual, ISP issued IP address of VPN users. A vulnerability we were asked to hold back from releasing for a whole year.
A DNS rebinding attack is utilised to reveal a user’s actual IP address by simply visiting a webpage for a few seconds. This has been made graphical for Proof of Concept purposes, but it is important to note this can be silently executed. During our testing, it was possible to unmask the true IP address of users across multiple popular VPN providers – resulting in complete deanonymisation.
The underlying model of router (ARRIS TG2492) and related models are a series of DOCSIS fibre routers known to be used by multiple ISPs around the world, many of which are owned by Liberty Global, who also owns Virgin Media.
Initial Investigation
The router’s web page can give us many clues about how the device works; by just logging in to the page and watching the network traffic in our browser’s developer tools, we can learn a few things.
Just looking at the requests, we can see it is using a web wrapper for SNMP. We can get and walk object identifiers (OIDs) using these endpoints. From the two parameters we can see we have a 5 digit nonce and a time based variable. To call these we also need a valid credential cookie which we will touch on later.
Looking at the response from one of the walk commands it looks to do what you would expect, finding all the children of the requested OID(s) and returning their values, also including a finish value. Armed with this knowledge we should be able to use this endpoint to find interesting objects for us.
Calling the walk endpoint with the OID of 1.3 returns roughly 16000 values. The problem is we do not know what the majority are, but we can make guesses based on their values, and we could even set values ourselves to see what changes. However, the pages JavaScript has a nice list of OIDs and a descriptive name for them.
Even better, there is a built-in function to decode an OID, so we could just run our list through this rather than doing anything clever to get it all from the JavaScript. Not all of the objects have descriptive names, and quite a few do not have a name we can access at all, but it helps us understand which object is for what.
Now we have a nice list of the objects, their names and example values, we can look for interesting objects, but we would also like to have a list of any objects that didn’t require authentication (or even a nonce value as we found out later on). An easy way to get this is to write a quick script to attempt to get the value for each object and log it if it was successful.
We get roughly 60 values which we can just read without authentication. Looking these up against our list of names, the vast majority are not that interesting, but there is a small number in there which are of concern.
Exploitation
What can be noted instantly is a decoded value titled “WanCurrentIPAddr.1” and, as the name suggests, it contains our external IP address in a hex format.
We know from our script by just loading this page, we can get the external IP; getting this information when you are already on the network is rarely going to be useful, but if an external webpage could access this, such as when connected to a VPN, it could deanonymise the connection. Now we needed a way to both call the internal webpage and retrieve the data, all while being an external entity, and this is where our DNS rebinding attack becomes useful.
The Attack
DNS Rebinding is an attack where a domain changes its IP address while a page from that domain is still loaded. To configure this, our domain has an extremely short TTL, so the browser needs to make another DNS request only a few seconds later to get the IP again (one method used in a DNS rebinding attack). When this happens, the browser loads the page with our JavaScript payload. The JavaScript requests our domain again but with a path to “/snmpGet?oid=1.3.6.1.4.1.4115.1.20.1.1.1.7.1.3.1” which will get the external IP (from the SNMP OIDs). As the TTL is so short, it asks the DNS server again for the IP address of the server. This time we have it set up to return our attack IP (192.168.0.1 in our case), so when our JavaScript requests the page, it gets the router’s response.
The whole attack takes a matter of seconds, so a user’s actual underlying IP address can be unmasked by simply visiting a URL, as demonstrated below.
Proof of Concept
We tested the exploit with a few VPNs to confirm its validity and while some VPN providers block access to local IP addresses by default (which prevents this attack), many did not. As shown in the image above, our PoC works against a very well known VPN service, but it’s important to note this is not the only VPN provider which suffers from this issue. The window on the right and inside the VPN client you can see our VPN IP address, and on the left you can see the true, deanonymised, IP address.
The video below demonstrates the attack, along with the speed in which the attack can be carried out. For PoC purposes, the video has an interactive GUI, but in a real-world scenario, this attack can be launched silently on a completely legitimate-looking webpage without the user’s knowledge.
Timeline
20th October 2019 – Issue reported
22nd October 2019 – Issue acknowledged
18th December 2019 – Requested an update from Virgin/Liberty Global
19th December 2019 – Issue acknowledged again
17th Feburary 2020 – Requested an update from Virgin/Liberty Global
21st February 2020 – Liberty Global requested a phone call, and subsequently requested holding back on public disclosure until Q1 2021 to which we agreed to.
9th December 2020 – Requested an update from Virgin/Liberty Global (no response)
21st December 2020 – Requested an update from Virgin/Liberty Global prior to disclosure in Q1 2021 (no response)
15th March 2021 – Requested an update from Virgin/Liberty Global prior to upcoming disclosure (no response)