Business is increasingly outsourcing non-core functionality through buying services in ‘the cloud’ rather than hosting on-prem. This has many advantages for the company, not least, because someone else is tasked with keeping the system operating 24/7. It doesn’t always work perfectly, but on the whole Software as a Service is great for both the clients and the service providers.
Now, one of the steps in connecting your business domain to these SaaS is Domain Verification – proving that you actually own the domain that you want them to provide service for. Because this process is often automated, one of the favoured options of providing this proof is for the SaaS provider to provide you with a special token or string that you need to put into the DNS record for your domain as a TXT record.
Simple enough, right? Well yes. Let’s look at an example.
Want to have Microsoft o365 handle your company email? Awesome. Go sign up and tell Microsoft to handle mail for your domain, e.g. pgregg.com. Microsoft isn’t sure that I actually own pgregg.com – so they generate a random code and tell me to add a TXT record under pgregg.com with the (randomised) value “MS=ms12345678”. When I confirm that I’ve made that change to the DNS zone, Microsoft will make a pgregg.com TXT DNS query looking for the string they told me to add. If it is there, then I’ve proved that I own the domain and Microsoft will happily provide service for the domain.
There are other validation processes (such as adding a meta header to your domain’s web page), but this is less convenient and so TXT records are often preferred.
Once you have proved that you own the domain, there is no further need for the record to remain in DNS.
Sounds great, what’s the downside?
Let’s look at the domain hackerone.com, a site that enables hackers and businesses to connect (for good).
$ host -t txt hackerone.com
hackerone.com descriptive text "v=spf1 include:_spf.google.com include:amazonses.com include:mail.zendesk.com include:spf.mail.intercom.io include:mktomail.com include:registrarmail.net -all"
hackerone.com descriptive text "google-site-verification=glWWhC-27LpigyjAxBsVOVUScJgNQ23GWdC4uOWC3dc"
hackerone.com descriptive text "cloudpiercer-verification=32e7eea9d2f153b176b182626588bc77"
hackerone.com descriptive text "MS=ms75772789"
hackerone.com descriptive text "citrix-verification-code=9c920630-2d05-4154-b72a-1021665d3b58"
hackerone.com descriptive text "google-site-verification=mKdqQzjtY7X20BzUFnhAmFU2pmtFJ_Zie_S22FiwubA"
hackerone.com descriptive text "facebook-domain-verification=niq4ke9m7djq4jt36f02t093aig8a5"
hackerone.com descriptive text "atlassian-domain-verification=JpJ4g3munTo9KsuR3Elcdpn97c+KQV7KDjj2YmE+ULiWhGlcfA5f1ivoC0W2puQk"
hackerone.com descriptive text "ZOOM_verify_pzZpSwKqRx6pAD9lLkSl5g"
hackerone.com descriptive text "adobe-idp-site-verification=5d77b0274800290cf193145126595b14308358f46dfe90eba5e298f99d32d2fc"
hackerone.com descriptive text "zapier-domain-verification-challenge=d1be5c1b-f415-418f-9542-abc14d8321af"
hackerone.com descriptive text "4b7570f2564f4074b42872e1d78668ad"
hackerone.com descriptive text "drift-domain-verification=18fef5450d713c159ad9f6309fa338d298c11edd56fb22e343d758fb5f58437f"
hackerone.com descriptive text "docusign=848c7864-3a91-42aa-8e30-2671086f7516"
hackerone.com descriptive text "c06l6z7hp4vk6bzpqb1j6b8w1m64nf84"
hackerone.com descriptive text "h1-domain-verification=LDEQA8SYNEMgdUN1kfMtjFNptDJcnjKN8LxNHCN3JNvT5Fxo"
hackerone.com descriptive text "stripe-verification=20c821f6e4dfc5ee358ea9b8e4635cf062a2acac5751f8004d23b122f1cb5ac2"
hackerone.com descriptive text "stripe-verification=74802599834dfbfc093c8352686c992d22e7b20a6fdcfceac2e6a846074d6936"
Wow, there’s a lot to take in there.
OK, what can we learn from this?
Pretty standard SPF record, and hackerone.com allows a bunch of other service providers to send mail from hacker.com on their behalf.
But, hol’up for the rest.
Google, Cloudpiercer Discovery Tool (against themselves), Microsoft o365, Citrix, Facebook, Atlassian, Zoom, Adobe Enterprise IDP, Zapier, Drift, Docusign, and Stripe.
That’s a rich list of Phishing vectors to come from – businesses which the victims will expect to have communications from, significantly increasing the chances of phishing success; and you’re just handing your SaaS provider list to the attackers by not maintaining some hygiene on your DNS records.
An additional risk is Supply Chain attacks. By broadcasting many of the third parties you have working relationships with, you’re providing a supply chain vector to those attackers specifically trying to attack you.
Please delete Domain Verification TXT records when you’re done verifying.