Akamai研究人员Ben Barnea在Windows Server服务中发现了一个重要的漏洞,鉴于此漏洞影响较大,建议客户尽快做好自查及防护。该漏洞被分配为CVE-2022-30216,风险评分为8.8。Windows Server服务在处理特制请求时存在漏洞,经过身份认证的远程攻击者可利用此漏洞在目标系统上执行代码。

该漏洞利用了Server服务实现的安全回调过程中的一个单字节缓冲区溢出漏洞(off-by-one)。单字节缓冲区溢出,其中最常见的是边界验证不严,通常包括循环次数错误和字符串操作不合适而造成的。

我们确认该漏洞存在于未修复的Windows 11和Windows Server 2022计算机中。

当该漏洞与针对Active Directory证书服务(AD CS)的新技术局域网管理器(NTLM)中继攻击结合使用时,具有域凭据的攻击者就能够在域控制器上远程运行代码。

我们还相信,攻击者可能会使用这种技术来修改服务器的证书映射,从而执行服务器欺骗。

该漏洞已向微软披露,并在7月进行了修复。

Windows 10 Version 21H2 for x64-based Systems
Windows 10 Version 21H2 for ARM64-based Systems
Windows 10 Version 21H2 for 32-bit Systems
Windows 11 for ARM64-based Systems
Windows 11 for x64-based Systems
Windows Server, version 20H2 (Server Core Installation)
Windows 10 Version 20H2 for ARM64-based Systems
Windows 10 Version 20H2 for 32-bit Systems
Windows 10 Version 20H2 for x64-based Systems
Windows Server 2022 (Server Core installation)
Windows Server 2022
Windows 10 Version 21H1 for 32-bit Systems
Windows 10 Version 21H1 for ARM64-based Systems
Windows 10 Version 21H1 for x64-based Systems

漏洞介绍

最近几个月,研究人员对微软的远程过程调用(MS-RPC)进行了深入的研究。简而言之,RPC 用于高效的进程间通信。它依赖于标准的客户端服务器模型,它是当今 Windows 中使用最广泛的协议之一。

研究人员在MS-RPC设计中发现的一个更有趣的方面是安全回调,它的作用是限制对RPC服务器的访问,本质上为不需要的(通常是远程的)用户提供安全性。许多 RPC 服务器实现了安全回调,每个服务器都有自己的逻辑和注意事项。

Windows服务广泛使用RPC使其功能对客户端可用。这促使研究人员研究不同的服务及其安全回调实现的底层逻辑。果然,他们找到一个安全漏洞,该漏洞可能允许攻击者执行服务器欺骗或触发对受害者的身份验证。

Server 服务(也称为 LanmanServer)是负责管理 SMB 共享的 Windows 服务。共享是可以通过公共网络文件系统服务器在网络上访问的资源,比如文件、打印机和目录树。从本质上讲,网络共享允许用户利用网络上的其他设备来执行各种日常任务。

Server服务允许远程计算机通过命名管道(\\pipe\srvsvc)上的RPC创建、配置、查询和删除共享。为了介绍方便,我们将把该服务称为srvsvc。

srvsvc中的漏洞会造成很大影响,因为该服务提供核心功能,且默认情况下会在每台Windows计算机上运行。

SMB over QUIC

SMB over QUIC 由 TLS 1.3 使用端口 443 (HTTPS) 而不是端口 445 (SMB) 建立隧道,并且所有 SMB 流量都包含在隧道内,这意味着没有任何流量暴露在网络中。由于这些功能,SMB over QUIC 是具有更高安全要求的移动用户或组织的可靠选择。

从 Windows 10 20H2 开始,微软推出了一项新功能——SMB over QUIC。该功能允许通过新的传输层网络协议 QUIC 访问 SMB 共享。QUIC 的目的是提供更可靠、更安全的连接,同时克服常见的互联网问题,例如延迟和数据包丢失。

在QUIC网络交互中,作为一种附加的安全措施,客户端通过检查服务器提供的证书来验证服务器的身份。通过在 QUIC 上添加 SMB,服务器服务开始负责管理这些证书。

研究人员就是在这个功能中发现漏洞的,要理解它,我们首先需要探索RPC服务器执行访问控制的方法。

安全回调

许多 Windows 服务(其中包括 srvsvc)实现了一个 RPC 服务器,以允许进程间通信并为不同的客户端提供对其功能的访问。Windows 中的 RPC 利用了各种安全机制,本文将专注一个叫做安全回调的方法。

安全回调的目标是限制对RPC接口的访问。回调是由RPC服务器开发人员实现的,它允许每个开发人员应用自己的逻辑来允许访问特定的用户或阻止访问特定的功能。在RPC中,由服务器公开的函数使用opnums(操作号)表示,我们将在 srvsvc 的安全回调中很快看到。

cve-image-1.webp.jpg

安全回调的变化

要了解这个漏洞,我们首先需要查看在SMB over QUIC功能添加之前srvsvc的安全回调:

cve-image-2.webp.jpg

srvsvc安全回调——Windows 10 19H2

如上所示,srvsvc的安全回调逻辑如下:

如果远程客户端试图访问64-69范围内的函数——拒绝访问;

如果远程客户端(非集群帐户)试图访问一个58-63范围内的函数——拒绝访问;

因此,从本质上讲,远程客户端被阻止访问接口的这些特定功能。此范围检查提示受限制的函数是敏感的,应该只由预期的(本地)进程调用。

随着SMB over QUIC的增加,Windows 10 20H2为srvsvc服务增加了四个新功能:

LocalrServerCertificateMappingGet
LocalrServerCertificateMappingSet
LocalrServerCertificateMappingEnum
LocalrServerCertificateMappingRemove

因为远程访问这些函数是不可取的,所以它们被添加到本地函数范围中——srvsvc的安全回调禁止远程客户端使用这些函数。

而且,如下所示,范围确实被更改为包括这四个新函数的 opnum,将第一个本地范围从 64-69 增加到 64-73,并将安全回调的访问控制扩展到这些函数。到目前为止,一切顺利。

cve-image-3.webp.jpg

srvsvc安全回调——Windows 10 20H2

在Windows 11和Windows Server 2022中,微软增加了一个名为LocalrServerCertificateMappingModify的新函数:

4.png

但是,这一次,在这个新版本中,受限制函数的范围并没有改变,而是包含了新添加的函数:

5.png

srvsvc安全回调——Windows 11/Server 2022

因此,在添加此函数时,它没有被安全回调所覆盖,因此远程RPC客户端可以访问它。

被利用的可能

通过调用此函数,攻击者可以更改服务器上的证书映射配置。证书映射是服务器的 QUIC 证书和证书存储中的证书之间的“符号链接”。我们相信攻击者可能会使用这个函数来添加他们自己的证书映射,从而执行服务器欺骗。请注意,此函数不会在 Windows 证书存储中添加或修改证书,而是将 QUIC 服务器使用的证书映射到 Windows 存储中的证书。

在尝试评估漏洞的影响时,我们注意到函数接收的结构包含证书的存储位置:

6.png

通过提供UNC路径作为storeLocation变量,攻击者可以使LocalrServerCertificateMappingModify触发受害者服务器向他们控制的计算机发出RPC请求。触发请求的函数流如下:

LocalrServerCertificateMappingModify → SsValidCertandUpdateCertinfo → CertOpenStore → _CertDllOpenSystemStoreProvW → EnumPhysicalStore → FormatSystemRegPath → RegConnectRegistryExW → BaseBindToMachine → Rpc_OpenPredefHandle → NdrClientCall3

在服务器发送到我们计算机的RPC请求期间,服务器对攻击者的服务器执行身份验证。攻击者现在可以利用受害者的凭证来执行NTLM中继攻击。

利用该漏洞并执行 NTLM 中继流,研究人员成功复制了 PetitPotam 攻击场景,即滥用 AD CS 并接管域控制器。

7.png

触发漏洞需要攻击者能够访问域中的计算机。对于NTLM中继场景,需要增加AD的CS角色,以及AD的一个容易被NTLM中继的服务(证书颁发机构 Web 注册、证书注册 Web 服务)。

漏洞修复

微软周二在7月的补丁中发布了针对该漏洞的补丁。目前这个漏洞已经被修复了:

1.纠正安全回调中的本地函数范围,从而防止对LocalrServerCertificateMappingModify的远程访问;

2.在每个添加的本地函数中增加一个访问检查;

缓解和检测

以下是缓解NTLM中继的建议:

8.png

通常,滥用AD CS的NTLM中继攻击将涉及TGT请求。事件日志(EventID 4768)将包括请求计算机的IP地址。如果从不是域控制器本身的计算机为域控制器请求TGT,则可以检测到恶意TGT请求。

总结

当添加新功能时,注意它们带来的潜在后果是很重要的。不仅在功能本身,而且在用户访问它的方式上。在我们的案例中,SMB over QUIC 被添加到 Windows 中,并为服务器服务引入了新功能。但是,该漏洞不在于通过 QUIC 实现 SMB,而在于旧功能限制对相应 RPC 接口的访问方式。

Akamai研究人员Ben Barnea在Windows Server服务中发现了一个重要的漏洞,鉴于此漏洞影响较大,建议客户尽快做好自查及防护。该漏洞被分配为CVE-2022-30216,风险评分为8.8。Windows Server服务在处理特制请求时存在漏洞,经过身份认证的远程攻击者可利用此漏洞在目标系统上执行代码。

该漏洞利用了Server服务实现的安全回调过程中的一个单字节缓冲区溢出漏洞(off-by-one)。单字节缓冲区溢出,其中最常见的是边界验证不严,通常包括循环次数错误和字符串操作不合适而造成的。

我们确认该漏洞存在于未修复的Windows 11和Windows Server 2022计算机中。

当该漏洞与针对Active Directory证书服务(AD CS)的新技术局域网管理器(NTLM)中继攻击结合使用时,具有域凭据的攻击者就能够在域控制器上远程运行代码。

我们还相信,攻击者可能会使用这种技术来修改服务器的证书映射,从而执行服务器欺骗。

该漏洞已向微软披露,并在7月进行了修复。

Windows 10 Version 21H2 for x64-based Systems
Windows 10 Version 21H2 for ARM64-based Systems
Windows 10 Version 21H2 for 32-bit Systems
Windows 11 for ARM64-based Systems
Windows 11 for x64-based Systems
Windows Server, version 20H2 (Server Core Installation)
Windows 10 Version 20H2 for ARM64-based Systems
Windows 10 Version 20H2 for 32-bit Systems
Windows 10 Version 20H2 for x64-based Systems
Windows Server 2022 (Server Core installation)
Windows Server 2022
Windows 10 Version 21H1 for 32-bit Systems
Windows 10 Version 21H1 for ARM64-based Systems
Windows 10 Version 21H1 for x64-based Systems

漏洞介绍

最近几个月,研究人员对微软的远程过程调用(MS-RPC)进行了深入的研究。简而言之,RPC 用于高效的进程间通信。它依赖于标准的客户端服务器模型,它是当今 Windows 中使用最广泛的协议之一。

研究人员在MS-RPC设计中发现的一个更有趣的方面是安全回调,它的作用是限制对RPC服务器的访问,本质上为不需要的(通常是远程的)用户提供安全性。许多 RPC 服务器实现了安全回调,每个服务器都有自己的逻辑和注意事项。

Windows服务广泛使用RPC使其功能对客户端可用。这促使研究人员研究不同的服务及其安全回调实现的底层逻辑。果然,他们找到一个安全漏洞,该漏洞可能允许攻击者执行服务器欺骗或触发对受害者的身份验证。

Server 服务(也称为 LanmanServer)是负责管理 SMB 共享的 Windows 服务。共享是可以通过公共网络文件系统服务器在网络上访问的资源,比如文件、打印机和目录树。从本质上讲,网络共享允许用户利用网络上的其他设备来执行各种日常任务。

Server服务允许远程计算机通过命名管道(\\pipe\srvsvc)上的RPC创建、配置、查询和删除共享。为了介绍方便,我们将把该服务称为srvsvc。

srvsvc中的漏洞会造成很大影响,因为该服务提供核心功能,且默认情况下会在每台Windows计算机上运行。

SMB over QUIC

SMB over QUIC 由 TLS 1.3 使用端口 443 (HTTPS) 而不是端口 445 (SMB) 建立隧道,并且所有 SMB 流量都包含在隧道内,这意味着没有任何流量暴露在网络中。由于这些功能,SMB over QUIC 是具有更高安全要求的移动用户或组织的可靠选择。

从 Windows 10 20H2 开始,微软推出了一项新功能——SMB over QUIC。该功能允许通过新的传输层网络协议 QUIC 访问 SMB 共享。QUIC 的目的是提供更可靠、更安全的连接,同时克服常见的互联网问题,例如延迟和数据包丢失。

在QUIC网络交互中,作为一种附加的安全措施,客户端通过检查服务器提供的证书来验证服务器的身份。通过在 QUIC 上添加 SMB,服务器服务开始负责管理这些证书。

研究人员就是在这个功能中发现漏洞的,要理解它,我们首先需要探索RPC服务器执行访问控制的方法。

安全回调

许多 Windows 服务(其中包括 srvsvc)实现了一个 RPC 服务器,以允许进程间通信并为不同的客户端提供对其功能的访问。Windows 中的 RPC 利用了各种安全机制,本文将专注一个叫做安全回调的方法。

安全回调的目标是限制对RPC接口的访问。回调是由RPC服务器开发人员实现的,它允许每个开发人员应用自己的逻辑来允许访问特定的用户或阻止访问特定的功能。在RPC中,由服务器公开的函数使用opnums(操作号)表示,我们将在 srvsvc 的安全回调中很快看到。

cve-image-1.webp.jpg

安全回调的变化

要了解这个漏洞,我们首先需要查看在SMB over QUIC功能添加之前srvsvc的安全回调:

cve-image-2.webp.jpg

srvsvc安全回调——Windows 10 19H2

如上所示,srvsvc的安全回调逻辑如下:

如果远程客户端试图访问64-69范围内的函数——拒绝访问;

如果远程客户端(非集群帐户)试图访问一个58-63范围内的函数——拒绝访问;

因此,从本质上讲,远程客户端被阻止访问接口的这些特定功能。此范围检查提示受限制的函数是敏感的,应该只由预期的(本地)进程调用。

随着SMB over QUIC的增加,Windows 10 20H2为srvsvc服务增加了四个新功能:

LocalrServerCertificateMappingGet
LocalrServerCertificateMappingSet
LocalrServerCertificateMappingEnum
LocalrServerCertificateMappingRemove

因为远程访问这些函数是不可取的,所以它们被添加到本地函数范围中——srvsvc的安全回调禁止远程客户端使用这些函数。

而且,如下所示,范围确实被更改为包括这四个新函数的 opnum,将第一个本地范围从 64-69 增加到 64-73,并将安全回调的访问控制扩展到这些函数。到目前为止,一切顺利。

cve-image-3.webp.jpg

srvsvc安全回调——Windows 10 20H2

在Windows 11和Windows Server 2022中,微软增加了一个名为LocalrServerCertificateMappingModify的新函数:

4.png

但是,这一次,在这个新版本中,受限制函数的范围并没有改变,而是包含了新添加的函数:

5.png

srvsvc安全回调——Windows 11/Server 2022

因此,在添加此函数时,它没有被安全回调所覆盖,因此远程RPC客户端可以访问它。

被利用的可能

通过调用此函数,攻击者可以更改服务器上的证书映射配置。证书映射是服务器的 QUIC 证书和证书存储中的证书之间的“符号链接”。我们相信攻击者可能会使用这个函数来添加他们自己的证书映射,从而执行服务器欺骗。请注意,此函数不会在 Windows 证书存储中添加或修改证书,而是将 QUIC 服务器使用的证书映射到 Windows 存储中的证书。

在尝试评估漏洞的影响时,我们注意到函数接收的结构包含证书的存储位置:

6.png

通过提供UNC路径作为storeLocation变量,攻击者可以使LocalrServerCertificateMappingModify触发受害者服务器向他们控制的计算机发出RPC请求。触发请求的函数流如下:

LocalrServerCertificateMappingModify → SsValidCertandUpdateCertinfo → CertOpenStore → _CertDllOpenSystemStoreProvW → EnumPhysicalStore → FormatSystemRegPath → RegConnectRegistryExW → BaseBindToMachine → Rpc_OpenPredefHandle → NdrClientCall3

在服务器发送到我们计算机的RPC请求期间,服务器对攻击者的服务器执行身份验证。攻击者现在可以利用受害者的凭证来执行NTLM中继攻击。

利用该漏洞并执行 NTLM 中继流,研究人员成功复制了 PetitPotam 攻击场景,即滥用 AD CS 并接管域控制器。

7.png

触发漏洞需要攻击者能够访问域中的计算机。对于NTLM中继场景,需要增加AD的CS角色,以及AD的一个容易被NTLM中继的服务(证书颁发机构 Web 注册、证书注册 Web 服务)。

漏洞修复

微软周二在7月的补丁中发布了针对该漏洞的补丁。目前这个漏洞已经被修复了:

1.纠正安全回调中的本地函数范围,从而防止对LocalrServerCertificateMappingModify的远程访问;

2.在每个添加的本地函数中增加一个访问检查;

缓解和检测

以下是缓解NTLM中继的建议:

8.png

通常,滥用AD CS的NTLM中继攻击将涉及TGT请求。事件日志(EventID 4768)将包括请求计算机的IP地址。如果从不是域控制器本身的计算机为域控制器请求TGT,则可以检测到恶意TGT请求。

总结

当添加新功能时,注意它们带来的潜在后果是很重要的。不仅在功能本身,而且在用户访问它的方式上。在我们的案例中,SMB over QUIC 被添加到 Windows 中,并为服务器服务引入了新功能。但是,该漏洞不在于通过 QUIC 实现 SMB,而在于旧功能限制对相应 RPC 接口的访问方式。

苹果系统运行着一些现有的最大和最赚钱的软件应用程序生态系统。理论上,要进入这些生态系统,传统上需要使用macOS,并加入苹果开发者计划(Apple Developer Program)。

如果你想为 Apple 操作系统开发应用程序,你可能会使用 Apple 的操作系统和 Apple 的官方工具进行开发和分发。但对于开源开发人员通常希望以最小的努力分发跨平台应用程序。在整个编程语言生态系统中,你运行的操作系统被抽象为许多应用程序的实现细节。通过创建 macOS、iOS 等开发需要直接访问 macOS 和通常高于市场价格的Apple 硬件的要求,苹果软件生态系统强加的分发要求是有效的排他性,并阻止利益相关方对进入其生态系统。

在苹果平台上发布软件的一个问题是代码签署和公证,即你需要:

1.在应用程序中嵌入加密签名,有效地证明来自 Apple Developer Program 关联帐户的真实性。 (这是签名。)

