Skip to content

PSA: Geekdom offers unsafe space for proprietary data

Hi folks-

First off, let me say this: I think the management and employees of Geekdom mean well. I do not believe there is any intent to endanger their customers’ proprietary data, or that of their customers’ customers. But I would very strongly suggest they hire somebody to do an audit of their systems. With an eye to protecting their customers from the very sort of attack they are (almost certainly inadvertently!) running themselves.

Background: Geekdom provides a very cool “coworking” space in downtown San Antonio for independent entrepreneurs, startups, and other creative types. This means employees of many different companies are using their space. I personally signed up for it last week, and in many ways I found the space and atmosphere congenial.

However…

I ran into a couple of issues right away in their offices, listed here in increasing order of importance:

  1. Their domain is (quite badly) misconfigured for sending email. For some (most?) recipients, this merely means any email from geekdom.com is much more likely to land in a “spam” folder. For others, such as any of the staff or customers using Cabin Fever’s email servers, email from geekdom.com will simply be rejected. (Typically, truly bad email configuration is a reliable sign of a spammer.) This could happen to anyone; we all only know what we know. But it’s fixable. Here’s a free online SPF record checker they might use to troubleshoot their problem.
  2. They use a “service” (I trimmed the image above to obscure it, and I will not link to it here either) that intercepts traffic from Geekdom’s Wi-Fi network, decrypts it, then re-encrypts it and sends it along.

Now, the first issue above is relatively easy to resolve. I assume they’ll get to it at some point. I will say, though, that as I write this post that free, well-known, easy to use SPF checker I linked to above shows 9 separate errors in a single DNS entry. I’ve never seen anything like it. It doesn’t inspire confidence in the professionalism of their setup elsewhere.

The second issue, though? It’s extremely troubling. I suspect it came about because somebody clicked a checkbox for “advanced security” or some such thing without knowing what it meant. (Immediate question arises in my head: what else are they doing, however accidentally? I have no idea but I’m left with zero confidence that proprietary data should pass through their network.)

I noticed the second issue when trying to connect to a calendar server running in my home office. As you can see above, the unnamed security/firewall provider was attempting to coerce my computer to use their certificate…thus rendering my and my customers’ private data available to…well, truthfully, I have no idea who could see or use the information. But it’s double-plus ungood. If everybody using Geekdom’s Wi-Fi were, say, bank employees using that bank’s network? A reasonable argument could be made for this sort of system. But that’s simply not the case here.

Yes, it’s possible to get around this.

It’s not even hard. I do somewhat complicated networking because of the nature of my work, but a combination of VPNs and SSH tunnels would absolutely let me bypass this monitoring/hacking of my data. The problem? I’m imperfect. I develop on a computer running Arch Linux, so there’s pretty much nothing on it that I didn’t install and configure (think racehorse versus stubborn mule if you’re a Windows or Mac person), so I could in principle avoid leaks. Until I made a single mistake, that is.

Which does give rise to a question: if this monitoring is so benign and helpful, why don’t they try it with all connections, SSH and VPN included? Answer: my guess is that they know damn well what they’re doing is unreasonable. They’re not even trying to decrypt all data this way, or we’d be getting certificate warnings all over the place. We’d be forced to notice. Just low-hanging fruit, certain types of password-authenticated logins, huh? Just to see if they can get away with it? People wouldn’t stand for it if they were actually (and openly) monitoring all traffic. Though who knows? Lots of VPN protocols/implementations are inherently insecure, especially if an entire session can be recorded–and this “security provider” is in a perfect position to do just that. Maybe they’re doing all kinds of things over there.

This whole thing creates a known actively hostile network. It would be irresponsible of me to continue using it, given that I have a duty to protect my customers’ data. And, to reiterate, I don’t know what other means they’re using to decrypt my data. I have to assume they’re doing all they can, though. They’ve declared their intent, after all. Shouldn’t I believe them?

Couple of things. Cabin Fever’s site is kind of a placeholder at the moment, while I re-inflate the new and improved Scarecrow. Both this site and the separate Scarecrow site have been thoroughly redesigned, but not yet re-launched. Not many people will see this post, unless I start making a point of sending this information out. Which is not my intent. I’m not planning to go back to Geekdom (I canceled my membership), but I’ll give them some time to fix this and let me know before I attempt to contact anyone about it.

Second, when I brought this to the attention of a Geekdom staff member, it became clear that this kind of snooping was by design…on somebody’s part. I have no idea who made the decision. But the staff member read a response from some sort of support person claiming that the decryption of my traffic was intentional, and saying I could get rid of the error message by uploading my certificate to their server–which would, of course, simply allow them to decrypt the data without bothering with their (forged!) certificate. While this would avoid error messages temporarily–only until my certificate expired, at which point I’d get a new one–it would not at all address the underlying problem: neither Geekdom employees nor their “security” provider should have any access to my or my customers’ data in the first place. There are reasons to encrypt data. The whole idea of that is to restrict access. So, well, it is what it is.

I’ll also note that the Android application I’ve been using for this same calendar service gave me no certificate warnings. Which means I need to quit using that particular Android app, so in one sense all this was sort of helpful to me going forward. Important note: since the mail application uses passwords for authentication, this means the attacker “security service” decrypted my password in the process of, um, “protecting” me. What other passwords have they decrypted, leaving their customers unaware of this (truly large) security breach? What have they done with all that data? I have no idea. But it could easily be, or lead to, a very bad situation. So. Obviously I shouldn’t go back. But should anyone? Perhaps not until they’ve mended their ways.

Really…in addition to passwords, what other traffic is being decrypted? My guess: everything that can be. That is, let me be plain here, just a guess.

Here’s my primary queston though:

How in the world have other Geekdom customers not noticed this? It’s not a subtle issue, and man in the middle attacks are a well-known problem. Ha! Maybe they should all read my book? It is, after all, free….

But they almost certainly won’t. I’m posting this with the hope that I’ll have a reason to take it down before too long, specifically before it does any harm to a business I actually like.

But, really, fellow techies: if you, via either intent or inattention, allow MitM attacks, which is bad, from a system using untrusted ad hoc certificates, which is even worse…doesn’t that mean that, even if nothing horrible arises from it in this case, you’re also implicitly allowing ALL other MitM attacks? From anybody? At any time? I gotta ask: how come?

We’ll see how it goes.

As always (however very very long it may have been since my last post)…have fun out there!

 

Published inDaily post

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *