欢迎访问本站!

首页科技正文

usdt官网下载(www.caibao.it):不规范的依赖治理:我若何入侵苹果,微软和数十家公司(新型供应链攻击的故事)

admin2021-03-0574安全技术众测渗透

USDT第三方支付API接口

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

不规范的依赖治理:我若何入侵苹果,微软和数十家公司(新型供应链攻击的故事)

自从我更先学习若何编程,我一直对执行如下一条简朴下令的信托水平所吸引。

pip install package_name

某些编程语言,如Python,附带一种简朴,靠近官方的方式用于为项目安装依赖项。这些安装程序通常与公然代码存储库绑定,在那里任何人都可以自由上传代码包供他人使用。

你可能已经听说过这些工具-好比Node有npm和npm注册表,Python的pip使用PyPI(Python包索引),和Ruby的gem可以在RubyGems找到。

当下载和使用来自任何资源的包,你基本是信托它的发行者在你的机械上运行代码的。那么这种盲目的信托会被恶意行为者行使吗?

谜底是: 固然可以

任何程序包托管服务都无法保证其用户上传的所有代码都是无害的。已往的研究解释,typosquatting(行使盛行软件包名称的错字版本举行攻击)能够异常有效地获取来自全世界各地的随机PC的接见权限。

其他众所周知的依赖项链条攻击路径,包罗使用种种方式去损坏现存的软件包,或以不再存在的依赖项名称上传恶意代码。

想法

在2020年夏日,Justin Gardner(@Rhynorater)实验与我入侵PayPal时,分享了在Github上发现有趣的Node.js源码。

该代码旨在供内部PayPal使用,在它的的package.json文件中,泛起了包罗公共依赖和私有依赖夹杂的情形-公共的软件包来自npm,而非公共的软件包名称,很有可能由PayPal内部托管。这些名称那时在公共npm注册表并不存在。

由于此处不清楚从那边导入包的逻辑,因此产生了几个问题

  • 若是以这些名称将恶意代码上传到npm会发生什么?PayPal的一些内部项目是否有可能更先默使用新的公共软件包而不是私有软件包?
  • 开发人员甚至自动化系统会更先在库中运行代码吗?
  • 若是这行得通,我们可以从中获得赏金吗?
  • 这种攻击还会对其他公司起作用吗?

事不宜迟,我更先制订设计来回覆这些问题。

这个想法是将我自己的“恶意” Node程序包以无人使用的名称上传到npm注册表中,这将从安装它们的盘算机"打电话回家"。若是最终将任何软件包安装在PayPal拥有的服务器上(或其他任何地方),就此而言,其中的代码会立刻通知我。

在这一点上,我觉得很主要的一点是,必须明确指出,在此研究历程中所针对的每个组织都已允许通过公共破绽赏金设计或通过私人协议来对其平安性举行测试。 未经授权,请勿实验这种测试

DNS 永远滴神

值得庆幸的是,npm允许在安装软件包时自动执行随便代码,这使我可以轻松建立一个Node软件包,该软件包通过其preinstall剧本 *** 有关所安装的每台盘算机的一些基本信息。

为了在基于数据识别组织的能力与制止 *** 太多敏感信息之间取得平衡,我决议只纪录用户名,主机名和每个唯一安装的当前路径。与外部IP一起使用的数据就足够了,可以辅助平安团队凭据我的讲述确定可能受到攻击的系统,同时制止将我的测试误认为是现实的攻击。

现在剩下一件事了—我该若何获得这些返回的数据?

众所周知,大多数可能的目的都将位于受到优越珍爱的企业 *** 内部,我认识到DNS窃取是解决的好方式,值得实验。

多多益善

有了攻击的基本设计,现在是时刻发现更多可能的目的了。

第一个计谋是寻找替换生态系统举行攻击。因此,我将代码移植到了Python和Ruby上,以便能够划分将相似的软件包上传到PyPI(Python软件包索引)和RubyGems。

然则,该测试最主要的部门可以说是找到尽可能多的相关依赖项的名称。

