wireshark decryption

[Aurélien Aptel]

re-sending on samba-technical as it might get more feedback here.

Hi,

I've sent a couple of changes to Wireshark to add a table in the the
SMB2 protocol preference to add Session ID => (secret) Session Key
mappings so that Wireshark can derive the decryption keys and decrypt
the traffic.

The way wireshark prefs works allows you to pass them via the command
line e.g.:

% ./tshark -o 'uat:custom_smb2_seskey_list:"3d00009400480000","28f2847263c83dc00621f742dd3f2e7b"' -r
~/prog/smbcrypto/filt.pcap 
...SMB2 172 Negotiate Protocol Request
...SMB2 318 Negotiate Protocol Response
...SMB2 190 Session Setup Request, NTLMSSP_NEGOTIATE
...SMB2 318 Session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE
...SMB2 430 Session Setup Request, NTLMSSP_AUTH, User: SUSE\administrator
...SMB2 142 Session Setup Response
...SMB2 180 Tree Connect Request Tree: \\WS2016\encrypted
...SMB2 150 Tree Connect Response
...SMB2 268 Decrypted SMB3;Ioctl Request FSCTL_VALIDATE_NEGOTIATE_INFO
...SMB2 258 Decrypted SMB3;Ioctl Response FSCTL_VALIDATE_NEGOTIATE_INFO
...SMB2 250 Decrypted SMB3;Create Request File:
....

Otherwise you can add them manually in
Edit > Preferences > Protocols > SMB2.

The change can be found here [1], any help in getting it reviewed/merged
welcome.

The session key is computed by the client, it's different than the
"session key" generated in SMB1 ([2]) which is sent on the wire and not
safe to use for anything cryptographic. I suspect the dissector was
already trying to use this one but it's most likely wrong.

As for obtaining the session key, I came up with 2 solutions:
- Make the kernel dump them. I will send a patch soon
  after this email on linux-cifs that adds a CIFS_DEBUG_DUMP_KEYS config
  option that simply dumps the keys on the console.
- Dump them by reading kernel memory. This can be done with gdb and
  /proc/kcore. I've attached a hackish gdb script to do that.

Fist solution is more robust and does not require any tool but it's a
bit dangerous to include code that simply dumps sensitive data like
this. I've made it clear in the config name and description that it is
not safe to enable this for anything other than debugging.

Second solution simply needs root access and gdb but structure offsets
are hardcoded in the script (probably only works on x86_64 as a
result). If the kernel debug info package is installed on the system gdb
can lookup structure offsets and so the script doesn't need to hardcode
the offsets... but it's quite large (around a GB on my system).

gdb -q /boot/vmlinux-4.4.62-18.6-default /proc/kcore      \
    -ex "source ~aaptel/prog/gdb-linux/cifs_dump_keys.py" \
    -ex 'cifs-dump'

Reading symbols from /boot/vmlinux-4.4.62-18.6-default...
done.

[New process 1]
Core was generated by `BOOT_IMAGE=/boot/vmlinuz-4.4.62-18.6-default root=UUID=74a87444-aac1-4b24-a6d1-'.
#0  0x0000000000000000 in irq_stack_union ()
[*] trying to get cifs symbols from kallsyms...
[*] OK! cifs-dump command defined
host <10.160.66.43> vers <1.0> dom <SLES11SP4> user <aaptel> pw <xxxxxxxxx>
SID <64 00 00 00 00 00 00 00>
SESKEY <00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>

host <10.160.65.202> vers <2.0> dom <SUSE> user <administrator> pw <xxxxxxxxxxx>
SID <25 00 00 44 00 50 00 00>
SESKEY <00 00 00 00 80 ce ed fb 02 88 ff ff 80 76 1c 57>

(gdb) q

1: https://code.wireshark.org/review/#/q/topic:smb2-decryption-uat
2: https://msdn.microsoft.com/en-us/library/ff470134.aspx

Cheers,

-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cifs_dump_keys.py
Type: text/x-python
Size: 4353 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170524/2950140e/cifs_dump_keys.py>