影响分析：RubyGems未授权访问漏洞（CVE-2022-29176）

RubyGems是一个软件包注册中心，用于为 Ruby 语言生态系统提供软件，它托管超过170,000个Ruby包(gem)，在其生命周期内提供了近1000 亿次下载。

2022年5月6日，RubyGems披露存在一个可导致未授权访问的漏洞（CVE-2022-29176），该漏洞的CVSS评分为9.9。

RubyGems发布安全公告指出，“由于 yank 操作中存在一个漏洞，因此任何 RubyGems.org 用户都能越权删除并取代某些gems。”

本篇文章将分析CVE-2022-29176漏洞的性质，带来的影响评估和事件分析。

想要自动检测恶意软件？联系Mend授权合作伙伴——龙智，了解更多关于Mend的自动恶意软件检测平台Diffend的信息。

 

2022年5月6日，发布了一个RubyGems的关键安全漏洞，RubyGems是Ruby生态系统的主要包源。

 该漏洞是由于可从存储库中取消发布（“yank”）某些Ruby包，并使用相同的文件名和版本号重新发布污染或恶意的版本。该漏洞需要满足以下条件：

• gem名称中有一个或多个破折号，例如something-provider。
• 以第一个破折号之前的单词命名的包不存在（例如，用于kostya-sigar的kostya, 用于googleapis-common-protos-types的googleapi）。
• 被篡改的包是在过去30天内创建的，或者超过100天未更新。

由于RubyGems提供了详细的包信息列表，所以很容易通过处理这些信息来找到满足以上条件的包。

此外，我们不能假设恶意行为者之前没有注意到该漏洞。虽然这个漏洞是由安全研究人员报告的，但调查人员也假设已存在利用该漏洞的情况。考虑到这一点，在检查可疑活动时，我们重新访问了RubyGems上所有可用的软件包。

CVE-2022-29176的本质

RubyGems 中的一个bug是，它允许未经授权的参与者，在不必成为其所有者的情况下撤回（删除）包版本。该请求将被分派给包的控制者，但由于获取包版本的机制，撤销操作可能将在不同的包上执行。相关代码如下：

find_by!(full_name: "#{rubygem.name}-#{slug}")

　　

由于没有正确地过滤/检查slug，所以可能查询到其它包的版本。但尽管如此，它也可能会带来法律和安全风险。

例如，googleapi示例，可以构建以下的包版本:slug: googleapis-common-protos-types-1.3.1当发送common-protos-types-1.3.1作为一个slug时。

这将有效地删除此版本的目标包。

由于这种性质的问题，事态迅速升级。通过删除所有版本，在某些情况下，该名称可以用于复用。这意味着我们有了一个很棒的新包名可供使用。

 

包版本的不变性怎么样？

 

RubyGems软件包的版本在设计上是不变且不可替代的。这就意味着除非发生安全事件，即有人泄露RubyGems并篡改软件包的内容，否则用户不能简单地更换或更新给定的版本。当然，您也可以删除版本或上传新版本，但新版本需要有不同的编号。

补充信息

这里经常被忽略的一点是，单个RubyGems版本仅在发布它的平台范围内是唯一的。平台基于 CPU架构、操作系统类型，有时还基于操作系统版本。示例包括“x86-mingw32”或“java”。该平台表明gem仅适用于为该平台构建的ruby。RubyGems会自动为您的平台下载正确的版本。

默认平台称为 -ruby，它可以在任何平台上运行。虽然您无法替换它的内容，但您可以自由地删除它并发布具有相同编号的新平台特定版本。例如，您可以删除 karafka-testing-1.4.3 并上传 karafka-testing-1.4.3-i686-linux。版本本身不会改变，但会指定平台。

没有什么能阻止恶意行为者列出所有可用平台，并在每个平台发布一个版本，从而导致每名用户均受此影响。

 

我有一个 Gemfile.lock，它是不可变的，是这样的吗？

 

当然不对。在某些情况下，尽管有锁定文件，Bundler仍可以重新解决依赖关系。这是一种预期中的行为，但尽管如此，它也可能会带来法律和安全风险。

使用-frozen作为默认设置，并使用受损的软件包，您将收到类似于以下内容的消息：

“您的捆绑包仅支持平台 [“x86_64-linux”]，但您的本地平台是 x86_64-darwin。使用 `bundle lock –add-platform x64-mingw32` 将当前平台添加到锁文件中，然后重试。”

虽然上述语句不具有描述性，也未说明任何安全风险，但至少它可能会让人们注意到某些事情已经发生了变化。

 

在Bundler中进行校验和验证会有帮助吗?

 

不会。在上述情况下，Bundler可能会决定重新解析依赖关系。新的依赖关系意味着更新锁文件。更新的lockfile意味着针对特定平台的相同版本的新校验。

影响评估和事件分析

我们正在进行一个行动，旨在帮助开源软件社区和包注册中心保护所有用户，作为行动的一部分，WhiteSource提供了来自我们Diffend平台的情报。

当我们收到关于该事件的通知时，我们使用Diffend进行了评估，以确保：

• 没有流行的软件包被篡改
• 没有任何包通过该漏洞被接管(除了研究包)
• 没有包发布了特定于平台的版本，同时删除了-ruby

当分析这样的案例时，我们从影响评估开始。因为我们实时收集关于RubyGems的信息，我们能够检查到，去年有：

• 132045版本的添加或删除
• 16,629个包受到这些更改的影响

因为Diffend跟踪所有权转换，所以我们知道包发生的任何所有权变化。

因为这种攻击需要一个新的所有者，所以我们可以将范围缩小到1101个包。

当常规的所有权转移发生时，应该有一个阶段，在这个阶段有两个所有者：

• 旧所有者交出包所有权

• 新所有者接受所有权

根据前面讨论的漏洞本质，利用该漏洞的所有者转移，不存在交接阶段，旧所有者消失，新所有者出现。

预期所有权转移流程：

 

意外的所有权转移流：

 

注意：这种模式可以有合法的案例，但对我们来说，该模式可以帮助我们筛选异常包。

当将此逻辑应用于我们的1,101个包时，我们最终会得到174个包。现在，过滤了带有连字符的包后，我们最终剩下60个。在这60个中，只有三个具有每个平台特定的版本：

• shopify-proxy-2-jit
• mrslave-omniauth-runner
• mygem-dcgl-other

注意：这个问题有更多的概念包能够证明，但这些包没有所有权更改，因此无关紧要。这些软件包都是研究性质的。

可以肯定的是，我们仔细检查了所有60个，没有发现任何恶意签名。

 

我们真的可以假设之前没有人注意到这一点吗？

 

不可以，这就是为什么我们还检查了所有被撤销了-ruby平台版本，同时存在其他平台相同版本的包。

SELECT versions.package_id from versions
  inner join (
    SELECT "versions"."package_id", "versions"."number" FROM "versions" WHERE  yanked_at is not null
  ) yanked
  on versions.package_id = yanked.package_id and versions.number = yanked.number
  where versions.yanked_at is null

这为我们提供了85个包，其中29个带有连字符。对于这29个包，我们再次进行了人工审核，没有发现任何恶意妥协的迹象。

现在撤销以后篡改可以吗？

这个也被检查过了。我们已经确定了过去两周内被移除的25个包，但没有一个包能够引起我们的注意。

那么“常规”的篡改案例呢？

 

虽然这超出了本次调查的范围，但我们还监控各种注册表，以发现潜在的包篡改迹象。到目前为止，我们未在RubyGems中发现任何问题，也未表明存在任何问题。最重要的是，我们也没有发现任何与此事件相关的恶意程序包。

 

总结

 

虽然这个问题确实很严重，因为它可能在Ruby社区中造成了严重影响，但根据我们的数据和以下调查，得出的结论是，gem没有受到损害并且问题得到了缓解。

Mend的自动恶意软件检测平台Diffend，通过检查确保您仅使用经过验证的包源代码，并防止您将任何恶意软件包导入您的组织或个人计算机。

 

认识作者

 

马西杰·门菲尔德（MACIEJ MENSFELD）

马西杰·门菲尔德是Diffend平台的创始人和高级产品经理。他开发了供应链安全和开源软件。

 

文章来源：https://www.mend.io/resources/blog/impact-analysis-rubygems-critical-cve-2022-29176-unauthorized-package-takeover/

如需了解更多关于Mend（原WhiteSource）的信息，请联系Mend授权合作伙伴——龙智：

电话：400-775-5506

邮箱：marketing@shdsd.com