在搜索了一些目的公司的私有软件包名称的整整几天后,发现可以在GitHub以及主要软件包托管服务(有时公布的内部软件包内部)内部的主要软件包托管服务中找到许多其他名称--甚至在种种互联网论坛上的帖子。

然则,到目前为止,找到私有程序包名称的更佳位置竟然是…在javascript文件中。

显然,package.json包罗javascript项目依赖项名称的内部文件在构建历程中会嵌入到公共剧本文件中,从而露出内部程序包名称,这是很常见的。同样,这些文件中泄露的内部路径或require()挪用也可能包罗依赖项名称。苹果,Yelp和特斯拉只是以这种方式公然内部名称的公司的一些例子。

在2020年下半年,由于@streaak的辅助和他精彩的侦探手艺,我们能够自动扫描属于目的公司的数百万个域,并提取数百个尚未npm注册表声明的javascript程序包名称。

然后,我将代码上传到所有找到的名称下的包托管服务中,并守候回调。

效果

乐成率简直是惊人的。

,

Usdt第三方支付接口

菜宝钱包(caibao.it)是使用TRC-20协议的Usdt第三方支付平台,Usdt收款平台、Usdt自动充提平台、usdt跑分平台。免费提供入金通道、Usdt钱包支付接口、Usdt自动充值接口、Usdt无需实名寄售回收。菜宝Usdt钱包一键生成Usdt钱包、一键调用API接口、一键无实名出售Usdt。

,

从开发人员在自己的盘算机上犯下的一次性错误,到内部设置欠妥或基于云的构建服务器,再到系统易受攻击的开发管道,结论很明显:抢占正当的内部软件包名称险些是一种一定的方式去进入一些更大的科技公司的 *** ,然后可以远程执行代码,而且可能允许攻击者在构建历程中添加后门。

迄今为止,这类型的破绽,我已经更先称其为<依赖混淆>,且在跨越35个组织的所有三种测试的编程语言中检测到该类型问题。绝大多数受影响的公司属于1000多名员工种别,这很可能反映了大型组织内部使用内部私有库的普遍性。

由于更容易找到javascript依赖项名称,险些所有已纪录的回调中有75%来自npm软件包-但这并不一定意味着Python和Ruby不太容易受到攻击。现实上,只管在我的搜索历程中只能识别属于八个组织的内部Ruby gem名称,但事实证明,其中有四家公司很容易通过RubyGems造成依赖混淆。

加拿大电子商务巨头Shopify是这样的公司之一,其构建系统在我上载后仅几个小时就自动安装了一个名为shopify-cloud的Ruby gem ,然后实验在其中运行代码。Shopify团队在一天之内准备好修复程序,并为发现问题提供了30,000美元的破绽赏金。

另外30,000美元的奖励来自于苹果,我于2020年8月上传到npm的Node包中的代码在其 *** 内的多台盘算机上执行。受影响的项目似乎与Apple的身份验证系统(外部称为Apple ID)有关。

当我提出这个错误可能使威胁者向Apple ID注入后门的想法时,Apple并不认为这种影响水平可以准确说明问题,而是说:

在运营服务中实现后门需要更庞大的事宜序列,这是一个带有附加寄义的异常特定的术语。

然则,Apple确实认可使用此npm软件包手艺可以在Apple服务器上执行远程代码。凭据软件包安装的流程,该问题在我讲述后的两周内获得了解决,但仅在公布此帖子之前不到一天就授予了赏金破绽。

在针对其他公司的其他几回乐成攻击中,可以看到在内部服务器和小我私家开发人员的PC上都安装了相同主题的npm软件包,其中一些安装通常是在软件包上传后数小时甚至几分钟举行的。

哦,这一切更先于PayPal的名字吗?这些也奏效了,又产生了3万美元的赏金。现实上,大多数已授予的Bug赏金都设置为每个程序的计谋所允许的更大数目,有时甚至更高,这说明了依赖混淆bug的严重性通常很高。

其他受影响的公司包罗Netflix,Yelp和Uber。

这不是一个Bug,这是一个功效

只管发现了大量的依赖混淆,但一个细节在某个水平上依然是不清晰的:为什么会这样? 导致此类的破绽真正缘故原由是什么?

