Yeti JWT漏洞CVE-2024-46508允许攻击者伪造认证令牌

Yeti JWT漏洞 CVE-2024-46508 允许攻击者伪造认证令牌

执行摘要

Yeti威胁情报平台（版本2.1.12之前）中硬编码的默认JWT签名密钥允许任何知道默认密钥的攻击者伪造有效的认证令牌，从而获得对平台Web界面和API的无限制访问权限。这个漏洞被追踪为CVE-2024-46508，CVSS得分为7.5（高），源于应用程序在安装时未能强制执行唯一的YETI_AUTH_SECRET_KEY环境变量。这一披露来自Rhino Security Labs，在对开源平台进行安全评估时发现了这个问题。

技术分析

Yeti是一个开源的威胁情报平台，安全团队使用它来聚合、存储和分析来自多个来源的入侵指标（IOCs）。漏洞存在于JWT认证机制中：如果管理员没有明确将YETI_AUTH_SECRET_KEY环境变量设置为非默认值，Yeti将回退到源代码中嵌入的硬编码密钥。知道这个默认密钥的未经身份验证的远程攻击者可以创建任意JWT令牌，包括具有任何用户身份的令牌，包括管理员账户。

Yeti使用的JWT库使用HMAC-SHA256对称签名令牌。没有唯一的密钥，签名密钥实际上就是公开知识——任何检查Yeti源代码或文档的人都可以得到它。一旦生成伪造的令牌，攻击者就可以将其呈现给Yeti Web服务器或API端点，后者会将其接受为合法的。这绕过了所有认证检查，授予攻击者对平台数据的完全读写访问权限，包括存储的威胁情报源、用户账户和配置设置。

Rhino Security Labs指出，由于许多Yeti部署在Docker容器或自动化CI/CD管道中运行，其中环境变量可能没有明确配置，这个问题加剧了。默认密钥在Yeti安装指南中被明确记录为占位符，但操作员可能会忽略更改它的步骤。研究人员使用简单的Python脚本，在不到30秒的时间内演示了对默认Yeti安装的令牌伪造。

缓解措施与建议

运行版本2.1.12之前的Yeti管理员应立即升级到2.1.12或更高版本，该版本移除了硬编码的默认值，并要求设置一个唯一的密钥。对于无法立即升级的部署，操作员必须确保YETI_AUTH_SECRET_KEY环境变量被设置为一个密码学上随机、高熵的字符串（至少32字节），并且该变量被正确注入到应用程序的运行时环境中。更改密钥后，所有现有的JWT令牌将失效，因此所有用户和自动化流程都需要重新认证。

防御者应通过检查应用程序日志中的意外认证事件或尝试验证使用已知默认密钥签名的令牌，来审计他们的Yeti安装是否使用了默认密钥。在多租户或面向互联网的配置中使用Yeti的组织应将此漏洞视为关键——成功的利用将导致威胁情报平台的完全妥协，这可以被用来污染源或泄露敏感的IOC数据。