ntlm&Kerberos

2年前 (2021-09-11) 三千院翼 学习笔记 0评论 已收录 370℃

Ntlm&Kerberos认证方式

NTLM

NTLM介绍

NTLM 是 telnet 的一种验证身份方式,它是基于挑战(Chalenge)/响应(Response)认证机制的一种认证模式,是一种即时应答的协议,NT又是指windows NT 早期的标准安全协议。

NTLM认证流程

第一步:客户端接收用户输入的用户名,密码,域,然后客户端会将密码hash过后存于本地

第二步:客户端将用户名明文发送给DC

第三步:DC会生成一个16字节的随机数,名为Challenge,之后传回给客户端

第四步:当客户端收到Challenge之后,会复制一份,与之前转换成Hash的密码一同,在混合转换成Hash,混合后值为:response,之后客户端再将Challenge,Response及用户名一并都传给服务端

第五步:服务端在收到客户端传过来的这三个值以后会把它们都转发给DC

第六步:当DC接到过来的这三个值的以后,会根据用户名到域控的账号数据库(ntds.dit)里面找到该用户名对应的hash,然后把这个hash拿出来和传过来的challenge值再混合hash

第七步:将(6)中混合后的hash值跟传来的response进行比较,相同则认证成功,反之,则失败

undefined

NTLM Hash的生成

假设我的密码是admin,那么操作系统会将admin转换为十六进制,经过Unicode转换后,再调用MD4加密算法加密,这个加密结果的十六进制就是NTLM Hash

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

Kerberos

Kerberos介绍

Kerberos是一个Authentication协议,目的即为判断用户的身份是否为用户所声明的身份,也就是判断在域内声明的客户端或服务端是否就为客户端或服务端。

Kerberos特点

Kerberos协议避免了用户的密码以明文的形式被传输,避免了密码被截获的危险。而且使用的是一种短期的Key,由于这种Key只在一段时间内有效,即使加密的数据包被恶意的网络监听者截获,等他把Key计算出来的时候,这个Key早就已经过期了。相较于NTLM,NTLM还需要将用户名进行明文传输,导致可能中途被截断导致安全问题。同时引入的短期动态口令的原理,防止截断加密包进行破解。

Kerberos角色

KDC(确切地说是KDC中的Authentication Service)实现对Client身份的确认,并颁发给该Client一个TGT。

AD(Account Database) 用户数据库

用户一般为客户端/Client

服务端/Service

AS(Authentication Service)接收KRB_AS_REQ验证发送方是否为声称的角色,同时验证该角色是否在AD里

TGS(Ticket Granting Service)票据分发服务

Kerberos认证流程

第一步:Client向KDC的Authentication Service发送Authentication Service Request(KRB_AS_REQ)发送内容:

​ 包含用户身份信息即为用户名密码和KDC的Ticket Granting Service的Server Name

第二步:AS通过它接收到的KRB_AS_REQ验证发送方的是否是在Client name & realm中声称的那个人,也就是说要验证发送放是否知道Client的Password。所以AS只需从Account Database中提取Client对应的Master Key对Pre-authentication data进行解密,如果是一个合法的Timestamp,则可以证明发送方提供的是正确无误的密码。验证通过之后,AS将一份Authentication Service Response(KRB_AS_REP)发送给Client。发送内容:

​ 这一步包含被客户端的Master Key加密过的Logon Session Key(验证身份的登录信息)

​ TGT(加密后)包含:Logon Session Key(登录信息) Client name & realm(用户信息) End Time:(TGT的到期时间)

第三步:客户端向KDC中的TGS(Ticket Granting Service)发送Ticket Granting Service Request(KRB_AS_REP) 发送内容:

​ TGT

​ Authenticator(包含了证明TGT拥有者为自身的信息)

​ Client name & realm Server name & realm (均为加密后)

第四步:TGS先使用自己的Master Key对客户端提供的TGT进行解密,获得Logon Session Key。再通过Logon Session Key解密Authenticator进行验证。验证通过向对方发送Ticket Granting Service Response(KRB_AS_REP) 发送内容:

​ 使用Logon Session Key加密过的Session Key。该Session Key 将被用于Client和Server的认证

​ Ticket(内容与TGT加密信息一致)

第五步:Client收到KRB_TGS_REP,使用Logon Session Key解密第一部分后获得Session Key。有了Session Key和Ticket,Client就可以直接和Server进行交互.利用可以直接交互,客户端向Server发送KRB_AP_REQ 发送内容:

​ Ticket(与第四步不同,这次需要的是客户端获得的被Server Key加密的Ticket)

​ Authenticator(与第三步内容相同)

​ Flag(是否需要双向验证的标志)

第六步:Server接收到KRB_AP_REQ之后,使用自己的Master Key解密Ticket,从而获得Session key。通过Session key解密Authenticator,验证对方身份,如果验证通过允许对方访问资源,反之拒绝。

对于需要进行双向验证,Server从Authenticator提取Timestamp,使用Session Key进行加密,并将其发送给Client用于Client验证Server的身份。

undefined

博主
               

一个网安苦手,VtbMusic开发组成员|兽耳科技官方群管理组成员|珈百璃字幕组成员|夜樱诺娅字幕组成员|铃音_Official鸽组成员|米孝子|信安摸鱼生

相关推荐

有任何意见请评价。