影响分析：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 是，它允许未经授权的参与者，在不必成为其所有者的情况下撤回（删除）包版本。该请求将被分派给包的控制者，但由于获取包版本的机制，撤销操作可能将在不同的包上执行。相关代码如下：
由于没有正确地过滤/检查 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 平台版本，同时存在其他平台相同版本的包。
这为我们提供了 85 个包，其中 29 个带有连字符。对于这 29 个包，我们再次进行了人工审核，没有发现任何恶意妥协的迹象。
现在撤销以后篡改可以吗？
这个也被检查过了。我们已经确定了过去两周内被移除的 25 个包，但没有一个包能够引起我们的注意。
那么“常规”的篡改案例呢？
虽然这超出了本次调查的范围，但我们还监控各种注册表，以发现潜在的包篡改迹象。到目前为止，我们未在 RubyGems 中发现任何问题，也未表明存在任何问题。最重要的是，我们也没有发现任何与此事件相关的恶意程序包。
总结
虽然这个问题确实很严重，因为它可能在 Ruby 社区中造成了严重影响，但根据我们的数据和以下调查，得出的结论是，gem 没有受到损害并且问题得到了缓解。
Mend 的自动恶意软件检测平台 Diffend，通过检查确保您仅使用经过验证的包源代码，并防止您将任何恶意软件包导入您的组织或个人计算机。
认识作者：
马西杰·门菲尔德（MACIEJ MENSFELD）
马西杰·门菲尔德是 Diffend 平台的创始人和高级产品经理。他开发了供应链安全和开源软件。
如需了解更多关于 Mend（原 WhiteSource）的信息，请联系Mend授权合作伙伴——龙智：
电话：400-775-5506
邮箱：marketing@shdsd.com
还未添加个人签名 2021.05.18 加入
还未添加个人简介
评论