So here’s a situation: you buy a “NAS” box - network attached storage, bring it home, stick some drives in it, and plop it on your network. The thing has an affinity for running in https mode, so you drop a wildcard certificate on it inside a sub-zone of a domain you don’t even use for anything meaningful on the public Internet.

By sub-zone, I mean that your wildcard TLS cert is for something like *.nothing-special.whatever.example.com. It’s buried pretty deep.

You put an entry for it in your hosts file:

172.16.12.34 nas.nothing-special.whatever.example.com

Then you load that in your browser and it works.

A few days later, you notice that you’ve started getting requests coming to your server on the “outside world” with that same hostname. This is a hostname that only exists in the /etc/hosts file of your laptop.

You’re able to see this because you set up a wildcard DNS entry for the whole “*.nothing-special.whatever.example.com” space pointing at a machine you control just in case something leaks. And, well, something *did* leak.

Every time you load up the NAS, you get some clown GCP host knocking on your door, presenting a SNI hostname of that thing you buried deep inside your infrastructure. Hope you didn’t name it anything sensitive, like “mycorp-and-othercorp-planned-merger-storage”, or something.

Around this time, you realize that the web interface for this thing has some stuff that phones home, and part of what it does is to send stack traces back to sentry.io. Yep, your browser is calling back to them, and it’s telling them the hostname you use for your internal storage box. Then for some reason, they’re making a TLS connection back to it, but they don’t ever request anything. Curious, right?

This is when you fire up Little Snitch, block the whole domain for any app on the machine, and go on with life.

Using this sentry reporting mechanism as a way to make them scan arbitrary other hosts (in DNS) is left as an exercise for the reader.

From Writing - rachelbythebay via this RSS feed