NTLM 基础 介绍
这个系列文章主要讲ntlm认证相关的内容。以及着重介绍ntlm两大安全问题--PTH和ntlm_relay。
ntlm篇分为四篇文章
第1篇文章也是本文,这篇文章主要简单介绍一些基础概念以及引进一些相关的漏洞,比如Pass The Hash以及ntlm_relay。
其余三篇文章的内容全部都是讲ntlm_relay,这 个安全问题是ntlm篇的重点内容。
第2篇文章主要讲触发windows向攻击者发起ntlm请求的一些方式,比如大家耳熟能详的打印机漏洞。
第3篇文章主要讲的是攻击者接收到ntlm请求之后做的事,如爆破Net-ntlm,又或者relay到SMB,HTTP,Exchange,LDAP等。
第4篇文章主要回顾一下从上世纪ntlm_relay被提出来,微软从08年开始为ntlm_relay陆陆续续推出的一些补丁以及绕过,如ms08068,MS16-075,CVE-2015-0005,CVE-2018-8581,CVE-2019-1040,CVE2019-1384。以及ntlm relay的一些缓解措施。
windows内部是不保存明文密码的,只保存密码的hash。
其中本机用户的密码hash是放在 本地的SAM文件 里面,域内用户的密码hash是存在域控的NTDS.DIT文件 里面。那hash的格式是怎么样的呢?
在Windows系统导出密码的时候,经常看到这样的密码格式
Administrator:500:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089C0:::
其中的
AAD3B435B51404EEAAD3B435B51404EE
是LM Hash
31D6CFE0D16AE931B73C59D7E0C089C0
是NTLM Hash下面详细介绍下这两种hash格式。
全称是LAN Manager Hash, windows最早用的加密算法,由IBM设计。
LM Hash的计算:
- 1.用户的密码转换为大写,密码转换为16进制字符串,不足14字节将会用0来再后面补全。
- 2.密码的16进制字符串被分成两个7byte部分。每部分转换成比特流,并且长度位56bit,长度不足使用0在左边补齐长度
- 3.再分7bit为一组,每组末尾加0,再组成一组
- 4.上步骤得到的二组,分别作为key 为 "
[email protected]#$%
"进行DES加密。 - 5.将加密后的两组拼接在一起,得到最终LM HASH值。
#coding=utf-8
import re
import binascii
from pyDes import *
def DesEncrypt(str, Des_Key):
k = des(binascii.a2b_hex(Des_Key), ECB, pad=None)
EncryptStr = k.encrypt(str)
return binascii.b2a_hex(EncryptStr)
def group_just(length,text):
# text 00110001001100100011001100110100001101010011011000000000
text_area = re.findall(r'.{%d}' % int(length), text) # ['0011000', '1001100', '1000110', '0110011', '0100001', '1010100', '1101100', '0000000']
text_area_padding = [i + '0' for i in text_area] #['00110000', '10011000', '10001100', '01100110', '01000010', '10101000', '11011000', '00000000']
hex_str = ''.join(text_area_padding) # 0011000010011000100011000110011001000010101010001101100000000000
hex_int = hex(int(hex_str, 2))[2:].rstrip("L") #30988c6642a8d800
if hex_int == '0':
hex_int = '0000000000000000'
return hex_int
def lm_hash(password):
# 1. 用户的密码转换为大写,密码转换为16进制字符串,不足14字节将会用0来再后面补全。
pass_hex = password.upper().encode("hex").ljust(28,'0') #3132333435360000000000000000
print(pass_hex)
# 2. 密码的16进制字符串被分成两个7byte部分。每部分转换成比特流,并且长度位56bit,长度不足使用0在左边补齐长度
left_str = pass_hex[:14] #31323334353600
right_str = pass_hex[14:] #00000000000000
left_stream = bin(int(left_str, 16)).lstrip('0b').rjust(56, '0') # 00110001001100100011001100110100001101010011011000000000
right_stream = bin(int(right_str, 16)).lstrip('0b').rjust(56, '0') # 00000000000000000000000000000000000000000000000000000000
# 3. 再分7bit为一组,每组末尾加0,再组成一组
left_stream = group_just(7,left_stream) # 30988c6642a8d800
right_stream = group_just(7,right_stream) # 0000000000000000
# 4. 上步骤得到的二组,分别作为key 为 "[email protected]#$%"进行DES加密。
left_lm = DesEncrypt('[email protected]#$%',left_stream) #44efce164ab921ca
right_lm = DesEncrypt('[email protected]#$%',right_stream) # aad3b435b51404ee
# 5. 将加密后的两组拼接在一起,得到最终LM HASH值。
return left_lm + right_lm
if __name__ == '__main__':
hash = lm_hash("123456")

