C-Ark 凭证解码器

针对 CVE-2021-31796 的漏洞利用工具
用于解码 C-Ark 凭证文件的工具

作者：Aaron Mizrachi - https://twitter.com/unmanarc/
Enrique Vaamonde - https://twitter.com/_ejvm
首次发布：2019年9月2日
公开披露：2021年10月11日

参考资料

负责任披露：

此漏洞自2019年9月起一直在等待发布。

以下是时间线：

2019-08-1x 在一次演习中，我们的团队发现并向本地供应商代表报告了某些凭证存储方法中存在的潜在加密弱点。
2019-08-30 在此之前，我们只有一个使用他们自己工具的 "ollydbg" 内存中的概念验证。我们试图说明这在某些特定情况下如何成为攻击向量，但未能成功。因此，我们决定开始编写这个概念验证程序，以获得更明显的论据。
2019-09-02 我们成功地在自己的概念验证中实现了哈希和加密算法（完全独立于产品）。
2019-09-03 我们向供应商宣布了我们的发现，并表达了公开此信息的意愿。
2019-09-20 我们收到供应商的请求，要求推迟公开发布，直到问题修复。
2020-05 我们再次联系他们，请求允许发布该工具，并交换了几封邮件，他们表示尚未准备就绪。
2021-09/2021-10 我们发现其他不相关的研究人员最近也公开发现并披露了同样的漏洞，鉴于此……我们终于（经过两年！）获得了供应商的许可，与您分享我们的发现以及利用 CreateCredFile 加密弱点的概念验证工具。

潜在用途：

在渗透测试中，如果有人足够聪明能够接触到 PSM 并偶然获得 CredFile 的访问权限，那么就有可能利用该文件建立与 Vault 的连接，从而控制整个系统……

作为对策，大多数凭证文件会设置一些“限制”，以防止密码在不同环境/计算机（例如，黑客自己的 PSM）中使用。

然而，这些限制可以被修改，如果你逆向并获取原始密钥部分。这个解密后的密钥部分可用于重新创建具有不同“安全”参数（例如，另一台主机、另一个应用程序、另一个操作系统用户）的文件。

操作模式

为了生成 AES-256（32 字节）原始解密密钥，我们从凭证字段 "AdditionalInformation" 中取一对 SHA1SUM，每个哈希附加 "0x00000000" 和 "0x00000001"；第一个哈希提供密钥的前 20 字节，第二个哈希仅提供后 12 字节。

如果存在任何环境限制（如 IP/主机/执行路径/...），我们会在计算两个 SHA1SUM 之前，将每个明文值前置到 AdditionalInformation。

重要的是要提到，"ClientApp" 字段是通过 BASE64(SHA1SUM(strlower(ClientApp))) 进行转换的，然后才前置到 "AdditionalInformation" 并生成两个 SHA1SUM。

解密是使用 AES-256-CBC OpenSSL 函数进行的，使用 Password 或 NewPassword 字段。(https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption)

我们使用 (verificationflags-16) 来确定启用了哪些验证/限制：

usingClientApp      = ((uVerificationsFlag&0x1) != 0);
usingAppPath        = ((uVerificationsFlag&0x2) != 0);
usingClientIP       = ((uVerificationsFlag&0x4) != 0);
usingOSUser         = ((uVerificationsFlag&0x8) != 0);
usingClientHostname = ((uVerificationsFlag&0x20) != 0);

并且如果某些限制未在输出的凭证文件中显示，你始终可以手动引入它们。我想我们都同意，“应用路径”和“客户端 IP”都不是真正随机的值。

缓解措施：

使用 HSM \o/，不要将解密密钥存储在 cred 文件中。

构建方法：

qmake . 
make -j8

CACredDecoder

最受欢迎