Article from Troy Hunt Source: http://www.troyhunt.com/2013/02/lousy-abc-cryptography-cracked-in.html 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 Search for it: 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: Code: Select All 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.
