惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
V2EX
C
Check Point Blog
博客园_首页
B
Blog
D
Docker
U
Unit 42
量子位
I
InfoQ
有赞技术团队
有赞技术团队
Martin Fowler
Martin Fowler
GbyAI
GbyAI
L
LangChain Blog
云风的 BLOG
云风的 BLOG
博客园 - Franky
美团技术团队
T
The Blog of Author Tim Ferriss
阮一峰的网络日志
阮一峰的网络日志
月光博客
月光博客
Vercel News
Vercel News
Recent Announcements
Recent Announcements
雷峰网
雷峰网
大猫的无限游戏
大猫的无限游戏
小众软件
小众软件
Google DeepMind News
Google DeepMind News

AresX's Blog

从两篇 X 文章开始:我第一次构建量化系统的回忆录 Xray Crack Patching SSL 指纹识别和绕过 HTB - You know 0xDiablos Docsify 自动生成sidebar.md脚本 Shiro高版本加密方式下的漏洞利用 Xray tomcat回显Gadget对应Payload提取 IDEA远程调试Docker中程序的方法 解决goldenPac报错问题 域渗透学习(七)PTT 票据传递攻击 域渗透学习(六)PTH 哈希传递攻击 域渗透学习(五)基于IPC的远程连接 域渗透学习(四)Dump Password & Hash 域渗透学习(三)域内信息搜集 域渗透学习(二)Kerberos协议 域渗透学习(一)Windows认证机制 Linux后门 JAVA反射机制瞎扯篇 关于IPC和PTH用户权限问题 Goindex添加隐藏目录功能
戏说地狱三头犬
AresX · 2020-03-12 · via AresX's Blog

某公司遭到竞争对手的渗透,大量公司员工账号被盗,公司领导瑟瑟发抖,因为现在不知道聊天窗对面是自己的员工还是竞争对手,在这种情况下怎么来保证员工和老板间的对话是安全并且互相可信的呢?

这时候就引入了一个第三者,HR,由于公司施行工资保密制度,员工之间不知道彼此工资的具体数字,但是HR知道全公司员工的工资数字,现在假定每个员工的工资都是不同的,我们用员工,老板,和HR来完成一个安全可信的加密机制,(假定HR是可信任的)

员工,老板和HR便是Kerberos认证中的三个角色

俗称地狱三头犬

那么继续说,公司目前处在这样一个人与人之间毫无信任可言的情况下,还是要继续运转

某天,员工张二狗需要从老板大黄那里取得一份公司机密信息,但是如果二狗直接给老板发消息索要信息,那老板肯定不会给他,因为公司聊天工具里的人现在都是不可信任的,二狗不知道网线那边是不是真的老板,老板也不知道给自己发消息的是不是真的二狗,这时候就尴尬了

然后这时,聪明的老王出现了,老王是个国外读了10年本科的密码学砖家,他就给公司提出来一套流程,鉴于目前大家都没有办法确定某个人就是某个人,那么我们来用密码学的手段确定彼此的身份吧

这个流程是什么呢,如果二狗想给老板发消息,就要先通过HR来确定二狗就是二狗,怎么确定呢,二狗知道自己的工资,HR也知道二狗的工资,那么二狗就先给HR发个消息,我要找老板谈话,帮我弄个身份鉴定证书吧,但是二狗不能直接找HR要这个鉴定证书,因为二狗要先证明二狗就是二狗本人

于是二狗先给HR发了个消息,我是二狗,我要证明我就是二狗!

HR收到了二狗的消息,然后从公司数据库中一查,果然有二狗这个人,但是即使有这个人,又怎么确定二狗就是二狗本人呢,HR就用二狗的工资作为加密密钥,对一串非常复杂的数字(12345)进行加密作为消息A,然后又把这个数字12345和当前跟二狗聊天窗口的截图还有聊天的时间记到一个文件中,再用自己的工资对这个文件进行加密作为消息B

之后HR把用二狗工资加密的消息A和用自己工资加密的消息B一起发送给二狗,为什么要这样做呢,二狗如果能成功解密消息A,就能得到12345,因为只有真正的二狗知道自己的工资,假二狗不知道,消息B又是用来做什么的呢,我们继续看

