VPN users unmasked by zero-day vulnerability in Virgin Media routers

>"published details of the flaw nearly two years after first alerting Virgin Media"

Two Years !! - Ja this just makes me mad !

Sure security issues happen to the best of them and us, but dammit being alerted to this and just ignoring it, tells you EXACTLY the level of competence of management and their commitment to YOUR data.

If I may add a few data points, I recently had a look at some of the ISPs in my country, just "basic level stuff". I'm by no means a PEN-Tester. This is what I found:

1. ISP A

1.1 CLIENT-Side Localstorage, no validation: Thus if you are signed in, goto localstorage and change 'user-id:123' to 'user-id:456' - Congrats you are now logged in as user:456

1.2 All API's where you can pass in a user-id, did not check if you are allowed. Thus you can do "/api/getuserinfo/"

1.3 Same API, also brings back HASHED-PW and HASHED-PIN, I thought it was strange but what's the chance one can "crack" SHA on a PC these days, especially with 'proper' password libraries like bCrypt/Salt. Turns out there were NO SALTs added to hashed pw and it was SHA-256. Hashcat makes quick work of most passwords.

PS was also "funny" how they "HASHED" the PIN (4 digit value) that was also returned in API response. If you think hashcat is fast with passwords, you know how fast it is to test the hash-values for [0000-9999] :)

1.4 Time to respond: I managed to have a phone call with the CEO which at least sounded (I do think the response was 100% sincere) UPSET, WORRIED and asked that I send him all the info and recommendations I have.

Good response to a bad situation ! - Well done.

2. ISP B

2.1 Hmmm seems someone deployed a part of a .git folder to their website.. Only .git/INDEX and .git/HEAD were deployed but it was very easy to reconstruct the "commits/changesets" with something like GitTools and discovered part of the changesets was when they were doing lead generation via facebook and their CRM system. API keys were all hard coded and visible in changeset.(source code) Thus using the API keys one has access to their whole CRM it seems.

2.2 Company Response: Managed to track down CEO via LinkedIn, super nice guy and it's a BIG ISP. He was very upset about security and super thankful for my "responsible disclosure" he CC'd most of his exec-committee. CTO, InfoSec, COO and operations team. He's parting words. "I hope someday we can help you as well" ! Well done

3. ISP C

3.1 Wow they were/are just terrible. They have unauthenticated AJAX calls for their “account-pages,billing details, router details”. You ONLY had to “guess” the account number (very predictable account numbering scheme)

3.2 Company Response: Spent a few days tracking down their contact details. Managed to find their emails for CEO, COO, and a few other “CxO” people. I emailed them about the security on their site. Do they have an InfoSec team or where should I send the details to ? He responded to send it to him (so we know the email address works). After sending proof and details of their complete lack of security I got zero response. After TWO weeks I followed up with the CEO and he only replied (send me your contact number, no phone call yet) but they did seem to fix the security issues only once I followed up.

Why is the web browser allowing the Javascript program to access a different server than the one it was loaded from? They call this a "DNS rebinding attack", and it seems it could compromise any router that doesn't have a password set, not just this router? So isn't the real problem here the browser running untrusted code and giving it access to your local network because it didn't check if the DNS had changed?

Comcast makes you downgrade to a business account if you want to get a reverse DNS entry from them. Reverse DNS is a requirement if you want to host your own e-mail and not have your mail categorized as spam. Comcast business accounts don't allow you to use your own DOCSIS modem.

As one of those edge cases im glad I don't use their router and I am even happier that doing so makes them sad.

Jails/Containers should be fine as well.

Just need to make sure host applications don't see the network interface provided by the VPN gateway, so they don't accidentally leak it (linking it to your real IP). A typical example are browsers when using WebRTC.