Finding services companies via their TXT records | Hacker News Reader

Finding services companies via their TXT records

abenezerbelachew.com

126 pointsabenezerb67 comments

Domain validation TXT records are poor infosec hygiene. If used at all, those records should never include any hint as to what service they are intended for.

E.g. the record should NOT be:

example.com IN TXT "someservice.com-validation=029845yn0sidng0345randomnyosndgf03548yn"

instead, it should be something like

example.com IN TXT "029845yn0sidng0345randomnyosndgf03548yn"

Of course there will be multiple such records for different service providers. The service providers will just have to check all those (handful) of TXT records for the random assigned token in their database instead of pre-filtering them by the someservice.com-validation prefix.

As jelavich pointed out, there is also https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-veri... which suggests another improvement on that. To avoid polluting the example.com name with tons of TXT records and to avoid problems with CNAME records and such, those records should be further down in the tree like

_validation_mv0395ng035.example.com IN TXT "029845yn0sidng0345randomnyosndgf03548yn"

The record name token "mv0395ng035" could either be another random number assigned to example.com by someservice.com they just put in their database. Or it could be something like HMAC(example.com, <common secret known to someservice.com>), so they don't have to save all those tokens. In any case, the check will be just one DNS lookup, one comparison and done. Quicker, equally easy and more privacy-preserving and infosec-hygienic.

The problem with opaque records like "029845yn0sidng0345randomnyosndgf03548yn" is that you have zero clue what it's authorizing, making it impossible to audit your DNS records to ensure that you're only authorizing what you want to be authorizing.

And what do opaque records gain you anyways? Security by obscurity is not real security, and it's often possible to determine a domain's service providers by other means, such as CNAME/MX records, or by scanning the website for <script> tags.

Ideally, domain validation records would be of the form ACCOUNT_ID@SERVICEPROVIDER so you can know exactly what the record is authorizing.

Domain verification should typically be a one-time or at least rare event. You shouldn't have to keep the txt records after the verification is completed.

No, domain validation should be frequent, so that revoking authorization can take effect quickly, which is particularly important if the domain changes ownership.

That’s insane. Domains are not owned by the same entity forever.

It should be one-time, yes. Maybe it shouldn't be rare though. But your point still stands as the TXT records should be ephemeral. So I don't think this deserves the downvotes.

At least ACME's DNS challenge protocol is designed this way.

> The client SHOULD de-provision the resource record(s) provisioned for this challenge once the challenge is complete, i.e., once the "status" field of the challenge has the value "valid" or "invalid".

https://datatracker.ietf.org/doc/html/rfc8555#page-67

> The problem with opaque records like "029845yn0sidng0345randomnyosndgf03548yn" is that you have zero clue what it's authorizing,

I would have hoped the DNS management is automated and IaC-ed, so you just check the relevant commit message.

The service could also MitM you. They give you a code that validates their account against a second service.

Interesting point. I guess it would be possible to mask them, e.g. they give you the string "gitlab-123token123" and you set the TXT to hash("gitlab-123token123").

In a perfect world there would be a special DNS record type for this. The DNS server would store the full token value, but would return the hash when someone queries it. I think this would provide both maximum security and maximum privacy.