二狗发送完消息之后,盯着聊天窗,然后钉,钉,响了两声,HR发来了两串东西,二狗看不懂,但是二狗想起来之前老王提出来的认证流程,先用自己的工资解密了第一个消息,得到了那串数字12345,然后用这串12345把跟HR聊天窗口的截图和时间放在一起进行了加密,作为消息D,那么消息C是什么呢,消息C就是HR发来的第二个消息,消息B,不过这次消息C中还要多一个东西,就是老板的名字大黄,大黄和消息B合在一起就组成了消息C

为什么呢,因为二狗这次发送的消息C和D就是为了证明他就是二狗本人,二狗自然确定自己就是真二狗,那么自然也要把老板的名字加到消息中,因为他要HR给他用来跟老板对话的身份鉴定证书,如果不加上老板的名字,HR即便确定了二狗是二狗,也不知道二狗要跟谁对话

现在消息C(消息B和老板的名字大黄)和消息D(二狗用12345加密的聊天窗口截图和聊天时间)就发到了HR那里

HR收到了消息C和D,得到了三个东西,原来用自己工资加密的消息B,老板的名字,和之前自己随便想出来的12345加密的消息D

这里就来到了第一个关键点,HR怎么通过这几个东西来确定二狗就是二狗呢,HR首先用自己的工资解密了消息C,得到了之前的聊天窗截图和聊天时间,还有自己之前随便想出来的12345,然后用这个12345来解密消息D,又得到了二狗对他们两个的聊天窗的截图和聊天时间,通过对比这两个聊天窗截图和时间是否都匹配,HR就确定了这个二狗是真的二狗(假二狗不知道真二狗的工资,所以就无法解密得到12345,也就没法用12345加密消息D,HR自然也没办法解密了),并且就是之前跟自己聊天的那个二狗(因为之前发过去的用自己工资加密的消息B原封不动的发回来了,而这个消息B除了自己谁都无法解密修改)

这里有人要问了,那HR直接用自己想出来的12345解密消息D不是也可以确定二狗就是真二狗吗,这个怎么解释呢,这个公司有一百万个员工,每个员工时不时都想跟老板说说话,而HR脑子存储量不够大,记不住12345这么复杂的数字,更何况是一百万个12345,那脑子不得爆炸了,所以把12345用自己的密钥加密发过去,再收回来用自己的密钥解密取出来,这样就不用记了

现在HR确定了二狗就是二狗,那么看看二狗想跟谁聊天吧,消息C中写的是老板大黄的名字,HR就从公司数据库中查,老板大黄:工资4块3毛1角

然后HR又用老板的工资,加密了和二狗聊天窗口的截图,聊天时间和另一串非常复杂的数字45678 作为消息E(也就是鉴定证书),和用从消息C中找到12345加密了新的复杂数字45678作为消息F

又回到二狗这里,二狗收到这两个消息,用12345解密了第二个消息F,得到了45678,然后用45678加密了自己和HR的聊天窗截图和聊天时间作为消息G,之后把消息E和消息G发给老板,是不是和之前很像

这时老板收到了二狗的消息,老板先用自己的工资解密了消息E(HR用老板工资加密的截图,聊天时间还有45678),得到了45678,然后用这串复杂的数字成功解密了消息G,得到二狗的截图和聊天时间,再对比这两个聊天截图和聊天时间是不是一样的,一样的话老板才能确定二狗是真二狗,经过HR权威认定的二狗,可以充满信任的聊天了,这里其实也有对老板身份的鉴别,因为假老板不会知道真老板的工资,自然也就没有办法解密消息E

至此整个认证流程基本结束,我们将其中的几个关键信息提取出来,换成正常含义下对应的词语

  • 二狗 Client
  • HR KDC
  • 老板大黄 Service/Server
  • 二狗的工资 Client NTLM Hash
  • HR的工资 krbtgt NTLM Hash
  • 老板的工资 Service/Server NTLM Hash
  • HR工资加密的截图,时间和12345 TGT 黄金票据
  • 老板工资加密的截图,时间和45678 TGS 白银票据
  • 12345 Client/TGS Sessionkey
  • 45678 Client/Service Sessionkey
  • 聊天窗截图 Client ID
  • 聊天时间 Timestamp 时间戳

看懂了上面的故事,Kerberos的认证流程也就了解的差不多了,不过是细节上会有些差异