烂土豆提权技术详解ms16-075

烂土豆技术宅解读(不知所云)

烂土豆提权技术属于Windows里才有的,技术文档上说到烂土豆都是一连串不知所云的词汇排比。

使用中间人攻击(NTLM重放),在本地协商一个安全令牌。

这个过程是通过一系列的Windows API调用实现的,只有具有"模仿安全令牌权限"的账户才能去模仿别人的令牌。

"烂土豆"(Rotten Potato)及其变种"多汁土豆"(Juicy Potato)是 Windows 提权史上非常经典的漏洞利用技术。它的核心目标很明确:把当前的低权限账户(如 IIS 的 AppPool 用户),提升到系统最高权限 NT AUTHORITYSYSTEM。

简单来说,这是一种"中间人攻击",利用了 Windows 在处理身份验证时的逻辑缺陷。

等等,但你真的能理解清楚这个技术的本质吗?


镜像+重放+模拟令牌

先举个简单的例子:

你(低权限用户)想进入只有"国王"(SYSTEM)能进的房间。你不能直接进去,但你可以利用"传话"的方式来冒充国王。

结合案例解读

整个过程可以分为四个步骤:
1. 制造"传话"机会 (利用 DCOM/RPC)

Windows 内部有很多服务(如 BITS 服务)是以 SYSTEM 身份运行的。这些服务在进行进程间通信(IPC)时,会使用 DCOM(分布式组件对象模型)或 RPC(远程过程调用)。

操作:攻击者(烂土豆程序)会诱导这些高权限的 SYSTEM 服务,尝试去连接一个由攻击者控制的、伪造的网络端口(比如本地的一个 TCP 端口)。

目的:让 SYSTEM 服务向你的"假服务器"发起连接请求。

挖一个"地道" (建立假服务器)

你在皇宫墙角偷偷挖了个狗洞(开启一个伪造的 TCP/SMB 服务),假装自己是国王的一个亲信大臣。

你对着皇宫里大喊:"紧急军情!请国王大人亲自通过这个狗洞把密诏递给我!"

因为 Windows 的某些机制(MS16-075 漏洞)有缺陷,国王(SYSTEM)这个傻白甜真的信了,他走到狗洞边,准备把密诏(NTLM 认证信息)递出来给你看。

2. 强行"握手" (NTLM 认证请求)

当 SYSTEM 服务连接到你的"假服务器"时,Windows 的安全机制会要求进行身份验证。你的"假服务器"会要求对方进行 NTLM 身份验证。

关键点:SYSTEM 服务很听话,它会乖乖地把代表自己身份的"令牌"(Token)发给你(虽然是加密的挑战-响应格式)。

你并没有真的看密诏内容,而是迅速把国王的"身份信息"(Token)抓到了手里。利用系统的逻辑漏洞,你把国王的身份"反射"到了你自己身上。国王(system)把密诏(NTLM)给你的瞬间,你其实是做了两件事:

诱骗:你伪装成一个服务(假服务器),骗来了 SYSTEM 的"介绍信"(NTLM 认证包)。

复制:你并没有真的去解密这封介绍信(因为解密很难),而直接把它(NTLM认证包)复印了一份。

3. "偷梁换柱" (NTLM 中继/重放)

这是最核心的一步。你收到了 SYSTEM 的认证请求,但你无法破解它的密码。不过,你不需要破解,你只需要把这个认证请求"中继"到另一个你有权限的地方。

技术细节:烂土豆程序利用 API(如 AcceptSecurityContext)模拟成一个认证服务器。它接收 SYSTEM 的认证包,然后利用本地的 RPC 机制(通常是 135 端口)发起另一个身份验证流程。

结果:程序成功欺骗了系统,让系统以为"本地的低权限用户"其实就是"SYSTEM",从而协商出一个可用的 Impersonation Token(模拟令牌)。

你拿着这张复印的"介绍信",转身跑到了本地系统的大门口(通常是 RPC 接口,端口 135),对守卫(操作系统)说:

"看!这是 SYSTEM 大人的介绍信!我现在要以 SYSTEM 的名义,在这里开个新账户(或者创建个新进程)!"

