Security – The Wacky World of Chris Knight

2020/07/222020/07/22

Never Give Someone Your Secret Keys

You didn’t need me to tell you that, though. Right? It goes without saying, as it’s right in the name. Secret Key. You give people the other half, the Public Key. I think they teach that in kindergarten these days.

So, why am writing a post about such a simple topic? Let me tell you a story…

I’ve been using keybase.io for years.

I probably haven’t been using all its features, but it serves as another way of verifying some ways of communicating securely with me.

keybase.io was bought by Zoom, and we don’t know what that means yet. Will it stay free? Will it get shut down because all Zoom cared about was the crypto skills and tech?

One thing that is happening is that at least one ‘competitor’ has already popped up. Yesterday I received an invite from Cyph to sign up. They’d conveniently scraped my public info at keybase.io and populated an account that was ready for me if I accepted the invite. All I had to do was click the link and provide a new password and PIN. What the heck, I’ll sign up and make sure I get the name Ghostwheel before Scott in Atlanta grabs it.

There’s a reason I put ‘competitor’ in quotes is because there is something very phishy about Cyph. The website at cyph.app wants me to prove I own the pgp public key they scraped from keybase.io by… uploading my private key to their servers.

That. is. not. going. to. happen.

That’s now how it works. That’s not how any of this works!

You want me to prove I own the secret key? Give me a random blob of text to sign, and you verify it with my public key.

You want to compromise any pgp/gnupg encrypted communications I have ever had? Yeah, that’s when you ask for my secret key.

Now that I’m taking another look at the invitation email, it isn’t even properly signed. It has a signed.asc but it’s malformed. Looking more phishy by the minute.

We’re supposed to move from keybase.io to a website that wants us to add our secret keys to their keystore, and where the CEO can’t send a properly pgp signed email?

Yeah, nah.

2019/12/242019/12/24

Nebula: The Zero Trust Networking Tool You Didn’t Know You Needed

I first became aware of Nebula a few days ago, thanks to two excellent write-ups at Ars Technica. (here and here) It’s an open source product freely given to the world by the folks at Slack. (Best known for making billions putting a fresh skin on IRC.). While those two write-ups at Ars Technica do a decent job at introducing Nebula, I feel like a use case for Nebula that hasn’t been fully explained.

Nebula isn’t like the VPNs for which you are constantly bombarded with ads. It isn’t designed for you to hide your torrent traffic, or to mask your IP address. It is designed to secure communications between systems you control, and makes for an excellent building block in a Zero Trust implementation.

First off, what’s “Zero Trust”? It’s the idea that you can’t trust any of your infrastructure, any more than you could trust the Internet. It’s logical evolution of the old adage “never trust the client”. If you can’t trust the client, you can’t trust the network they are connected to either. Assume at all times:

There’s a compromised device on your network sniffing traffic.
All of those ‘Smart Appliances’ you got for Christmas are remotely hackable, if they weren’t flat out designed to attack your network from the inside.
Any machine can have zero-day malware that isn’t detectable yet.
The NSA has a tap on your AWS VPC (Virtual Private Cloud).
Any of the Five Eyes countries have taps on the switches/routers at your ISP.
The ‘free WiFi’ at the cafe is sniffing traffic to insert ads, or worse.
Your ISP is sniffing traffic for * reason.
Your SuperMicro server has the Magick Chip that sends data to China.
Your network gear has Huawei components.
One of your sysadmins didn’t get enough of a raise and has sold access to your network for fun and profit.
There are a thousand other risk factors not on this list.

The old paradigm was built around a division of realms: the trusted home/office/datacenter network and the wild west of the Internet, with firewalls in between. That paradigm is shifting with the acceptance of the reality that devices inside your trusted network are going to be compromised. By accepting that, and making design decisions with that in mind, the impact of your future compromise(s) just might be reduced.

Now that you are starting to embrace the appropriate level of paranoia, how does Nebula VPN help? Nebula lets you create a mesh VPN between the hosts in your network, whether or not they are on the same subnet or in the same VPC. It allows you to secure traffic that was otherwise difficult to secure, or that you wouldn’t normally consider securing because it takes place in a ‘trusted’ layer of your network. With Nebula it becomes trivial to encrypt MySQL, MongoDB, Redis, Memcache, etc, traffic; restricting access to hosts with the appropriate certificates installed while also limiting exposure if another instance in your infrastructure becomes compromised.

Unlike traditional hub and spoke VPNs, Nebula functions as something closer to a mesh. In a traditional VPN, two clients who want to talk to each other would have to route their traffic to the server and back. With Nebula, clients negotiate the best way to talk to each other, using the shortest route possible. This is a far more efficient use of bandwidth.

I spent a couple of hours adding a new column on my IP/subnet spreadsheet, creating certificates, and writing a Puppet module to deploy Nebula in my quirky infrastructure. I now have a virtual VPN subnet that spans systems across two continents, where I can now use the Nebula IP for a host to automagically encrypt traffic.

I haven’t used Nebula long enough to run into any gotchas, which means I’m still a novice. Despite that, I do feel secure in saying that it makes for a powerful tool in your Security toolbox.

If you want to give it a try, this write-up at Ars Techica will have you up and running in ten minutes or so.

2019/09/172019/09/17

State Farm Security Fail

On State Farm’s security page, they say “The Security of Your Personal Information is a Priority at State Farm” and “We work hard to make sure your account information stays secure. Learn more about how to protect yourself and how State Farm protects you.”

That’s all well and good to say, but the reality is not so simple.

State Farm supports 2FA on your account, which is good-ish. They don’t support Google Authenticator, or Duo. They do support SMS messages and email, in a way in which enabling 2FA enables both and you can’t disable SMS in the settings. This is not so good, as current industry advice is to avoid SMS as 2FA due to SIM swapping attacks and SS7 hacks.

But then it gets worse. The devil is in the details, or in this case the following sentences: “Use a verification code or answer public based questions every time I log in.” “Selecting Two-Factor Authentication means you’ll receive a unique verification code by email or text or you will answer a series of public based questions each time you log in.” This is where things get really scary. Verification by ‘public based questions’ is an absolute favorite for identity thieves. They can sit at their computer with a copy of your credit report and answer these with a high degree of success.

I tried complaining about lapse in security practice to State Farm, and they seem to have fully drunk the LexisNexis kool-aid on this. They stand by their use of a vulnerable verification tool that puts my accounts at risk.

Time to find a new insurance provider.