How does Karma's open WiFi network successfully protect its users?

Question

Foreword

This question has a lot of build-up, so please scroll down to the bottom if you just want to see the question. Please at least skim the background info, though.

---

Background

I ordered a Karma Go hotspot with their "Neverstop" unlimited LTE->WiFi plan (no data cap, but 5 Mbps throughput cap). It was an enticing gift for a family member who needs a backup Internet connection because they don't have anything better.

I put in a support ticket with Karma asking them why the 4G Hotspot I paid for is locked into an "Open" WiFi configuration (it expressly disallows setting it up as WPA2 or any other type of encryption). Here was their response:

Right now, Karma Go is an open network that can't be locked. The ability to share WiFi is a big part of what makes Karma unique. Just know that everyone who connects to your Go will need to create their own account and use their own data. You are safe, I promise. No one can use your data or access your account.

Karma Go is secure. Major sites like Google, Facebook, banks all use HTTPS connection, which encrypt your information heavily. As long as you make sure you're on a secure connection, you should have nothing to worry about.

Users connecting to your device will have to create their own account and use their own data. They can't see your data or access your account.

Basically, they claim that this strategy works because of two reasons (the second point is one I thought of myself as a direct consequence of the first):

1. Login: when you first connect to the WiFi network and try to go somewhere over HTTP, you're redirected to an HTTPS-encrypted login site at yourkarma.com. You can't do anything else until you authenticate.

2. Bandwidth (slightly off-topic for security.SE, but hear me out): Each individual user is capped at 5 Mbps, and the LTE network backing the hotspot is capable of significantly more if you have good signal (around 15 - 20 Mbps), so in practice you are fairly unlikely to hit link-level saturation unless you have more than 2-3 users connected simultaneously. This is probably fine for even suburban areas if the first point is airtight.

The first one, Login, is what really worried me. Being the security-conscious person I am, I decided to test the theory.

I developed a hypothesis that either they're:

1. Storing authentication credentials and "doing something to your web browser" (cookie? maybe, if they do JS injection and pass it with every page, but they don't seem to MITM HTTPS) -- most likely what they could do is require your browser to run a proxy over TLS, and authenticate with that proxy on each request. That'd work.

2. Doing horribly insecure MAC whitelisting, and their email reply to me is complete nonsense.

I tested the first method by firing up another browser on the same computer I successfully authenticated on -- Internet Explorer, since my main browser is Firefox -- and tried to connect to google. Sure enough, I didn't get the hotspot login page. So they're not playing with browser settings, proxies, cookies, or any other type of "session-specific" authentication. They must be allowing you to connect via some information in layer 2. But absence of evidence is not evidence of absence; at this point I'm not sure that they're actually doing MAC whitelisting.

So I decided that I'd test option #2, that they're doing MAC whitelisting, with a VM.

I used VMware Workstation 12.0.1 with Ubuntu 15.10.

First, I just switched my VM over to Bridged so it would appear as its own MAC:

I didn't change the MAC at this point; I just turned on the VM. And here's what I got:

OK, so all browsers on my host are now authenticated and blessed, but because the VM has a different MAC, it isn't blessed. Hmm. Now let's try to change the VM's MAC to equal my WiFi dongle's MAC:

1. Get the MAC of the dongle:

2. Put it into the VM:

3. Try Google:

My question, finally

So it appears that this service is vulnerable to MAC spoofing. Given this, is there any way that what the customer service rep said in their email has any truth to it at all, or is it 100% marketing bluff? Is there a security feature in here somewhere that I'm missing?

More evidence of bad security... sigh

Oh, and as a cherry on top, their pre-authentication captive portal blocks OCSP requests, and Chrome says the page also loads insecure resources that could be MITM'ed over the unencrypted wire to do just about anything:

I suppose this means I could inject some JS to rewire the "Login" button to asynchronously submit the request to Karma (to get on the public Internet), then submit the same credentials in the user/pass button to a third-party server, thus stealing the user's login and directly contradicting the email from Karma saying my account is secure. ;o

Answer 1

So it appears that this service is vulnerable to MAC spoofing.

I'm not sure that I see a direct security concern threat here. You've demonstrated that you can bypass their licensing to access the service for free. That's not necessarily a security problem. But as @AndréBorie has pointed out, activity performed by the MAC spoofer will appear to come from you. This could be a problem if the spoofer performs illicit activity.

What seems more problematic is that, according to the getting started page, the Karma Go is an unsecured WiFi access point. That means that it's open to numerous snooping and spoofing attacks. While SSL will provide you with some protection, it is difficult to always use it. Many sites don't have SSL versions or are only partial SSL. You may also have random open ports on your device that can be attacked from elsewhere on the network. Using a VPN service should provide you with sufficient security provided that you download the VPN client and make its first connection over a more secure network.