时间戳

首页 > 技术文章 > kerberos协议与票据

kerberos协议与票据

cjz12138 2020-11-09 15:51 原文

kerberos协议与票据

windows用户密码存储在SAM文件（安全用户管理）中

当我们登录系统时，会对我们的密码进行hash加密后与数据库中密码对比、

（SAM文件保留了计算机本地所有用户的凭证信息）

image-20200927202906998

NTLM（NT Lan Manager）协议

早期SMB协议在网络上传输明文口令。后来出现 LAN Manager Challenge/Response验证机制，简称LM，它是如此简单以至很容易就被破解。微软提出了WindowsNT挑战/响应验证机制，称之为NTLM。

是一种基于挑战、应答的wins早期认证机制，安全性不高，从windows2000开始默认不再使用。

认证流程

winlogon.exe -> 接收用户输入 -> lsass.exe -> (认证)
（lsass进程，这个进程中会存一份明文密码，将明文密码加密成NTLM Hash，对SAM数据库比较认证）

认证过程是将我们输入的密码转化成NTML hash 与SAM 文件中的NTML hash对比

windows下两种hash加密方法

LM hash

一种对称加密hash

参考：https://www.cnblogs.com/-qing-/p/11343859.html

LM hash的不足：

1.输入密码后 大小写不敏感

2.可以猜测到密码是否大于七位

3.‘魔术字符串’已知，容易破解

NTML hash

将输入的密码进行十六进制编码后转化为Unicode，再用MD4加密得到结果

admin -> hex(16进制编码) = 61646d696e
61646d696e -> Unicode = 610064006d0069006e00
610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634
具体过程

1.客户端向服务端发送用户信息

2.服务端收到后判断该用户是否在本地账户列表中，如果没有认证失败，如果有随机产生一个16位随机数，称为‘Challenge’，

使用用户名对应的NTLM hash加密Challenge生成Challenge-1，存放在服务端内存中，然后将Challenge发送给客户端

3.客户端收到Challenge后用密码对应的NTLM hash加密后得到Response（ 表现形式为Net-NTLM hash），将它发送给服务方

4.服务端验证Response和Challenge-1 相等则验证成功

image-20200927205604311

kerberos协议

Kerberos 是一种网络认证协议，其设计目标是通过密钥系统为 客户机 / 服务器应用程序 提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据。在以上情况下， Kerberos 作为一种可信任的第三方认证服务，是通过传统的密码技术（如：共享密钥）执行认证服务的

三个实体：Client Server KDC(Authentication Server --AS 和 Ticket-Grant Service --TGS)

AS :用来认证用户身份

TGS：授权服务访问

Server：提供服务

Client：请求服务

具体过程

第一步:用户登录、请求身份认证

1用户登录

这个阶段用户输入账号密码，在客户端密码被一个单向hash函数加密成Client密钥

2.1客户端请求用户认证

用户向AS发送请求

随后AS确认存在该用户，就将数据库中该用户对应的密码也用同样的单向hash函数加密，得到Client密钥，，与用户登录时生成的相同。

2.2AS确认客户端用户身份

AS发回给Client的内容

1.用Client密钥加密的Client/TGS SessionKey（client ，TGS间的通讯）

2.用TGS密钥加密的TGT（用 krbtgt的HTLM hash加密）

（TGT中有：Client/TGS SessionKey、Client ID、Ticket的有效时间、Client的网络地址）

Client收到后因为有Client密钥所以可以解密得到Client/TGS SessionKey

第二步：请求服务授权

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

Client向TGS发送的有

要服务的ID （Service ID） 和 上一步AS给的TGT

还有用Client/TGS SessionKey加密的{Client ID,Timestamp}

3.2TGS授权客户端用户访问服务

然后TGS返回给Client的信息有

MsgF:使用[Client/TGS SessionKey]加密的[Client/Server SessionKey]

MsgE:Client/Server SessionKey（用Service密钥加密）、Client网络地址、Ticket有效时间、Client ID

因为Client有Client/TGS SessionKey 可以的到 Client/Server SessionKey

然而 Client/Server SessionKey因为是用Service加密，所以对Client不透明

第三步：发送服务请求、Server响应请求

4.1客户端向申请的服务发送请求

MsgE:就是上一步的MsgE,

MsgG:用Client/Server SessionKey加密的{Client ID,Timestamp}(用来向ss证明，自己有来自TGS的key)

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

SS收到客户端的服务请求之后，先利用自身的[Service密钥]对Msg E进行解密，提取出Client-To-Server Ticket, 在3.2步骤中，提到了该Ticket中包含了[Client/Server SessionKey]以及Client ID信息。
SS使用[Client/Server SessionKey]解密Msg G，提取Client ID信息，而后将该Client ID与Client-To-Server Ticket中的Client ID进行比对，如果匹配则说明Client拥有正确的[Client/Server SessionKey]。
而后，SS向Client响应Msg H(包含使用[Client/Server SessionKey]加密的Timestamp信息)。
Client收到SS的响应消息Msg H之后，再使用[Client/Server SessionKey]对其解密，提取Timestamp信息，然后确认该信息与Client发送的Authenticator 2中的Timestamp信息一致。

黄金票据（Golden Ticket）

在认证的第一步Client通过AS认证后，AS会给Client发送Client/TGS SessionKey和TGT ，因为Client/TGS SessionKey不会保存在KDC中，而TGT的产生是用krbtgt 的NTLM hash加密（固定）的，所以假如知道了krbtgt的NTML hash就可以伪造TGT，然后这样有了黄金票据，在Client和TGS交互的时候，只要拿出伪造的TGT，和随便一个Client/TGS SessionKey生成的{Client ID,Timestamp}就可以跳过AS的验证，不用验证账号和密码

特点

需要知道krbtgt的NTML hash

不用到AS那去验证

可以获取任意服务

白银票据（Silver Ticket）

在认证的第三步，Client要向Server发送ST 和 Client/Server SessionKey加密的{Client ID,Timestamp} ，然后服务端用自己的Key（Server的NTML hash）解密得到 Client/Server SessionKey，然后用Client/Server SessionKey解密得到{Client ID,Timestamp} 。

如果Client知道了Server的NTML hash就可以伪造出一个ST ，而 Client/Server SessionKey在server收到之前是不知道的，也可以伪造，从而绕过了KDC，直接获取服务。

特点

需要知道server的NTML hash

不需要和KDC验证

只能得到特定的服务

推荐阅读