MICROSOFT WINDOWS NFS V4中发现一个远程代码执行漏洞
2022-9-17 12:7:15 Author: 嘶吼专业版(查看原文) 阅读量:10 收藏

关于MICROSOFT WINDOWS NFS V4 的漏洞频频出现,七月份,趋势科技研究团队就公布了一个CVE-2022-30136,该漏洞是在网络文件系统 (NFS) 的实现中发现的,并且是由于对 NFSv4 请求的处理不当造成的。未经身份验证的攻击者可以利用此漏洞在 SYSTEM 上下文中执行任意代码。

NFS v4是NFS v3的继承版本,主要针对WAN环境部署NFS做出改进并提出NFS分布式文件系统方案。NFSv4为虚拟分配提供的新特性。随着存储虚拟分配功能的普及使用,nfsv4可以为预留固定大小的存储空间;同样在文件系统上删除文件后,也能够在存储上面释放相应空间。

趋势科技研究团队在最新Windows 网络文件系统中发现一个远程执行代码漏洞。该漏洞是由于 NFS 请求中的字段验证不正确造成的。远程攻击者可以通过向目标服务器发送恶意 RPC 调用来利用此漏洞。成功利用会导致在 SYSTEM 上下文中执行任意代码。不成功的利用可能会导致目标系统崩溃。

Microsoft Windows 附带了几个旨在与非 Windows 文件共享进行通信和交互的网络功能。其中一个模块称为网络文件系统(NFS)。

网络文件系统(NFS)是文件系统之上的一个网络抽象,来允许远程客户端以与本地文件系统类似的方式,来通过网络进行访问。虽然 NFS 不是第一个此类系统,但是它已经发展并演变成 UNIX系统中最强大最广泛使用的网络文件系统。NFS 允许在多个用户之间共享公共文件系统,并提供数据集中的优势,来最小化所需的存储空间。

网络文件系统(NFS)从1984 年问世以来持续演变,并已成为分布式文件系统的基础。当前,NFS(通过 pNFS 扩展)通过网络对分布的文件提供可扩展的访问。

版本4由IETF开发,文档记录在RFC 3010(2000年12月发布)中,并在RFC 3530(2003年4月发布)和RFC 7530(2015年3月发布)中进行了修订。NFS允许用户像访问本地文件系统一样访问远程文件共享。共享可以设置不同的访问级别和权限,如读写、只读。此外,还可以使用IP/UID/GID/Kerberos安全性。NFS使用ONC (Open Network Computing)远程过程调用RPC (Remote Procedure Call)来交换控制消息。ONC RPC最初是由Sun Microsystems开发的,也可以称为Sun RPC。

当ONC RPC消息通过TCP传输时,它们的前面有一个指定消息长度的Fragment标头结构。这允许接收方区分通过单个 TCP 会话发送的多条消息。其他协议(如UDP)不使用该字段。注意,所有多字节值都是按照大端字节顺序编码的。

一般ONC RPC请求消息的结构如下:

Sun-RPC 消息中的 Credentials 结构如下所述:

上述结构中的 Flavor 字段用作 Contents 数据的类型标识符。由于历史原因,安全风格被称为身份验证风格。由于历史原因,安全方法被称为身份验证方法。RPC规范中定义了多种安全规则,如AUTH_NONE(0)、AUTH_SYS(1)、AUTH_SHORT(2)、AUTH_DH(3)和RPCSEC_GSS(6)。

RPCSEC_GSS 的 Contents 字段具有以下结构:

GSS Procedure字段定义了四种类型:RPCSEC_GSS_DATA(0)、RPCSEC_GSS_INIT(1)、RPCSEC_GSS_CONTINUE_INIT(2) 和 RPCSEC_GSS_DESTROY(3)。另外,对于GSS Service字段,有 rpc_gss_svc_none(1)、rpc_gss_svc_integrity(2) 和 rpc_gss_svc_privacy(3) 三种类型。在使用RPCSEC_GSS认证RPC客户端时,必须使用RPCSEC_GSS_INIT和RPCSEC_GSS_CONTINUE_INIT RPC消息创建安全上下文。首先,RPC 客户端发送一个 RPCSEC_GSS_INIT 消息开始创建上下文。然后,RPC 服务器决定是否需要另一个令牌来创建。如果是这样,服务器返回一个GSS_S_CONTINUE_NEEDED消息,而客户端需要发送一个RPCSEC_GSS_CONTINUE_INIT消息来继续。

