Cracking HSRP MD5 authentication "hashes"

[Dhiru Kholia]

Hi,

I have added support for cracking HSRP MD5 authentication "hashes" to
JtR-jumbo (in the bleeding-jumbo branch), which you can get from the
following URL,

https://github.com/magnumripper/JohnTheRipper

$ python ../run/hsrp2john.py HSRP-auth-md5-openwall.pcap > hsrp-hashes

$ ../run/john hsrp-hashes -w=wordlist
Loaded 5 password hashes with 5 different salts (hsrp, HSRP MD5 ...)
openwall (?)
...

$ OMP_NUM_THREADS=2 ../run/john --format=hsrp --test # i7-4750HQ
Will run 2 OpenMP threads
Benchmarking: hsrp, HSRP MD5 authentication [MD5 32/64]...
Many salts: 5240K c/s real, 2620K c/s virtual
Only one salt: 4503K c/s real, 2263K c/s virtual

Sample .pcap files are available on the https://github.com/kholia/my-pcaps
page. This repository also documents the reversing process for fun.

Dhiru

[Solar Designer]

Hi Dhiru,

Post by Dhiru Kholia
I have added support for cracking HSRP MD5 authentication "hashes" to
JtR-jumbo (in the bleeding-jumbo branch), which you can get from the
following URL,
https://github.com/magnumripper/JohnTheRipper
$ python ../run/hsrp2john.py HSRP-auth-md5-openwall.pcap > hsrp-hashes
$ ../run/john hsrp-hashes -w=wordlist
Loaded 5 password hashes with 5 different salts (hsrp, HSRP MD5 ...)
openwall (?)
...

Cool. Thanks!

Can't you make this a "dynamic" mode, though? This would both avoid the
need for a new C source file, and run faster (can use SIMD right away).

I just took a look at hsrp_fmt_plug.c and I think this could probably be
expressed in terms of Jim's existing dynamic formats interface.

As you have noticed, I almost always suggest this when you add a new
format that uses only MD5 or SHA-1. Perhaps this is the approach you
should always start with, and only fall back to writing C code when the
dynamic approach fails?

Also, hsrp2john.py is missing a public domain statement and/or a license.
Actually, the same applies to some other *.py files you contributed.
Can you please apply the license terms from lotus2john.py for the rest
of the Python scripts where you're the sole author as well?

Post by Dhiru Kholia
Sample .pcap files are available on the https://github.com/kholia/my-pcaps
page. This repository also documents the reversing process for fun.

Nice. Can you please also add these samples to:

http://openwall.info/wiki/john/sample-non-hashes

Twitter:

<@WEareTROOPERS> @DhiruKholia @solardiz @digininja Once you have those hashes, you may put them to proper use with #Loki http://www.insinuator.net/tag/loki/
<@solardiz> @WEareTROOPERS @DhiruKholia @digininja Also relevant: http://packetlife.net/blog/2008/oct/27/hijacking-hsrp/ http://www.gotohack.org/2011/01/scapy-hsrp-md5-auth-dissecter-to.html http://bb.secdev.org/scapy/pull-request/27/add-support-for-md5-authentication-in-hsrp/diff

Alexander

[Dhiru Kholia]

On Wed, 3 Sep 2014, Solar Designer wrote:

Hi!

Post by Solar Designer

Post by Dhiru Kholia
I have added support for cracking HSRP MD5 authentication "hashes" to
JtR-jumbo (in the bleeding-jumbo branch), which you can get from the
following URL,

Can't you make this a "dynamic" mode, though? This would both avoid the
need for a new C source file, and run faster (can use SIMD right away).
I just took a look at hsrp_fmt_plug.c and I think this could probably be
expressed in terms of Jim's existing dynamic formats interface.

Jim is already on it (http://tinyurl.com/HSRP-discussion).

Post by Solar Designer
As you have noticed, I almost always suggest this when you add a new
format that uses only MD5 or SHA-1. Perhaps this is the approach you
should always start with, and only fall back to writing C code when the
dynamic approach fails?

Yes, this would be ideal. I wish I had more time (and courage) to
understand the dynamic primitives.

Post by Solar Designer
Also, hsrp2john.py is missing a public domain statement and/or a license.
Actually, the same applies to some other *.py files you contributed.
Can you please apply the license terms from lotus2john.py for the rest
of the Python scripts where you're the sole author as well?

This should be fixed now. Thanks!

Post by Solar Designer

Post by Dhiru Kholia
Sample .pcap files are available on the https://github.com/kholia/my-pcaps
page. This repository also documents the reversing process for fun.

http://openwall.info/wiki/john/sample-non-hashes

Done now.

http://openwall.info/wiki/john/sample-non-hashes#HSRP-MD5-auth-packets

Post by Solar Designer
...
http://bb.secdev.org/scapy/pull-request/27/add-support-for-md5-authentication-in-hsrp/diff

Thanks for finding all these links! I have been trying to crack HSRP MD5
scheme for a while now ;)

Dhiru

[jfoug]

-----From: Dhiru Kholia Wednesday, September 03, 2014 3:58

Post by Dhiru Kholia

Post by Solar Designer
Can't you make this a "dynamic" mode, though? This would both avoid
the need for a new C source file, and run faster (can use SIMD right

away).

Post by Dhiru Kholia

Post by Solar Designer
I just took a look at hsrp_fmt_plug.c and I think this could probably
be expressed in terms of Jim's existing dynamic formats interface.

Jim is already on it (http://tinyurl.com/HSRP-discussion).

I had to create a custom function for this. This format is strange. It is
this:

md5(pad_md64($p).$s.$p) The pad_md64 is a proper 'buffer' for MD5, but it
is not sent to MD5_Final. It contains the high bit set (the 0x80 after the
password), and length of bits in the last 8 bytes of a %64==0 sized null
padded buffer. Then to that unprocessed buffer, the salt and password are
again appended, then the resultant buffer is run through MD5.

So until I added that buffer-padding logic, there was not a way to do this
format in dyna. Also, the salts appear to be largely made up of null bytes.
I 'believe' this can be handled in dyna, I am just not 100% sure it is
handled 100% cleanly. I believe that dyna does 'late' $HEX$ removal if
there is NULL bytes intermixed in the salt. I simply have not had time to
view all the nuances. It may be that hashes are not removed if they are
already in a .pot file, or some other tricky stuff that we get into when we
have to modify salts.

Yes it is being put into dyna. It uses the 'flat' SIMD model, which builds
flat buffers (can handle up to 256 bytes of 'flat' buffer space, and then
performs the SIMD MD5 operations required (2 or 3 limbs). I know there will
be issues I have to work through. I will have to sort and order these (I do
not think dynamic can that now), since length of passwords will deem if this
is a 2 or 3 limb MD5. I will have to group all 2 limb and all 3 limb
passwords, packing them into the SSE-PARA sized groups. I had to do this on
some other format recently (do not remember which one), but that was not
dynamic. So this may still have to be handled with an external .C file (thin
format), and that extra logic will be put into that file, and simply use
dyna to process. The current code works fine (the .C file Dhiru wrote),
since it uses CTX model to process 1 hash at a time. If one password uses 2
limbs, and the next 3, then that is not a problem. But when you get into
intermixed SIMD code, you pretty much need to have all grouped items to have
the same processing.

So yes, I have started this as a POC within dyna, BUT it is not prime time
ready.

Also, I am not sure just how prevalent this format is, or if it is even
still in the wild. The RFC is from '95 so this is pretty much antique as
far as computing is concerned.