报告:PowerShel lGallery易受输入错误和其他包管理攻击

安全
Aqua Nautilus最新报告指出,PowerShell Gallery关于包名称和所有者的政策中仍然存在重大缺陷,在本文中,我们将详细分析这些缺陷,讨论其风险,并提出一些缓解措施。

Aqua Nautilus最新报告指出,PowerShell Gallery关于包名称和所有者的政策中仍然存在重大缺陷,这些缺陷使得在该注册表中不可避免地发生typosquatting攻击,同时也使用户极难辨别软件包的真实所有者。最终,这些缺陷将为潜在的针对注册表庞大用户群的供应链攻击铺平道路。

PowerShell Gallery模块通常用作云部署过程的一部分,特别是在AWS和Azure中流行,用于和云资源进行交互和管理。因此,安装恶意模块对组织来说可能是致命的。此外,攻击者还可以利用另一个缺陷,以发现未列出的包和注册表中已删除的秘密。

尽管研究人员已经向微软安全响应中心报告了这些漏洞,并确认了所报告的行为和正在进行的修复,但截至2023年8月,这些问题仍然存在,这表明微软方面并未实施任何切实的更改。

在本文中,我们将详细分析这些缺陷,讨论其风险,并提出一些缓解措施。

PowerShell Gallery中的三大缺陷

PowerShell是微软开发的命令行shell和脚本语言,用于自动化任务和系统管理。PowerShell Gallery是用于分享和获取PowerShell代码(如PowerShell 模块、脚本和DSC资源)的中央存储库。这些软件包由不同的实体编写,包括微软、AWS、VMware和PowerShell社区的其他成员。

PowerShell Gallery的重要性不言而喻。然而,最近,研究人员在其中发现了三个关键漏洞。接下来,我们将深入研究它们:

缺陷1:松散的包名称策略

研究发现,PowerShell Gallery有一个宽松的模块名称策略。例如,在分析过程中,研究人员已经确定PowerShell Gallery缺乏任何形式的防止模块TypoSquatting攻击的防护措施,这与其他流行的包管理器(如npm)截然不同。

这个漏洞可能为供应链攻击打开大门,使恶意行为者能够上传恶意的PowerShell模块,这些模块在毫无戒心的用户看来是无比真实的。因此,他们可以在其他用户的系统上执行代码,特别是在云环境中。

研究人员发现,大多数Azure包都是用Az.<package_name>模式创建的。但是,非常流行的模块“Aztable”并不符合这一惯例,因为缺少了点(并非Az.)。AzTable是一个关键模块,它提供了操作表的示例函数(在Azure Storage Table上添加、检索和更新实体)。考虑到其在生产中起到的关键作用,它已积累超过1000万的下载量也就不足为奇了。

但是,如果有人创建了另一个遵循惯例的“Az.Table”新模块怎么办?这个新模块可以欺骗那些安装完全在攻击者控制下的PowerShell模块的用户。

“Az.”前缀可能看起来像一个只有包所有者才能控制的作用域,类似于其他平台(例如npm)。但是,这里的情况并非如此,任何人都可以控制其包的前缀。

需要注意的是,这个缺陷超出了前面提到的特定示例,因为PowerShell Gallery注册表中有许多包可以使用这个向量和混淆来欺骗。

其他包管理器(如npm)会采取措施来降低这种风险,并禁止攻击者对流行的包名执行键入。这里有一些来自npm博客的例子来说明它是如何工作的。

由于“react-native”的存在,没有人可以发布这样的变体:

  • reactnative
  • react_native
  • native

类似地,因为“jsonstream”的存在,所以没有人可以发布这样的变体:

  • json-stream
  • stream
  • json_stream
  • js-on-stream

如果攻击者或其他人试图这样做,服务器将以“403 Forbidden”状态响应,表明新包名称与现有包名称太相似。

缺陷2:在PowerShell Gallery中伪造模块元数据

