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.
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.
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.
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 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.
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.
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)