给大家讲个关于kerberos协议的故事...

  • A+
所属分类:安全文章

文章来源|MS08067 内网安全知识星球

本文作者:Spark(Ms08067内网安全小组成员)

内网纵横四海  认准Ms08067

给大家讲个关于kerberos协议的故事...

关于kerberos协议的原理网上的文章应该已经有很多了,但是因为篇幅较长、步骤复杂、涉及的名词缩写较多等原因,所以对初学者来说不是很友好。本文另寻思路,以故事的形式带大家由浅入深理解kerberos协议。

故事背景:windows本地认证

所谓的本地认证也就是计算机自身的认证。计算机本身是如何进行认证的,密码存储在哪里,是以什么样的形式存储的?


0.1 密码在哪里
路径:
%SystemRoot%system32configsam

给大家讲个关于kerberos协议的故事...

当我们登录系统的时候,系统会自动地读取SAM文件中的“密码”与我们输入的“密码”进行对比,如果相同,则认证成功。


0.2 密码的形式
Windows本身不存储用户的明文密码,它会将用户的明文密码经过加密算法转换成NTLM Hash后存储在SAM数据库中。当用户登录时,将用户输入的明文密码也加密成NTLM Hash,与SAM数据库中的NTLM Hash进行比较。

给大家讲个关于kerberos协议的故事...

上图是用python将“admin123”转换为NTLM Hash的形式。NTLM Hash长度32位,由数字与字母组成,是支持本地认证及Net NTLM认证协议过程中的一个重要参与物。


0.3 怎样进行认证

Windows Logon Process(即winlogon.exe) 是负责处理安全相关的用户交互界面的组件。Winlogon的工作包括加载其他用户身份安全组件、提供图形化的登陆界面,以及创建用户会话。

LSASS(本地安全认证子系统服务)用于微软Windows系统的安全机制。它负责Windows系统安全策略。它负责用户在本地验证或远程登陆时验证用户身份,管理用户密码变更,并产生访问日志。

整体流程如下:

1. 开机

2. winlogon.exe显示输入用户名密码的图形化页面

3. 用户输入用户名密码

4. lssas.exe将密码加密为NTLM Hash,并与本地SAM数据库中的NTLM Hash进行比较

5. 如果相同,则认证通过


故事一:windows网络认证

在内网渗透中,经常遇到工作组环境。工作组环境是一个逻辑上的网路环境,隶属于工作组的机器之间缺少“信托机构”,无法互相建立一个完美的信任机制,只能点对点,是比较落后的认证方式。

这里什么是信托机构,什么又是点对点认证呢?下面有请故事主角张三。

现张三有一笔钱需要转给李四,他需要有权限访问到李四的钱包,然后把钱放进去。


1.1 存在信托机构的情况

如果说存在一个信托机构,比如银行。那么首先张三得是银行的一个合法用户,李四也是银行的一个合法用户。在这样的前提下,张三访问李四的钱包,需要先通过银行的认证。


1.2 工作组环境的情况

实际上信托机构就是指域控,而工作组下没有域控。所以张三访问李四的钱包,只需要知道李四的账号密码,直接向李四发起访问请求即可。

本节故事描述的就是工作组的情况,即张三与李四进行点对点认证。现假设张三需要访问的是李四的445号钱包(对应服务端的445端口)。

445端口对应的SMB服务,早期在网络上传输明文口令。后来出现了LAN Manager Challenge/Response验证机制,简称LM认证。它是如此简单以至于很容易就被破解。后来微软提出了WindowsNT挑战/响应验证机制,称之为NTLM认证。下面来逐步理解这个NTLM挑战/响应验证机制。


1.3 NTLM 挑战/响应验证机制

给大家讲个关于kerberos协议的故事...

第一步:协商

客户端主要在这一步向服务器确认协议的版本,是v1还是v2,当然不止这些。

第二步:质询
背景:客户端拥有服务器上的合法用户名密码,并以此凭证请求访问服务器上的某服务。 
为方便理解,认证过程中相同的材料我用相同的颜色标了出来。

给大家讲个关于kerberos协议的故事...

第三步:验证
这一步其实就是上面质询过程中的第4点。
举个例子,如图:

给大家讲个关于kerberos协议的故事...


现在张三使用李四的账号(LiSi/123456)去访问李四的SMB服务:

1. 李四(Server)接受到张三(Client)发送的用户名(LiSi)后,判断本地账户列表是否有用户名LiSi。如果没有,返回认证失败;如果有,生成Challenge,并且从本地查找LiSi,使用NTLMHash加密Challenge,生成一个Net NTLM Hash对应的NTLM Hash存在内存中,并将Challenge发送给张三。

2. 张三接受到Challenge后,将自己提供的用户名(LiSi)的密码(123456)转换为NTLM Hash,使用NTLM Hash加密Challenge,这个结果叫Response,本质上也是Net NTLM Hash。最后将Response发送给李四。

3. 李四接受到张三发送的Response,将Response与之前的Net NTLM Hash进行比较,如果相等,则认证通过。


1.4 Pass The Hash
我们可以回顾一下整个流程:

给大家讲个关于kerberos协议的故事...

其实整个过程中缺少了一样很重要的东西,也就是在故事背景中埋下过的一个小伏笔:windows本身不存储明文密码

我们根据结果逆推:如果需要正确的response(蓝色)来通过认证,因为response本质上也是Net NTLM Hash(红色)根据公式“Net NTLM Hash = NTLM Hash(Challenge)”,我们需要正确的NTLM Hash(黄色)和Challenge(绿色)。而由于Challenge是服务端发送给,只要我们拥有正确的NTLM Hash,即可通过认证,无需明文密码!

基于上述逆推结果,诞生了Pass The Hash(即hash传递攻击)。

场景:
  • 内网渗透中获取不到明文密码、破解不了NTLM Hash而又想扩大战果横向移动。

必要条件:

  • 需要服务端的用户名

  • 需要正确的NTLM Hash

实验

首先在服务端抓取NTLM Hash:

给大家讲个关于kerberos协议的故事...

接着使用msf的攻击框架,可以看到这里只需填写用户名和NTLM hash,不需要明文密码:

给大家讲个关于kerberos协议的故事...

成功获取权限:

给大家讲个关于kerberos协议的故事...


故事二:域认证

故事一是讲没有信托机构的情况,接下来说有信托机构的情况。物理层面上,大家可以把信托机构看成是域控。域中的认证一般使用kerberos协议认证。

参与域认证的角色:
  • Client

  • Server

  • KDC(Key Distribution Center) = DC

其中,域控中包含:
  • AD(Account Database):存储所有的client白名单,只有存在于白名单的client才能顺利申请到TGT。

  • AS(Authentication Service):为client生成TGT的服务。

  • TGS(Ticket Granting Service):为client生成某个服务的ticket。


域认证中设计的名词缩写较多,这边先做一个汇总,结合图片食用:

给大家讲个关于kerberos协议的故事...

  • DC:Domain Controller:域控

  • KDC:Key Distribution Center:密钥分发中心

  • TGT:Ticket-Granting Ticket:发放的票据

  • AD:Account Database:账户数据库

  • AS:Authentication Service:认证服务

  • TGS:Ticket Granting Service:票据分发服务

如上图,整个域认证可分为三大步六小步。

下面开始讲故事。故事的名字叫张三(client)去游乐园坐过山车(server)。

由于前文提到,域环境内存在信托机构,非点对点认证。现在张三想坐过山车,必须通过游乐园管理员(DC)的认证。

首先张三在网上提前订了游乐园的门票,成为了游乐园(Domain)的合法用户。这是前提。

第一步:

给大家讲个关于kerberos协议的故事...

张三(client)向游乐园管理员(DC)提出请求。请求中包含时间戳、张三的信息(client info)、管理员的信息(KDC info)等。

给大家讲个关于kerberos协议的故事...

游乐园管理员接收到请求后,由AS认证服务去AD中查询张三是否为合法用户。AD确认张三为合法用户后,AS返回给张三一张游乐园通票(TGT),通票上含有张三的身份证号(client info)等信息,用于后续验证。通票由管理员密码(KDC hash)加密,张三不可解。

