Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d6ccd8ff785c30bc024cd468b054e843@smtp.hushmail.com>
Date: Wed, 28 Apr 2021 11:04:50 +0200
From: magnum <john.magnum@...hmail.com>
To: john-users@...ts.openwall.com
Subject: Re: Extracting the hash from MS word

On 2021-04-27 17:05, magnum wrote:
> On 2021-04-27 03:14, Ian B wrote:
>> I am going through an old directory and binning/checking some old 
>> documents ~2005/6 there's a few encrypted word documents for which I 
>> have forgotten the password. I successfully recovered the hash and 
>> hence the password from a few with the office2john.py script. However, 
>> for two of them this fails with the following issue
>>
>> em1.doc : invalid keySize
>> Traceback (most recent call last):
>>    File "./office2john.py", line 3148, in <module>
>>      ret = process_file(sys.argv[i].decode("utf8"))
>>    File "./office2john.py", line 3109, in process_file
>>      passinfo = find_rc4_passinfo_doc(filename, workbookStream)
>>    File "./office2john.py", line 2553, in find_rc4_passinfo_doc
>>      if typ == 3:
>> UnboundLocalError: local variable 'typ' referenced before assignment
> 
> If latest code give you an error, we have a bug somewhere. If you're 
> willing to share one of those files with us (or just me, in private 
> email) we can have a look at it.

Ian kindly sent me a copy of the file in question (Thanks!) and some 
debug prints reveal this:

em1.doc : providerType d algId 6801 algHashId 8004 keySize 56

8004 means SHA-1 and 6801 means RC4 so that's normal, but the keysize is 
56. Until now we've only ever seen 40 (courtesy of NSA) or 128 but 
trying to parse the specifications, 56 is also valid.

Actually MS-OFFCRYPTO doc says "When using CryptoAPI RC4 encryption, be 
aware that the Microsoft Base Cryptographic Provider v1.0 is limited to 
56-bit key lengths". We've seen many documents using RC4 and 128 bits, 
so maybe that text just means those documents used RC4 from somewhere 
else than CryptoAPI, or version later than 1.0... I have no idea yet.

Anyway apparently it's just a matter for us to support it. I'll need to 
experiment further but one problem is our current $oldoffice$ hash 
format: Instead of separately storing hash algorithm and key size, we 
have just a "type" which currently boils down to

0 ... MD5, RC4, 40-bit
1 ... MD5, RC4, 40-bit
2 ... currently never used but treated as MD5, RC4, 40 bit
3 ... SHA1, RC4, 40-bit
4 ... SHA1, RC4, 128-bit

I would rather put the actual algHashId, algId and keySize figures in 
there but to be backwards compatible that's a bad idea. So maybe I 
should just pick type 5 for "SHA1, RC4, 56-bit". This would also stop 
older versions of John from accepting it then handle it incorrectly - so 
probably better than repurposing type 2.

Also, until we know how to reproduce *creating* such document samples, 
or we crack one of Ian's, we can't be sure it's simply a matter of 
truncating to 56 instead of 40 all else equal: There may be some other 
magic involved.

I enclose a diff that might make Jumbo support this type but I have no 
idea it's correct.

magnum

View attachment "oldoffice56.diff" of type "text/plain" (4104 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.