image-20191115121137786
LM加密算法存在一些固有的漏洞
- 1.首先,密码长度最大只能为14个字符
- 2.密码不区分大小写。在生成哈希值之前,所有密码都将转换为大写
- 3.查看我们的加密过程,就可以看到使用的是分组的DES,如果密码强度是小于7位,那么第二个分组加密后的结果肯定是
aad3b435b51404ee
,如果我们看到lm hash的结尾是aad3b435b51404ee
,就可以很轻易的发现密码强度少于7位 - 4.一个14个字符的密码分成7 + 7个字符,并且分别为这两个半部分计算哈希值。这种计算哈希值的方式使破解难度大大降低,这使得14个字符的密码的有效强度等于,7个字符的密码的两倍,该密码的复杂度明显低于14个字符的密码的理论强度。
- 5.Des密码强度不高
为了解决LM加密和身份验证方案中固有的安全弱点,Microsoft 于1993年在Windows NT 3.1中引入了NTLM协议。下面是各个版本对LM和NTLM的支持。

image-20191115140404117
其中

image-20191115140419378
也就是说从Windows Vista 和 Windows Server 2008开始,默认情况下只存储NTLM Hash,LM Hash将不再存在。(因此后面我们介绍身份认证的时候只介绍Net-ntlm,不再介绍net-lm)如果空密码或者不储蓄LM Hash的话,我们抓到的LM Hash是
AAD3B435B51404EEAAD3B435B51404EE
。所以在win7 中我们看到抓到LM Hash都是
AAD3B435B51404EEAAD3B435B51404EE
,这里的LM Hash并没有价值。
image-20191115173913172
但某些工具的参数需要填写固定格式
LM hash:NT hash
,可以将LM hash填0(LM hash可以为任意值),即00000000000000000000000000000000:NT hash
。接下来讲下NTLM Hash的计算
1.先将用户密码转换为十六进制格式。
2.将十六进制格式的密码进行Unicode编码。
3.使用MD4摘要算法对Unicode编码数据进行Hash计算
python2 -c 'import hashlib,binascii; print binascii.hexlify(hashlib.new("md4", "[email protected]!123".encode("utf-16le")).digest())'

image-20191115121200362
NTLM验证是一种Challenge/Response 验证机制,由三种消息组成:通常称为type 1(协商),类型type 2(质询)和type 3(身份验证)。
它基本上是这样工作的:

image-20191114185958711
- 1.用户登录客户端电脑
- 2.(type 1)客户端向服务器发送type 1(协商)消息,它主要包含客户端支持和服务器请求的功能列表。
- 3.(type 2)服务器用type 2消息(质询)进行响应,这包含服务器支持和同意的功能列表。但是,最重要的是,它包含服务器产生的Challenge 。
- 4.(type 3)客户端用type 3消息(身份验证)回复质询。用户接收到步骤3中的challenge之后,使用用户hash与challenge进行加密运算得到response,将response,username,challeng发给服务器。消息中的response是最关键的部分,因为它们向服务器证明客户端用户已经知道帐户密码。
- 5.服务器拿到type 3之后,使用challenge和用户hash进行加密得到response2与type 3发来的response进行比较。如果用户hash是存储在域控里面的话,那么没有用户hash,也就没办法计算response2。也就没法验证。这个时候用户服务器就会通过netlogon协议联系域控,建立一个安全通道,然后将type 1,type 2,type3 全部发给域控(这个过程也叫作Pass Through Authentication认证流程)
- 6.域控使用challenge和用户hash进行加密得到response2,与type 3的response进行比较
下面简单介绍下三个过程,如果对于细节不感兴趣的话就可以忽略。
这个过程是客户端向服务器发送type 1(协商)消息,它主要包含客户端支持和服务器请求的功能列表。
主要包含以下结构

image-20191119100921744
抓包查看对应的信息如下

image-20191118192434619
这个过程是服务器用type 2消息(质询)进行响应,这包含服务器支持和同意的功能列表。但是,最重要的是,它包含服务器产生的Challenge。
主要 包含以下结构

image-20191119100959608
其中最主要的信息是challenge。后面加密验证依赖于challenge
抓包查看对应的信息如下

image-20191118192532383
这个过程客户端接收到challenge之后,使用用户hash与challenge进行加密运算得到response,将response,username,challenge发给服务器。消息中的response是最关键的部分,因为它向服务器证明客户端用户已经知道帐户密码。
主要包含以下结构

image-20191119101155300
这里的Challeng不同于type2 的Challenge,这里的Challenge是一个随机的客户端nonce。
MIC是校验和,设计MIC主要是为了防止这个包中途被修改
session_key是在要求进行签名的时候用的,用来进行协商加密密钥,可能有些文章会说session_key就是加密密钥,需要拥有用户hash才能计算出来,因此攻击者算不出来,就无法加解密包。但是想想就不可能,这个session_key已经在流量里面明文传输,那攻击者拿到之后不就可以直接加解密包了。当然这是后话,后面讲签名的时候会详细讲讲这个问题。
抓包查看对应的信息如下

image-20191118192616222
在type3中的响应,有六种类型的响应
- LM(LAN Manager)响应 - 由大多数较早的客户端发送,这是“原始”响应类型。
- NTLM v1响应 - 这是由基于NT的客户端发送的,包括Windows 2000和XP。
- NTLMv2响应 - 在Windows NT Service Pack 4中引入的一种较新的响应类型。它替换启用了 NTLM版本2的系统上的NTLM响应。
- LMv2响应 - 替代NTLM版本2系统上的LM响应。
- NTLM2会话响应 - 用于在没有NTLMv2身份验证的情况下协商NTLM2会话安全性时,此方案会更改LM NTLM响应的语义。