Live data from Hacker News

Ask HN: How did the internet discover my subdomain?

news.ycombinator.com

251–260 of 322 posts

Re: Ask HN: How did the internet discover my subdomain?

#251

Earlier quoted context omitted.

I sadly did not see the comment above, but I'd like to just add, that this bruteforce and sniffing methods are target only against our paying customers. We built global reverse-DNS dataset solely from cert transparency logs. Our active scanning/bruteforcing runs only for assets owned by our customers.

…as long as your tools are only in your hands to be used, correct? Once a tool is created and used on a machine with access to the greater internet, doesn’t your logic hold that its security is compromised inherently? Not saying you have been infiltrated, or a rogue employee has cleverly exported a copy or the methodology to duplicate it off-site, but I’m not saying that hasn’t happened either.

It's not that hard to write this code. It's not a nuclear weapon.

Re: Ask HN: How did the internet discover my subdomain?

#252
post #91

Earlier quoted context omitted.

Finding IP does not mean finding the domain. When doing HTTP request to IP you specify the domain you want to connect to. For example you can configure your /etc/hosts to have xxxnakedhamsters.google.com pointing to 8.8.8.8 and make the http request, which will cause Google getting the domain request (i.e. header Host: xxxnakedhamsters.google.com) and it will refuse it or try to redirect to http. Of course it's only…

But there's no evidence in the OP's post that they have, in fact, discovered the domain. The only thing posted is that there is a GET request to a listening web server. The OP and all the people talking about certificates are making the same assumption. Namely that the scanning company discovered the DNS name for the server and tried to connect. When, if fact, they simply iterate through IP address blocks and make ge…

[deleted]

Re: Ask HN: How did the internet discover my subdomain?

#253
post #31

Certificate Transparency logs, or they don't actually know the domain name: just port-scanning[1] then making requests to open web ports. [1] Turns out you can port-scan the entire internet in under 5 minutes: https://github.com/robertdavidgraham/masscan

Port scanning usually can't discover subdomains. Most servers don't expose the of the domains they server content for. In case of HTTP they usually only serve the subdomain content if the Host: request-header includes it.

And in the case of HTTPS they need to insist on SNI (and TLSv3 requires it).

Re: Ask HN: How did the internet discover my subdomain?

#254

Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many oth…

Hi, former pentester here. If any one of your trusted clients is using a google/chromium based browser, the telemetry from that browser (webdiscovery) would reveal the existence of the subdomain in question. As others have said, security by obscurity doesn't work.

Re: Ask HN: How did the internet discover my subdomain?

#255

Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many oth…

"Security by obscurity does not work" This is one of those false voyeur OS internet tennets designed to get people to publish their stuff. Obscurity is a fine strategy, if you don't post your source that's good. If you post your source, that's a risk. The fact that you can't rely on that security measure is just a basic security tennet that applies to everything: don't rely on a single security measure, use redundant…

> "Security by obscurity does not work"

The saying is "security by obscurity is not security" which is absolutely true.

If your security relies on the attacker not finding it or not knowing how it works, it's not actually secure.

Obscurity has its own value of course, I strongly recommend running any service that's likely to be scanned for regularly on non-standard ports wherever practical simply to reduce the number of connection logs you need to sort through. Obscurity works for what it actually offers. That has nothing to do with security though, and unfortunately it's hard in cases where a human is likely to want to type in your service address because most user-facing services have little to no support for SRV records.

Two of the few services that do have widespread SRV support are SIP VoIP and Minecraft, and coincidentally the former is my day job while I've also run a personal Minecraft server for over a decade. I can say that the couple of systems I still have running public-facing SIP on port 5060 get scanned tens of thousands of times per hour while the ones running on non-standard ports get maybe one or two activations of fail2ban a month. Likewise my Minecraft server has never seen a single probe from anyone other than an actual player.

Re: Ask HN: How did the internet discover my subdomain?

#256
Certificate Transparency would also be my guess. These are logs published by big TLS certificate issuers to cross-check and make sure they're not issuing certificates for domains they have no standing on.

The way around this is to issue a wildcard for your root domain and use that. Your main domain is discoverable but your subs aren't.

There are other routes: leaky extensions, leaky DNS servers, bad internet security system utilities that phone home about traffic. Who knows?

Unless your IP address redirects to your subdomain —not unheard of— it's not somebody IP/port scanning. Webservers don't typically leak anything about the domains they serve for.

Re: Ask HN: How did the internet discover my subdomain?

#257

Earlier quoted context omitted.

…as long as your tools are only in your hands to be used, correct? Once a tool is created and used on a machine with access to the greater internet, doesn’t your logic hold that its security is compromised inherently? Not saying you have been infiltrated, or a rogue employee has cleverly exported a copy or the methodology to duplicate it off-site, but I’m not saying that hasn’t happened either.

It's not that hard to write this code. It's not a nuclear weapon.

[dead]

Re: Ask HN: How did the internet discover my subdomain?

#258
post #6

If it is on DNS, it is discoverable. Even if it were not, the message you pasted says outright that they scan the entire IP space, so they could be hitting your server's IP without having a clue there is a subdomain serving your stuff from it.

Ahh yeah, my internet network knowledge was never super strong, and now is rusty to boot. Thanks for your note.

[dead]

Re: Ask HN: How did the internet discover my subdomain?

#259

Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many oth…

Well, I sure hope the remainder of my URLs are safe.

Like, in: example.com/secret-id-48723487345

I hope the last bit is not leaked somehow (?)

Btw, we need a "falsehoods programmers believe about URLs" ...

Although there is: https://www.netmeister.org/blog/urls.html

Re: Ask HN: How did the internet discover my subdomain?

#260

Hi, our company does this basically "as-a-service". The options how to find it are basically limitless. Best source is probably Certificate Transparency project as others suggested. But it does not end there, some other things that we do are things like internet crawl, domain bruteforcing on wildcard dns, dangling vhosts identification, default certs on servers (connect to IP on 443 and get default cert) and many oth…

So to mostly prevent this.

Disable direct IP access. Use wildcard certificates. Don't use guessable subdomains like www or mail.

Post reply on HN