Decrypting a Hash Password.

[V8N3T]

Ok, this experiment was done on my box and my box only. Its not illeagle or anything like that. All ive been trying to do is figure out how to pull a hash file out of SAM, and I have. But now I gotta figure out how to Decrypt it. Here is the hash password i pulled off my box.
Administrator:500:0e52cac67419a9a224a3b108f3fa6cb6 d:08846f7eaee8fb117ad06bdd830b7586c:::
The only thing im stuck at is decrypting it. This experiment is not a malicious attempt. Its strictly experimental. Ive been doing alot of reading the past 2 days on this particular area. But I just cant find a tool / or website to decrypt this string. I know what the password is cause i created it. But im just asking for some support on decrypting this string. Thanks again yall. "That string should decrypt to = password "

[noid]

Well, you really cant 'decrypt' a hash, per se. A hash is a one way algorithm. What you can do is take words/characters/symbols and hash them and compare the hash.

Lets say in unix (where passwords are stored in MD5 sum hashes) my password is bannana. My passwd entry would look like

noid:jN14!0x4JuIqktnKhm3d9(&l:1234:1234:noid:/home/noid:/bin/bash

Now, you cant work the hash backwards (yet, theres some crazy people working to fully break MD5). So what you would do is get a list of words and hash them out and compare them.

So, lets say you THINK my password is 'apple', you'd get a cracking program that would hash 'apple' and compare the entry to whats stored there.

So, lets say 'apple' hashes out to '0@NN9TyntwaqZI^tp01', well, thats obviously whats not store in my hashed field, so the password isnt 'apple'. So, you then try 'bannana' as a password. The password cracker hashes 'bannana' out as 'jN14!0x4JuIqktnKhm3d9(&l', which sure enough, matches the hash in the entry for my name. So, you never decrypted the password, but you figured out that it was 'bannana'.

Now, there is a little more to it(i.e. SALT numbers), but I dont want to overwhelm you with it. Get your self a copy of lophtcrack or another windows based cracker and some good wordlists. lophtcrack can run without a wordlist by brute forcing the password in 8 byte chunks, but it takes a while.

Someone correct me if I'm too far off base here.

[TheCotMan]

[Edit: Added content here:]
[Crap. Noid beat me to a reply. I am getting too slow.]

All ive been trying to do is figure out how to pull a hash file out of SAM, and I have. But now I gotta figure out how to Decrypt it.
...
But im just asking for some support on decrypting this string.

If a hash is any good, it should be one-way.

"Decrypting" is generally not what is done with a hash to find out the plain-text message.

A user's password is hashed when they change it, and that hash is stored in the system. The next time they authenticate, the system re-hashes their just entered password and compares the newly computed hash to the hash of the password stored from the last time they changed their password. This way the system never actually "decrypts" the hashed values during authentication.

The two common attack against hashed-passwords are:
* dictionary attack
* brute force attack

L0pht -> l0pht heavy industries -> @stake has had software available to use these techniques. At one time, they provided source code for the *NIX version for free, but made the GUI version for windows only available for a price.
http://www.atstake.com/products/lc/

There are papers published that discussed various problems with the network authentication as well as password storage on the local windows server in SAM DB.

Go to google and search for keywords:
hobbit mudge and SAM and/or CIFS

[Second]

Kind of makes things sound easy, like even I could do it.

:)

[Voltage Spike]

Kind of makes things sound easy, like even I could do it.

This stuff isn't security by obscurity so it doesn't have to be difficult to understand. Ideally, any attacks of this form are a brute force against the password which means the difficult part is finding enough computing power to perform the attack.

The only "interesting" properties of the problem are that you can perform the attack offline (once you've captured the hash) and, theoretically, you could find alternate "passwords" (called hash collisions) that don't match the original and won't work in other contexts.

[astcell]

If my password was "bannana" and your password was "bannana", would our hashes be exactly the same? If so, someone can write a program to hash out the entire dictionary, heck even add one and two-digit numbers at the end of the word. Then you'll have every possible hash for dictionary+2 attacks. Export the results to a searchable database and you can have a good chance at having the has you are looking for.

I got the idea from Arthur C. Clarke's "9 Billion Names of God."

[converge]

Your password really is 'bannana', isn't it?

[Voltage Spike]

If so, someone can write a program to hash out the entire dictionary, heck even add one and two-digit numbers at the end of the word.

That's the idea. If you aren't trying to gain access to a specific account, then the chances are pretty high[1] that this technique will work.

[1] I've been told that between 70-80% of all passwords fall into this category.

Your password really is 'bannana', isn't it?

The extra 'n' exists to fool astcell's precomputation attack. noid is very clever that way.

[TheCotMan]

If my password was "bannana" and your password was "bannana", would our hashes be exactly the same?

Short answer: it depends.
You read what noid referred to as a "salt"?
For conventional password hashing in *NIX systems a "salt" is included This decreases the chance that two plain-text passwords will hash to the same value-- yes it is possibe, but not likely.

When a salt is not used, then the hashes are the same.

In conventional *NIX systems, the salt is stored in the /etc/password file or /etc/shadow, and can be read as plain-text to be used when hashing the newly entered password so the same salt is used for both and the resulting hash will end up being the same when the passwords are the same.

One of the problems mentioned in the papers produced by hobbit/mudge with CIFS and hashing had to do with ways MS dealt with passwords.

Short answer:
* MS Made passwords backward compatabile with an earlier network-based IBM protocol that removed requirements for case sensitivity and other symbols with passwords. This reduced the the search space and decreased the problem substantially since multiple collisions would exist.
* MS broke 14 character passwords into 2 groups of 7 passwords and dealt with each half separately. Further, lack of a salt meant that the second half of the hash would always start with 0xCACA [when password were 7 character of length or less] and the reason for the scategorical humor in a DefCon 5 presentation. (If second half of 7 characters was "empty" and no salt was used, the hashing of "nothing" is the same each time.)

(Things have changed since then to make it a little more difficult though.)

If so, someone can write a program to hash out the entire dictionary, heck even add one and two-digit numbers at the end of the word. Then you'll have every possible hash for dictionary+2 attacks. Export the results to a searchable database and you can have a good chance at having the has you are looking for.

Yes, this idea has been around for a while. If you assume a search-space of dictionary words, and the hash does not use a salt, then you can pre-hash every "password" in your search space once, and order the hashed results into an ordered list of some sort, and then be guaranteed a search in your specificed keyspace in Big-O of log2(n) time, where n is the size of your search space. (Pretty fast)

This size (number of bytes) required to store these hashes ends up being a pretty big for most current hashes when large dictionaries are used.

When a "salt" is used, you can think of the system selecting a random string of bits of specified length (commonly about 16 bits for conventional *NIX passwords) [for password hash storage when the password is changed on the system] then each plain-text password has the possibiity of being one of roughly 65,000* different hashes. This means to completely exhaust all possible hashes for a single password, you would need to hash the same password about 65,000* times in a pre-hashed attack.

Of course, a brute force attack would almost certainly be much larger than a dictionary attack (unless the dictionary keyspace is the same size as the brute force key spcae ;-)

[*- Though in reality, the number of different usable hashes is often smaller and from 11 to 15 bits to limit characters used to "printable" and not use format string and filed separators like ":"]

[Second]

A post abounding with information

Wow..thank you very much for that post. I think I'm going to re-read it about four or five times, break it down in sections and research all of it because there's so much information there. Any way you could give me "the long answer"? It's really interesting. Thank you for sharing that with us..to show my appreciation, here's an ASCII rose

:)

[astcell]

Hmmm, the only thing needed would be a small coded algorithm which would read one file,maybe a .txt file, then generate the hashed password in a comma delimited file. Of course searching such a monsterous file may end up can take time.

Is this called warhashing?

[TheCotMan]

Hmmm, the only thing needed would be a small coded algorithm which would read one file,maybe a .txt file, then generate the hashed password in a comma delimited file.

Or maybe a SQL DB optimized for searching? Only need one table with two fields (hash / plain-text) and a query for each hash lookup. DB abstraction and overhead allows for distribution too. Ordered lists in RAM would be faster, but RAM is more expensive than Secondary Storage (HD/CD/DVD/etc)

Is this called warhashing?

I AM CORNHOLIO! Are you threatening me? heh heh. :-)

[Maybe I should start war-sleeping. heh heh hrm. yeah!]

[astcell]

SQL may be overkill but it will be faster with a big dictionary of course. So, who'se up to it?

[Floydr47]

Would the hash for "bannana" remain the same whether it was, say for instance, an AOL password or an MSN password or would each create it's own hash? If the hash changed from one to the other then the theory of hashing a dictionary + 2 wouldn't hold water would it? I mean the English language contains some 68,000 +/- words and a hash system would contain an infinite number of combinations...not being a smart ass, just thinking out loud.

[TheCotMan]

SQL may be overkill but it will be faster with a big dictionary of course. So, who'se up to it?

Though more like a flat-file with special searching and indexing in memory than a DB, it has "kind of" been done with alphanumeric passwords even though L0pht had similar ideas in their presentation for future releases.
Similar techniques were used in the "Early days" when trying to break WEP before flaws in the original protocol were exposed.

Since Proofs Of Concept have been made available, the act of using a larger dictionary is only limited by resources available. Also, this problem lends itself very well to using distributed computing in an attack and can scale very well.

Your target is someone with lots of memory and disk space, or a farm of systems they can (ab)use with a total of free-space and RAM that is large and some coding or DB skills.