如果GSS Service字段设置为2 (rpc_gss_svc_integrity),则Program-specific data字段的前缀结构如下:如果GSS Service字段设置为3 (rpc_gss_svc_privacy),则对Program-specific data字段进行加密。

当Program字段设置为100003 (NFS), 并且Procedure字段设置为1 (Compound)时,Program-specific data字段具有如下结构:

在请求数据中,对于消息中的每个操作:

操作码 OP_CREATE(6) 的操作数据;

操作码 OP_OPEN(18) 的操作数据;

操作码 OP_SETATTR(34) 的操作数据;

Data (fatattr4)的格式如下:

ACL 的属性数据(Bit12, 0x1000);

NFS 的 Windows 实现中存在缓冲区溢出漏洞。该漏洞是由于在处理 Nfs4SrvAclBuildWindowsAclsFromNfsAcl 中的 ACL 属性数据时对 ACE_Count 字段的错误验证造成的。

只有在使用操作码6、18、34设置ACL属性数据时,该函数才容易受到攻击。

服务器分配一个大小为 (ACE_Count << 5) 的响应缓冲区。此大小在 Nfs4SrvAclBuildWindowsAclsFromNfsAcl 中存储为 uint64_t。这种大小的缓冲区是使用 NfsMemMgrBufferAllocate 创建的。然而,NfsMemMgrBufferAllocate只接受uint32_t的缓冲区大小,所以请求大小的上32位被忽略。

这允许攻击者指定一个 ACE_Count,这样(ACE_Count << 5) & 0xFFFFFFFF < ACE_Count。这将导致函数稍后在使用缓冲区时发生缓冲区溢出。

特别是,ACE_Count值高于0x8000000将触发此漏洞。

注意,ACE_Count = 0x8000000本身不容易受到攻击,因为当请求的长度为零时,NfsMemMgrBufferAllocate将出错。

攻击者可以利用此漏洞溢出堆缓冲区。成功利用可能会导致在 SYSTEM 上下文中执行任意代码。不成功的利用将导致目标系统崩溃。

检测设备需要检查RPC请求消息中的Program字段是否为100003(NFS),Procedure字段是否为1(COMPOUND),Program Version字段是否为4(NFS4)。如果找到,设备必须检查 ONC RPC 消息中的程序特定数据。

检测设备应在每次操作中检查易受攻击的操作码(6、18、34)。如果存在,设备应检查 ACL 属性数据的操作。如果存在 ACL 属性数据,则设备应检查 0x8000000 以上的 ACE_Count 字段。

消息中没有固定的偏移量可用于忽略非易受攻击的操作码,因为 NFS 操作不会始终包含操作数据的长度。必须处理完整的消息以确定是否有任何 ACL 属性数据。

如果 ACE_Count 字段大于 0x8000000,则应认为该流量是可疑的,可能有攻击者在利用此漏洞。

微软已在2022年8月修复此漏洞。在他们介绍的办法中,他们还列出了一种禁用NFSv4.1作为减少攻击的方法。然而,这可能会导致有关功能的丧失。

参考及来源:https://www.zerodayinitiative.com/blog/2022/8/31/cve-2022-34715-more-microsoft-windows-nfs-v4-remote-code-execution


文章来源: http://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247550631&idx=2&sn=c009b965a96f9fd19a9a260cd20765ca&chksm=e915d69dde625f8b93747abbbbd130af1479815a36d83a84a5474cb41fa738813cc2efe61528#rd
如有侵权请联系:admin#unsafe.sh