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.


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:

enter image description here

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

enter image description here

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:

enter image description here

  1. Put it into the VM:

enter image description here

  1. Try Google:

enter image description here

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:

enter image description here

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

  • 2
    This reads more like a blog post than an actual question. Dec 24, 2015 at 18:14
  • I can't understand why everyone gets this open WIFI authentication wrong even though it's a solved problem - serve two networks, one unencrypted that redirects to an HTTPS registration page, and a second, EAP-secured one that requires the credentials obtained during registration. An added bonus is that they don't have to suffer through the captive portal nonsense as their device can remember EAP credentials. Dec 25, 2015 at 11:50
  • About trying to solve your problem, have you tried just opening this horrible piece of hardware, taking the SIM card out and putting it in a 3G network card? I wouldn't be surprised if they did IMEI whitelisting so this wouldn't be possible but it's still worth a try. Dec 25, 2015 at 11:52
  • @AndréBorie Having set up a wireless network in exactly that manner, I can tell you why it isn't generally done: Windows. In particular, Windows 7 and prior versions refuse to accept the RADIUS certificate unless they're pre-configured to accept or ignore it, before you ever connect. This isn't really an issue with Windows 8 and later, but there's still a lot of Windows 7, and even some Vista and XP out there. May 2, 2016 at 12:08
  • @MichaelHampton but since we have the unencrypted network serving the certificate, users could download it from there and import it. This doesn't protect against MITM but at the very least makes it way more difficult than an unencrypted network. But this will get even better once Hotspot 2.0 is more widespread. May 2, 2016 at 15:08

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

  • While I won't downvote, I disagree and see this as a major security problem - the whole point of this captive portal is to get the identity of the user (as required by most countrie's laws), and then the device ties the identity of the user to their MAC address. So an attacker can impersonate an authenticated user and commit illicit activities under their name. Dec 25, 2015 at 11:55
  • Good point @AndréBorie. I updated my answer. Dec 25, 2015 at 17:37
  • Your point about SSL misunderstands the starter post, i understand it that Karma Go uses a TLS Proxy for non-encrypted pages. Dec 25, 2015 at 22:01
  • What do you mean that is uses a TLS proxy for non-encrypted pages @JamesCameron? Why would there be a TLS proxy for pages that aren't encrypted? And I don't think there's any proxy at all as there's no need to set any proxy settings on client devices. Dec 25, 2015 at 22:03
  • @NeilSmithline Looks like i misread when you first connect to the WiFi network and try to go somewhere over HTTP, you're redirected to an HTTPS-encrypted login and thought they would be that clever adding a TLS Proxy when having an unencrypted network by design that would protects against sniffing. Sorry for the misunderstanding. Dec 25, 2015 at 22:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .