Update to NTLM docs
Eric Glass
eric.glass at gmail.com
Wed Sep 6 18:22:41 GMT 2006
The second sealing operation had me puzzled for a bit; but it looks
like the output buffer from the first sealing operation is being
inadvertently passed as the input buffer for the second (i.e. rather
than encrypting 0x000102030405060708 as the second message, it is
encrypting 0x2097118ac9f028260b - the ciphertext from the first
encryption).
The attached is marked up with more details, but briefly:
key = 0xae33a32dca8c9821844f740d5b3f4d6c
for the first sealing:
RC4(key, 0x000102030405060708) = 0x2097118ac9f028260b
CRC32(0x000102030405060708) = 0x0243e1bc
trailer = 0x00000000 + crc + sequence number = 0x000000000243e1bc00000000
RC4(0x000000000243e1bc00000000) = 0x9ae5c53fc5154b1c98b2588e
trailer = 0x00000000c5154b1c98b2588e
final output = sealed message + version (0x01000000) + trailer
0x2097118ac9f028260b0100000000000000c5154b1c98b2588e
then the second sealing:
RC4(0x2097118ac9f028260b) = 0xaa483ab902a9514d98
CRC32(0x2097118ac9f028260b) = 0xd85a0e3f
trailer = 0x00000000 + crc + sequence number = 0x00000000d85a0e3f01000000
RC4(0x00000000d85a0e3f01000000) = 0x17f71dade7c41a75a4fcf23f
trailer = 0x00000000e7c41a75a4fcf23f
final output = sealed message + version (0x01000000) + trailer
0xaa483ab902a9514d980100000000000000e7c41a75a4fcf23f
On 9/6/06, Kai Blin <kai.blin at gmail.com> wrote:
> On Wednesday 30 August 2006 18:23, Eric Glass wrote:
> Hi Eric,
>
> sorry for the delay.
>
> > > Your analysis of the signing and sealing part looks good, but it seems
> > > like in the dummy case (NTLMv1, no NTLMSSP_NEGOTIATE_SIGN and
> > > NTLMSSP_NEGOTIATE_SEAL flags negotiated), the sealing is handled a little
> > > different, too. I'm currently trying to track down what is happening
> > > there. I'll let you know if I find anything useful.
> >
> > Do you have a sample? I'd be interested to take a look.
>
> Attached is a dump of a sample program I wrote that hopefully duplicates the
> output you used for your davenport site.
>
> I'm using the user "test" with the password "test1234" in the workgroup
> TESTNT. The box running the program is called CASINO01, but that shouldn't
> make a difference.
>
> I've first dumped the type 1, 2 and 3 messages, then the exported server
> context, then I ran MakeSignature on the server, and EncryptMessage twice on
> the server, the message being 0x000102030405060708.
>
> Cheers,
> Kai
>
> --
> Kai Blin, <kai Dot blin At gmail Dot com>
> WorldForge developer http://www.worldforge.org/
> Wine developer http://wiki.winehq.org/KaiBlin/
> --
> Will code for cotton.
>
>
>
-------------- next part --------------
client->server
Running communicate, dumping data:
4e544c4d5353500001000000078200a000000000000000000000000000000000
Done!
--------------------------------------------------------------------------------
4e544c4d53535000 "NTLMSSP"
01000000 Type 1 message
078200a0 Flags
Negotiate Unicode (0x00000001)
Negotiate OEM (0x00000002)
Request Target (0x00000004)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Negotiate 128 (0x20000000)
Negotiate 56 (0x80000000)
0000000000000000 Supplied Domain (empty)
0000000000000000 Supplied Domain (empty)
--------------------------------------------------------------------------------
server->client
Running communicate, dumping data:
4e544c4d53535000020000001000100030000000058282a036d60c838692d2870000000000000000
540054004000000043004100530049004e004f00300031000200100043004100530049004e004f00
300031000100100043004100530049004e004f00300031000400100063006100730069006e006f00
300031000300100063006100730069006e006f003000310000000000
Done!
--------------------------------------------------------------------------------
4e544c4d53535000 "NTLMSSP"
02000000 Type 2 message
1000100030000000 Target Name header (length 16, offset 48)
058282a0 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Target Type Server (0x00020000)
Negotiate Target Info (0x00800000)
Negotiate 128 (0x20000000)
Negotiate 56 (0x80000000)
36d60c838692d287 Challenge
0000000000000000 Context
5400540040000000 Target Information header (length 84, offset 64)
43004100530049004e004f0030003100 Target Name ("CASINO01")
Target Information block:
02001000 NetBIOS Domain Name (length 16)
43004100530049004e004f0030003100 "CASINO01"
01001000 NetBIOS Server Name (length 16)
43004100530049004e004f0030003100 "CASINO01"
04001000 DNS Domain Name (length 16)
63006100730069006e006f0030003100 "casino01"
03001000 FQDN Host Name (length 16)
63006100730069006e006f0030003100 "casino01"
00000000 Target Information Terminator
--------------------------------------------------------------------------------
client->server
Running communicate, dumping data:
4e544c4d53535000030000001800180064000000180018007c0000000c000c004000000008000800
4c00000010001000540000000000000094000000058280a054004500530054004e00540074006500
7300740043004100530049004e004f0030003100d5f31ec735534ea02f7c798857d0b852abc89770
2730853a8c52b39f2be544af3b0e188cccf62b14450e97f64e48489a
Done!
--------------------------------------------------------------------------------
4e544c4d53535000 "NTLMSSP"
03000000 Type 3 message
1800180064000000 LM/LMv2 Response header (length 24, offset 100)
180018007c000000 NTLM/NTLMv2 Response header (length 24, offset 124)
0c000c0040000000 Domain Name header (length 12, offset 64)
080008004c000000 User Name header (length 8, offset 76)
1000100054000000 Workstation Name header (length 16, offset 84)
0000000094000000 Session Key header (empty)
058280a0 Flags
Negotiate Unicode (0x00000001)
Request Target (0x00000004)
Negotiate NTLM (0x00000200)
Negotiate Always Sign (0x00008000)
Negotiate Target Info (0x00800000)
Negotiate 128 (0x20000000)
Negotiate 56 (0x80000000)
54004500530054004e005400 Domain Name ("TESTNT")
7400650073007400 User Name ("test")
43004100530049004e004f0030003100 Workstation Name ("CASINO01")
d5f31ec735534ea02f7c798857d0b852abc897702730853a LM/LMv2 Response
8c52b39f2be544af3b0e188cccf62b14450e97f64e48489a NTLM/NTLMv2 Response
--------------------------------------------------------------------------------
server->client
Running communicate, dumping data:
Done!
Dumping server context
c8b32e78c8b32e780000000000000000000000000000000060730a00058282a10000000000000000
a8aa1300a8aa130028ab130028ab13000000000000000000d0020000000000000000000000000000
00000000000000000200000000000000ffffffffffffff7f20050000ae33a32dca8c9821844f740d
5b3f4d6cae33a32dca8c9821844f740d5b3f4d6cae33a32dca8c9821844f740d5b3f4d6cae33a32d
ca8c9821844f740d5b3f4d6c000000000000000000000000ae3787b72ff94884680d3e5658c064df
9d9e5d8f0655f22a002ebc7e9f944e2908cf90e0057f622d31a92b7d0ca6f586d5d36e24af70cdbe
52ea49d067aa4ffae85a5cb1a41e3241a288f8de8a4c8909593cc698b657750af014b26f13778eee
855310d716f61ce5c795a0a3bbac358bb02611c954a54b2791d6e297f1fd8c6d18fffc190b9c69b8
0122f7c8fb036146c2b581443960fe239b967b17e33de15b73e445401f1db3a8c5ad51f48d665e38
796b8263b9ca363f763aef71d1ec12d8a76cb46a333b0fddab7850ba3493dcd4077299d22515eb5f
300221e9e79a80d91a1b4d2865e6ccc3470eda7c4ace04bfbddbedc1cb207483f343c4a1422c7a92
00000000000000000000000000000000ae3787b72ff94884680d3e5658c064df9d9e5d8f0655f22a
002ebc7e9f944e2908cf90e0057f622d31a92b7d0ca6f586d5d36e24af70cdbe52ea49d067aa4ffa
e85a5cb1a41e3241a288f8de8a4c8909593cc698b657750af014b26f13778eee855310d716f61ce5
c795a0a3bbac358bb02611c954a54b2791d6e297f1fd8c6d18fffc190b9c69b80122f7c8fb036146
c2b581443960fe239b967b17e33de15b73e445401f1db3a8c5ad51f48d665e38796b8263b9ca363f
763aef71d1ec12d8a76cb46a333b0fddab7850ba3493dcd4077299d22515eb5f300221e9e79a80d9
1a1b4d2865e6ccc3470eda7c4ace04bfbddbedc1cb207483f343c4a1422c7a920000000000000000
43004100530049004e004f00300031005c007400650073007400
Done
--------------------------------------------------------------------------------
c8b32e78c8b32e7800000000000000000000000000000000
60730a00 server context handle dwUpper
058282a1 flags
0000000000000000
a8aa1300a8aa130028ab130028ab13000000000000000000d0020000000000000000000000000000
00000000000000000200000000000000ffffffffffffff7f20050000
ae33a32dca8c9821844f740d5b3f4d6c outbound signing key
ae33a32dca8c9821844f740d5b3f4d6c inbound verifying key
ae33a32dca8c9821844f740d5b3f4d6c outbound encrypting key
ae33a32dca8c9821844f740d5b3f4d6c inbound decrypting key
000000000000000000000000
ae3787b72ff94884680d3e5658c064df
9d9e5d8f0655f22a002ebc7e9f944e2908cf90e0057f622d31a92b7d0ca6f586d5d36e24af70cdbe
52ea49d067aa4ffae85a5cb1a41e3241a288f8de8a4c8909593cc698b657750af014b26f13778eee
855310d716f61ce5c795a0a3bbac358bb02611c954a54b2791d6e297f1fd8c6d18fffc190b9c69b8
0122f7c8fb036146c2b581443960fe239b967b17e33de15b73e445401f1db3a8c5ad51f48d665e38
796b8263b9ca363f763aef71d1ec12d8a76cb46a333b0fddab7850ba3493dcd4077299d22515eb5f
300221e9e79a80d91a1b4d2865e6ccc3470eda7c4ace04bfbddbedc1cb207483f343c4a1422c7a92
00000000000000000000000000000000
ae3787b72ff94884680d3e5658c064df9d9e5d8f0655f22a
002ebc7e9f944e2908cf90e0057f622d31a92b7d0ca6f586d5d36e24af70cdbe52ea49d067aa4ffa
e85a5cb1a41e3241a288f8de8a4c8909593cc698b657750af014b26f13778eee855310d716f61ce5
c795a0a3bbac358bb02611c954a54b2791d6e297f1fd8c6d18fffc190b9c69b80122f7c8fb036146
c2b581443960fe239b967b17e33de15b73e445401f1db3a8c5ad51f48d665e38796b8263b9ca363f
763aef71d1ec12d8a76cb46a333b0fddab7850ba3493dcd4077299d22515eb5f300221e9e79a80d9
1a1b4d2865e6ccc3470eda7c4ace04bfbddbedc1cb207483f343c4a1422c7a920000000000000000
43004100530049004e004f00300031005c007400650073007400 "CASINO01\test"
ntlmHash = md4(password) = 0x3b1b47e42e0463276e3ded6cef349f93
NTLMUserSessionKey = md4(ntlmHash) = 0xae33a32dca8c9821844f740d5b3f4d6c
Key is *not* weakened (NTLM1 only weakens Lan Manager Session Keys).
sign/seal key = 0xae33a32dca8c9821844f740d5b3f4d6c
--------------------------------------------------------------------------------
MakeSignature on the server side
Dumping signature:
01000000000000000000000000000000
Done!
--------------------------------------------------------------------------------
dummy signature = 01000000000000000000000000000000
--------------------------------------------------------------------------------
EncryptMessage on the server side
Dumping crypt
2097118ac9f028260b0100000000000000c5154b1c98b2588e
Done!
--------------------------------------------------------------------------------
key = 0xae33a32dca8c9821844f740d5b3f4d6c
RC4(key, 0x000102030405060708) = sealed message = 0x2097118ac9f028260b
CRC32(0x000102030405060708) = 0x0243e1bc
trailer = 0x00000000 + crc + sequence number = 0x000000000243e1bc00000000
(sequence number is zero, dummy signing does not increment)
RC4(0x000000000243e1bc00000000) = 0x9ae5c53fc5154b1c98b2588e
(uses the same RC4 cipher as previous, i.e. keystream not reset)
first four bytes are overwritten with a counter value; the actual value is
insignificant, and does not affect verification. In your sample it's using
four null bytes, which is kind of interesting. Might depend on the options
used for the security context, not sure.
trailer = 0x00000000c5154b1c98b2588e
final output = sealed message + version (0x01000000) + trailer
0x2097118ac9f028260b0100000000000000c5154b1c98b2588e
--------------------------------------------------------------------------------
EncryptMessage on the server side
Dumping crypt
aa483ab902a9514d980100000000000000e7c41a75a4fcf23f
Done!
--------------------------------------------------------------------------------
This one had me scratching my head for about half an hour; as the first step,
you should be seeing:
RC4(0x000102030405060708) = sealed message = 0x8ade2930cf5c7f6c9b
but you're getting 0xaa483ab902a9514d98 as the next chunk of ciphertext. I
couldn't figure out what was going on until I tried:
RC4(0x2097118ac9f028260b) = 0xaa483ab902a9514d98
i.e. it looks like you're passing the output buffer of the first encryption as
the input buffer of the second. I'm assuming that's the discrepancy you were
seeing; carrying through with that:
CRC32(0x2097118ac9f028260b) = 0xd85a0e3f
trailer = 0x00000000 + crc + sequence number = 0x00000000d85a0e3f01000000
(sequence number is one, incremented by previous trailer signature)
RC4(0x00000000d85a0e3f01000000) = 0x17f71dade7c41a75a4fcf23f
first four bytes clobbered with counter (nulls in your case again):
trailer = 0x00000000e7c41a75a4fcf23f
final output = sealed message + version (0x01000000) + trailer
0xaa483ab902a9514d980100000000000000e7c41a75a4fcf23f
If you clear out the buffer, you should get the following for the second
sealing run (hopefully):
RC4(0x000102030405060708) = sealed message = 0x8ade2930cf5c7f6c9b
CRC32(0x000102030405060708) = 0x0243e1bc
trailer = 0x00000000 + crc + sequence number = 0x000000000243e1bc01000000
(sequence number is one, incremented by previous trailer signature)
RC4(0x000000000243e1bc01000000) = 0x17f71dad3dddf5f6a4fcf23f
trailer = 0x000000003dddf5f6a4fcf23f
final output = sealed message + version (0x01000000) + trailer
0x8ade2930cf5c7f6c9b01000000000000003dddf5f6a4fcf23f
More information about the samba-technical
mailing list