Big Data/Analytics Zone is brought to you in partnership with:

Troy Hunt is a Software Architect and Microsoft MVP for Developer Security. He blogs regularly about security principles in software development at troyhunt.com and is the author of the OWASP Top 10 for .NET developers series and free eBook of the same name. Troy is also the creator of the recently released Automated Security Analyser for ASP.NET Websites at asafaweb.com. Troy is a DZone MVB and is not an employee of DZone and has posted 67 posts at DZone. You can read more from them at their website. View Full User Profile

Lousy ABC Cryptography Cracked in Seconds as Aussie Passwords are Exposed

03.01.2013
| 2066 views |
  • submit to reddit

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:

  1. user_id
  2. user_age
  3. user_town
  4. user_nick
  5. user_regip
  6. addedtomap
  7. user_email
  8. user_gender
  9. isModerator
  10. user_password
  11. user_updateip
  12. hhscore_score
  13. user_postcode
  14. postcode_state
  15. user_lastLogin
  16. user_statusText
  17. user_info_public
  18. user_regDateTime
  19. hhscore_testDate
  20. user_latitude_min
  21. user_latitude_max
  22. user_longitude_min
  23. user_info_approved
  24. user_longitude_max
  25. user_statusFlagged
  26. user_updateDateTime
  27. 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:

  1. 7907c2d05ed0039357d08433049877341e2b635d
  2. 08207f637617d60a7f5d478ebab54e5e9d160dff
  3. f7a9e24777ec23212c54d7a350bc5bea5477fdbb
  4. ef9e6d538efda4b736776330850218adc2f8e6b1
  5. ae5728815eff76b748cddab86f926642c5d168dd
  6. 96f0878719d2d667ecf68687f3b93d29af64ac14
  7. 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:

Password hash search result

Pick one of the results:

Password hash and plain text

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:

image

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:

  1. 71ede320c5ec9d7551b0f12e0e62e6912b2d9a32:000111222
  2. 68cbbe7db52ebfdb3ae38f54484a71c536ae1809:!@#123qwe
  3. 004c5f9c1491b0bd0b88260b8e3854038f66b2ed:$p0ng3b0b
  4. 11b5d7225c43267a0776dbe71174abd8c7e16fd6:00003796
  5. c0be05fd3dfd1c390f073a618c8f706ad3f4e8a9:02062002
  6. 88bce010e57c66e450d1318ecd21a70be3cd7e7a:07121991
  7. 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.

Published at DZone with permission of Troy Hunt, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)