给大家讲个关于kerberos协议的故事...

除了通票(TGT)以外,管理员还会返回以张三的密码(client hash)加密的一把钥匙(session key),这把钥匙也会存在于通票(TGT)中。

第二步:由于得到通票(TGT)后张三没有管理员的密码,无法解密通票,所以张三再次向游乐园管理员(DC)发起请求,提出要坐过山车(server)的445号(445端口)座位。该请求包含使用钥匙(session key)加密的张三的身份证号(client info)和通票(TGT)。

给大家讲个关于kerberos协议的故事...

管理员(DC)得到通票后,先使用自己的密码(KDC hash)解密通票,得到钥匙(session key)和张三的身份证号(client info)。接着,使用钥匙(session key)解密另一部分,获得张三的身份证号。两个身份证进行对比,相同则通过认证。通过认证后,管理员返回使用钥匙(session key)加密的过山车钥匙(server session key)和一张小票(ticket),这张小票使用过山车密码(server hash)加密,其中包含了过山车钥匙(server session key)和张三的身份证号(client info),结构大致如下。

给大家讲个关于kerberos协议的故事...

第三步:最后张三将过山车钥匙(server session key)加密的身份证号,和小票(ticket)发送给过山车,过山车先用自己的密码解密小票(ticket),得到过山车钥匙(server session key)和张三的身份证号,再用过山车钥匙(server session key)解密请求的另一部分,得到张三的身份证号,两个身份证号进行对比,相同则认证通过。

给大家讲个关于kerberos协议的故事...

至此,张三终于可以坐过山车的445号座位了。但是如果张三想坐游乐园的其他设备,比如摩天轮或者旋转木马,甚至张三如果想坐过山车的其他座位,都需要带着通票重新向管理员发起请求,也就是重复下图中的第3小步。

给大家讲个关于kerberos协议的故事...


2.1 Pass The Ticket

与windows网络认证的缺陷相同,域认证中也没有明文密码的参与。因此:
  • 如果我们获取到了过山车的密码(server hash),那么我们可以伪造ticket与server session key,也就是我们常说的白银票据。

  • 如果我们获取到了游乐园管理员的密码(KDC hash),那么我们可以伪造TGT与session key,也就是我们常说的黄金票据。


白银票据

域中客户端访问服务端的文件共享:

给大家讲个关于kerberos协议的故事...

无法获取认证:

给大家讲个关于kerberos协议的故事...

mimikatz伪造白银票据:
kerberos::list #列出票据kerberos::purge #清除票据kerberos::golden /domain:域名 /sid:域SID /target:Server01.spark.com /service:cifs /rc4:NTLM Hash /user:server001 /ptt

给大家讲个关于kerberos协议的故事...

可以直接访问:

给大家讲个关于kerberos协议的故事...


黄金票据
黄金票据与白银票据相比: 
  • 需要域控的权限(KDC hash)

  • 需要与域控通信



实验环境与前文相同:

给大家讲个关于kerberos协议的故事...

mimikatz伪造:
kerberos::golden /domain:域名 /sid:域SID /rc4:krbtgt NTLM Hash /user:任意用户名 /ptt

给大家讲个关于kerberos协议的故事...

可以访问:

给大家讲个关于kerberos协议的故事...

从命令中也可以看出,黄金票据不需要指定服务器地址与服务,但是需要的是krbtgt的NTLM hash,也就是KDC hash。

参考链接

  • https://www.bilibili.com/video/BV1S4411q7Cw?from=search&seid=6002087845489093061



扫描下方二维码加入星球学习

加入后会邀请你进入内部微信群,内部微信群永久有效!

给大家讲个关于kerberos协议的故事... 给大家讲个关于kerberos协议的故事...

给大家讲个关于kerberos协议的故事...给大家讲个关于kerberos协议的故事...

给大家讲个关于kerberos协议的故事... 给大家讲个关于kerberos协议的故事...

目前40000+人已关注加入我们

给大家讲个关于kerberos协议的故事...

本文始发于微信公众号(Ms08067安全实验室):给大家讲个关于kerberos协议的故事...

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: