Exploiting Vulnerabilities in a TLD Registrar to Takeover Tether, Google, and Amazon
On October 8th, 2021, it was possible to modify the nameservers of any domain under the “.to” TLD due to underlying vulnerabilities in the TLD service provider. On October 9th, after disclosing the vulnerabilities to Tonga Network Information Center, Palisade worked alongside the team to remediate the vulnerabilities and validate the fixes.
Since the report was immediately disclosed by Palisade and the DNS registrar was very responsive, the vulnerability was fixed in under 24 hours and there was no malicious exploitation of the vulnerability whatsoever.
The way in which an attacker could compromise any domain under the “.to” TLD would be to (1) exploit a SQL injection vulnerability on the registrar website to obtain the plaintext DNS master passwords for any customer using the “.to” TLD, (2) use the web portal to login to the management console using the compromised credentials, then (3) overwrite the nameservers to an attacker controlled DNS server.
By performing the above steps, an attacker could overwrite the DNS settings for domains under the “.to” TLD and route traffic normally intended for the victim website to their own website. An attacker could then perform the following attacks against the legitimate users of the domain:
Steal cookies and browser local storage to immediately access victim sessions (including HTTPonly and secure cookies)
Exploit domain-level authorization checks (e.g. taking over “google.to” and abusing the domain’s trust to leak authorization codes which give immediate access to Google accounts)
Display attacker-controlled content on the domain or any subdomains (e.g. taking over “amzn.to”, the official Amazon shortlink for all affiliate products, and displaying a login page which would be controlled by an attacker and logging all credentials)
Various related attacks, depending on how each domain is used (e.g. compromising an API and returning modified data to applications using the API)
Some websites potentially affected include:
The official Tether website used for purchasing and managing the Tether stablecoin. Users of this site can only make purchases in orders of $100,000 or more. Even if an attacker controlled this domain for a short period of time, they could likely steal a very large amount of money from Tether users.
When disclosing this vulnerability, we worked with Tether who immediately locked their DNS settings so that even if an attacker did compromise the password, they could not overwrite their nameservers.
Amazon’s official link shortening provider used for affiliate marketing. There are nearly 125,000,000 indexed entries on Google for people using this domain to sell products with affiliate codes. If an attacker were to compromise it, they could (albeit probably get noticed doing so) skim the affiliate links on Amazon similar to how Darlene hacked Postmates in Mr. Robot.
An official Google domain which is whitelisted for redirects and authorization flows for Google. If you want to see an example of this, open this URL while being authenticated for Google and observe you are redirected to “google.to”.
Since the Google.to domain is whitelisted under Google’s account OAuth flow, it would be possible to takeover the domain then send a crafted “accounts.google.com” link which would leak a token which could be used to authenticate to the victim’s Google account.
Uber’s shortlink provider. Used for hyperlinking resources on many of their blogs and the Uber app.
Verizon’s shortlink provider. Same usage as “ubr.to”.
Although the number isn’t known, there are nearly 513,000,000 results on Google for pages under the “.to” TLD. One trend among websites affected by this TLD takeover was that many were using the two-character TLD to shortlink things like resetting user passwords, affiliate marketing, and linking company resources.
Spotting Domains in the Wild
Commentary on TLD Security
Something I think about frequently with my background as a bug bounty hunter is how programs incentivize hackers to find vulnerabilities in different assets and how incredibly broad organizations dependencies are.
If an example company ACME is built using Apache as a web server and a bug bounty hunter is trying to find vulnerabilities for ACME to pay for, should ACME pay for vulnerabilities in Apache? Is it worth the hackers time to find vulnerabilities in Apache? This conversation gets super interesting when you think about bug bounty hunters trying to get the most “bang for their buck” in the terms of time spent hacking from the profit model of any contractor.
Most programs (in my opinion) are less willing to pay for vulnerabilities in dependencies that would result in mass-scale impact across different organizations (e.g. 0day vulnerabilities, TLD takeovers, etc.) if they are outside of their management and therefore there is less emphasis on finding these sorts of vulnerabilities for a very large portion of the people actively hunting for bugs.
In terms of the “hacker ecosystem”, if security researchers following the traditional model of bug bounty don’t feel that it’s productive to look for these bugs, they simply won’t.
This leaves a gap for things like TLD takeovers, dependency vulnerabilities, and vulnerabilities in services outside of an organizations control not really having an incentive model for bug bounty hunters. Those who do hunt for these bugs without expectation of payment from the vendor mostly seem to be either (a) people having fun, or (b) those being paid/coerced by someone other than the affected vendor to find those vulnerabilities (think Zerodium, governments).
Even if the TLD registrars, dependencies, or services do have bug bounty programs, can they really pay for what the vulnerability is worth? How much do you think Verisign would be willing to pay if you were able to compromise any “.com” website versus the impact of taking over a website like Google or Facebook?
When buying a domain with a TLD like “.to” you’ll normally do it through a vendor like Namecheap, but if you were to browse to the root domain you’ll often find very old 1990s and early 2000s manual registration pages running outdated technologies (see this website for an example).
If you were to compromise these sites, you could theoretically access the systems used to manage all domains under the TLD which would be very, very, very bad. As of now, I don’t feel that these TLDs are getting adequate attention and many other TLDs may suffer the same issues as the “.to” TLD.
There are some programs, however, which will honor simply the impact and payout for vulnerabilities in third-party assets or things like TLDs. Additionally, there are some platforms like HackerOne which offer “The Internet Bug Bounty” program which pays for vulnerabilities in projects like Nginx, Django, Ruby, and Rails, but these are a long shot from being able to satisfy the entire ecosystem.
The bottom line is that there are over 1,500 different TLDs with many having their own custom DNS registrar websites. Many do have bug bounty or vulnerability disclosure policies, but as a researcher trying to play by the rules, are the incentives really there to hack them and will they even let you?
Credit and Disclosure Timeline
This vulnerability and writeup was a collaboration between the following:
The vulnerability disclosure timeline was as follows:
October 8th, 20:00 CEST: Vulnerability discovered and reported
October 9th, 19:00 CEST: Contact with Tether and Tonic regarding bug
October 9th, 20:00 CEST: Vulnerability attempted fix #1 by Tonic
October 9th, 20:30 CEST: Vulnerability fixed by Tonic, confirmed fix
