Kerberos协议与NTLM协议

作者: const27 分类: All,内网 发布时间: 2020-07-28 07:37

参考 http://www.nosqlnotes.com/technotes/kerberos-protocol/
https://www.anquanke.com/post/id/190261

NTLM协议

NTLM也是一个认证协议,与Kerberos协议功能是一样的,不过NTLM的安全性可没有Kerberos好

验证机制

NTLM协议验证机制是基于 挑战(chanllage)/回应(response) 模式的

它的验证模式大致如下:

  1. 用户输入账号密码,本地把密码加密为一个hash值,称为NTML-Hash
  2. 客户端向服务器发送用户名 (这个数据称为 TYPE 1 Negotiate
  3. 服务端接收请求,判断数据库中该用户名是否存在,若存在则生成一个16位随机数称之为chanllage。同时将chanllage返回给客户端 ( TYPE 2
  4. 客户端收到chanllage后将其用上面生成的hash值来加密这个chanllange,并与用户名,chanllange等组合到一起得到Net-NTLMHash 最后将 Net-NTLMHash 封装到 TYPE 3 NTLM_AUTH消息中发往服务器。
  5. 服务器收到TYPE3后,用自己数据库中该用户的密码的NTML-Hash加密chanllage,并比较自己计算出的 Net-NTLMHash 与客户端发过来的 Net-NTLMHash ,若相同则认证成功
  6. (以上是客户端-服务端模型,若是在域中,验证步骤就会有点不同)
    若在域中,那么服务端在第5步收到TYPE3后不会自行进行比对,而是将 Net NTLM-Hash 转发给域控制器DC,由DC进行最后的 Net NTLM-Hash 比较认证

Kerberos协议

Kerberos协议,是一个常用的认证与授权协议(下面只是简化过的大致流程,具体流程请看下面的wireshark抓包分析)

整体流程

认证与鉴权整体流程

参与的关键角色

认证与鉴权关键角色
  • Client: Application Client 应用客户端
  • AS: Authentication Server 用来认证用户身份
  • TGS: Ticket-Granting Service 用来授权服务访问
  • SS: Service Server 用户所请求的服务
  • 其中AS和TGS都属于KDC系统( 密钥分发中心 )

认证:

以下的加密都是对称加密

1.用户登录

1用户登录

用户先输入用户名和密码,其中密码在这个阶段会被单向hash函数加密为一个密钥,用来解密后面的信息

2.请求身份认证(client和kdc双向认证)

2.1 客户端向AS发送认证请求

2.1客户端请求用户认证

客户端向as发送用户名信息(明文)(进发送用户名而没有发送密码)

2.2AS确认客户端身份

2.2AS确认客户端用户身份

AS先把用户名在数据库中查找一下,如果该用户名存在则找到该用户的密码使用单向hash函数生成client密钥并返回Msg A和B。
A中的内容是一个被Client密钥加密的用于生成Authenticator1的数据
B中的内容是一个被TGS密钥加密的一堆信息叫做TGT,当前无TGS密钥故无法解开,其中包含 客户端ID,有效期 ,Client网络地址以及MSG A解密后的内容

3. 请求服务授权(client请求kdc认证server)

3.1 客户端向TGS发送请求服务授权请求

3.1客户端请求授权服务访问

Client在MSG C向TGS发送 请求的服务的ID,2.2中的TGT,MSG D 发送由 [Client/TGS SessionKey]加密的Authenticator 1 {Client ID, Timestamp}。

3.2 TGS为Client响应服务授权票据

3.2TGS授权客户端用户访问服务
  • Msg E   使用[Service密钥]加密的Client-To-Server Ticket, 该Ticket中包含了如下信息:
    • [Client/Server SessionKey]
    • Client网络地址
    • Ticket有效时间
    • Client ID
  • Msg F   使用[Client/TGS SessionKey]加密的[Client/Server SessionKey]

4. 发送服务请求(client与ss双向认证)

4.1 Client向SS(Service Server)发送服务请求
4.1客户端向申请的服务发送请求


发送的消息中包括:

  • Msg E   上一步3.2中,TGS为Client响应的消息Msg E。该消息可以理解为由Client为SS携带的消息。
  • Msg G   由[Client/Server SessionKey]加密的Authenticator 2,包含{Client ID, Timestamp}信息。
    这里的Authenticator 2区别于前面3.1步骤中的Authenticator 1。

Note

  1. [Client/Server SessionKey]并未直接透明传输,而是被包含在使用[Service密钥]加密的Msg E中。
  2. 既然[Client/Server SessionKey]并不直接透明传输, Client需要向SS证明自己拥有正确的[Client/Server SessionKey],所以,Authenticator 2使用了[Client/Server SessionKey]加密。

4.2 SS响应Client

4.2被请求的服务给客户端响应

Kerberos抓包分析

以上是kerberos协议简化图

ASREQ

即客户端往服务端的第一次通讯

我抓到的包的样子,我们来解读一下
1.pvno: 标记着kerberos协议的版本
2.msg-type: 标记着这个包的类型, ASREQ对应的就是KRBAS_REQ(0x0a)
3.padata:用于存储一些认证信息
其实这个头下面还有很多不同的类型的头,但是这里抓到了PA-DATA PA-ENC-TIMESTAMP和PA-DATA PA-PAC-REQUEST这两个头部,但是这两个头部是padata最常用最核心的头部.
PA-DATA PA-ENC-TIMESTAMP : 就是用户hash加密的时间戳,作用在于:as配合用户的明文账户(cname头)在数据库中查询该用户是否存在,若存在则取用其hash来解密这个时间戳,若揭秘成功则认证通过
PA-DATA PA-ENC-TIMESTAMP:  这个是启用PAC(一个控制用户权限的东西)支持的扩展。
4.req-body:请求主体,也包含了许多信息.这个头里面比较重要的东西是
cname:存储着发送请求的用户名(明文用户名)
sname:这个包含的是服务端的身份, 在ASREQ里面是krbtgt ,还有所在域名称。till为到期时间,nonce为随机生成数
realm:所在域名称
etype:告知服务器,这个hash的加密方式

之前一直困扰我的 “为什么有些文章说的第一步是向服务器发送明文账户名,有些文章是向服务器发送时间戳hash”问题抓了一下包就懂了..

ASREP

1.ticket:这个就是TGT了。
tkt-vno:票据格式版本号
realm:所在域名
sname:同asres
enc-part:被krbtgt密钥加密的票据本体部分
2.enc-part:被client hash 加密的login session key

TGSREQ

1.ap-req->…->tikect: 可以发现TGSREQ把整个TGT发送给了TGS
2ap-req->…->authenticator:被login session key加密的时间戳和client id

TGSREP

1.tikect:这里就是TGS部分了。
enc-part:这里的enc-part是被所请求的服务的用户hash加密的
2.enc-part:被login session key加密的service session key

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

Leave a Reply

Your email address will not be published. Required fields are marked *

标签云