4

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:

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

allquixotic
  • 618
  • 1
  • 5
  • 14
  • 2
    This reads more like a blog post than an actual question. – Neil Smithline Dec 24 '15 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. – André Borie Dec 25 '15 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. – André Borie Dec 25 '15 at 11:52
  • @AndréBorie Having [set up a wireless network in exactly that manner](http://serverfault.com/a/519093/126632), 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. – Michael Hampton May 02 '16 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. – André Borie May 02 '16 at 15:08

1 Answers1

4

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.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
  • 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. – André Borie Dec 25 '15 at 11:55
  • Good point @AndréBorie. I updated my answer. – Neil Smithline Dec 25 '15 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. – James Cameron Dec 25 '15 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. – Neil Smithline Dec 25 '15 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. – James Cameron Dec 25 '15 at 22:11
  • No one commented on the fact that the captive portal login page is coded to pull from `http` (unencrypted) websites, and that you're logging in over an unsecured WiFi hotspot? This seems like it's extremely exploitable to steal your login credentials if someone catches you logging in and can inject JS. – allquixotic Dec 26 '15 at 04:56
  • @NeilSmithline If I'm understanding correctly, an attacker can use up the data that you've already paid for by impersonating you. Isn't that a pretty serious security issue in itself? – Hans Brende Jul 01 '16 at 22:44
  • @HansBrende - I'm not sure that I follow. What "data that you've already paid for" are you speaking of? I guess they could use part of your 5 Mbps bandwidth. Is that what you mean? – Neil Smithline Jul 01 '16 at 22:54
  • @NeilSmithline I'm talking about the number of gigabytes you've purchased from Karma. If an attacker can impersonate you, he can deplete the gigabytes which you've purchased; isn't that a rather serious issue? See https://yourkarma.com/pricing – Hans Brende Jul 02 '16 at 22:29
  • @NeilSmithline is what I've said accurate? – Hans Brende Jul 13 '16 at 20:27