You could use your DNSSEC signing key to sign a validation message (offline, because that doesn't work over DNS).

As discussed elsewhere in this thread, domain validation needs to be frequently rechecked. Therefore, it's far more convenient to publish a DNS record than to manually sign messages out-of-band.

DNSSEC already provides attestation, why add another layer within the same system?

Because a DNSSEC attestation is usually public, except if you maybe use NSEC 3 and hide the RR behind some random name.

In real life,lots of companies infrastructure is an undocumented non-version controlled mess

Keep hoping. Most orgs are updating their DNS through some awful web interface that often doesn't even have the ability to add a comment.

> making it impossible to audit your DNS records

Every DNS provider I've used in recent memory, has offered a non-authoritative / non-DNS-exposed "comment" or "description" field for each record. Even if you aren't doing "DNS infrastructure as code" but just editing DNS records in a UI dashboard, you can just use these fields to describe the motivation behind each record at creation time.

> Every DNS provider I've used in recent memory, has offered a non-authoritative / non-DNS-exposed "comment" or "description" field for each record.

In my experience this is not at all common. I think I know of 3 that do, and I've used many more that don't.

To make this explicit: maintaining accurate DNS configuration is extremely important to enterprise security and availability.

Allowing outdated DNS entries to persist can open up all sorts of horrible opportunities for impersonation, phishing, etc.

At the same time, removing a DNS entry that you still need can cause massive downtime.

So anything that makes it easier for ops teams to observe and maintain DNS (in whatever ugly way available) is probably a security win in the long run.

Even stupid age-old BIND zone files can be version controlled and commented. Anything inferior to that level of documentability should be an instant no-no.

That can help with the ongoing maintenance of your records, but doesn't help you when you're adding the record in the first place.

As pointed out by singron at https://news.ycombinator.com/item?id=38069760 a malicious service provider (SP1) could give you a DNS record that was really issued by a different service provider (SP2). When you publish the DNS record, you're actually authorizing SP1's account at SP2 to use your domain.

With non-opaque records, you can be sure of what you're publishing.

Ah, now I get it. Yes, that is a possible problem.

If you are using TXT records like "029845yn0sidng0345randomnyosndgf03548yn" then how do you know which one to delete once you are not using that service? Do you just go back and forth between different services to find the one (some services only show this while you are in a validation phase, so finding them later might be a pain), or do you just leave them around?

Keep a log of every record added and why it was added. When making any DNS changes review the log as well.

Hopefully you're managing DNS as code, so you have a repo commit log that can give you that context.

Ops guy... These days cloudflare allows you to put comments directly into their service, but for a long time I would just export the zonefile and annotate that. There is a KB article somewhere in jira that will tell you what stuff is. I can also summon the ticket history to see what changes were made and why.

Those comments have a very short length limit (smaller than the records themselves) and I don't understand why.

Simple, indirection to the rescue again! Just add an increasing number in the comment field and keep track of which number is which comment in an Excel sheet on SharePoint or similar.

And yes, I'm mostly joking.

You can also look up common cnames or historical DNS records which would always point back to the vendor. For instance, do they use sendgrid, look for a bounce. record that points to sendgrid's servers. Do they use Facebook, well if they have a Facebook page that is verified yes. I would assume that Docusign and Attlasian also list Stripe as one of their customers on their website as well. Public TXT records are not that big of a deal.

There are two sides to this issue.

On one hand, the InfoSec side where you want to hide info. On the other side, the service provider doing the validation WANTS to advertise their service on these DNS records so they are disincentivized to make the changes you’re suggesting.

This type of “hygiene” is pointless; it does nothing but provide a tiny amount of obscurity, which is easily pierced in other ways.

It’s not hard to figure out what services a company is using, and most of these services requiring verification are so ubiquitous that confirming the knowledge adds no marginal utility to attackers. “Oh wow, this SaaS company has verified with Atlassian and Google, who could have guessed.”

This kind of thing is pointless against a targeted attack. But it can hide you long enough in case of zero-days/fresh unpatched vulnerabilities because attackers will first target the more easily visible victims.

It’s pointless against a targeted attack, but it will help attackers target you? That doesn’t really make sense to me. Can you share an example?

If an attacker knows about some exploit involving someservice.com, which you are using. That attacker will try to find out where he can use that exploit of his. E.g. he might use something like shodan, google or DNS to get a list of users of someservice.com. Those potential victims that turn up in that list will get attacked first. Later on, if that list is used up, the attacker might then look at other means of getting new victims, like e.g. just trying out the exploit on targets where he doesn't know they are vulnerable. So in that case, not being "visible" to an attacker buys you time to fix the vulnerability.

On the other hand, if you are on the attacker's hotlist, he'll try you first and you gain nothing.

TXT records are useful for OSINT. I've used them to tie together fake business listings on Google Maps. It also allowed me to tie the listings directly to the marketer responsible.

Where is the blog post about this?

No blog post. But, since you and another have requested I'll just write a comment.

I work for a small, local, family company. I maintain the websites and do some of the marketing.

We've noticed an uptick in websites for fake businesses and fake business listings in our area/industry in the past 3-4 years. The goal is to generate leads which can be resold to local contractors--usually without the customer knowing. It's a scheme called "rank and rent."

A few months ago, I noticed a new listing in our area. I started digging into the SEO spam for it. There was a website, a couple of one-episode podcasts, social media profiles, business listings, PDF spam, and more.

Looking into the HTML source of the site, I discovered some JSON-LD for a completely different company. I looked up the company on Google Maps. Sure enough, there was a listing. And the website was using the same theme as the one I was digging into.

I decided to pull the DNS records. They both used the same Cloudflare NS. Not a smoking gun, but interesting. Then when I pulled the TXT records, I noticed both used the same IP for the SPF record. Bingo!

A quick cURL resolving the domains to the IP, and I had proof they were hosted on the same shared hosting server.

With the IP, I was able to do a reverse lookup for other sites hosted on the same server. This netted me several domains that also used the same theme and had Google Maps listings (GBP). The money result was several marketing firm domains.

One turned out to have a GBP. It had videos and photos the person used to verify the listing. Fortunately, it had the marketer speaking in the video as well. That voice sample allowed me to compare it to the podcasts mentioned above. Aside from him faking an accent, it was definitely the same guy. I've since discovered ~30 such podcasts for his different listings.

The other marketing domains were even more interesting. They were also run by the same guy. Again, verified via voice in a video on these sites. He used these websites to recruit people for "social media gigs." The gigs were setting up Google Business listings in their area. They'd setup a listing, get the postcard with a verification code, pass it off to the marketer, and he'd pay them $50-100.

The kicker was a Google form on the recruitment page. It asked if the person would be willing to leave 5-star reviews for businesses they'd never done business with for $20.

I went back to Google Maps and started bouncing through people who'd left reviews. That opened up a whole world of listings that I hadn't known about.

At present, I'm over 80 listings which can be tied back to him.

I've also identified several websites that don't have GBP listings yet thanks to the TXT records and reverse lookups.

I'd love to read more about this!

I left a comment in the thread. Feel free to ask questions. Though, I'm cautious about giving too many details as I plan to report the guy to the AG in his state.

This site even provides nice logos for this purpose: https://www.nslookup.io/txt-lookup/

I made a tool called "Pig" that does this type of DNS enumeration: https://github.com/donuts-are-good/pig

You just give it a domain like this: `pig example.com` and it spits out anything it can find about your DNS, including matching services for about 150 different common services.

Built With, surfaces this too https://builtwith.com/stripe.com

Remember the recent Hacker News discussion, where you could send mails from 2 million domains through mailchannel? They got the number "2 million" through builtwith.com as you can see which domains use mailchannel. It's in the slides in the submission.

https://news.ycombinator.com/item?id=37628337

This actually really annoys me about AWS route53 private hosted zones. It makes perfect sense that a general-purpose ACME service can only query public DNS servers, but it doesn't make nearly as much sense when getting certificates through Amazon Certificate Manager. AWS clearly has the ability to hit private IPs in your VPC; otherwise, basic EC2 healthchecks would not be possible. Yet they require you to create a DNS record in a public hosted zone anyway. This becomes particularly annoying when you're operating in GovCloud because GovCloud doesn't offer public hosted zones at all, so your organization has to maintain a separate commercial account and create a public hosted zone there that acts as a second authoritative name server for your otherwise private domain. Then you run into an additional annoyance when using IaC tooling to provision certificates and DNS records because GovCloud and commercial IAM services are air-gapped from each other, so you can't use an assume role. Instead, whatever user account runs your IaC tool needs to keep separate AWS SDK profiles for GovCloud and Commercial and, assuming you want your IaC to be runnable by multiple users, you have to externally prescribe how these profiles are named.

There are so many levels of leaky abstraction here.

Amazon Certificate Manager issues publicly-trusted certificates, so they have to abide by the validation rules mandated by the Baseline Requirements, which do not permit what you desire.

CAs have often sought to bypass domain or CAA validation for domains which they believe are hosted with them, and this has repeatedly proven to be a bad idea because it relies on the CA to maintain accurate records about what domains are hosted with them. The source of truth for this information is in the public DNS, so it's more robust to require CAs to check public DNS records.

See for example the now-forbidden DNS Operator Exemption to CAA, which I advocated to be banned after Microsoft bypassed CAA checking for domains which they thought they controlled but really didn't: https://groups.google.com/g/mozilla.dev.security.policy/c/0T...

If your domains don't otherwise have public DNS records, maybe you should be using private certificates instead of publicly-trusted ones?

My main issue with auth-by-TXT is that they never tell you when you can remove them.

Some services check them only once, others -- every month?

For a good infosec hygiene, they should also be rotated regularly.

Another domain with a huge set of TXT records is oracle.com

  $ dig +short oracle.com TXT | wc -l
  41

> Amazon SES

It's really nice to see a company with a cloud offering ... using a rivals cloud offering (yes, Oracle is large, AWS probably has Azure/Google-services, but it's fun :) )

