Those Look Just Like Hashes!
Have you ever during a penetration test collected a list of values that look very much like hashes, and thought "I could maybe start cracking those, if I only knew what algorithm was used to calculate those hash values".
I had exactly this happen recently. In the past I've found any one of the dozens of lists of hash outputs on the net to be handy - Hashcat for instance has a pretty complete list posted ( http://hashcat.net/wiki/doku.php?id=example_hashes ). But this time I donned my googles and found the handy Hash Identifier python script at https://code.google.com/p/hash-identifier/ . This tool really saves a lot of work - these days my eyes are too old and my fingers are too big to be counting tiny characters in a hash string with any accuracy.
Hash_ID.py does a nice job of the more commmon hashes. Of course, if someone has the bad judgement to hash the output of one algorithm with another one (this is a really BAD idea if you are trying to prevent collisions), an identification utility like this will only id the last hash algorithm used.
Did it work for me? Yes, yes it did! It nicely identified the hash algorithms used. With the hashes and the algorithm, I was able to dump the list into OCLHashcat on a VM I've got for this (described here https://isc.sans.edu/forums/diary/Building+Your+Own+GPU+Enabled+Private+Cloud/16505). And the values did indeed give me a list of passwords, which I was then able to use against several different systems.
The finding of course in this situation was NOT "Nyah Nyah, I got in!", that's NEVER the finding. What goes in the report is (in a tactful way) "Application XYZ is using a simple unsalted hash algorithm to protect passwords", along with an english-language explanation of why exactly this is a bad idea, worded so that the manager of the coder who owns the XYZ application will understand it.
The end goal of a pentest isn't really to get in. The goal of a pentest is to explain to your client why fixing security related issues will benefit their business, and to get that explanation in front of the folks who decide which projects get priority. Breaking in is usually just the most fun way to make your point effectively.
Back to the tool at hand - if you've used a different hash identification utility, let us know using the comment form at the bottom of this page!
===============
Rob VandenBrink
Metafore
Comments
Source : http://www.smeegesec.com/2013/11/hashtag-password-hash-identification.html
Anonymous
Dec 10th 2013
1 decade ago
Anonymous
Dec 10th 2013
1 decade ago
Not necessarily a bad idea; it will make the hash a slower hash... mix the original input into the function to avoid creating additional collisions, from what the outer hash function has.
Finding the input via brute-force password cracking will be harder, since the attackers now need to compute the inner function at every attempt.
$a = md5($pass . BCRYPT($salt, $a . $pass) . md5($pass))
for($i = 0; $i < 10000; $i++) {
$a = sha256($a . $pass . RIPEMD_160($a . $pass))
}
$outhash = $a
Anonymous
Dec 10th 2013
1 decade ago
Anonymous
Dec 10th 2013
1 decade ago
Wondering if the ASIC devices used by BitCoin miners would allow a hacker to speed up their Hash cracking speeds. Much like the GPU can be utilized for hashing.
Given that BitCoin is just a SHA256(SHA256($a)) and while the ASIC's are designed for SHA256, would they not work at just as good efficiency doing MD5, SHA1, etc. Since they are all just similar iterations of one another to some extent or am I really off the reservation with that thought?
Did some searching and can not find any documentation on how to make calls to these devices other than I guess that a SHA256 call automatically gets routed to the device? Would be interesting to see what kind of hashing speeds could be accomplished with a reasonably low cost setup. While I would expect it to be somewhat in the same realm as the BitCoin mining hashes I wonder if doing the others (MD5, SHA1, etc) would be faster.
Anonymous
Dec 10th 2013
1 decade ago
Wondering if the ASIC devices used by BitCoin miners would allow a hacker to speed up their Hash cracking speeds. Much like the GPU can be utilized for hashing.
Given that BitCoin is just a SHA256(SHA256($a)) and while the ASIC's are designed for SHA256[/quote]/
Probably not; the mining ASICs are well, application-specific, they are not general-purpose SHA256 accelerators: they are going to be designed to take all
the shortcuts available and known to the designers, that will improve mining speed.
My understanding is they do not offer a way to perform large number of individual arbitrary SHA256 operation significantly faster than a GPU could;
if you were just feeding SHA256 inputs to a board that "accelerated SHA", then you would still be involving the CPU with each hash request -- with an expensive I/O stage.
The mining devices take more work than the SHA256 off the CPU; they also take work off the CPU involving what inputs to use for the SHA256 hash function.
For example: The mining devices may take a workload involving calculating the SHA256 of the preliminary portion (Hash the first part), achieving a SHA midstate
then this SHA256 midstate is reused for different 2^32 NONCE values. It is just the NONCE that is incremented.
Until the hash result is within the target range.
See
https://bitcointalk.org/index.php?topic=51281.msg612224#msg612224
"The midstate is the SHA-256 hashing state after hashing the first chunk (64) bytes of the block header. After you get a block header from the server, you typically hash the first chunk 1 time, and hash the second chunk 2^32 times going through all the possible nonce values. ...
Because the nonce is in the second chunk, there is no need to hash the first chunk over and over every time you try a new nonce value."
Anonymous
Dec 10th 2013
1 decade ago
If I suspect, that in the future, one of the hash algorithms might contain a flaw or intentional backdoor, then mixing algorithms
can increase confidence in a way that using a single slow algorithm does not.
I am also making things harder, and increasing costs and amount of work potential attackers will have to do,
since they will not simply be able to re-use readymade toolkits they already have, or tools such as Hash_ID.
The hash will not be enough -- they will actually need to gain access to source code, most likely, and
have to spend time analyzing the password hashing system, and working on building their software to conduct
an attack against the hashes.
It is a good idea to increase the costs potential attackers will have to incur, as much as possible.
Anonymous
Dec 10th 2013
1 decade ago
Citation please. Since the output of a good hash is supposed to be as close to random noise as possible, it seems that applying a second round of hashing from the same hash would be no different that a second (or more) round from a different hash, assuming both are designed for security.
Anonymous
Dec 11th 2013
1 decade ago