2.将你的应用程序上传到 Apple,以便他们对其进行检查,验证它符合要求,可能还会存储一个副本。然后,苹果会发布自己的加密签名,即公证书,然后需要将其嵌入到正在分发的应用程序上,这样苹果的操作系统才能信任它。(这是公证。)

从历史上看,这些步骤需要 Apple 专有软件专门从 macOS 运行。这意味着,即使你在 Rust、Go 等软件生态系统或 Web 平台中,你可以在不直接访问 macOS 的情况下交叉编译应用程序(测试显然是另一回事),如果你愿意,你仍然需要 macOS签署和公证你的申请。由于默认的安全设置,在macOS上需要有效的签名和公证。在 iOS 等移动平台上,除非你运行的是越狱设备,否则不可能发布未经签名和公证的应用程序。

如果我不需要macOS来构建我的应用程序,为什么我要被迫把苹果设备作为我的软件发布过程的一部分?为什么在发布的时候,我必须签署和公证我的申请,它不能更简化吗?

如果能重新实现 Apple 代码签名,以便开发人员有更多的灵活性和机会将应用程序分发到 Apple 的生态系统。其最终目标是扩大 Apple 生态系统对更多开发者的访问。

首先,得益于 rcodesign 0.14.0的发布。这是我第一次发布 rcodesign 的预构建二进制文件(Linux、Windows 和 macOS)。

macOS rcodesign 可执行文件是自签名的,它由 GitHub Actions Linux 运行程序使用 YubiKey 独有的代码签名证书进行签名。

2021年,apple-codesign 项目/Rust crate 发生了很大变化!只需查看更改日志

这个项目从tugger-apple-codesign改名而来。

如果你是通过 cargo install 安装的,你需要 cargo install --force apple-codesign 来强制 Cargo 用另一个 crate 中的一个来覆盖 rcodesign 可执行文件。

rcodesign CLI可执行文件仍然存在,而且比以往任何时候都更强大。你仍然可以在Linux、Windows、macOS和任何其他平台上对Apple应用程序进行签名,你可以在这些平台上编译Rust程序。

Sphinx 文档请点击这里,这与 PyOxidizer 的文档一起发布在 readthedocs.io 上(因为我使用的是 monorepo)。那里有一些通用文档,例如有关如何通过将你自己的替代代码签名 PKI 部署到并行 Apple 来选择性地绕过 Gatekeeper 的指南

支持签名包、DMG 和 .pkg 安装程序

当我去年宣布这个项目时,只有 Mach-O 二进制文件和非常简单的 .app 包是可签名的。即便如此,也有很多微妙的问题。

Rcodesign sign现在可以对更复杂的包进行签名,包括许多嵌套的包。有报道称iOS应用包签名正确。

该工具还支持签名.dmg磁盘映像文件和.pkg扁平封装包安装程序。

已知的签名限制现在记录在 Sphinx 文档中。

我相信 rcodesign 现在支持对用于 Apple 软件分发的所有主要文件格式进行签名。

支持 Linux、Windows 和 macOS 上的公证

苹果发布了一个名为Transporter的Java工具,可以让你上传文物到苹果进行公证。它们使这个工具可用于Linux、Windows,当然还有macOS。

虽然这个工具不是开源的,但使用这个工具可以让你在 Linux 和 Windows 上进行公证,同时仍然使用 Apple 的官方工具与他们的服务器通信。

rcodesign 现在支持调用 Transporter 并将工件上传到 Apple 进行公证。我们现在支持公证包、.dmg 磁盘映像和 .pkg 扁平封装安装程序包。我已经成功地从 Linux 公证了所有这些应用程序类型。

由于支持对所有应用程序类型进行签名和公证,现在可以在没有 macOS 参与发布过程的情况下发布 Apple 软件。

YubiKey 集成

我尝试尽可能多地使用我的 YubiKey,因为存储在 YubiKey 上的密钥或私钥可能比位于某个文件系统上的密钥或私钥更安全。如果你破解了我的设备,你很可能会获得我的私钥。但是你需要物理访问我的 YubiKey 并强迫或强迫我解锁它,以获得访问其私钥的权限。

rcodesign 现在支持使用 YubiKeys 进行签名操作。

这确实需要默认的智能卡 Cargo 功能。因此,如果手动构建,你将需要例如cargo install --features smartcard apple-codesign.。

YubiKey 集成来自 yubikey 。这个 crate 将直接与 macOS 和 Windows 中内置的智能卡 API 对话。所以如果你有一个启用了 YubiKey 支持的 rcodesign 构建,YubiKeys 应该可以工作。通过插入 YubiKey 并运行 rcodesign smartcard-scan 进行尝试。

YubiKey 集成文档可以点此查看

我甚至实现了一些命令来轻松管理 YubiKey 上的代码签名证书。例如,你可以直接在设备上运行 rcodesign smartcard-generate-key --smartcard-slot 9c 以生成新的私钥,然后  rcodesign generate-certificate-signing-request --smartcard-slot 9c --csr-pem-path csr.pem将该证书导出到证书签名请求 (CSR),你可以在 developer.apple.com 上交换 Applie 颁发的签名证书。这意味着你可以轻松创建其私钥直接在硬件设备上生成且永远无法导出的代码签名证书。以这种方式生成密钥比将密钥存储在软件库(比如苹果的Keychains)中更安全。

远程代码签名

我最感兴趣的功能是我称之为远程代码签名的功能。

我在GitHub托管的Linux GitHub Actions运行程序上签署了一个macOS通用Mach-O可执行文件,使用的YubiKey物理连接到我桌子旁边的Windows 11设备上。未在计算机之间复制签名的应用程序。

我有一个调用 rcodesign sign --remote-signer 的 GitHub Actions 工作流程。我手动触发了该工作流程,并开始使用浏览器观察近乎实时的作业输出。rcodesign sign --remote-signer 打印出一些指令(包括一堵 base64 编码数据的墙)以指示下一步该做什么。重要的是,它要求其他人运行 rcodesign remote-sign 以继续签名过程。

该日志向我们展示了使用 YubiKey 进行连接和身份验证,以及一些关于与远程服务器对话的状态更新。

远程签名使我能够从 GitHub 运营的 GitHub Actions 运行程序签署 macOS 应用程序,同时使用安全存储在我的 YubiKey 上的代码签名证书,该证书插入到距 GitHub Actions 运行程序数百公里的 Windows 设备上。

这里发生的是 2 个 rcodesign 进程通过中央中继服务器桥接的 websocket 相互通信。我免费操作一个默认服务器。服务器是开源的,如果你想运行你自己的服务器,你可以使用terrform模块,希望只需要花几分钟时间。当启动设备希望创建签名时,它向请求加密签名的签名者发送一条消息。然后将签名发送回发起者,发起者将其合并。

我设计这个特性时考虑到了CI系统的自动发布(比如GitHub Actions)。我想要一种方法,可以简化应用程序的代码签名和发布过程,而不必给CI中的低信任设备无限访问我的私人签名密钥的权限。这可能在许多其他场景中都是有用的。你是否曾经因为没有苹果发行的代码签名证书而通过电子邮件或下拉框将应用程序发送给别人签名?现在你有了一个不需要复制文件的替代解决方案。只要你可以看到启动设备的日志输出,或者将输出传递给你(例如通过聊天应用程序或电子邮件),你就可以在另一台设备上远程签署文件!

关于远程签名安全性

Websockets 通过由第三方操作的中央服务器?!授予远程设备访问权限以对任意内容执行代码签名?!你的恐惧和怀疑是 100% 有道理的:我也会这么想!

促进远程代码签名的服务会成为一个非常有利可图的攻击目标,如果被滥用,它可能被用来强制使用有效的代码签名证书的各方签署不想要的代码,如恶意软件。实现这样的功能有很多很多很多错误的方法。

远程代码签名设计和安全注意事项包含了我的一些高级设计目标和安全评估。远程代码签名协议详细介绍了通信协议,包括所涉及的加密(实际的加密,而不是流行的加密)。关键在于协议和服务器的设计使恶意服务器或中间人无法伪造签名请求。签名会话在几分钟后过期,第三方或服务器无法注入会导致不需要签名的恶意消息。通过初始握手获得会话临时共享加密密钥,并从那里使用对称加密密钥,因此对等方之间的所有有意义的消息都是端到端加密的。恶意服务器可以做的最糟糕的事情就是进行拒绝服务。

我相信我的远程签名实现比许多常见做法更安全,因为今天的常见做法需要复制私钥并让低信任度设备(如 CI 工作人员)访问私钥或者文件在没有加密监管链的情况下被复制以证明不会被篡改。是的,远程签名为远程访问引入了使用签名密钥的向量。但是按照我的意图进行实践,远程签名可以消除复制私钥或授予对它们的无限访问权限的需要。从威胁建模的角度来看,我认为密钥访问中的网络限制使得远程签名比现在许多人使用的私钥管理实践更安全。

话虽如此,这里的星号是我实现了我自己的密码系统来实现端到端消息安全。如果在设计或实现中存在漏洞,密码系统可能会崩溃,从而带来对消息伪造的防御。届时,恶意服务器或特权网络攻击者可能会强迫某人签署不需要的软件。但这很可能是损害的程度:对签名密钥的脱机攻击是不可能的,因为签名需要存在,而且私钥永远不会通过网络传输。即使没有端到端加密,该系统也比将你的私有密钥作为一个容易被窃取的CI秘密(或类似的)留在周围更安全。