You can bet some of those those IP's listed in the SPF record are going to be interesting to look at.

https://www.ietf.org/archive/id/draft-ietf-dnsop-domain-veri...

Is it good hygiene to delete these records once they've served their purpose (i.e. validating control of the domain in question)? Or do these records server more than that use?

Some services do periodic re-checks of the record and un-verify the domain if the record was removed.

As they should. If a domain name changes hands, the previous owner should have its ownership verification revoked.

But the new owner could just duplicate the entries, to avoid that you have to periodically revalidate with a new entry.

I think it's more about the opposite. If you are the new owner, you don't want the old owner to continue to have access to features connected to your new domain.

So as a new owner you would want to remove the tokens.

Intriguing, hadn't considered that way round!. spf especially is something you'd have to update

Presumably services pay attention to the TTL, so services don't have to constantly refresh.

There should be a mechanism to have the validating party revoke the code they gave you. (Right?)

SPF, DKIM, and DMARC data lives in TXT records that must stay there forever; otherwise, you'll have problems delivering your email.

It’s a great observation that those TXT records are (of course) public.

Could be interesting to scrape some data to estimate the penetration of particular SaaS providers eg Google, Atlassian, etc.

It doesn't tell you which Atlassian or Google products are used. Could be as simple as wanting access to Google Search Console, formerly Webmaster Tools, or wanting to publish an app to the Atlassian Marketplace. It doesn't mean they use Gmail or Jira.

