The flaw that left .AS websites and owners exposed for at least 16 years

library
crime | hacking | security

A security researcher by the name of Infosec Guy has discovered a flaw in the website of the AS (American Samoa) domain registry nic.as that, in the registry’s own words, “pre-dates the century”.

According to Infosec Guy the flaw allowed anyone to modify the records of any domain name accessible through the AS Registry website, giving them an easy way to hijack .as websites:

…a malicious attacker could quite easily modify any domain information – such as nameservers – allowing them to take control of websites by redirecting their traffic to servers they control.

The .as domain is the country code top-level domain for the US territory of American Samoa.

As well as being used by sites associated with the territory, the .AS domain is used by organisations wanting to create short and memorable domains, such as the University of Texas (utex.as) and by URL shortening services.

Insecure Direct Object References

The bug that Infosec Guy found was an Insecure Direct Object Reference, a type of flaw that allows users to access or change things that aren’t under their control by tweaking things that are.

In this case the researcher noticed that a parameter in the site’s URL was being used to control which domain’s details were shown on the screen.

By changing the domain in the URL parameter he could see records for domains he didn’t own.

Those details included contact details for administrative and technical contacts (details that are often public anyway), unencrypted passwords and buttons to “Modify”, “Renew” or “Delete” the domain – actions the hacker says he was able to execute successfully.

Using parameters like this isn’t itself a problem (although it can lead to data leaks) and many sites do it. The problem is that the site didn’t check whether or not users were allowed to see details of the domains they were attempting to look at.

In HTTP, the language of the web, a URL is user-supplied data and like any user input it should always be treated as untrustworthy and subject to validation and appropriate access control checks.

What makes the problem look worse is that the domain name in the URL parameter Infosec Guy was tweaking was base64 encoded.

It’s hard to think of a reason why this would be necessary but (bad) developers have been known to use base64 encoding to obfuscate details they’d prefer you didn’t see, not realising that it provides no protection at all.

We have no idea if that was the idea behind using it here or not but, intentionally or otherwise, it appears to have been the only protection on offer.

Unfortunately base64 obfuscation isn’t encryption so it’s easily reversed and developers and hackers alike can spot attempts to hide things with base64 from 1,000 yards.

Passwords in plain sight

The AS Registry website showed passwords on screen, alongside administrative and technical contact details for each domain, and that’s a clear sign that they were not being stored properly.

The only safe way to store passwords is as stretched and salted hashes.

Stretched and salted hashes are secure because they cannot be reversed or undone to reveal the password used to generate them.

Attackers have to guess at passwords and test them one-by-one until they get lucky.

Even the organisation storing the hash doesn’t know your password, and so it’s impossible for them to retrieve it, lose it or show it to you.

The AS registry defended they use of poor password security in an email exchange with Infosec Guy, saying that it didn’t matter because the password field wasn’t being used.

Actually, the password field has never been used. It’s a hold over from the original Network Solutions .com email template from the mid 1990’s

That might mitigate the problem for the AS Registry but, as Infosec Guy correctly points out in his own write-up, people frequently reuse passwords and that makes it a serious problem for them.

An attacker who managed to see passwords using the flaw that Infosec Guy discovered, or who managed to steal the site’s password database, didn’t need to spend time and money cracking passwords, they’d have instantly been able to cause all sorts of problems for affected users on any other sites where they reused their passwords.

Collecting passwords that aren’t used also flies in the face of the principle of least privilege and, alongside the lack of authentication and the use of base64 encoding, it raises questions about the general hygiene of the site’s code and the registry’s approach to security and quality assurance.

A write-up of the flaw, including the communications between Infosec Guy and the AS Registry is available on the hacker’s own site.

The flaw on the nic.as site has been fixed since February and the American Samoa Domain Registry have hit back with a belligerent press release on their own home page that describes Infosec Guy’s report as “inaccurate, misleading and sexed-up to the max”:

While it is true that in January of this year we received a report of an issue, that issue related to the legacy registrar system, NOT to the backend Registry system. At no time was the Registry system itself in jeopardy.

Most domain names in .AS are now managed by registrars using EPP, and this system is not involved in any way. To suggest otherwise is scaremongering.

We fixed the potential issue back in February with the legacy Registrar system before any problems arose. There was never any potential for unauthorized changes to domain name information, as the Legacy Registrar system is a manual system.

The press release doesn’t do is address the flaw’s age – it says that the system in question is a legacy system but presumably there was time when it wasn’t. Has the vulnerable system been a legacy system for the sixteen or more years the bug existed, and if not how long were users affected?

The registry’s words also don’t address the lack of authentication, the storage of passwords in plain text, the unnecessary collection of data or say how the flaw went unnoticed for so long.