Apple 钥匙串支持

0.14 版本开始,我们现在可以提前支持使用存储在 Apple 钥匙串中的代码签名证书进行签名!如果你在 Keychain Access 或 Xcode 中创建了 Apple 代码签名证书,那么这可能就是你的代码签名证书所在的位置。

我拖延了很长一段时间,因为我没有意识到这有什么好处:如果你使用macOS,只需使用 苹果的官方工具。但是随着rcodesign获得了对远程代码签名的支持,以及其他一些功能,这些功能可以让它成为所有平台上苹果工具的有力替代品,我认为我们应该提供这个功能,这样我们就不会再阻止人们从keychain导出私钥了。

Apple 的代码签名很复杂。 苹果的工具和rcodesign之间很容易出现细微差别。

rcodesign 现在有 print-signature-info 和 diff-signatures 命令来转储和比较与代码签名相关的 YAML 元数据,以便更容易地比较代码签名实现甚至多个签名操作之间的行为。

苹果系统运行着一些现有的最大和最赚钱的软件应用程序生态系统。理论上,要进入这些生态系统,传统上需要使用macOS,并加入苹果开发者计划(Apple Developer Program)。

如果你想为 Apple 操作系统开发应用程序,你可能会使用 Apple 的操作系统和 Apple 的官方工具进行开发和分发。但对于开源开发人员通常希望以最小的努力分发跨平台应用程序。在整个编程语言生态系统中,你运行的操作系统被抽象为许多应用程序的实现细节。通过创建 macOS、iOS 等开发需要直接访问 macOS 和通常高于市场价格的Apple 硬件的要求,苹果软件生态系统强加的分发要求是有效的排他性,并阻止利益相关方对进入其生态系统。

在苹果平台上发布软件的一个问题是代码签署和公证,即你需要:

1.在应用程序中嵌入加密签名,有效地证明来自 Apple Developer Program 关联帐户的真实性。 (这是签名。)

2.将你的应用程序上传到 Apple,以便他们对其进行检查,验证它符合要求,可能还会存储一个副本。然后,苹果会发布自己的加密签名,即公证书,然后需要将其嵌入到正在分发的应用程序上,这样苹果的操作系统才能信任它。(这是公证。)

从历史上看,这些步骤需要 Apple 专有软件专门从 macOS 运行。这意味着,即使你在 Rust、Go 等软件生态系统或 Web 平台中,你可以在不直接访问 macOS 的情况下交叉编译应用程序(测试显然是另一回事),如果你愿意,你仍然需要 macOS签署和公证你的申请。由于默认的安全设置,在macOS上需要有效的签名和公证。在 iOS 等移动平台上,除非你运行的是越狱设备,否则不可能发布未经签名和公证的应用程序。

如果我不需要macOS来构建我的应用程序,为什么我要被迫把苹果设备作为我的软件发布过程的一部分?为什么在发布的时候,我必须签署和公证我的申请,它不能更简化吗?

如果能重新实现 Apple 代码签名,以便开发人员有更多的灵活性和机会将应用程序分发到 Apple 的生态系统。其最终目标是扩大 Apple 生态系统对更多开发者的访问。

首先,得益于 rcodesign 0.14.0的发布。这是我第一次发布 rcodesign 的预构建二进制文件(Linux、Windows 和 macOS)。

macOS rcodesign 可执行文件是自签名的,它由 GitHub Actions Linux 运行程序使用 YubiKey 独有的代码签名证书进行签名。

2021年,apple-codesign 项目/Rust crate 发生了很大变化!只需查看更改日志

这个项目从tugger-apple-codesign改名而来。

如果你是通过 cargo install 安装的,你需要 cargo install --force apple-codesign 来强制 Cargo 用另一个 crate 中的一个来覆盖 rcodesign 可执行文件。

rcodesign CLI可执行文件仍然存在,而且比以往任何时候都更强大。你仍然可以在Linux、Windows、macOS和任何其他平台上对Apple应用程序进行签名,你可以在这些平台上编译Rust程序。

Sphinx 文档请点击这里,这与 PyOxidizer 的文档一起发布在 readthedocs.io 上(因为我使用的是 monorepo)。那里有一些通用文档,例如有关如何通过将你自己的替代代码签名 PKI 部署到并行 Apple 来选择性地绕过 Gatekeeper 的指南

支持签名包、DMG 和 .pkg 安装程序

当我去年宣布这个项目时,只有 Mach-O 二进制文件和非常简单的 .app 包是可签名的。即便如此,也有很多微妙的问题。

Rcodesign sign现在可以对更复杂的包进行签名,包括许多嵌套的包。有报道称iOS应用包签名正确。

该工具还支持签名.dmg磁盘映像文件和.pkg扁平封装包安装程序。

已知的签名限制现在记录在 Sphinx 文档中。

我相信 rcodesign 现在支持对用于 Apple 软件分发的所有主要文件格式进行签名。

支持 Linux、Windows 和 macOS 上的公证

苹果发布了一个名为Transporter的Java工具,可以让你上传文物到苹果进行公证。它们使这个工具可用于Linux、Windows,当然还有macOS。

虽然这个工具不是开源的,但使用这个工具可以让你在 Linux 和 Windows 上进行公证,同时仍然使用 Apple 的官方工具与他们的服务器通信。

rcodesign 现在支持调用 Transporter 并将工件上传到 Apple 进行公证。我们现在支持公证包、.dmg 磁盘映像和 .pkg 扁平封装安装程序包。我已经成功地从 Linux 公证了所有这些应用程序类型。

由于支持对所有应用程序类型进行签名和公证,现在可以在没有 macOS 参与发布过程的情况下发布 Apple 软件。

YubiKey 集成

我尝试尽可能多地使用我的 YubiKey,因为存储在 YubiKey 上的密钥或私钥可能比位于某个文件系统上的密钥或私钥更安全。如果你破解了我的设备,你很可能会获得我的私钥。但是你需要物理访问我的 YubiKey 并强迫或强迫我解锁它,以获得访问其私钥的权限。

rcodesign 现在支持使用 YubiKeys 进行签名操作。

这确实需要默认的智能卡 Cargo 功能。因此,如果手动构建,你将需要例如cargo install --features smartcard apple-codesign.。

YubiKey 集成来自 yubikey 。这个 crate 将直接与 macOS 和 Windows 中内置的智能卡 API 对话。所以如果你有一个启用了 YubiKey 支持的 rcodesign 构建,YubiKeys 应该可以工作。通过插入 YubiKey 并运行 rcodesign smartcard-scan 进行尝试。

YubiKey 集成文档可以点此查看

我甚至实现了一些命令来轻松管理 YubiKey 上的代码签名证书。例如,你可以直接在设备上运行 rcodesign smartcard-generate-key --smartcard-slot 9c 以生成新的私钥,然后  rcodesign generate-certificate-signing-request --smartcard-slot 9c --csr-pem-path csr.pem将该证书导出到证书签名请求 (CSR),你可以在 developer.apple.com 上交换 Applie 颁发的签名证书。这意味着你可以轻松创建其私钥直接在硬件设备上生成且永远无法导出的代码签名证书。以这种方式生成密钥比将密钥存储在软件库(比如苹果的Keychains)中更安全。

远程代码签名

我最感兴趣的功能是我称之为远程代码签名的功能。

我在GitHub托管的Linux GitHub Actions运行程序上签署了一个macOS通用Mach-O可执行文件,使用的YubiKey物理连接到我桌子旁边的Windows 11设备上。未在计算机之间复制签名的应用程序。

我有一个调用 rcodesign sign --remote-signer 的 GitHub Actions 工作流程。我手动触发了该工作流程,并开始使用浏览器观察近乎实时的作业输出。rcodesign sign --remote-signer 打印出一些指令(包括一堵 base64 编码数据的墙)以指示下一步该做什么。重要的是,它要求其他人运行 rcodesign remote-sign 以继续签名过程。

该日志向我们展示了使用 YubiKey 进行连接和身份验证,以及一些关于与远程服务器对话的状态更新。

远程签名使我能够从 GitHub 运营的 GitHub Actions 运行程序签署 macOS 应用程序,同时使用安全存储在我的 YubiKey 上的代码签名证书,该证书插入到距 GitHub Actions 运行程序数百公里的 Windows 设备上。

这里发生的是 2 个 rcodesign 进程通过中央中继服务器桥接的 websocket 相互通信。我免费操作一个默认服务器。服务器是开源的,如果你想运行你自己的服务器,你可以使用terrform模块,希望只需要花几分钟时间。当启动设备希望创建签名时,它向请求加密签名的签名者发送一条消息。然后将签名发送回发起者,发起者将其合并。

我设计这个特性时考虑到了CI系统的自动发布(比如GitHub Actions)。我想要一种方法,可以简化应用程序的代码签名和发布过程,而不必给CI中的低信任设备无限访问我的私人签名密钥的权限。这可能在许多其他场景中都是有用的。你是否曾经因为没有苹果发行的代码签名证书而通过电子邮件或下拉框将应用程序发送给别人签名?现在你有了一个不需要复制文件的替代解决方案。只要你可以看到启动设备的日志输出,或者将输出传递给你(例如通过聊天应用程序或电子邮件),你就可以在另一台设备上远程签署文件!

关于远程签名安全性

Websockets 通过由第三方操作的中央服务器?!授予远程设备访问权限以对任意内容执行代码签名?!你的恐惧和怀疑是 100% 有道理的:我也会这么想!

