NTLM
NTML协议是Windows的早期认证方式, 为保证后向兼容而保留. 可以用于域内认证和工作组认证. 主要分为本地认证和网络认证两种方式.
加密流程
1 | -------- --------- ------------ --------- |
本地认证
我们的密码不会明文保存在Windows中, Windows会在设置密码时把密码加密成NTLM Hash后储存在SAM文件中, 一般路径为system32/config/SAM
.
NTLM的本地认证发生在用户登录的过程中. 当我们登录系统的时候, Windows会调用winlogon.exe来接受密码输入, 之后密码会传递给lasaa.exe. 该进程会先在内存中保存一份明文密码, 再把明文密码加密为NTLM Hash后与SAM数据库中的对应Hash进行对比, 如果比对成功则登录成功.
1 | ---------- |
网络认证
在域环境中需要进行网络认证, 虽然一般使用的都是Kerberos协议, 但是NTLM协议也可以用于认证. 一般基于挑战应答机制.
- 用户在客户端
C
输入账号和密码,C
缓存NTLM Hash, 并明文发送用户名到服务端S
S
生成随机的16字节挑战字符串t
, 明文发送给C
C
接收到t
后, 使用NTLM Hash对t
进行加密, 生成响应r
并发送到SS
接收到r
后, 将第一步发来的用户名, 挑战字符串t
, 响应r
一并发给域控(DC)DC
在本地数据库中找到用户名对应的NTLM Hash, 对发来的t
进行加密, 如果加密结果r1===r
, 则认为认证成功, 将认证结果返回给服务端S
在整个挑战-应答机制中, 密码和NTLM Hash并没有在网络上进行传递. 同时为了提高安全性, DC中也不会储存用户的明文密码. 由此, 如果攻击者能够获取用户的NTLM Hash, 则也不需要获得明文密码也可冒充用户进行登录操作. 从而产生Hash 传递攻击(Pass The Hash)
1 | ---- -------- -------- |
Kerberos
Kerberos常用于域内的认证, 不要求网络上所有主机都是安全的, 并且假定网络上的数据包都是不可信的. 在这种情况下, Kerberos能够提供一种可靠的第三方认证服务.
在一次Kerberos认证过程中, 会出现多个角色: AD, AS, TGS组成的KDC(域控); 提供服务的服务端; 申请服务的客户端
AD储存着用户白名单, 只有存在于白名单中的客户端才能申请到TGT.
AS是为客户端生成TGT(Ticket Granting Ticket)的服务.
TGS是为客户端生成对应服务的ticket的服务.
粗略流程
- 客户端
C
向Kerberos请求服务, 希望获取访问服务端S
的权限 - Kerberos的AS接收到请求, 判断用户是否在白名单中, 成功后AS返回TGT给
C
C
获取TGT后, 向Kerberos请求访问服务S
的权限, 由于这次带着TGT, 所以就由TGS模块生成访问S
的ticket给C
C
获取Ticket后就可以带着Ticket访问S
了, 如果要访问其他的S
, 则需要重新向TGS申请Ticket.
认证流程
第一步
- 客户端发送身份信息(用户名, 域控的信息)到KDC
- KDC验证客户端的信息, 计算机名, 地址等是否存在于AD中, 查找用户名对应的NTLM Hash.
- KDC使用用户对应的NTLM Hash加密一个随机生成的session key(类似上面的挑战字符串)称之为TGS Session Key, 用于客户端和TGS进行通信.
- KDC使用TGS的密钥(krbtgt)加密 上面的Session Key, 用户ID, 用户地址, 有效期 这几个信息, 称为TGT
- KDC发送3,4两步生成的TGS Session Key和TGT给用户.
- 第一步结束, 后续客户端会继续和TGS进行认证.
第二步
- 客户端解密第一步接收到的TGS Session Key, 得到session key. 然后使用session Key加密用户ID和时间戳, 构造认证符.
- 发送第一步接收到的TGT, 客户端信息, 服务端信息和构造好的认证符到KDC的TGS服务
- TGS服务接收到上面的信息后开始认证流程, 首先利用TGS密钥解密TGT, 获取session key, 然后通过session key解密上面加密的认证符. 确定时间戳是否超时失效. 然后比较本次收到的信息和之前第一步发送出去的信息是否相等. 如果相等则会生成新的随机session key, 称为server session key. 利用一直使用的session key加密server session key
- TGS 利用上一步收到的服务端信息, 使用服务端的NTLM Hash加密
server session key, 客户端信息, 失效时间
这些信息, 构造ticket - 把ticket 和加密后的server session key发送给客户端
第三步
- 客户端解密, 获得对应的sever session key. 使用key加密客户端信息和时间戳, 配合ticket 发送到服务端.
- 服务端利用自己的NTLM 解密Ticket, 获取其中的server session key和客户端信息. 再利用server session key解密出发过来的客户端信息, 比对客户端信息是否相同. 如果相同就提供服务.
认证流程本质
客户端和DC之间不停的交换密钥, 利用对称加密算法, 验证时间戳和身份来完成可信认证.
锐意更新中(剩下的图明天画)