权限提升漏洞之Netlogon协议详解 以及可能出现得漏洞分析

1.Netlogon服务1

  • Netlogon服务为域内的身份验证提供一个安全通道

    • 它被用于执行与域用户和机器身份验证相关的各种任务 ,最常见的是让用户使用NTLM协议登录服务器

    • 默认情况下,Netlogon服务在域内所有机器后台运行


2.Netlogon服务2

  • Netlogon服务为域内的身份验证提供一个安全通道

    • 它被用于执行与域用户和机器身份验证相关的各种任务 ,最常见的是让用户使用NTLM协议登录服务器

    • 默认情况下,Netlogon服务在域内所有机器后台运行

      • 该服务的可执行文件路径为C:\Windows\system32\lsass.exe

3.Netlogon认证流程1

  • Neglogon 客户端和服务端之间通过 Microsoft Netlogon Remote Protocol(MS-NRPC)来进行通信。

    • MS-NRPC并没有使用与其他RPC相同的解决方案

    • 在进行正式通信之前,客户端和服务端之间需要进行身份认证并协商出一个Session Key

      • 该值用于保护双方后续的RPC通信流量。

该服务的可执行文件路径为C:\Windows\system32\lsass.exe


4.Netlogon认证流程2

  • Neglogon 客户端和服务端之间通过 Microsoft Netlogon Remote Protocol(MS-NRPC)来进行通信。

    • MS-NRPC并没有使用与其他RPC相同的解决方案

    • 在进行正式通信之前,客户端和服务端之间需要进行身份认证并协商出一个Session Key

      • 该值用于保护双方后续的RPC通信流量。

5.简要的Netlogon认证流程3

  • 域内机器客户端

  • 客户端发送Client Challenge

  • 服务端发送Server Challenge

  • Session Key=Encrypt(SharedSecret,Client Challenge,Server,Challenge)

  • 客户端发送Client Credential=(Encrypt(Session Key,Client Challenge))

  • 服务端发送Server Credential=(Encrypt(Session Key,Server Challenge))

  • 域控服务端

  • 1)由客户端启动网络登录会话,客户端调用NetrServerReqChallenge函数给服务端发送随机的8字节的Client Challenge值。

  • 2)服务端收到客户端发送的NetrServerReqChallenge函数调用指令后,服务端也调用NetrServerReqChallenge 函数发送随机的8字节的Server Challenge值。

  • 3)此时,客户端和服务端均收到了来自对方的Challenge值 ,然后双方都使用共享的密钥secret(客户端机器账户的Hash)以及来自双方的Challenge值通过计算得到SessionKey Session Key=KDF(secret,(Client Challenge+Server Challenge))

    • 此时,客户端和服务端均拥有了相同的Client Challenge、Server Challenge、Session Key
  • 4)客户端使用Session Key 作为密钥加密Client Challenge 得到Client Credential并发送给服务端。

    • 服务端收到客户端发来的Client Credential后,本地使用Session Key 作为密钥加密Client Challenge 计算出 Client Credential

    • 然后比较本地计算出的Client Credential和从客户端发送来的Client Credential 是否相同。

    • 如果两者相同,则说明客户端拥有正确的凭据以及Session Key

  • 5)服务端使用Session Key 作为密钥加密Server Challenge 得到Server Credential并发送给客户端

    • 客户端收到服务端发来的Server Credential后,本地使用Session Key作为密钥加密Server Challenge 计算出Server Credential

    • 然后比较本地计算出的Server Credential和从服务端发送来的Server Credential是否相同。

    • 如果两者相同,则说明服务端拥有相同的Session Key.

  • 6)至此,客户端和服务端双方互相认证成功并且拥有相同的Session Key,此后使用Session Key 来加密后续的RPC通信流量


6.协议漏洞分析

  • 到底是以上哪步出现了问题导致漏洞的产生呢?后面空了再来说说这个问题哟
相关推荐
xierui1231231 小时前
给内容 Agent 接平台账号前,先设计四层权限:读、写、预填、提交
人工智能·网络安全·aigc·软件工程
技术不好的崎鸣同学3 小时前
第一章:PEB结构解析与内存定位
windows·安全·系统安全
古养摩登原始人3 小时前
脑机接口合规最新发展:从政策到实践,构建安全可控的技术生态
人工智能·安全
Multipath7125 小时前
乾元通基于原生UDP时隙感知的多链路聚合方案
网络·网络协议·5g·安全·udp·智能路由器·实时音视频
liuyunshengsir6 小时前
Codex Harness 安全沙箱机制原理:AI 编程代理如何安全地执行命令
人工智能·安全
qq_297670876 小时前
第 4 篇:HTTP 和浏览器——HTTPS 不只是「把 HTTP 包一层 TLS」那么简单
网络安全·https·tls
LorryJovens7 小时前
【LAAP论文】Chat GPT6来临:当一个强认知框架下的harness工程遇到强模型的安全对齐应对的调查研究
安全
Flynt8 小时前
Chrome 修了个零日漏洞,你的 VS Code 和 Cursor 可能还在裸奔
安全·electron·visual studio code
TechWayfarer8 小时前
做IP归属地查询时总是查不准?IP纯净度检测实战:从“查归属地“到识别“脏IP“的四个维度
服务器·网络·python·tcp/ip·安全·web安全
huizhulihuiwu8 小时前
高端大型会议会务系统 私有化部署:如何平衡安全、性能与成本?
大数据·安全·会议签到·智能会议·会务系统