Neil Developer

NTLM认证协议及SSPI的NTLM实现

2014-03-30
Neil

没错,NTLM就是微软应用最广泛的认证协议之一。 NTLM是NT LAN Manager的缩写,这也说明了协议的来源。NTLM 是 Windows NT 早期版本的标准安全协议。Windows 2000内置三种基本安全协议之一。 NTLM适用范围非常广,既可用于域内的认证服务, 也可用于没有AD的环境,让两台独立电脑相互认证。

你可能知道NTLM可以认证用户身份,但是你可能不知道NTLM可以提供会话安全服务(NTLM Session security)。 

本文也会分成几篇来写, 现在计划可能包含下面几个大方面的内容:

1.  NTLM协议的认证

包括 NTLMv1  和 NTLMv2 两个版本。  涉及到NTLM的认证全过程,以及NTLM 的 EPA(Extended Protection for Authentication)实现。

2. NTLM Session Security

即NTLM的会话安全,或者说是NTLM的SSPI实现。 这一部分内容可能不是很常用,能找到的资料也比较少。 这里先简单的说两句。 我们都知道NTLM可以用于认证,实际上,认证过后,NTLM还能提供安全服务。 比如提供对后续通信的安全签名,防篡改,或者对后续通信进行安全可信赖加密,防止被窃听。这一部分实际上是微软SSPI服务内容。 SSPI是Security Support Provider Interface(Microsoft安全支持提供器接口)。  SSPI是一个安全框架,很多协议都对它有实现。 比如我们熟知的Kerberos认证协议,它也有SSPI实现的部分。

3. NTLM消息的实例

这一部分,我们会找一个具体的实例来解释认证的全过程。


值得注意的是 NTLM 现在已经不光用于windows平台了,Linux 或者 java 平台也可以进行 NTLM 认证,使用 NTLM 的安全服务(但是Java平台对NTLM的会话安全支持貌似有问题)。

作为一个开始,我们先来介绍几个基础概念, 概念清楚了,然后再看技术细节。

1. 什么是认证。

认证就是承认和证明的意思。 就是你能证明你的身份。 比如你要访问一个受保护的资源,服务器需要认证你的身份。 你可以声称你是系统管理员, 但是怎么证明你就是管理员呢。 方法很多,这里有个简单直接的方法就是证明你知道管理员的密码。

认证的问题转化为: 怎么证明你知道你所声称的用户的密码?.

一个简单暴力的证明方法是,让你直接提供密码给服务器,然后服务器去数据库里面比对,看你提供的密码对不对。如果对,认证通过。否则失败。 常见的所谓Windows Forms认证,或者叫做windows basic 认证就是这种方式。 简单直接。 但是密码需要在网络上传输,安全问题就不说了,你懂的。

怎样在不直接提供密码的情况下,间接证明你知道密码呢?  NTLM就是干这个的了。

  • 什么是NTLM 认证。

NTLM是一种在不直接提供密码的情况下,间接证明客户端知道用户密码的方法。

NTLM认证最常见的应用场景恐怕就是用在浏览器(http协议)上的认证了。 但是实际上,NTLM 只规定了认证的流程,和认证消息格式。 并不跟具体的协议相关。 所以跟http就更没有必然联系了。 浏览器只是在http协议头上携带了NTLM的消息而已,通过了认证。 我们知道http通常是明文的,所以如果直接传输密码非常不安全,NTLM就有效的防止了这个问题。

怎么理解这个问题呢,举个夸张点的例子,  如果不嫌烦,客户端和服务端甚至可以通过传递小纸条的方式传递NTLM消息,来认证身份。 而纸条的内容是明文的, 中间传递者都可以随意查看,但是却无法知道密码,也无法伪造。

现在可以开始技术细节了, 我们还是采取由大及小的方式。 先从整体介绍,再逐步深入。

  • NTLM 的 认证消息,及认证流程。

前面说过了,NTLM消息并不和任何传输协议绑定, 它的认证消息理论上可以通过任何方式传递,所以我们的讨论都集中在协议本身,而不去关心下层的传输方式。

我们先看一个图:

image

NTLM认证共需要三个消息完成:

(1).  Type1 消息。 Negotiate 协商消息。

客户端在发起认证时,首先向服务器发送协商消息。 协商需要认证的主体,用户,机器以及需要使用的安全服务等等信息。 并通知服务器自己支持的协议内容,加密等级等等。

 

(2). Type2 消息。 Challenge 挑战消息。

服务器在收到客户端的协商消息之后, 会读取其中的内容,并从中选择出自己所能接受的服务内容,加密等级,安全服务等等。 并生成一个随机数challenge, 然后生成challenge消息返回给客户端。

 