这一缺陷导致恶意人员嗅探模块的元数据,包括作者、版权和描述字段,使其看似更加合法,从而诱骗不知情用户安装。

研究人员指出,用户判断真正作者/所有者的唯一方法是打开“Package Details”标签。然而,这只会将他们引向虚假作者的配置文件,因为攻击者在PowerShell Gallery中创建用户时可以自由选择任何名称。因此,确定PowerShell库中PowerShell模块的实际作者是一项极具挑战性的任务。

【合法的 VS 伪造的(Masquerading)】

尽管Microsoft在PowerShell Gallery文档中建议称,“Author”(作者)元数据是由包的作者提供的,且没有经过Microsoft的验证,只有“Owner”(所有者)字段与用于发布包的Gallery帐户强绑定,这使得它比“Author”字段更值得信赖。但默认情况下显示Author字段,隐藏Owner字段,这给已经感到困惑的用户增加了挑战。

唯一可用的指标是可以操纵的下载计数和最后发布日期。只有当用户打开默认隐藏的“Package Details”部分时,他们才能获得上传Masquerading模块的用户的真实个人资料。

缺陷3:暴露未列出的模块及其秘密

在对PowerShell Gallery的持续研究中,研究人员还发现了另一个漏洞,它允许攻击者枚举所有包的名称和版本,包括那些未列出且试图隐藏的软件包。

这个缺陷的重要性在于它能够暴露未列出的包,这些包通常出于各种原因被隐藏在公众视野之外。

微软关于PowerShell Gallery中未列出包的官方文档表明,未列出的包不会出现在搜索API中,只有那些已经知道确切包名称和版本的人才可以访问和下载未列出的包。然而,我们的研究结果推翻了这一假设。

该漏洞会带来安全风险,因为它允许对敏感信息进行未经授权的访问。用户无意中暴露了PowerShell模块特定版本中的秘密,并试图通过删除仍然暴露于潜在漏洞的包来隐藏这些秘密。

在访问URL“https://www.powershellgallery.com/api/v2/Packages”时,研究人员发现了一个XML文件,其中包含关于PowerShell Gallery中所有包的全面信息。令人惊讶的是,这包括列出的和未列出的包,以及它们各自的版本。

通过利用位于xml响应底部的API链接,特别是“https://www.powershellgallery.com/api/v2/Packages?$skip=number”,攻击者可以不受限制地访问完整的PowerShell包数据库,包括相关版本。这种不受控制的访问为恶意参与者提供了在未列出的包中搜索潜在敏感信息的能力。因此,任何包含机密数据的未列出的包都非常容易受到损害。

在研究报告中,研究人员列举了一些未列出的秘密包,并惊讶地看到发布者错误地上传了包含Github API密钥的.git/config文件,或者包含Gallery本身API密钥的模块发布脚本。其中一项机密属于一家要求匿名的大型科技公司。

【一个带有明文API密钥的发布脚本】

这些发布者注意到了他们的错误,并取消了该模块的特定版本,认为他们已经降低了风险。然而,使用我们上面展示的API,任何人都可以轻松地接收包的所有版本,包括未列出的版本,并列举它们作为秘密。

需要注意的是,PowerShell Gallery中的包所有者可以选择请求删除他们的包,而不是取消它们的列表。但是,此操作只能由gallery的支持团队执行。

概念验证(PoC)

研究人员决定为缺陷1和2创建一个PoC,并上传一个旨在模仿现有流行软件包“AzTable”的完美复制品“Az.Table”。

作为PoC的一部分,研究人员利用了PowerShell“ScriptsToProcess”元素,它允许在导入PowerShell模块期间执行脚本。请注意,这与npm preinstall/postinstall的概念类似。

在“ScriptsToProcess”命令中,研究人员合并了一个收集基本元数据(包括主机名、pwd和whoami)的脚本。目的是跟踪模拟包的下载,并在其导入时启动回调。

在几个小时内,研究人员便收到了来自不同云服务的几台主机的回复,这强调了TypoSquatting的有效性,并强调了与这些安全漏洞相关的危险。

披露时间表

2022年9月27日——Aqua研究团队向MSRC报告了缺陷。

2022年10月20日——MSRC证实了研究人员报告的行为。

2022年11月2日——MSRC表示该问题已经修复(无法在在线服务中提供产品修复的详细信息)。

2022年12月26日——Aqua研究团队复制了缺陷(并没有预防措施)。

2023年1月3日——Aqua研究团队重新上述了关于MSRC缺陷的报告。

2023年1月3日——MSRC再次证实研究人员报告的行为。

2023年1月10日——MSRC将该报告标记为“已解决”。

2023年1月15日—— MSRC回应称,“工程团队仍在努力修复typposquatting和软件包细节欺骗。我们目前有一个短期的解决方案,用于发布到PSGallery的新模块。”

2023年3月7日——MSRC回应称,“响应性修复已经到位”。

2023年8月16日——缺陷仍可用。

缓解和建议

如上所述,这个问题仍然是可重复出现的,所以在使用PowerShell Gallery中的包时需要更加注意和谨慎,直到微软修复了这些缺陷。在此之前,安全专家提供了一些可行建议:

  • 平台责任:首先,最好的解决方案是平台修复缺陷。这可能包括实现严格的包命名策略、验证作者、限制对未列出的包的访问,以及改进包所有权的可见性。当然,作为用户,我们要对我们安装的东西负责,我们需要在安装之前检查我们下载的代码。然而,平台的责任是尽可能地减少攻击面。
  • 使用签名PowerShell模块策略:考虑到在PowerShellgallery中发现的漏洞,建议强制执行只允许执行签名脚本的策略。这确保了任何脚本或模块(包括从PowerShell Gallery下载的脚本或模块)在运行之前必须使用受信任的证书进行数字签名,从而为防止恶意脚本的执行提供了额外的安全层。
  • 使用可信私有存储库:这可以确保存储库具有有限的互联网访问和用户访问,用户可以在其中管理和使用自己的私有模块,同时还可以以更安全的方式存储来自公共PowerShell gallery的模块。
  • 定期扫描敏感数据:这包括扫描模块源代码中的秘密,并在存储和管理模块代码的存储库中进行定期安全评估。为了防止攻击者利用,及时处理和轮换任何暴露的秘密也是很重要的。
  • 在云环境中检测可疑行为:实现一个强大的连续监控系统,在CI/CD管道和云基础设施中实时跟踪活动。这种主动的方法不仅允许组织检测潜在的威胁和可疑行为,还能够检测与已建立的正常配置文件的任何偏差。

原文链接:https://blog.aquasec.com/powerhell-active-flaws-in-powershell-gallery-expose-users-to-attacks

责任编辑:赵宁宁 来源: FreeBuf.COM
相关推荐

2019-11-04 11:25:33

内部攻击网络

2021-09-26 10:32:51

勒索软件恶意软件安全

2023-07-14 09:00:00

2019-02-25 07:55:35

Windows服务器DoS

2021-10-21 08:59:17

技术HTTP攻击

2019-11-25 14:04:15

勒索软件网络攻击漏洞

2024-01-08 19:18:17

2018-08-23 09:16:22

2011-10-17 12:15:50

2021-10-25 09:46:37

代码攻击Node.js

2012-06-18 09:48:50

2017-03-22 09:21:13

2013-05-23 14:42:58

2014-08-08 16:14:33

2015-01-28 14:57:52

2020-10-13 09:59:13

滥用Windows错误

2022-07-29 08:48:12

IT管理错误CIO

2009-01-05 18:53:53

服务器管理

2010-06-24 09:45:15

Linux RPMYUM
点赞
收藏

51CTO技术栈公众号