促进远程代码签名的服务会成为一个非常有利可图的攻击目标,如果被滥用,它可能被用来强制使用有效的代码签名证书的各方签署不想要的代码,如恶意软件。实现这样的功能有很多很多很多错误的方法。

远程代码签名设计和安全注意事项包含了我的一些高级设计目标和安全评估。远程代码签名协议详细介绍了通信协议,包括所涉及的加密(实际的加密,而不是流行的加密)。关键在于协议和服务器的设计使恶意服务器或中间人无法伪造签名请求。签名会话在几分钟后过期,第三方或服务器无法注入会导致不需要签名的恶意消息。通过初始握手获得会话临时共享加密密钥,并从那里使用对称加密密钥,因此对等方之间的所有有意义的消息都是端到端加密的。恶意服务器可以做的最糟糕的事情就是进行拒绝服务。

我相信我的远程签名实现比许多常见做法更安全,因为今天的常见做法需要复制私钥并让低信任度设备(如 CI 工作人员)访问私钥或者文件在没有加密监管链的情况下被复制以证明不会被篡改。是的,远程签名为远程访问引入了使用签名密钥的向量。但是按照我的意图进行实践,远程签名可以消除复制私钥或授予对它们的无限访问权限的需要。从威胁建模的角度来看,我认为密钥访问中的网络限制使得远程签名比现在许多人使用的私钥管理实践更安全。

话虽如此,这里的星号是我实现了我自己的密码系统来实现端到端消息安全。如果在设计或实现中存在漏洞,密码系统可能会崩溃,从而带来对消息伪造的防御。届时,恶意服务器或特权网络攻击者可能会强迫某人签署不需要的软件。但这很可能是损害的程度:对签名密钥的脱机攻击是不可能的,因为签名需要存在,而且私钥永远不会通过网络传输。即使没有端到端加密,该系统也比将你的私有密钥作为一个容易被窃取的CI秘密(或类似的)留在周围更安全。

Apple 钥匙串支持

0.14 版本开始,我们现在可以提前支持使用存储在 Apple 钥匙串中的代码签名证书进行签名!如果你在 Keychain Access 或 Xcode 中创建了 Apple 代码签名证书,那么这可能就是你的代码签名证书所在的位置。

我拖延了很长一段时间,因为我没有意识到这有什么好处:如果你使用macOS,只需使用 苹果的官方工具。但是随着rcodesign获得了对远程代码签名的支持,以及其他一些功能,这些功能可以让它成为所有平台上苹果工具的有力替代品,我认为我们应该提供这个功能,这样我们就不会再阻止人们从keychain导出私钥了。

Apple 的代码签名很复杂。 苹果的工具和rcodesign之间很容易出现细微差别。

rcodesign 现在有 print-signature-info 和 diff-signatures 命令来转储和比较与代码签名相关的 YAML 元数据,以便更容易地比较代码签名实现甚至多个签名操作之间的行为。

关于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作为减少攻击的方法。然而,这可能会导致有关功能的丧失。

关于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作为减少攻击的方法。然而,这可能会导致有关功能的丧失。

趋势科技的研究人员跟踪了CopperStealer幕后组织的最新部署,这次是通过基于Chromium的恶意浏览器扩展程序窃取加密货币和用户的钱包帐户信息。

趋势科技最近发布了关于CopperStealer通过滥用浏览器窃取程序、广告软件浏览器扩展程序或远程桌面等各种组件传播恶意软件的分析。跟踪网络犯罪集团的最新活动,研究人员发现了一个恶意浏览器扩展,当受害者登录到一个主要的加密货币交易网站时,该扩展能够创建和窃取受感染设备的API密钥。这些API密钥允许扩展程序执行交易并将加密货币从受害者的钱包发送到攻击者的钱包。

与以前的攻击类似,这个新组件通过fake crack (也称为warez)网站传播。该组件通常与浏览器窃取程序一起分布在一个释放器中,并与其他不相关的恶意软件捆绑在一起。这个捆绑包被压缩成一个受密码保护的档案,自7月以来一直在野外传播。

滴管/扩展安装程序

该组件在第一阶段使用之前文章中描述的相同加密器,然后是第二阶段,其中解密的DLL是UltimatePackerExecutables-(UPX)打包的。解密和解包后,我们注意到一个名为CRX的资源目录,其中包含一个7-Zip压缩文件。恶意Chrome浏览器扩展通常以这种方式打包。

1.png

名为CRX的扩展安装程序,包含一个7-Zip压缩文件

该压缩文件包含一个带有设置的JSON文件和另一个带有扩展安装程序本身代码的7-Zip压缩文件。

2.png

CRX的解压内容

扩展安装程序首先修改文件首选项和安全首选项在chrome浏览器的用户数据目录。这个名为Preferences的文件是JSON格式,包含个人用户设置。扩展安装程序关闭浏览器通知。

同时,名为SecurePreferences的文件也是JSON格式,包含已安装扩展的设置。对于新安装的扩展,crx.json文件的内容将插入到此安全首选项设置文件中。新安装的扩展也会添加到位于注册表中的扩展安装允许列表中。

然后将crx.7z压缩文件中的文件提取到位于

Chrome
Chromium
Edge
Brave
Opera
Cốc Cốc
CentBrowser
Iridium
Vivaldi
Epic
Coowon
Avast Secure Browser
Orbitum
Comodo Dragon

我们还注意到,该扩展程序被安装到受害者的浏览器中,具有两个不同的扩展程序ID,且在官方Chrome网上商店中都找不到:

Cbnmkphohlaaeiknkhpacmmnlljnaedp;
Jikoemlnjnpmecljncdgigogcnhlbfkc;

扩展分析

安装扩展程序后,我们还注意到chrome://extensions/中新安装了以下扩展程序。

3.png

安装的恶意扩展

扩展清单定义了两个Java脚本。后台脚本名为background.js,并且只在一个实例中运行在扩展本身内部。同时,内容脚本称为content.js,并在coinbase.com上下文中运行,如扩展清单中的代码片段所示。

4.png

在扩展清单中指定的内容脚本的设置

脚本混淆

这两个Javascript文件都被严重混淆。在第一个混淆步骤中,所有字符串被拆分为子字符串,存储在单个数组中,通过调用多个带有5个十六进制整数参数的十六进制命名函数来实现对数组的访问。

5.png

第一层混

看看第二个混淆步骤,所有字符串、逻辑操作符(+、-、*、/)、函数调用等都被插入到对象数组中。每个对象都有一个随机字符串作为名称,或者另一个字符串或函数作为值。在我们分析的示例中,_0x1f27e3['PFPYr']对应字符串" set ", _0x1f27e3['LYLfc'](0,1)对应逻辑表达式0!=1。

6.png

第二层混淆

这两个混淆步骤都可以通过使用自定义自动化脚本来反混淆。

后台脚本分析

通过分析脚本,本节分析了攻击者如何能够窃取合法加密货币钱包用户的账户信息。当扩展启动时,后台脚本进行两个查询。第一个是对http:///traffic/chrome的GET请求,可能是出于统计目的。第二个查询是对http://

blockchain.com
coinbase.com
binance.com
ftx.com
okex.com
huobi.com
kraken.com
poloniex.com
crypto.com
bithumb.com
bitfinex.com
kucoin.com
gate.io
tokocrypto.com
tabtrader.com
mexc.com
lbank.info
hotbit.io
bit2me.com
etoro.com
nicehash.com
probit.com

然后,该扩展为各种加密货币和令牌定义了一个攻击者的地址数组:

Tether (USDT, specifically in Ethereum ERC20 and TRON TRC20)
Ethereum (ETH)
Bitcoin (BTC)
Litecoin (LTC)
Binance coin (BNB)
Ripple (XRP)
Solana (SOL)
Bitcoin Cash (BCH)
Zcash (ZEC)
Stellar Lumens (XLM)
Dogecoin (DOGE)
Tezos (XTZ)
Algorand (ALGO)
Dash (DASH)
Cosmos (ATOM)

对于ETH地址,脚本硬编码了大约170个额外的基于ERC20的代币。之后,扩展启动onMessage侦听器以侦听来自扩展进程或内容脚本发送的消息。该消息采用JSON格式,其中一个name-value pair 称为method。后台脚本侦听以下方法:

· Method “homeStart”

这个方法试图从Chrome的本地存储获取API密钥(apiKey)和API秘密(apiSecret),如果这些密钥和秘密对是之前获得并保存的。以下步骤需要这些参数:

1.使用API通过请求/api/v2/accounts获取有关钱包、地址和余额的信息。此请求的结果也被泄露到http://

2.如果请求成功,API会向内容脚本发送“okApi”消息并开始解析钱包信息。如果钱包余额不为零,它会尝试将85%的可用资金发送到攻击者控制的钱包。

7.png

寻找余额不为零的钱包

8.png

窃取85%的可用资金

交易请求的结果也会被泄露到http://

1.如果不成功,API会向内容脚本发送“errorApi”消息。“errorApi”消息包含来自https://www.coinbase.com/settings/api的CSRF令牌作为一个参数,以及对新API密钥创建请求的响应。

2.Method “createApi”。

此消息是从内容脚本接收的,并包含一个双因素身份验证(2FA)代码作为参数之一。此代码用于打开新的模式窗口以创建API密钥。通常,当你在CoinbaseAPI设置中点击“+NewAPIKey”时,会请求一个2FA代码,如果代码正确,就会出现模式窗口。

在创建新API的第二步中,需要选择钱包及其权限。恶意扩展请求所有帐户的所有可用权限。

