烂土豆提权技术详解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的认证机制,不仅要看签名,还得看签名怎么来的。

相关推荐
大方子17 小时前
【PolarCTF】rce1
网络安全·polarctf
枷锁—sha18 小时前
Burp Suite 抓包全流程与 Xray 联动自动挖洞指南
网络·安全·网络安全
聚铭网络19 小时前
聚铭网络再度入选2026年度扬州市网络和数据安全服务资源池单位
网络安全
darkb1rd21 小时前
八、PHP SAPI与运行环境差异
开发语言·网络安全·php·webshell
世界尽头与你1 天前
(修复方案)基础目录枚举漏洞
安全·网络安全·渗透测试
枷锁—sha2 天前
【SRC】SQL注入快速判定与应对策略(一)
网络·数据库·sql·安全·网络安全·系统安全
liann1192 天前
3.1_网络——基础
网络·安全·web安全·http·网络安全
ESBK20252 天前
第四届移动互联网、云计算与信息安全国际会议(MICCIS 2026)二轮征稿启动,诚邀全球学者共赴学术盛宴
大数据·网络·物联网·网络安全·云计算·密码学·信息与通信
旺仔Sec2 天前
一文带你看懂免费开源 WAF 天花板!雷池 (SafeLine) 部署与实战全解析
web安全·网络安全·开源·waf
七牛云行业应用2 天前
Moltbook一夜崩盘:150万密钥泄露背后的架构“死穴”与重构实战
网络安全·postgresql·架构·高并发·七牛云