How the APNIC whois password hash leak was discovered

Background

The Asia Pacific Network Information Centre (APNIC) is a regional internet registry. APNIC is responsible for distributing IP addresses and Autonomous System Numbers (ASN) in the Asia Pacific region, including China, Japan, Australia, Southeast Asia, India, and other nearby countries. APNIC is comparable to ARIN who is responsible for the North American region. These organizations maintain the WHOIS databases for IP addresses and ASNs in their respecitve regions.

What is WHOIS?

Put simply: WHOIS is a way to look up who owns a domain, IP addresses, ASNs, and their contacts. For example: Lookup Google’s WHOIS here. Or you can open a command prompt and type the following:

whois google.com

You can also do the same with IP addresses:

whois 1.1.1.1

The issue

APNIC accidentally left the “auth:” string and the associated hash string in their public downloadable WHOIS database. This means that they inadvertently served the password hashes for all of the AS numbers they have allocated. If you did a WHOIS lookup on a third party site who had the APNIC database, you’d see the inclusion of the “auth:” field and associated password hash for the organization. This is a big deal – APNIC was leaking all of their “customer” password hashes.

How was this discovered?

In October of 2017, a colleague pointed me to a strange hash on an APNIC WHOIS record. This record was shown on a 3rd party site not associated with APNIC. I looked deeper into the issue and realized this was a huge leak of password hashes that affected thousands of organizations. At first I was in disbelief – it is not every day that you find something like this that affects so many companies, available for anyone in the public to access.

What is it this password hash for?

One of the record update methods that APNIC provides is via email. This might sound obsolete today, but this was designed before we had RESTful APIs. Personally, I’ve sent email updates to ARIN in the early 2000’s when working at a service provider.

APNIC uses a password hash to authenticate email updates to their WHOIS database. Without a way to authenticate an update, you would be opened up to spoofed email attacks against their database. The attackers would already know your email address, as it existed in the public WHOIS record, making this attack trivial.

What could you do with the hash?

I could see this going a few different ways:

  • An attacker is able to steal your IP space, and then advertise it from their network. If this happened it would take the entire company off the internet. The attacker’s actions would probably be noticed by email updates from APNIC first, and definitely after your services went offline. Once the IP addresses were stolen, the attackers could put up fake websites on your address space, to attack users or use it as a clean network to send spam from.
  • The attacker could try the password against any other sites you might have used it with. Or a worst case scenario: The password was reused on your infrastructure, allowing them to take over your systems.
  • They could also get into the organization’s MyAPNIC account, if the same password was used for both systems. I know this seems unlikely, who would do this right? You would be surprised (or maybe not).

How hard would it be to crack the hashes?

When the hashes were publicly available, an attacker could have easily scraped the 60,000+ ASNs that were on APNIC at that point in time.

APNIC provides their customers three options for authentication hashes: MD5-PW, CRYPT-PW, and PGPKEY. Cracking the first two hash types would be trivial. The third type (PGP) would not be crackable, or maybe it would be if you were a large government. A password cracking computer (or rig) running hashcat with a single GPU could crack a good portion the MD5-PW (hashcat -m 500) hashes in around an hour. The other crackable hashing format used by APNIC was CRYPT-PW (DES), so weak that an attacker could use John The Ripper (CPU based cracker) instead.

Since not all of the hashes were from countries that speak English, you would have had to find or generate custom word lists to crack the non-English passwords.

Best practice

For any of the readers who use APNIC, please take a look at the authentication options for mnter objects. I highly recommend using PGPKEY authentication, as the other options are very easy to crack as I pointed out in the previous paragraph. I know PGP is not user friendly to someone who is new to it, but it still fills the void for the features it provides.

For PGP software on MacOS, I recommend GPGTools and on Linux I recommend GnuPG. There are lots of guides online that walk you through setting it up so I won’t try to do that here.

Once you have PGP setup, you can sign your APNIC updates with your PGP private key. This means that only those who have access to your private PGP key can make changes to your APNIC maintainer object. If the auth: PGPKEY value was leaked in the future, it would do the attackers no good, as it is only the public key ID that you can share freely.

Personally, I think APNIC should phase out support for MD5-PW and CRYPT-PW. There isn’t a good reason to use these weak hashing algorithms any longer.

APNIC’s response was excellent

APNIC was very prompt in responding and confirming the issue. They worked quickly to resolve the issue, reset passwords, and took the issue seriously. Their blog post about the issue was transparent and didn’t try to hide anything. I gained a lot of respect from them and can say they responded extremely positively to the report. They took a bit of a reeling in the press articles, but I believe they did the right thing. I have confidence that they will work harder to make sure it doesn’t happen again in the future.

After they made the fix, you’ll notice that the WHOIS record now include: “auth: #Filtered”.

A few news articles were published after APNIC went public with their blog post: