Hashmash is a tool to aid in generating various hashes from user supplied values. Occasionally on a test you’ll see some dodgy looking functionality that you might look at and say ‘that looks vulnerable’. For example password reset functionality that returns an MD5 hash of something. Here’s where Hashmash comes in. Kudos to @ for the name 😉
Say you are assessing an application from an authenticated perspective and you have access to a user profile. You might perform a password reset from which you are emailed a link resembling www.vulnerablecompany.xyz/passwordreset=e23e4ae268f4ba432e74e625e6600e59. There are a number of attack vectors to explore here, but in this post we’ll assume (as pointed out by@ this is generally, never a good thing to do) this IS a hash and just look at ways it may possibly have been constructed. How has this been generated? What might it be based on? Are these values predictable? Let’s see…
In this example we have access to the user account so we might know, or be in a position to make an educated guess, of some key values that could be used to generate this MD5 hash. Perhaps it’s a combination of all, some or none of; firstname, surname, ID, email address or even a Epoch value. Using Hashmash we can supply a list of variables in a file, choose the hashing algorithm (i.e. MD5, SHA1 etc.) select any delimiters that might have been used to separate the values, for example firstname:surname or firstname&surname, and then generate a hash for each combination. The aim is to try and get a match of the hash we have and therefore we can deduce that the password reset link might be constructed in the form of ID:firstname:emailaddress or Epoch:ID:name etc. With this knowledge we could then potentially change the password for another valid account as we have ‘cracked’ the construction!
In this release of Hashmash we can choose to add a Epoch value to the generated values that span a timerange. For example if we requested the password reset on 01/04/2016 at 10:25:06 (and we can validate/assume that the server time is roughly in the same ballpark) and we might think/test/cross fingers and press go, that perhaps the Epoch value has been used as part of the value? We can generate Epoch values for the range 01/04/2016 10:24:00 to 01/04/2016 10:26:00 (just to cover some irregularities and/or differences in time settings between systems) and then each of these timestamps can be tested with the user defined values in turn. There is the option to generate time since Epoch in milliseconds (using the –milli switch), but obviously this would generate a large number of Epoch values, and this script is built to just work and not for efficiency!
Let’s say our values.txt file contains the values 1, 2, 3. Running Hashmash in the most basic mode will generate the following combinations.
Cleartext Value: 1 c4ca4238a0b923820dcc509a6f75849b Cleartext Value: 2 c81e728d9d4c2f636f067f89cc14862c Cleartext Value: 3 eccbc87e4b5ce2fe28308fd9f2a7baf3 Cleartext Value: 12 c20ad4d76fe97759aa27a0c99bff6710 Cleartext Value: 13 c51ce410c124a10e0db5e4b97fc2af39 Cleartext Value: 21 3c59dc048e8850243be8079a5c74d079 Cleartext Value: 23 37693cfc748049e45d87b8c7d8b9aacd Cleartext Value: 31 c16a5320fa475530d9583c34fd356ef5 Cleartext Value: 32 6364d3f0f495b6ab9dcf8d3b5c6e0b01 Cleartext Value: 123 202cb962ac59075b964b07152d234b70 Cleartext Value: 132 65ded5353c5ee48d0b7d48c591b8f430 Cleartext Value: 213 979d472a84804b9f647bc185a877a8b5 Cleartext Value: 231 9b04d152845ec0a378394003c96da594 Cleartext Value: 312 950a4152c2b4aa3ad78bdd6b366cc179 Cleartext Value: 321 caf1a3dfb505ffed0d024130f58c5cfa
OK, let’s generate a ‘test’ hash:
echo -n 1459970019:surname:firstname.lastname@example.org | md5sum
Run the script:
python hashmash.py --match e23e4ae268f4ba432e74e625e6600e59 --alg 1 --delim 2 --file values.txt --st "2016-04-06 19:13:00" --et "2016-04-06 19:15:00" --sec
[+] Gotya! 1459970019:surname:email@example.com
Compatibility for v0.1:
Tested on Kali 2.0/Python 2.7.9 and Ubuntu 14.04/Python 2.7.6 platforms.
I’m not a developer! The code is rough, very very rough. I know this. But it works. Hopefully.
Feedback, improvement suggestions (and additions) are always welcome.