这里的关键是,Windows 系统当时太单纯了。它收到这张介绍信时,只检查了:"嗯,这确实是 SYSTEM 的签名,货真价实。"

它没有检查:"递这张介绍信的人,是不是 SYSTEM 本人?"

它默认了"谁递介绍信,谁就是国王(system)认可的可信赖人"。

4. 冒充"国王" (令牌模拟)

现在你手里有了一个 SYSTEM 的令牌。利用 Windows 提供的 SeImpersonatePrivilege(模拟客户端权限),你可以拿着这个令牌去创建一个新的进程(比如 cmd.exe)。

结局:这个新启动的命令行窗口,虽然是由你启动的,但它拿着的是 SYSTEM 的令牌。于是,你拥有了系统的最高控制权。

因为系统相信了这张"偷来"的介绍信,它就会给你(那个低权限的用户)发一个"临时通行证"(Impersonation Token)。

拿着这个通行证,你就可以在系统里冒充 SYSTEM 身份运行程序了。

总结一下:

就是偷来 SYSTEM 的介绍信,骗过了系统的安检RPC,让自己冒充成了 SYSTEM。


为什么RPC这么好骗?
1.微软整个Windows 认证体系(NTLM)的设计哲学问题:

我们可以把 RPC 看作是皇宫里的"传旨太监":

只认圣旨(签名),不认人(来源):

Windows 的很多老服务(包括 RPC)在设计时,默认网络是安全的 。所以它们只验证"你是不是持有合法的令牌(签名)",而没有严格验证"你是怎么拿到这个令牌的"。

只要你的令牌是 SYSTEM 的,不管你是 SYSTEM 本人,还是你偷了 SYSTEM 的令牌,系统都默认给你放行。

2.缺乏"二次验证"机制:

这就是你感觉到的"傻"。现代的安全协议通常会有"通道绑定 "(Channel Binding)机制,也就是不仅看令牌,还要看这个令牌是不是从"合法的通道"里传过来的。

但在烂土豆利用的那个年代(以及某些旧配置下),RPC 和 SMB 协议缺乏这种绑定机制。这就导致了攻击者可以利用"命名管道"(Named Pipe)这种看似合法的通道,把伪造的令牌塞进去,而 RPC看都不看一眼,直接就放行了。

完结

这也正是为什么微软后来推出了SMB 签名、EPA(扩展保护)等机制,就是为了强制 RPC 和 SMB的认证机制,不仅要看签名,还得看签名怎么来的。

相关推荐
ManageEngine卓豪4 小时前
企业网络安全建设实践:2026 威胁态势、合规基线与分层防御落地
web安全·网络安全·it运维·网络安全防护
QZ166560951594 小时前
可视化易用·低误报率·跨区域部署:知源-AI数据分类分级系统在金融行业的落地实践
大数据·网络·安全·网络安全
2501_915909065 小时前
抓包工具断点拦截是什么?如何半路拦截修改 HTTP 请求
网络协议·计算机网络·网络安全·adb·https·udp
大方子7 小时前
【PolarCTF】PHP_Deserialization
网络安全·polarctf
持敬chijing10 小时前
白盒测试与代码审计-Claude Code Windows环境搭建
windows·安全·网络安全·网络攻击模型
Vitaliy Kostrov(柯维远)10 小时前
客户端如何检查直播流:从流内标记到停止播放
android·运维·服务器·驱动开发·网络安全·系统架构·cdn
sbjdhjd1 天前
从签名重放到 Agent Harness:一堂安全课程如何把前端逆向、MCP 与工程约束串起来
网络安全·ai·github·agent·webshell·mcp·harness
持敬chijing2 天前
白盒测试与代码审计-js登录逆向实战
javascript·网络·安全·web安全·网络安全·网络攻击模型
南棋网络安全2 天前
ssrf跨站请求伪造(保姆级教程)
运维·服务器·网络·网络安全
科技象限2 天前
数据防泄漏系统:文件是怎么溜出门的,就该怎么堵
运维·网络·网络安全·安企神