大多数受影响的组织都不愿透露有关其根本缘故原由和缓解计谋的更多手艺细节,然则在我的研究历程中以及与平安团队的相同中确实泛起了一些有趣的细节。

例如,Python依赖关系杂乱的罪魁祸首似乎是错误地使用了“设计不平安”下令行参数--extra-index-url。带上此参数使用pip install library指定您自己的包索引时,您可能会发现它可以按预期事情,然则pip背后的现实操作是这样的:

  • 检查library指定(内部)包索引上是否存在
  • 检查公共包索引(PyPI)是否library存在
  • 安装找到的任何版本。若是两个软件包均存在,则默认从具有更高版本号的源举行安装。

因此,library 9000.0.0在上面的示例中,上传名为PyPI的程序包将导致依赖关系被劫持。

只管这种行为已经广为人知,但简朴地在GitHub上搜索--extra-index-url就足以找到一些属于大型组织的易受攻击的剧本-包罗一个影响Microsoft .NET Core组件的bug。不幸的是,该破绽可能已允许向.NET Core添加后门程序,但该破绽在.NET Bug赏金设计中未发现。

Ruby的gem install --source事情方式也与此类似,然则我无法确定其用法是否是我发现所有该类破绽的根本缘故原由。

固然,更改--extra-index-url--index-url是快速而直接的解决方式,然则事实证明,依赖混淆的其他一些变体很难缓解。

JFrog Artifactory是一款普遍用于托管种种类型内部软件包的软件,它提供了将内部和公共库夹杂到统一“虚拟”存储库中的可能性,从而大大简化了依赖性治理。然则,多个客户示意Artifactory使用上述完全相同的易受攻击算法来决议遭遇相同名称时,是使用内部照样外部程序包。在撰写本文时,无法更改此默认行为。

报道,JFrog意识到了这个问题,但一直看待可能的解决方案视为“功效请求”,而没有看到ETA,在此期间,其一些客户则诉诸于将系统计谋更改应用于依赖项治理,以减轻依赖项中的依赖项杂乱。

Microsoft还提供了类似的名为Azure Artifacts的程序包托管服务。凭据我的一份讲述,对该服务举行了一些小的改善,以确保它可以为依赖项混淆破绽提供可靠的解决方式。有趣的是,没有通过测试Azure Artifacts去发现此问题,而是通过乐成攻击Microsoft自己的基于云的Office 365来发现此问题,该讲述获得了在Azure可能获得的更高奖励40,000美元。

有关根本缘故原由和预防建议的更多详细信息,您可以查阅Microsoft的白皮书“使用专用软件包供稿时缓解风险的3种方式”。

未来的研究?

只管许多大型科技公司已经意识到这种破绽,并已在其基础架构中对其举行了修复,或者正在起劲实行缓解措施,但我仍然感应可以继续有许多发现的感受。

具体来说,我信赖找到泄露内部程序包名称的新方式将展现更多易受攻击的系统,而寻找其他的编程语言和目的存储库将露出依赖混淆Bug的其他攻击面。

话虽这么说,无论您的履历水平若何,我都竭诚激励您花一些时间在脑海中实验一下该想法-无论它是否与依赖项治理平安性相关。

致谢

  • @EdOverflow和@prebenve,他们在我之前曾自力研究过类似类型的攻击,但不幸的是尚未公布他们的发现
  • Justin Gardner(@Rhynorater),分享了引发最初想法的代码,并校对了这篇文章
  • @streaak,用于辅助找到许多易受攻击的目的,而且与之互助异常棒
  • Ettic,精彩的工具dn *** in的建立者,我曾用它纪录DNS回调
  • Ohm M.,Plate H.,Sykosch A.,Meier M.(2020)“ Backstabber的刀珍藏:开源软件供应链攻击的回首”。DIMVA2020。盘算机科学讲座,第12223卷。Cham Springer(供应链攻击树插图的泉源)
  • 所有支持公共Bug赏金设计的公司,使我们有可能破费时间来研究像这样的想法。谢谢!

本文为翻译文章,原文链接:https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610

网友评论