45 seconds. That’s how long it took to crack 53% of the ABC’s now very public password database. That’s more than half of the almost 50,000 passwords that were publically exposed today. How the passwords (among other data) were exposed is yet to play out, but what we now know for sure is that the mechanism the ABC used to protect these credentials was woefully inadequate. Here’s how it was done:
Firstly, the dump comprises of 10 parts all listed over on Pastebin. All in all there are just under 50,000 records with the following attributes:
- user_id
- user_age
- user_town
- user_nick
- user_regip
- addedtomap
- user_email
- user_gender
- isModerator
- user_password
- user_updateip
- hhscore_score
- user_postcode
- postcode_state
- user_lastLogin
- user_statusText
- user_info_public
- user_regDateTime
- hhscore_testDate
- user_latitude_min
- user_latitude_max
- user_longitude_min
- user_info_approved
- user_longitude_max
- user_statusFlagged
- user_updateDateTime
- user_statusDateTime
Some of those are quite interesting and I may come back to them in a subsequent post but for now, let’s focus on the user_password column. It contains data that looks a little like this:
- 7907c2d05ed0039357d08433049877341e2b635d
- 08207f637617d60a7f5d478ebab54e5e9d160dff
- f7a9e24777ec23212c54d7a350bc5bea5477fdbb
- ef9e6d538efda4b736776330850218adc2f8e6b1
- ae5728815eff76b748cddab86f926642c5d168dd
- 96f0878719d2d667ecf68687f3b93d29af64ac14
- 7323517c3c74dea82eb14a152110f5f8e8575c28
What we’ve got here are hashes or in other words, the output of a one way cryptographic process. Done right, hashes provide good protection in the case of a data breach (such as what we’ve got here) as they can’t be un-hashed. Done wrong, hashes can be re-calculated en masse and effectively “cracked” thus disclosing the original plain text password. This is also what we’ve got here.
Before cracking anything though we need to know what hashing algorithm was used and if any salt (which adds randomness) was used. Finding the hashing algorithm was a piece of cake; copy one of the hashes, Google it and a result was hit on the second one I searched for. Here’s what I mean – take a password hash like this: fece64332bc17e695b7c498cc9858eebe7ae409f
Pick one of the results:
And there you have it – the cipher text is the SHA1 hash of 169400. This works because firstly, there are huge volumes of hashes and their plain text equivalents out there and secondly, because fallible humans reuse passwords so it doesn’t take long to find one that’s already been used – and cracked and published – in a previous breach. The other thing this shows us is that there is no salt which is a fundamental oversight by the developers of the system.
Of the 49,561 passwords in the breach, 41,585 of them were unique or in other words, about 8,000 passwords were used by more than one person. Because there was no salt there was no randomness on a per-password basis so when two people use the same password you get the same hash. This all makes it even easier to crack as the numbers reduce.
From here, the password cracking is exceptionally simple. I followed the same process as I used last year in my post about Our password hashing has no clothes where I successfully cracked tens of thousands of salted hashes in next to no time. This case is even easier as there’s no salt and it simply involved saving all those unique hashes into a file called abchashes.txt then using the same hashkiller password dictionary I used in the aforementioned example. I then used hashcat with a simple command to crack SHA1 hashes:
oclHashcat-plus64.exe -m 100 abchashes.txt hashkiller.com.dic
Here’s what happened next:
See the “Recovered” line? That’s 18,406 hashes recovered out of the 41,585 unique ones from the dump. In other words, 23,179 (less than half of the dump) couldn’t be recovered. But hey, that’s not bad when you look at the “Time.Started” line and see 45 seconds for the duration! A larger dictionary (I “only” had 23 million words in this one), or mutations of case or character substitution and you’d have a much higher success rate. 45 seconds got more than half of them, a few hours – or even days – and you’d have a very, very significant portion of passwords.
Here’s what the output from hashcat ultimately looks like:
- 71ede320c5ec9d7551b0f12e0e62e6912b2d9a32:000111222
- 68cbbe7db52ebfdb3ae38f54484a71c536ae1809:!@#123qwe
- 004c5f9c1491b0bd0b88260b8e3854038f66b2ed:$p0ng3b0b
- 11b5d7225c43267a0776dbe71174abd8c7e16fd6:00003796
- c0be05fd3dfd1c390f073a618c8f706ad3f4e8a9:02062002
- 88bce010e57c66e450d1318ecd21a70be3cd7e7a:07121991
- 613d195350bf80d3310b154bce2345d9eb0ed314:*kakadu*
What you’re seeing here is the original hash, a colon then the plain text password. It would now simply be a matter of loading this back up into a database, matching the hash to the one from the breach and there you have it – the original password right next to the username and other details for a significant portion of the database.
Earlier today the ABC posted a piece titled ABC to contact users following Making Australia Happy website hack. From this it appears the breach relates to a program that aired a few years ago and not the main ABC website so that’s some relief for them. Of course regardless of this, they’re ultimately accountable or at the very least should have had a vested interest in the security as clearly they’re now the ones in the headlines. Also, regardless of the program airing years ago, there are records in the dump with dates as recent as Sunday so clearly the site was still active.
Ultimately, it’s just another example of sloppy development let through by lacking security process (any security processes?) and unfortunately for ABC, they now have to bear the brunt of this. Unfortunately for the users in the breach, they now have to deal with the reality that their credentials – the same ones so many people use in so many other places – are out there in the wild and very, very easily obtainable. It’s a very unfortunate mess for everyone involved.