9.png

选择所有帐户和权限

之后,需要再插入一个身份验证代码,然后就会显示一个带有新生成的API密钥的表单。如果成功,后台脚本然后继续从“API Key details”表单提取两个API密钥(API Key和API Secret),将它们保存到Chromium的本地存储以供以后使用,并将它们提取到http:///traffic/step。如果API身份验证不成功,将向内容脚本发送一条“retryApi”消息。

内容脚本分析

我们进一步研究了内容脚本,以分析负责从受害者那里窃取2FA密码的进程。内容脚本包含以下语言的消息列表:

· 英语(en)

· 德语(de)

· 西班牙语(es)

· 法语(fr)

· 日语(jp)

· 印度尼西亚(身份证)

· 意大利语(它)

· 波兰语(pl)

· 葡萄牙语(pt)

· 俄语(ru)

· 泰语(日)

· 土耳其语(tr)

每条消息都包含电话和身份验证器的标题、描述和错误消息。

对于“phone”,显示的英文信息显示为:

· “title”:“请输入手机验证码。”

· “description”:“输入手机短信提供的两步验证码。”

· “message”:“该代码无效。请再试一次。”

对于“authenticator”,显示的英文消息如下所示:

· “title”:“请输入验证器的验证码。”

· “description”:“输入你的身份验证应用程序提供的两步验证码。”

· “message”:“该代码无效。请再试一次。”

内容脚本最初向/api/v3/brokerage/user_configuration发出请求,以查看用户是否已登录。然后脚本向后台脚本发送一个“homeStart”消息,并开始使用onMessage侦听类似于后台脚本进程的“method”属性。如果它接收到一个方法属性等于“okApi”的消息,它会隐藏代码加载器并移除模式窗口。如果它接收到一个方法属性等于“errorApi”的消息,它就会创建一个模式窗口。

10.png

显示要求输入身份验证代码的模式窗口

模式窗口有输入框并侦听oninput事件。如果每个输入框都包含一个数字,则将它们连接成一个“tfa”(2FA)变量,并作为“createApi”消息的参数发送到后台脚本。代码加载器也会显示出来。

模式窗口有六个输入框,需要输入六位数,这是在使用验证器时提供的。如果受害者通过短信使用身份验证,那么身份验证代码有7位数字,模式窗口将多一个输入框。此逻辑在模式窗口代码中实现。收到的方法属性等于“retryApi”的消息会删除所有插入的数字,并以红色显示错误消息。

11.png

输入验证码后,出现错误信息

总结

CopperStealer的幕后攻击者会经常发起攻击,研究人员将继续监控他们的部署,因为攻击者找到了更多针对不知情的受害者的方法。在分析此进程时,研究人员发现此扩展程序与之前报告的恶意软件组件之间存在多个相似之处,其中之一是恶意扩展程序和CopperStealer是从之前记录的同一个dropper和相同的传输载体传播的。

另一个惊人的相似之处是恶意扩展的命令和控制(C&C)域具有与域生成算法(DGA)域相同的格式,这些域被追溯为属于先前版本的CopperStealer。格式是由16个十六进制字符组成的字符串。此外,他们的两个C&C服务器都是使用PHP框架“CodeIgniter”构建的。这些属性向我们暗示,恶意软件和扩展程序背后的开发人员或运营商可能存在关联。

建议用户和组织从官方平台下载他们的软件、应用程序和更新,以缓解CopperStealer等恶意软件带来的风险和威胁。

趋势科技的研究人员跟踪了CopperStealer幕后组织的最新部署,这次是通过基于Chromium的恶意浏览器扩展程序窃取加密货币和用户的钱包帐户信息。

趋势科技最近发布了关于CopperStealer通过滥用浏览器窃取程序、广告软件浏览器扩展程序或远程桌面等各种组件传播恶意软件的分析。跟踪网络犯罪集团的最新活动,研究人员发现了一个恶意浏览器扩展,当受害者登录到一个主要的加密货币交易网站时,该扩展能够创建和窃取受感染设备的API密钥。这些API密钥允许扩展程序执行交易并将加密货币从受害者的钱包发送到攻击者的钱包。

与以前的攻击类似,这个新组件通过fake crack (也称为warez)网站传播。该组件通常与浏览器窃取程序一起分布在一个释放器中,并与其他不相关的恶意软件捆绑在一起。这个捆绑包被压缩成一个受密码保护的档案,自7月以来一直在野外传播。

滴管/扩展安装程序

该组件在第一阶段使用之前文章中描述的相同加密器,然后是第二阶段,其中解密的DLL是UltimatePackerExecutables-(UPX)打包的。解密和解包后,我们注意到一个名为CRX的资源目录,其中包含一个7-Zip压缩文件。恶意Chrome浏览器扩展通常以这种方式打包。

1.png

名为CRX的扩展安装程序,包含一个7-Zip压缩文件

该压缩文件包含一个带有设置的JSON文件和另一个带有扩展安装程序本身代码的7-Zip压缩文件。

2.png

CRX的解压内容

扩展安装程序首先修改文件首选项和安全首选项在chrome浏览器的用户数据目录。这个名为Preferences的文件是JSON格式,包含个人用户设置。扩展安装程序关闭浏览器通知。

同时,名为SecurePreferences的文件也是JSON格式,包含已安装扩展的设置。对于新安装的扩展,crx.json文件的内容将插入到此安全首选项设置文件中。新安装的扩展也会添加到位于注册表中的扩展安装允许列表中。

然后将crx.7z压缩文件中的文件提取到位于

Chrome
Chromium
Edge
Brave
Opera
Cốc Cốc
CentBrowser
Iridium
Vivaldi
Epic
Coowon
Avast Secure Browser
Orbitum
Comodo Dragon

我们还注意到,该扩展程序被安装到受害者的浏览器中,具有两个不同的扩展程序ID,且在官方Chrome网上商店中都找不到:

Cbnmkphohlaaeiknkhpacmmnlljnaedp;
Jikoemlnjnpmecljncdgigogcnhlbfkc;

扩展分析

安装扩展程序后,我们还注意到chrome://extensions/中新安装了以下扩展程序。

3.png

安装的恶意扩展

扩展清单定义了两个Java脚本。后台脚本名为background.js,并且只在一个实例中运行在扩展本身内部。同时,内容脚本称为content.js,并在coinbase.com上下文中运行,如扩展清单中的代码片段所示。

4.png

在扩展清单中指定的内容脚本的设置

脚本混淆

这两个Javascript文件都被严重混淆。在第一个混淆步骤中,所有字符串被拆分为子字符串,存储在单个数组中,通过调用多个带有5个十六进制整数参数的十六进制命名函数来实现对数组的访问。

5.png

第一层混

看看第二个混淆步骤,所有字符串、逻辑操作符(+、-、*、/)、函数调用等都被插入到对象数组中。每个对象都有一个随机字符串作为名称,或者另一个字符串或函数作为值。在我们分析的示例中,_0x1f27e3['PFPYr']对应字符串" set ", _0x1f27e3['LYLfc'](0,1)对应逻辑表达式0!=1。

6.png

第二层混淆

这两个混淆步骤都可以通过使用自定义自动化脚本来反混淆。

后台脚本分析

通过分析脚本,本节分析了攻击者如何能够窃取合法加密货币钱包用户的账户信息。当扩展启动时,后台脚本进行两个查询。第一个是对http:///traffic/chrome的GET请求,可能是出于统计目的。第二个查询是对http://

blockchain.com
coinbase.com
binance.com
ftx.com
okex.com
huobi.com
kraken.com
poloniex.com
crypto.com
bithumb.com
bitfinex.com
kucoin.com
gate.io
tokocrypto.com
tabtrader.com
mexc.com
lbank.info
hotbit.io
bit2me.com
etoro.com
nicehash.com
probit.com

然后,该扩展为各种加密货币和令牌定义了一个攻击者的地址数组:

Tether (USDT, specifically in Ethereum ERC20 and TRON TRC20)
Ethereum (ETH)
Bitcoin (BTC)
Litecoin (LTC)
Binance coin (BNB)
Ripple (XRP)
Solana (SOL)
Bitcoin Cash (BCH)
Zcash (ZEC)
Stellar Lumens (XLM)
Dogecoin (DOGE)
Tezos (XTZ)
Algorand (ALGO)
Dash (DASH)
Cosmos (ATOM)

对于ETH地址,脚本硬编码了大约170个额外的基于ERC20的代币。之后,扩展启动onMessage侦听器以侦听来自扩展进程或内容脚本发送的消息。该消息采用JSON格式,其中一个name-value pair 称为method。后台脚本侦听以下方法:

· Method “homeStart”

这个方法试图从Chrome的本地存储获取API密钥(apiKey)和API秘密(apiSecret),如果这些密钥和秘密对是之前获得并保存的。以下步骤需要这些参数:

1.使用API通过请求/api/v2/accounts获取有关钱包、地址和余额的信息。此请求的结果也被泄露到http://

2.如果请求成功,API会向内容脚本发送“okApi”消息并开始解析钱包信息。如果钱包余额不为零,它会尝试将85%的可用资金发送到攻击者控制的钱包。

7.png

寻找余额不为零的钱包

8.png

窃取85%的可用资金

交易请求的结果也会被泄露到http://

1.如果不成功,API会向内容脚本发送“errorApi”消息。“errorApi”消息包含来自https://www.coinbase.com/settings/api的CSRF令牌作为一个参数,以及对新API密钥创建请求的响应。