The MX records will tell you they use Gmail.

I've done this for https://www.nslookup.io. Downloaded a list of the 1 million most popular domain names, scraped TXT records for them, and mined common patterns to add formatting with logos to the TXT records section.

Here they are for the example OP gave: https://www.nslookup.io/domains/stripe.com/dns-records/

Looks like I need to rerun the script and add some logos (:

I did it on 2.5 million domains from the various top 1 million lists and here are the ones with over 10 thousand matches:

  11308 include
  12284 stripe-verification
  13377 cisco-ci-domain-verification
  15123 zoho-verification
  15621 knowbe4-site-verification
  18764 Sendinblue-code
  19472 amazonses
  21264 adobe-idp-site-verification
  23791 klaviyo-site-verification
  24156 docusign
  27694 yandex-verification
  34068 globalsign-domain-verification
  55512 atlassian-domain-verification
  65353 apple-domain-verification
  70535 _globalsign-domain-verification
  74467  
 155337 facebook-domain-verification
 400513 MS

1025970 google-site-verification

It was early days (although TXT records have been around ‘forever’) but they were one of the indicators used by BackChannel to profile target companies, since reading them was minimally invasive and light on resources to do. https://blog.eutopian.io/nsa-prisms-commercial-cousin/

Just sent this off to tailscale, whom I'm going through this right now with. lol. They put tailscale- in their TXT record name.

There is a recent rule based python tool for doing DNS record based service dependency fingerprinting at https://github.com/joniumGit/dnsmule/. It was written as part of a master's thesis work for OUSPG at University of Oulu.

Hmm I thought the article was going to be about finding actual services companies, like plumbers/contractors/salons/lawyers. Anyone with ideas on how to sites owned by these services companies?

These TXT records are also commonly used for DNS amplification DoS. If you run a public resolver you probably have already noticed the constant influx of "TXT? cisco.com" sort of queries.

Reply on news.ycombinator.com