Live data from Hacker News

When internal hostnames are leaked to the clown

rachelbythebay.com

91–100 of 265 posts

Re: When internal hostnames are leaked to the clown

#91
post #17

>Hope you didn't name it anything sensitive, like "mycorp-and-othercorp-planned-merger-storage", or something. So, no one competent is going to do this, domains are not encrypted by HTTPS, any sensitive info is pushed to the URL Path. I think being controlling of domain names is a sign of a good sysadmin, it's also a bit schizophrenic, but you gotta be a little schizophrenic to be the type of sysadmin that never gets…

> "So, no one competent is going to do this"

What about all the people who are incompetant?

Re: When internal hostnames are leaked to the clown

#92
post #66
post #52

Reverse address lookup servers routinely see escaped attempts to resolve ULA and rfc1918. If you can tie the resolver to other valid data, you know inside state. Public services see one way (no TCP return flow possible) from almost any source IP. If you can tie that from other corroborated data, the same: you see packets from "inside" all the time. Darknet collection during final /8 run-down captured audio in UDP. Fi…

"Darknet collection during final /8 run-down captured audio in UDP." Mind elaborating on this? SIP traffic from which year?

2010/2011 time frame. Google and others helped sink the traffic, all written up at apnic labs. It's how 1.1.1.0/24 got held back from general release.

Re: When internal hostnames are leaked to the clown

#93
post #76

This highlights a huge problem with LetsEncrypt and CT logs. Which is that the Internet is a bad place, with bad people looking to take advantage of you. If you use LetsEncrypt for ssl certs (which you should), that hostname gets published to the world, and that server immediately gets pummeled by requests for all sorts of fresh install pages, like wp-admin or phpmyadmin, from attackers.

It's not just Let's Encrypt, right? CT is a requirement for all Certificate Authorities nowadays. You can just look at the certificate of www.google.com and see that it has been published to two CT logs (Google's and Sectigo's)

Technically logging certificates is not a Requirement of the trust stores, but most web browsers won't accept a certificate which isn't presented with a proof of logging, typically (but not always) baked inside the certificates.

The reason for this distinction is that failing to meet a Requirement for issued certificates would mean the trust stores might remove your CA, but several CAs today do issue unlogged certificates - and if you wanted to use those on a web server you would need to go log them and staple the proofs to your certs in the server configuration.

Most of the rules (the "Baseline Requirements" or BRs) are requirements and must be followed for all issued certificates, but the rule about logging deliberately doesn't work that way. The BRs do require that a CA can show us - if asked - everything about the certificates they issued, and these days for most CAs that's easiest accomplished by just providing links to the logs e.g. via crt.sh -- but that requirement could also be fulfilled by handing over a PDF or an Excel sheet or something.

Re: When internal hostnames are leaked to the clown

#94
post #53

I bought a SynologyNAS and I have regretted already 3-4 times. Apart from the software made available from the community, there is very little one can do with this thing. Using LE to apply SSL to services? Complicated. Non standard paths, custom distro, everything hidden (you can’t figure out where to place the ssl cert of how to restart the service, etc). Of course you will figure it out if you spent 50 hours… but w…

You can run a container on Synology and install your custom services, tools there. At least that is what I do. For custom kernel modules you still need a Synology package for something like Wireguard.

If you have OPNSense, it has an ACME plugin with Synology action. I use that to automatically renew and push a cert to the NAS.

That said, since I like to tinker, Synology feels a bit restricted, indeed. Although there is some value in a stable core system (like these immutable distros from Fedora Atomic).

Re: When internal hostnames are leaked to the clown

#95
I have investigated similar situation on Heroku. Heroku assigns a random subdomain suffix for each new app, so URLs of apps are hard to guess and look like this: test-app-28a8490db018.herokuapp.com. I have noticed that as soon as a new Heroku app is created, without making any requests to the app that could leak the URL via a DNS lookup, the app is hit by requests from automatic vulnerability scanning tools. Heroku confirmed that this is due the new app URL being published in certificate authority logs, which are actively monitored by vulnerability scanners.

Re: When internal hostnames are leaked to the clown

#96
post #84

Isn't the article over emphasising a little bit on leakage of internal urls ? Internal hostnames leaking is real, but in practice it’s just one tiny slice of a much larger problem: names and metadata leak everywhere - logs, traces, code, monitoring tools etc etc.

In other words: never put sensitive information in names and metadata.

Or name them after little bobby tables.

Is there some sort of injection that's a legal host name?

Re: When internal hostnames are leaked to the clown

#97
post #59

[flagged]

Clueless lol. This is not about any of that. I run Plex on my local network at plex.domain.com. Plex sends logs to the internet with its local domain in the string. Leak. There is no easy way to solve this without deeply inspecting each packet a service sends outside your network, and even that doesn't work when services use SSL certificates and certificate pinning preventing MITMs.

wtf are you allowing plex to initiate outbound connections to begin with?

and why is plex not in it's own VLAN with a egress FW rules to second with?

lastly, why aren't you running snort/suricata to inspect the packets originating at plex?

let me solve this problem for you - it probably doesn't bother you at all.

otherwise, you'd scratched your itch a long time ago.

> Clueless lol.

It's ok to be clueless. And, it's ok to be working for a FAANG and be clueless too.

Re: When internal hostnames are leaked to the clown

#98

Not sure why they made the connection to sentry.io and not with CT logs. My first thought was that "*.some-subdomain." got added to the CT logs and someone is scanning *. with well known hosts, of which "nas" would be one. Curious if they have more insights into sentry.io leaking and where does it leak to...

Because sentry.io is a commercial application monitoring tool which has zero incentive to any kind of application monitoring on non-paying customers. That's just costs without benefits.

You now have to argue that a random third party is using and therefore paying sentry.io to do monitoring of random subdomains for the dubious benefit of knowing that the domain exists even though they are paying for something that is way more expensive.

It's far more likely that the NAS vendor integrated sentry.io into the web interface and sentry.io is simply trying to communicate with monitoring endpoints that are part of said integration.

From the perspective of the NAS vendor, the benefits of analytics are obvious. Since there is no central NAS server where all the logs are gathered, they would have to ask users to send the error logs manually which is unreliable. Instead of waiting for users to report errors, the NAS vendor decided to be proactive and send error logs to a central service.

Re: When internal hostnames are leaked to the clown

#99
post #53

I bought a SynologyNAS and I have regretted already 3-4 times. Apart from the software made available from the community, there is very little one can do with this thing. Using LE to apply SSL to services? Complicated. Non standard paths, custom distro, everything hidden (you can’t figure out where to place the ssl cert of how to restart the service, etc). Of course you will figure it out if you spent 50 hours… but w…

please don't do this to your synology

leave it to serve files and iscsi. it's very good at it

if you leave it alone, no extra software, it will basically be completely stable. it's really impressive

Re: When internal hostnames are leaked to the clown

#100
post #82
post #53

I bought a SynologyNAS and I have regretted already 3-4 times. Apart from the software made available from the community, there is very little one can do with this thing. Using LE to apply SSL to services? Complicated. Non standard paths, custom distro, everything hidden (you can’t figure out where to place the ssl cert of how to restart the service, etc). Of course you will figure it out if you spent 50 hours… but w…

I'm so happy I didn't buy a NAS, Synology or not. I think a proper computer running Linux gives me so much more flexibility.

that's still a NAS.
Post reply on HN