命名管道面临攻击：保障 Windows 进程间通信安全

命名管道是Windows上同一台计算机中应用程序之间通信的常用方式。它们速度快、由操作系统直接支持，并且适用于Windows服务、桌面应用、托盘进程、命令行工具和后台代理之间的通信。

典型设计可能包括一个以特权Windows服务作为命名管道服务器，而用户面应用程序作为客户端连接。由于两个进程运行在同一台计算机上，开发者常将这种通信视为内部通信，因此认为可信。

但在实际环境中，管道可以从一个存在许多不相关进程的环境中访问，这些进程可能运行在不同用户、会话和安全上下文下。

本地不等于可信

命名管道常被视为私有，因为它们用于同一计算机上应用程序间的通信。这种假设是不安全的。

一台Windows工作站可能以LocalSystem、管理员、标准用户、服务账户以及不同的交互式或远程会话运行进程。它还可能包含在受损账户下运行的第三方软件、脚本、诊断工具和恶意软件。

任何知道管道名称并拥有足够访问权限的进程都可以尝试连接。Windows本身并不知晓开发者打算让哪个可执行文件使用该管道。

因此，命名管道应被视为一个暴露的本地接口。在处理请求之前，应用程序必须确定谁连接了、该身份被允许做什么，以及提供的数据是否安全。

身份、访问控制和权限边界

当特权的Windows服务与较低权限的桌面应用程序通信时，风险最大。

以LocalSystem运行的服务可能能够修改受保护的文件和注册表项、启动进程、更改系统配置、访问其他用户的数据，或与内核驱动通信。当这些操作通过命名管道暴露时，管道就变成了特权功能的API。

一次成功连接只能证明客户端被允许打开管道，并不能证明：

• 客户端是预期的应用程序；

• 连接的用户已获授权；

• 请求的操作被允许；

• 提供的命令是安全的。

因此，管道权限应明确定义，并限制到最小适格身份集合。为Everyone、Authenticated Users或所有交互式用户设置宽泛权限，可能会允许无关进程访问管道。

身份验证和授权也必须保持分离。用户可以允许查询服务状态，但不应允许停止服务、更改受保护设置、启动进程或访问任意文件。敏感命令应单独授权。

模拟可以帮助在客户端安全上下文下执行操作，但必须谨慎处理。服务器应验证模拟是否成功，限制在模拟期间执行的工作，并始终恢复其原始身份。