2.Method “createApi”。

此消息是从内容脚本接收的,并包含一个双因素身份验证(2FA)代码作为参数之一。此代码用于打开新的模式窗口以创建API密钥。通常,当你在CoinbaseAPI设置中点击“+NewAPIKey”时,会请求一个2FA代码,如果代码正确,就会出现模式窗口。

在创建新API的第二步中,需要选择钱包及其权限。恶意扩展请求所有帐户的所有可用权限。

9.png

选择所有帐户和权限

之后,需要再插入一个身份验证代码,然后就会显示一个带有新生成的API密钥的表单。如果成功,后台脚本然后继续从“API Key details”表单提取两个API密钥(API Key和API Secret),将它们保存到Chromium的本地存储以供以后使用,并将它们提取到http:///traffic/step。如果API身份验证不成功,将向内容脚本发送一条“retryApi”消息。

内容脚本分析

我们进一步研究了内容脚本,以分析负责从受害者那里窃取2FA密码的进程。内容脚本包含以下语言的消息列表:

· 英语(en)

· 德语(de)

· 西班牙语(es)

· 法语(fr)

· 日语(jp)

· 印度尼西亚(身份证)

· 意大利语(它)

· 波兰语(pl)

· 葡萄牙语(pt)

· 俄语(ru)

· 泰语(日)

· 土耳其语(tr)

每条消息都包含电话和身份验证器的标题、描述和错误消息。

对于“phone”,显示的英文信息显示为:

· “title”:“请输入手机验证码。”

· “description”:“输入手机短信提供的两步验证码。”

· “message”:“该代码无效。请再试一次。”

对于“authenticator”,显示的英文消息如下所示:

· “title”:“请输入验证器的验证码。”

· “description”:“输入你的身份验证应用程序提供的两步验证码。”

· “message”:“该代码无效。请再试一次。”

内容脚本最初向/api/v3/brokerage/user_configuration发出请求,以查看用户是否已登录。然后脚本向后台脚本发送一个“homeStart”消息,并开始使用onMessage侦听类似于后台脚本进程的“method”属性。如果它接收到一个方法属性等于“okApi”的消息,它会隐藏代码加载器并移除模式窗口。如果它接收到一个方法属性等于“errorApi”的消息,它就会创建一个模式窗口。

10.png

显示要求输入身份验证代码的模式窗口

模式窗口有输入框并侦听oninput事件。如果每个输入框都包含一个数字,则将它们连接成一个“tfa”(2FA)变量,并作为“createApi”消息的参数发送到后台脚本。代码加载器也会显示出来。

模式窗口有六个输入框,需要输入六位数,这是在使用验证器时提供的。如果受害者通过短信使用身份验证,那么身份验证代码有7位数字,模式窗口将多一个输入框。此逻辑在模式窗口代码中实现。收到的方法属性等于“retryApi”的消息会删除所有插入的数字,并以红色显示错误消息。

11.png

输入验证码后,出现错误信息

总结

CopperStealer的幕后攻击者会经常发起攻击,研究人员将继续监控他们的部署,因为攻击者找到了更多针对不知情的受害者的方法。在分析此进程时,研究人员发现此扩展程序与之前报告的恶意软件组件之间存在多个相似之处,其中之一是恶意扩展程序和CopperStealer是从之前记录的同一个dropper和相同的传输载体传播的。

另一个惊人的相似之处是恶意扩展的命令和控制(C&C)域具有与域生成算法(DGA)域相同的格式,这些域被追溯为属于先前版本的CopperStealer。格式是由16个十六进制字符组成的字符串。此外,他们的两个C&C服务器都是使用PHP框架“CodeIgniter”构建的。这些属性向我们暗示,恶意软件和扩展程序背后的开发人员或运营商可能存在关联。

建议用户和组织从官方平台下载他们的软件、应用程序和更新,以缓解CopperStealer等恶意软件带来的风险和威胁。

FortiGuard Labs每两周收集一次关于勒索软件变体的数据,追踪分析发现Snatch,BianLian 和 Agenda都出现了最新的变体。这三个恶意软件都是用Go编程语言(Golang)编写的。

· 受影响的平台:Microsoft Windows

· 受影响方:Microsoft Windows 用户

· 影响:加密受感染设备上的文件并要求赎金才能解密文件

· 严重性级别:高

Snatch

Snatch勒索软件至少从2018年底就开始活跃了。2021年11月30日,Snatch勒索组织在其数据站点添加了一条条目,内容涉及入侵沃尔沃汽车公司的服务器并窃取文件,同时还附上了被盗文件的屏幕截图作为证据。

Snatch勒索软件是最早用Go编程语言的组织,当时用Go编写的勒索软件非常罕见。巧合的是,本文中涉及的所有其他勒索软件变种都是用Go编写的。

Snatch 勒索软件是一种文件加密器,以使用著名的文件扩展名“.snake”而闻名,它会附加到加密文件中。但是,已观察到其他文件扩展名。其勒索信的文件名也因变体而异。

已报告的 Snatch 勒索软件感染媒介是 RDP(远程桌面协议)凭证暴力破解。从 Windows 11 内部版本 22528.1000 开始,Microsoft 默认启用了帐户锁定策略,该策略会在登录尝试失败时锁定用户帐户。这不仅使 RDP 暴力破解变得更加困难,而且还使任何其他密码猜测攻击变得更加困难。

最新的 Snatch 勒索软件变种会加密受害者设备上的文件,并将“.gaqtfpr”扩展名附加到受影响的文件中。它还会删除一个文本文件“HOW TO RESTORE YOUR FILES.TXT”。该勒索信包含两个联系电子邮件地址以及受害者在向攻击者发送电子邮件时必须遵循的特定说明。

1.png

Snatch勒索软件最新变体发出的勒索信

2.png

被最新 Snatch 勒索软件变种加密的文件

BianLian

用Go编程语言编写的BianLian于2022年7月中旬首次被发现,它的运营商本月增加了他们的命令和控制(C2)基础设施,最近开始将受害者添加到其 Tor 上的数据泄露网站上。截至撰写本文时,至少有20家公司成为了其受害者。不过,攻击者很有可能隐瞒了支付赎金的受害者的数量,BianLian勒索软件的实际受害者可能会更多。

3.png

BianLian 勒索软件公开的受害者列表

每个 BianLian 受害者都被标记为他们的国家和他们所属的行业。根据可用的标签,它的勒索软件受害者至少在美国、英国和澳大利亚。目标行业包括医疗保健、教育、律师事务所、建筑、媒体、制药、营销、度假村和金融。

4.png

BianLian勒索软件攻击者对受害者的分类标签

每个受害者都有一个专门的页面。其中包括受害企业的描述、首席执行官或公司总裁的姓名、他们的个人收入、这些公司的收入、资产和收入,以及泄露的文件中包含哪些信息。

5.png

BianLian 勒索软件数据泄露网站上发布的受害者信息

有趣的是,Colin Grady 最近观察到,由一些勒索软件攻击者操作的泄漏网站在 2022 年 8 月 26 日关闭了。不过,其中一些仍存在断断续续的使用,其中就包括BianLian和Snatch勒索软件。

攻击者还警告受害者,他们必须在十天内支付赎金。否则,窃取的信息将被发布在该勒索软件组织的Tor网站上。为了给受害者施加额外压力,攻击者声称将向受害者的客户和业务伙伴发送指向被盗信息的链接,以损害受害者的声誉。受害者被指示使用Tox或通过电子邮件联系攻击者。由于赎金金额和支付方式没有写在勒索信上,因此受害者将与攻击者进行协商。

6.png

BianLian勒索软件的勒索信

7.png

数据泄露网站上列出的联系方式

8.png

BianLian 勒索软件加密的文件

由 BianLian 勒索软件加密的文件具有“.bianlian”文件扩展名。

Agenda

Agenda是另一个基于Go的勒索软件,于2022年6月中旬出现,根据VirusTotal报告的相关样本,该勒索软件可能已攻击了南非、罗马尼亚、立陶宛、印度、泰国、美国、加拿大和印度尼西亚。

据报道,Agenda勒索软件的感染载体是通过使用窃取的凭证登录到面向公众的服务器。然后,攻击者通过受害者的网络传播,攻击其他计算机。一旦攻击者获得网络上临界数量的设备的访问权,Agenda勒索软件就会被部署到受攻击的设备上。

为了规避反病毒解决方案的检测,勒索软件以安全模式加密文件。这种技术已在其他臭名昭著的勒索软件家族中观察到,例如 REvil、BlackMatter 和 AvosLocker。附加到加密文件的文件扩展名因变体而异。例如,如果勒索软件变种使用“.fortinet”作为文件扩展名,“blog.docx”将更改为“blog.fortinet”。它的勒索通知的名称以它添加到受影响文件的文件扩展名开始,然后是“-RECOVER-README.txt”。

9.png

Agenda勒索软件留下的勒索信

反病毒签名

通过FortiGuard的Web过滤、防病毒、FortiMail、forclient和FortiEDR服务,Fortinet客户已经可以免受这些恶意软件变体的攻击,如下所示:

Snatch

FortiGuard Labs 检测到本文中描述的最新的Snatch勒索软件变体,具有以下反病毒签名:

W64 / Filecoder.D083 ! tr.ransom

以下反病毒特征可以检测到已知的“Snatch”勒索软件变体样本:

· W64/Snatch.A!tr.ransom
· W32/Snatch.B!tr
· W32/Snatch.7991!tr.ransom
· W64/Snatch.BD11!tr.ransom
· W32/Snatch.C09B!tr.ransom
· W64/Ransom.A!tr
· W32/Filecoder.A!tr.ransom
· W32/Filecoder.NYH!tr
· W32/Filecoder.NYH!tr.ransom
· W32/Filecoder.NVR!tr.ransom
· W32/Filecoder.74A0!tr.ransom
· W64/Filecoder.D083!tr.ransom
· W64/Filecoder.AA!tr.ransom
· W32/Crypmod.ADEJ!tr.ransom 
· W32/DelShad.AM!tr.ransom
· W32/Trojan_Ransom.AB!tr
· W32/PossibleThreat

BianLian

FortiGuard实验室检测已知的BianLian勒索软件样本,其特征如下:

W32 / Filecoder.BT ! tr.ransom

Agenda

FortiGuard实验室通过以下反病毒签名检测到已知的Agenda勒索软件变体:

W32/Agent.AK!tr.ransom
W32/PossibleThreat

缓解措施

1.由于易于中断、对日常运营的破坏、对组织声誉的潜在影响,以及不必要的破坏或发布个人身份信息(PII)等,保持所有AV和IPS签名的最新是至关重要的;

2.由于大多数勒索软件是通过网络钓鱼发送的,组织应该考虑利用旨在培训用户了解和检测网络钓鱼威胁的Fortinet解决方案;

3.FortiPhish网络钓鱼模拟服务使用真实世界的模拟来帮助组织测试用户对网络钓鱼威胁的意识和警惕,并在用户遇到有针对性的网络钓鱼攻击时培训和加强适当的做法。

4.不支付赎金。像CISA、NCSC、FBI和HHS这样的组织警告勒索软件受害者不要支付赎金,部分原因是支付并不能保证文件会被恢复。根据美国财政部外国资产控制办公室(OFAC)的一项建议,赎金支付还可能鼓励对手将目标锁定在其他组织,鼓励其他攻击者传播勒索软件。

FortiGuard Labs每两周收集一次关于勒索软件变体的数据,追踪分析发现Snatch,BianLian 和 Agenda都出现了最新的变体。这三个恶意软件都是用Go编程语言(Golang)编写的。

· 受影响的平台:Microsoft Windows

· 受影响方:Microsoft Windows 用户

· 影响:加密受感染设备上的文件并要求赎金才能解密文件

· 严重性级别:高

Snatch

Snatch勒索软件至少从2018年底就开始活跃了。2021年11月30日,Snatch勒索组织在其数据站点添加了一条条目,内容涉及入侵沃尔沃汽车公司的服务器并窃取文件,同时还附上了被盗文件的屏幕截图作为证据。

Snatch勒索软件是最早用Go编程语言的组织,当时用Go编写的勒索软件非常罕见。巧合的是,本文中涉及的所有其他勒索软件变种都是用Go编写的。

Snatch 勒索软件是一种文件加密器,以使用著名的文件扩展名“.snake”而闻名,它会附加到加密文件中。但是,已观察到其他文件扩展名。其勒索信的文件名也因变体而异。

已报告的 Snatch 勒索软件感染媒介是 RDP(远程桌面协议)凭证暴力破解。从 Windows 11 内部版本 22528.1000 开始,Microsoft 默认启用了帐户锁定策略,该策略会在登录尝试失败时锁定用户帐户。这不仅使 RDP 暴力破解变得更加困难,而且还使任何其他密码猜测攻击变得更加困难。

最新的 Snatch 勒索软件变种会加密受害者设备上的文件,并将“.gaqtfpr”扩展名附加到受影响的文件中。它还会删除一个文本文件“HOW TO RESTORE YOUR FILES.TXT”。该勒索信包含两个联系电子邮件地址以及受害者在向攻击者发送电子邮件时必须遵循的特定说明。

1.png

Snatch勒索软件最新变体发出的勒索信

2.png

被最新 Snatch 勒索软件变种加密的文件

BianLian

用Go编程语言编写的BianLian于2022年7月中旬首次被发现,它的运营商本月增加了他们的命令和控制(C2)基础设施,最近开始将受害者添加到其 Tor 上的数据泄露网站上。截至撰写本文时,至少有20家公司成为了其受害者。不过,攻击者很有可能隐瞒了支付赎金的受害者的数量,BianLian勒索软件的实际受害者可能会更多。

3.png

BianLian 勒索软件公开的受害者列表

每个 BianLian 受害者都被标记为他们的国家和他们所属的行业。根据可用的标签,它的勒索软件受害者至少在美国、英国和澳大利亚。目标行业包括医疗保健、教育、律师事务所、建筑、媒体、制药、营销、度假村和金融。

4.png

BianLian勒索软件攻击者对受害者的分类标签

每个受害者都有一个专门的页面。其中包括受害企业的描述、首席执行官或公司总裁的姓名、他们的个人收入、这些公司的收入、资产和收入,以及泄露的文件中包含哪些信息。

5.png

BianLian 勒索软件数据泄露网站上发布的受害者信息

有趣的是,Colin Grady 最近观察到,由一些勒索软件攻击者操作的泄漏网站在 2022 年 8 月 26 日关闭了。不过,其中一些仍存在断断续续的使用,其中就包括BianLian和Snatch勒索软件。

攻击者还警告受害者,他们必须在十天内支付赎金。否则,窃取的信息将被发布在该勒索软件组织的Tor网站上。为了给受害者施加额外压力,攻击者声称将向受害者的客户和业务伙伴发送指向被盗信息的链接,以损害受害者的声誉。受害者被指示使用Tox或通过电子邮件联系攻击者。由于赎金金额和支付方式没有写在勒索信上,因此受害者将与攻击者进行协商。

6.png

BianLian勒索软件的勒索信

7.png

数据泄露网站上列出的联系方式

8.png

BianLian 勒索软件加密的文件

由 BianLian 勒索软件加密的文件具有“.bianlian”文件扩展名。

Agenda

Agenda是另一个基于Go的勒索软件,于2022年6月中旬出现,根据VirusTotal报告的相关样本,该勒索软件可能已攻击了南非、罗马尼亚、立陶宛、印度、泰国、美国、加拿大和印度尼西亚。

据报道,Agenda勒索软件的感染载体是通过使用窃取的凭证登录到面向公众的服务器。然后,攻击者通过受害者的网络传播,攻击其他计算机。一旦攻击者获得网络上临界数量的设备的访问权,Agenda勒索软件就会被部署到受攻击的设备上。

为了规避反病毒解决方案的检测,勒索软件以安全模式加密文件。这种技术已在其他臭名昭著的勒索软件家族中观察到,例如 REvil、BlackMatter 和 AvosLocker。附加到加密文件的文件扩展名因变体而异。例如,如果勒索软件变种使用“.fortinet”作为文件扩展名,“blog.docx”将更改为“blog.fortinet”。它的勒索通知的名称以它添加到受影响文件的文件扩展名开始,然后是“-RECOVER-README.txt”。

9.png

Agenda勒索软件留下的勒索信

反病毒签名

通过FortiGuard的Web过滤、防病毒、FortiMail、forclient和FortiEDR服务,Fortinet客户已经可以免受这些恶意软件变体的攻击,如下所示:

Snatch

FortiGuard Labs 检测到本文中描述的最新的Snatch勒索软件变体,具有以下反病毒签名:

W64 / Filecoder.D083 ! tr.ransom

以下反病毒特征可以检测到已知的“Snatch”勒索软件变体样本:

· W64/Snatch.A!tr.ransom
· W32/Snatch.B!tr
· W32/Snatch.7991!tr.ransom
· W64/Snatch.BD11!tr.ransom
· W32/Snatch.C09B!tr.ransom
· W64/Ransom.A!tr
· W32/Filecoder.A!tr.ransom
· W32/Filecoder.NYH!tr
· W32/Filecoder.NYH!tr.ransom
· W32/Filecoder.NVR!tr.ransom
· W32/Filecoder.74A0!tr.ransom
· W64/Filecoder.D083!tr.ransom
· W64/Filecoder.AA!tr.ransom
· W32/Crypmod.ADEJ!tr.ransom 
· W32/DelShad.AM!tr.ransom
· W32/Trojan_Ransom.AB!tr
· W32/PossibleThreat

BianLian

FortiGuard实验室检测已知的BianLian勒索软件样本,其特征如下:

W32 / Filecoder.BT ! tr.ransom

Agenda

FortiGuard实验室通过以下反病毒签名检测到已知的Agenda勒索软件变体:

W32/Agent.AK!tr.ransom
W32/PossibleThreat

缓解措施

1.由于易于中断、对日常运营的破坏、对组织声誉的潜在影响,以及不必要的破坏或发布个人身份信息(PII)等,保持所有AV和IPS签名的最新是至关重要的;

2.由于大多数勒索软件是通过网络钓鱼发送的,组织应该考虑利用旨在培训用户了解和检测网络钓鱼威胁的Fortinet解决方案;

3.FortiPhish网络钓鱼模拟服务使用真实世界的模拟来帮助组织测试用户对网络钓鱼威胁的意识和警惕,并在用户遇到有针对性的网络钓鱼攻击时培训和加强适当的做法。

4.不支付赎金。像CISA、NCSC、FBI和HHS这样的组织警告勒索软件受害者不要支付赎金,部分原因是支付并不能保证文件会被恢复。根据美国财政部外国资产控制办公室(OFAC)的一项建议,赎金支付还可能鼓励对手将目标锁定在其他组织,鼓励其他攻击者传播勒索软件。