(3). Type3 消息。 Authenticate认证消息。

客户端在收到服务端发回的Challenge消息之后, 读取熬服务端所支持的内容,和随机数challenge。  决定服务端所支持的内容是否满足自己的要求。 如果满足,则使用自己的密码以及服务器的随机数challenge通过复杂的运算,期间可能需要自己生成一个客户端随机数client challenge也加入运算, 并最终生成一个认证消息。并发回给服务器。

 

(4). 服务器在收到 Type3的消息之后, 回经过几乎同样的运算,并比较自己计算出的认证消息和服务端发回来的认证消息是否匹配。如果匹配,则证明客户端掌握了正确的密码,认证成功。 允许客户端使用后续服务。  如果不匹配,则认证失败。

 

  1. NTLM 认证消息的结构.

NTLM的消息很简单, 只有三种, Type1,  Type2 和 Type3.   它们都有相似的结构。  认证消息都是二进制的,但是通常我们见到的都是它们的Base64的编码格式。 类似这种:

TlRMTVNTUAADAAAAGAAYAHAAAACSAJIAiAAAAAAAAAAAAAAAGgAaAEgAAAAOAA4AYgAAAAAAAAAAAAAABYKIogAAAAAAAAAPYQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgBOAEUASQBMAC0AUABDALZLpLeO2n6Sx1s9JjrAfQOqf2QsmfTeP9cjC86k7BsjZEsKzjOoYBcBAQAAAAAAAEDGE3IuR88Bqn9kLJn03j8AAAAAAgAEAEsAQQABAAoARgBTAFcARQBCAAQADABrAGEALgBjAG8AbQADABgAZgBzAHcAZQBiAC4AawBhAC4AYwBvAG0ABQAMAGsAYQAuAGMAbwBtAAcACAC0gtdyLkfPAQAAAAAAAAAA

所以,如果你看到这种形式不要吃惊,把他们用Base64解码即可。

协议中的数字都是采用小端的方式存储。

(1).  消息头

这三种消息都具有相似的消息头:

image

 

 

(2) Flags 标记。

这三种消息一般都会携带一个 4字节的int值, 作为消息的Flags。 Flags在三种消息中的位置不一样,所以没有当做消息头来介绍。 不过,这个flags非常重要。这里先单独来介绍:

(下面是我的代码片段,重点标志我做了注释,后面用到的时候会进一步介绍)


flagsExps[0x1] = "Unicode"; flagsExps[0x2] = "OEM"; flagsExps[0x4] = "Request Target"; flagsExps[0x8] = "r10(must be zero)"; flagsExps[0x10] = "Negotiate Sign"; // 需要协商签名服务 flagsExps[0x20] = "Negotiate Seal"; // 需要协商加密服务 flagsExps[0x40] = "Negotiate Datagram Style"; //UDP 非连接模式 flagsExps[0x80] = "Negotiate Lan Manager Key"; // 在某些特定的NTLMv1下使用 Lan manager key 后面会详细介绍 //================================ flagsExps[0x100] = "Negotiate Netware(r9 must be zero)"; flagsExps[0x200] = "Negotiate NTLM"; flagsExps[0x400] = "r8(should be zero)"; flagsExps[0x800] = "Negotiate Anonymous"; //使用匿名登录 flagsExps[0x1000] = "Negotiate Domain Supplied"; flagsExps[0x2000] = "Negotiate Workstation Supplied"; flagsExps[0x4000] = "Negotiate Local Call(r7)"; flagsExps[0x8000] = "Negotiate Always Sign"; //=============================== flagsExps[0x10000] = "Target Type is a Domain."; flagsExps[0x20000] = "Target Type is a Server."; flagsExps[0x40000] = "Target Type Share(r6)"; flagsExps[0x80000] = "Negotiate NTLM2 Key(EXTENDED_SESSIONSECURITY)"; //使用扩展会话安全 flagsExps[0x100000] = "Request Init Response(NTLMSSP_NEGOTIATE_IDENTIFY)"; flagsExps[0x200000] = "Request Accept Response(r5, must be zero)"; flagsExps[0x400000] = "Request Non-NT Session Key"; flagsExps[0x800000] = "Negotiate Target Info"; //协商 携带 TargetInfo //=============================== flagsExps[0x1000000] = "r4(must be zero)"; flagsExps[0x2000000] = "NTLMSSP_NEGOTIATE_VERSION(协商携带操作系统版本号, 一般会忽略此项,仅供调试用途 )"; flagsExps[0x4000000] = "r3(must be zero)"; flagsExps[0x8000000] = "r2(must be zero)"; flagsExps[0x10000000] = "r1(must be zero)"; flagsExps[0x20000000] = "Negotiate 128"; // 协商128位加密 flagsExps[0x40000000] = "Negotiate Key Exchange"; //协商交换key, 在会话安全中,使用交换key来加密内容,而不是直接使用会话key flagsExps[0x80000000] = "Negotiate 56"; //协商56位加密

(3). Type 1 消息

我这里使用下面参考文档2中的一个图来介绍:

image

 

a . 前面首先是 8个字节+4个字节的 协议头。前面已经介绍过了。注意,消息类型为1

b . 然后是四个字节的Flags。 前面也介绍过了。  这个Flags中表达了客户端想要使用的NTLM的认证服务, 以及客户端自己所支持的服务。

 

c. 然后,是若干个可选的security buffer。

注意上图中的 security buffer, 安全缓冲区。 它是一个8字节固定大小的结构体。它看起来像是这个样子:

image

它其实是一个缓冲区指针。 它指向一个区域, 这个区域相对于Type1消息起始的偏移量为 offset, 这个区域的大小长度为 MaxLength, 其中的有效使用大小为:Length.

 

如果 Flags 中包含 0x1000 标记, 则需要提供域。把域名写入到这个缓冲区中。 字符集由Flags中的 OEM或者Unicode决定。

 

如果Flags中包含0x2000标记,则需要提供workstation的名字。  方法同上。

 

d. 然后是8字节的操作系统版本号。

如果Flags中包含0x2000000, 则需要提供 操作系统的版本号。

操作系统版本号的写法,请参考 参考文档1 的 2.2.2.10 节。

image

 

e. 然后,就是携带的前面security buffer中所指向的数据了。

 

在Type1的消息中,只有前面的 a 和 b项,是必须的, 后面的都是可选的。

 

 

 

(4) Type2 消息

服务端在收到 Type1消息之后, 会生成Type2消息返回给客户端。

这个也比较简单,我们还是用 参考文档2 中的一个图来介绍:

 

image

 

a . 前面首先还是 8个字节+4个字节的 协议头。前面已经介绍过了。 注意此时的消息类型已经是 2了。

b . 然后是四个字节的Flags。 前面也介绍过了。  这个Flags中表达了服务端所能接受的服务。

 

c. 上图中的TargetName 是要访问的机器名。 存储方法是security buffer. 前面介绍过了,不多说了。

 

d. Flags 不多说了。

 

e. Challenge, 这是一个服务端生成的8字节的随机数, 客户端会用来计算key. 后面会详细介绍用法。

 

f. Context, 这是一个8字节的值,其实是两个连续的32位值。 表示一个内部handle。 当服务端发现客户端就是自身的时候(在用一台电脑上),就会生成一个内部的安全handle,填充到这个字段。并且在Flags中设置  0x4000标记。 表示这是一个本地认证。

 

g. TargetInformation 也是一个security buffer。 其存储方式前面介绍过。 但是它的buffer中的内容需要介绍一下。基本上,TargetInformation是由一系列连续的 AV_PAIR 结构体连接起来的。

而AV_PAIR的结构如下:

(请参考下面 参考文档1 的 2.2.2.1节)

image

 

i) 先是两个字节的int16值, 表示 id, 表示这个AV结构的类型。

目前有如下类型:

image

image

 

 

ii) 然后是两个字节的int16值,表示值的长度。

 

iii) 然后就是值。 它的长度在上面指定的。

 

这个TargetInformation 结构非常重要。 后面Type3中还会用到。

 

h. 然后是8字节的操作系统版本号。 Type1中已经介绍过了。 不多说了。

 

然后后面就是要携带的数据了。

 

到这里先告一段落吧, 这里介绍了 NTLM 的概念以及认证流程。 并详细介绍了Type1和Type2消息, 以及Flags每个标志位的意义。 这大概覆盖了NTLM内容的30%左右的内容。  Type3消息是整个认证中最为复杂和关键的部分,我们将在下一篇中独立介绍。

希望大家多多支持。

欢迎访问我的个人独立博客: http://byNeil.com , 希望和大家多多交流共同进步。

 

 

参考文档:

  1. MS-NLMP-NT-LAN-Manager-NTLM-Authentication-Protocol-Specification

  2. The NTLM Authentication Protocol and Security Support Provider

  3. freebsd-freebsd  源码实现

  4. Mozilla Firefox source code Developer Guide - MDN-firefox 源码

  5. Heimdal NTLM 开源工程

  6. samba.org-pub-unpacked-samba_3_current-librpc-idl-ntlmssp.idl


Comments

Content