Attached is a patch to decrypt DCE/RPC conversations that make use of NTLMSSP version 1.
Here is a summary of the changes:
* Add a configuration option to the NTLMSSP section for the user password
* Based on the challenge and the user provided password, compute the SSP key
* Decrypt the DCE stub and NTLMSSP verifier using the key
* Store the decrypted payload in the packet state structure. This is done because RC4 is stateful, and the packets need to be decrypted in the correct order.
* Changes to packet-dcerpc.c to decrypt the verifier AFTER the stub. This is because of the RC4 statefulness.
* Dissect the verifier fields after decryption (CRC32, verifier sequence number)
* Expanded the NTLMSSP packet state to be a struct, instead of just containing the flags field.
* Added crypt-des.c and crypt-des.h. These currently include only support for DES-ECB (electronic code book mode). Ideally, when someone needs additional support for CBC or 3DES modes, they can be added to this file.
Here is what is still outstanding:
* Support for NTLMSSP version 2. I believe the decryption routine is the same, but the key negotiation is different, using HMAC-MD5 (according to LKCL and the Samba source). I separated the key setup from the decryption with the expectation that an alternate SSP key can be generated, then the actual decryption routines should be unchanged.
* The ability to dissect the decrypted payload. I need to be able to hand the TVB with the decrypted buffer back to the calling dissector. Not quite sure what the best approach for this is this yet.
* Determine if a challenge-response is valid for a given password. I broke the dissect_ntlmssp_blob result into a struct, with the expectation that I can compare the challenge-response in the packet with the challenge response computed in Ethereal. Just didn't get to it yet. This is why the dissect_ntlmssp_blob() function goes through the trouble of storing the result, yet I don't do anything with it.
Please email with comments, problems, etc. Also, if there are cases where it doesn't work with a particular trace, please include the trace and the password of the connecting client.
I've also attached a trace to demonstrate the functionality. The frames 23 through 26 get decrypted as a result of the NTLMSSP setup that occurs in frames 20 and 21.
Thanks,
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc
Attachment:
crypt-des.c.gz
Description: application/gzip
Attachment:
crypt-des.h.gz
Description: application/gzip
Attachment:
decrypt.diff.gz
Description: application/gzip
Attachment:
new_nt4w_to_nt4s_passchange_abcd_to_efgh.eth
Description: Binary data
