Lousy ABC cryptography cracked in seconds as Aussie passwords are exposed

Discussion in 'News Aggregator' started by Mr. Penguin, 28 Feb 2013.

  1. Mr. Penguin

    Mr. Penguin Administrator
    Staff Member Admin Moderator VIP

    18 May 2012
    Likes Received:
    Trophy Points:
    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:
    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:
    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:

    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:
    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.
  • About Us

    We are a community mixed with professionals and beginners with an interest in wireless security, auditing and pentesting. Feel free to check out and upload resources.

    You can also find us on: Twitter and Facebook

  • Donate to Us

    Did you find our forums useful? Feel free to donate Bitcoin to us using the form below. Those who donate the equivlent of $10 USD or more will be upgraded to VIP membership. Don't have Bitcoin? Use your credit card to GO VIP here. Don't want to fork out some coin? There are other ways to GO VIP. Bitcoin: 1LMTGSoTyJWXuy2mQkHfgMzD7ez74x1Z8K