我花费了400$完成了对大量组织的供应链攻击

文章由豆包的沉浸式翻译和语雀插件生成。原文请查看:

https://labs.watchtowr.com/8-million-requests-later-we-made-the-solarwinds-supply-chain-attack-look-amateur/

全文总结

本文主要介绍了对废弃的 Amazon S3 存储桶可能带来的安全风险的研究。研究团队通过注册被遗弃的 S3 存储桶，发现了大量来自不同重要组织的 HTTP 请求，包括政府、军事、财富 500 强等。如果被恶意利用，可能导致严重的供应链攻击。团队在研究后决定不再公开触及废弃基础设施话题，并感谢了相关合作实体。文章还介绍了研究的起源、Amazon S3 的概念以及研究过程和目标。

重要亮点

• • 研究背景与动机：网络安全行业对供应链攻击不陌生，过去几年有现实案例。研究团队从一个无法访问的安全供应商报告链接开始，思考废弃 S3 存储桶的安全问题，决定进行相关研究以展示互联网广泛存在的问题，尤其是供应链角度的弱点。
• • Amazon S3 介绍：Amazon S3 是一种对象存储服务，具有行业领先的可扩展性、数据可用性、安全性和性能。用户可通过“存储桶”在云端存储文件并分享，非常便宜且易于使用。但当 S3 存储桶被允许衰减并废弃后，可能被不良行为者重新注册利用，带来安全风险。
• • 研究过程与发现：研究团队在两个月内通过技术手段识别对废弃 S3 存储桶的引用，注册后记录收到的请求。发现这些存储桶在两个月内收到了超过 800 万个 HTTP 请求，来自各种重要组织。如果团队有恶意倾向，可以用恶意内容回应请求，从而访问请求系统或所在网络。
• • 研究影响与合作：研究团队认为如果研究成果落入坏人之手，可能导致比以往更严重的供应链攻击。他们感谢了 NCSC UK、AWS、主要的未命名 SSLVPN 设备供应商 #2 和 CISA 等实体在研究中的合作。AWS 对已识别的 S3 存储桶进行沉坑处理，降低了风险。
• • 研究结论与反思：作为一个行业，我们在解决复杂的供应链安全问题时，却常常忽略简单的问题。研究团队决定不再公开触及废弃基础设施话题，并强调不能因研究结果对任何单个组织的安全状况做出错误结论。

原文沉浸式翻译

Surprise surprise, we've done it again. We've demonstrated an ability to compromise significantly sensitive networks, including governments, militaries, space agencies, cyber security companies, supply chains, software development systems and environments, and more. Surprise，我们又做到了。我们已经实现了如何破坏敏感网络设施的能力，包括政府、军队、航天机构、网络安全公司、供应链、软件开发系统和环境等。

From those of you who enjoy our research, to the PSIRT and CERT teams who dread an email originating from @watchTowr.com, you are likely aware that we’ve historically delivered research that shone a spotlight on the security impact of abandoned infrastructure in various forms:从喜欢我们研究的人，到害怕来自 @watchTowr.com 的电子邮件的 PSIRT 和 CERT 团队，您可能知道我们过去提供的研究以各种形式关注废弃基础设施的安全影响：

• • Obtaining the ability to issue valid TLS/SSL certificates for any .MOBI domain (via abandoned domains used for WHOIS servers)获得为任何 .MOBI 域颁发有效 TLS/SSL 证书的能力（通过用于 WHOIS 服务器的废弃域）
• • Hijacking backdoors in backdoors to compromise government networks (by registering domains for backdoors, within widely used backdoors)劫持后门中的后门以破坏政府网络（通过在广泛使用的后门中为后门注册域）

Apparently, though, this wasn’t enough to satisfy us that we’d demonstrated just how held-together-by-string the Internet is and at the same time point out the reality that we as an industry seem so excited to demonstrate skills that would allow us to defend civilization from a Neo-from-the-Matrix-tier attacker - while a metaphorical drooling-kid-with-a-fork-tier attacker, in reality, has the power to undermine the world.然而，显然，这还不足以让我们满意，因为我们已经展示了互联网是多么紧密地联系在一起，同时指出了一个现实，即我们作为一个行业似乎非常兴奋地展示了能够让我们保护文明免受矩阵新级攻击者攻击的技能——而一个隐喻的流口水的孩子拿着叉子级攻击者，实际上却有能力破坏世界。

Therefore, almost without choice - once again, we’re excited to share our research with everyone and be somewhat depressed by the results - misery loves company, and a problem shared is a problem halved (thank you).因此，几乎别无选择——再一次，我们很高兴与大家分享我们的研究，并对结果感到有些沮丧——痛苦喜欢陪伴，分享的问题就是问题减半（谢谢）。

Arguably armed still with a somewhat inhibited ability to perceive risk and seemingly no fear, in November 2024, we decided to prove out the scenario of a significant Internet-wide supply chain attack caused by abandoned infrastructure. This time however, we dropped our obsession with expired domains, and instead shifted our focus to Amazon’s S3 buckets.可以说，我们仍然拥有某种抑制的感知风险的能力，而且似乎没有恐惧，因此在 2024 年 11 月，我们决定证明由废弃的基础设施引起的重大互联网范围供应链攻击的场景。然而，这一次，我们放弃了对过期域的痴迷，而是将重点转移到 Amazon 的 S3 存储桶上。

It’s important to note that although we focused on Amazon’s S3 for this endeavour, this research challenge, approach and theme is cloud-provider agnostic and applicable to any managed storage solution. Amazon’s S3 just happened to be the first storage solution we thought of, and we're certain this same challenge would apply to any customer/organization usage of any storage solution provided by any cloud provider.需要注意的是，尽管我们专注于 Amazon 的 S3 进行这项工作，但这项研究的挑战、方法和主题与云提供商无关，适用于任何托管存储解决方案。Amazon 的 S3 恰好是我们想到的第一个存储解决方案，我们确信同样的挑战将适用于任何客户/组织对任何云提供商提供的任何存储解决方案的使用。

The TL;DR is that this time, we ended up discovering ~150 Amazon S3 buckets that had previously been used across commercial and open source software products, governments, and infrastructure deployment/update pipelines - and then abandoned.The TL;DR 是，这一次，我们最终发现了 ~150 个 Amazon S3 存储桶，这些存储桶之前曾用于商业和开源软件产品、政府和基础设施部署/更新管道，然后被放弃了。

Naturally, we registered them, just to see what would happen - “how many people are really trying to request software updates from S3 buckets that appear to have been abandoned months or even years ago?”, we naively thought to ourselves.自然而然地，我们注册了它们，只是为了看看会发生什么 - “有多少人_真的_试图从似乎在几个月甚至几年前就被放弃的 S3 存储桶中请求软件更新？

As always, what we didn’t anticipate was how this would turn out (you could argue that we regularly seem to underestimate what is about to happen).与往常一样，我们没有预料到结果会如何（你可以说我们似乎经常低估即将发生的事情）。

Before you ask, for many reasons, after this research is published we’re resolutely vowing not to touch the subject of abandoned infrastructure again (publicly). We’ve beaten this proverbial horse to death in three different ways, and frankly we don’t want to completely lose faith in the Internet.在您提出要求之前，出于多种原因，在这项研究发表后，我们坚决发誓不再（公开）触及废弃基础设施的话题。我们已经以三种不同的方式将这匹众所周知的马打死了，坦率地说，我们不想完全对互联网失去信心。

As for the research itself, it panned out progressively, with S3 buckets registered as they were discovered. It went rather quickly from “Haha, we could put our logo on this website” to “Uhhh, .mil, we should probably speak to someone”.至于研究本身，它逐步进行，S3 存储桶在被发现时就进行了注册。它很快就从“哈哈，我们可以把我们的标志放在这个网站上”变成了“呃，.mil，我们可能应该找人谈谈”。

$400+ USD later (we’ve included S3, CloudTrail, and CloudWatch - because we relentlessly queried the logs), we had some results worth talking about.400+ 美元后（我们包括 S3、CloudTrail 和 CloudWatch - 因为我们不断查询日志），我们取得了一些值得讨论的结果。

(You can clearly see when we discovered the ‘Run Query’ button in CloudWatch in December 2024, mashing it to the point that we almost spent $8 USD)（您可以清楚地看到，当我们在 2024 年 12 月在 CloudWatch 中发现“Run Query”按钮时，将其粉碎到我们几乎花费了 8 美元的程度）

When creating these S3 buckets, we enabled logging - allowing us to track:在创建这些 S3 存储桶时，我们启用了日志记录 - 允许我们跟踪：

• • Who requested files from each S3 bucket (via the source IP address)谁从每个 S3 存储桶请求文件（通过源 IP 地址）
• • What they requested (filename, path, and the name of the S3 bucket itself)他们请求的内容（文件名、路径和 S3 存储桶本身的名称）

These S3 buckets received more than 8 million HTTP requests over a 2 month period for all sorts of things -这些 S3 存储桶在 2 个月内收到了超过 800 万个 HTTP 请求，涉及各种问题 -

• • Software updates,软件更新、
• • Pre-compiled (unsigned!) Windows, Linux and macOS binaries,预编译 （unsigned！）Windows、Linux 和 macOS 二进制文件，
• • Virtual machine images (?!),虚拟机映像 （？！）、
• • JavaScript files,JavaScript 文件、
• • CloudFormation templates,CloudFormation 模板、
• • SSLVPN server configurations,SSLVPN 服务器配置，
• • and more.和更多。

Put extraordinarily simply - if we were villainously inclined, we could’ve responded to each of these requests with something malicious like:简而言之 - 如果我们有邪恶的倾向，我们可以用恶意的东西来回应这些请求中的每一个，例如：

• • A nefarious software update, 一个邪恶的软件更新，
• • A CloudFormation template that gave us access to an AWS environment, 一个 CloudFormation 模板，它使我们能够访问 AWS 环境，
• • Virtual Machine images backdoored with ‘remote access tooling’, 使用“远程访问工具”进行后门作的虚拟机映像，
• • Binaries that deployed ‘remote access tooling’ or scary ransomware, or such,部署了“远程访问工具”或可怕的勒索软件等的二进制文件，
• • etc等

to give us access to the requesting system, or network that the requesting system was sat within.允许我们访问请求系统或请求系统所在的网络。

These millions of incoming ‘give me this file’ requests came from the networks of organizations (based on DNS/WHOIS lookups) that some would define as ‘fairly important’:这些数百万个传入的“给我这个文件”请求来自组织网络（基于 DNS/WHOIS 查询），有些人将其定义为“相当重要”：

• • Government networks政府网络
• • USA (inc NASA, numerous laboratories, state governments, etc)美国（包括 NASA、众多实验室、州政府等）
• • UK英国
• • Poland波兰
• • Australia澳大利亚
• • South Korea韩国
• • Turkey土耳其
• • Taiwan台湾
• • Chile智利
• • etc等
• • Military networks军事网络
• • Fortune 500s财富 500 强
• • Fortune 100s财富 100 强
• • “Major payment card network”“主要支付卡网络”
• • “Major industrial product company”“大型工业产品公司”
• • Global and regional banks and financial services organizations全球和区域性银行和金融服务组织
• • Universities around the world世界各地的大学
• • Instant messenger software companies即时通讯软件公司
• • Cyber security technology companies (lol)网络安全技术公司 （lol）
• • Casinos赌场
• • etc等

You get the idea.你明白了。

Note: We will not be drawing any relationship between a specific S3 bucket and ‘which networks we saw requests coming from’ to ensure that no project or software company is subsequently targeted.注意**：我们不会在**特定 S3 存储桶和“我们看到的请求来自哪些网络”之间建立任何关系，以确保随后不会针对任何项目或软件公司。

Before we start sharing our findings, we want to mention a few things about the nature of supply chain attacks.在我们开始分享我们的发现之前，我们想提一下关于供应链攻击性质的一些事情。

As a starting point, the cyber security industry is not new to the challenge posed by supply chain attacks. Over the last few years, we’ve seen real-world supply chain attacks play out, but seemingly only within the grasp of those that apparently most would call ‘nation-state’:首先，网络安全行业对供应链攻击带来的挑战并不陌生。在过去的几年里，我们看到了现实世界的供应链攻击，但似乎只在那些显然大多数人会称之为“民族国家”的人的掌握范围内：

• • Jia Tan VS XZ/liblzma and OpenSSHJia Tan VS XZ/liblzma 和 OpenSSH
• • SolarWinds Orion VS Cozy BearSolarWinds Orion VS Cozy Bear
• • Every living being VS NPM, roughly every other day每个生物 VS NPM，大约每隔一天

Are these solved yet? Who cares - while these are undoubtedly illegal, malicious incidents, these incidents do demonstrate the potential wide-scale impact of a supply-chain attack, while requiring effort and capability more sophisticated than our proverbial kid with a fork.这些问题解决了吗？谁在乎呢 - 虽然这些无疑是非法的恶意事件，但这些事件确实表明了供应链攻击的潜在广泛影响，同时需要比我们众所周知的分叉孩子更复杂的努力和能力。

Clearly, we’re not as smart as the people who undoubtedly put hours/days/months/years into planning and executing the above incidents - we are hackers in our home offices/hotel rooms who resist Jira - but we did watch.显然，我们不如那些无疑花费数小时/数天/数月/数年来计划和执行上述事件的人聪明 - 我们是家庭办公室/酒店房间里抵制 Jira 的黑客 - 但我们确实看到了。

We want to take this opportunity to give our sincere thanks to the entities that engaged with us (while likely rolling their eyes in the background) when we realized what we’d stumbled into, including:我们想借此机会向那些在我们意识到自己偶然发现的事情时与我们互动的实体表示衷心的感谢（尽管他们可能在背后翻了个白眼），包括：

• • NCSC UK (who have helped with introductions and signposting to the correct teams to speak to), NCSC UK（他们帮助介绍和指示正确的团队进行交谈），
• • AWS (who took said ~150 S3 buckets off our hands to sinkhole), AWS（他们从我们手中拿走了大约 ~150 个 S3 桶到天坑），
• • Major Unnamed SSLVPN Appliance Vendor #2 (who worked with us very quickly and directly to take relevant S3 buckets off our hands), and主要的未命名 SSLVPN 设备供应商 #2（他们非常快速、直接地与我们合作，从我们手中夺走了相关的 S3 存储桶），以及
• • CISA (who very quickly remediated an example that affected cisa.gov)CISA（他非常迅速地修复了一个影响 cisa.gov 的示例）

AWS's agreement to sinkhole the identified S3 buckets means that the release of this research does not increase the risk posed to any party—the same issues discussed in this research could not be recreated against the same specific S3 buckets, thanks to the sinkholing performed by the AWS team.AWS 同意对已识别的 S3 存储桶进行沉坑处理，这意味着这项研究的发布不会增加对任何一方构成的风险 — 由于 AWS 团队执行了沉坑处理，因此无法针对相同的特定 S3 存储桶重现本研究中讨论的相同问题。

We believe that in the wrong hands, the research we have performed could have led to supply chain attacks that out-scaled and out-impacted anything we as an industry have seen so far - **or put more clearly, we would've embarrassed Cozy Bear and made their SolarWinds adventures look amateurish and insignificant. **我们相信，如果落入坏人之手，我们所做的研究可能会导致供应链攻击，这些攻击的规模和影响超过了我们作为一个行业迄今为止所见过的任何事情——**或者更清楚地说，我们会让 Cozy Bear 难堪，让他们的 SolarWinds 冒险看起来业余和微不足道。 **

While we suspect some would argue that 'watchTowr is already the wrong hands'.. actually, you're probably right.虽然我们怀疑有些人会争辩说'watchTowr已经是坏人了'..实际上，你可能是对的。

As a final thought - as an industry, we spend a lot of time trying to solve issues like “securing the supply chain” in as many complex ways as possible and still completely fail to cover the easy things, like ‘make sure you don’t take candy from strangers’.最后，作为一个行业，我们花费了大量时间试图以尽可能多的复杂方式解决诸如“保护供应链”之类的问题，但仍然完全无法涵盖简单的事情，例如“确保你不要从陌生人那里拿糖果”。

If you made it this far, enjoy the research, and we'll be back again next week :^)如果你走到了这一步，请享受这项研究，我们下周会再回来 ：^）

Where Did This Idea Come From?这个想法从何而来？

Anyway. Before we get too carried away, let’s rewind, and start way back at the beginning.无论如何。在我们太得意忘形之前，让我们倒带，从头开始。

Picture the scene. A researcher is sitting at their desk, looking at memes for inspiration, surrounded by mountains of empty energy drink cans and disassembled computer hardware.想象一下这个场景。一名研究人员坐在他们的办公桌前，从模因中寻找灵感，周围是堆积如山的空能量饮料罐和拆解的计算机硬件。

Ten minutes later, they’re browsing a security vendor’s (let's call them "Antivirus and MDR Vendor #1") website looking for a report on a particular APT group, and voila - they find a link to the promised report in the lovely format of a PDF file.十分钟后，他们正在浏览安全供应商（我们称他们为“防病毒和 MDR 供应商 #1”）的网站，寻找有关特定 APT 组的报告，瞧 - 他们找到了一个链接，指向承诺的报告，格式为 PDF 文件。

To their dismay though, when they click the link to load the report from https://s3.eu-west-1.amazonaws.com/nationalcert-content/files/apt-1337.pdf, they’re met with not the report, but instead the following error message:然而，令他们沮丧的是，当他们单击链接以从 https://s3.eu-west-1.amazonaws.com/nationalcert-content/files/apt-1337.pdf 加载报告时，他们遇到的不是报告，而是以下错误消息：

<Error>    <Code>NoSuchBucket</Code>    <Message>The specified bucket does not exist</Message>    <BucketName>nationalcert-content</BucketName>    <RequestId>[redacted]</RequestId>    <HostId>[redacted]</HostId></Error>

Astute readers who are blessed with the ability to read will understand very quickly where this is going - the S3 bucket called nationalcert-content no longer exists (and so the poor researcher can’t read that PDF). This does constitute a "security issue", **but minor at most.**具有阅读能力的精明读者将很快明白这是怎么回事 - 名为 nationalcert-content 的 S3 存储桶已不复存在（因此，可怜的研究人员无法阅读该 PDF）。这确实构成了一个 “安全问题”，但最多是轻微的。

Could we register the S3 bucket in question, and use it to serve a malicious PDF file a job advert to anyone that requested it (captive audiences, etc)? Yes, yes we could.我们能否注册有问题的 S3 存储桶，并使用它向请求它的任何人（捕获受众等）提供招聘广告？是的，是的，我们可以。

While this sounds mischievous and nefarious (we didn’t do this, in this anonymized example), the reality is that the severity of such an attack is roughly equivalent to hijacking a dead link. It’s not great for the owner of the website, but it’s not the end of the world or significant.虽然这听起来很恶作剧和邪恶（在这个匿名示例中，我们没有这样做），但现实情况是，这种攻击的严重性大致相当于劫持一个死链接。这对网站所有者来说不是一件好事，但并不是世界末日或重要。

For those in the audience cursed with an inability to threat model - yes, as security “professionals” we can likely all think of scenarios in which this could theoretically be abused, especially when combined with the likely target audience of security researchers or threat intel analysts - but please calibrate yourself, this is not significant nor within the realms of a reasonable threat model.对于那些被诅咒为“无法威胁模型”的受众 - 是的，作为安全“专业人士”，我们可能都可以想到理论上可能滥用威胁模型的场景，尤其是当与安全研究人员或威胁情报分析师的可能目标受众相结合时 - 但请校准自己，这并不重要，也不在合理的威胁模型的范围内。

We know - none of this stuff is new or exciting. Give us a few minutes. We’re really trying our best to build context before we drop the interesting stuff.我们知道 - 这些东西都不是新鲜的或令人兴奋的。请给我们几分钟时间。我们真的在尽最大努力构建上下文，然后再放弃有趣的内容。

What Is Amazon S3?什么是 Amazon S3？

Per Amazon, Amazon S3 is:根据 Amazon 的说法，Amazon S3 是一种对象存储服务，提供行业领先的可扩展性、数据可用性、安全性和性能。数百万各种规模和行业的客户为几乎任何使用案例（例如数据湖、云原生应用程序和移动应用程序）存储、管理、分析和保护任意数量的数据。借助经济高效的存储类和易于使用的管理功能，您可以优化成本、组织和分析数据，并配置微调的访问控制，以满足特定的业务和合规性要求。

TL;DR: it is a dedicated file storage solution in the cloud. It has the benefit that it is both very cheap and very easy to use.TL;DR：是云端专用的文件存储方案。它的好处是它既非常便宜又非常易于使用。

Amazon S3 is a good solution in its own right - it allows anyone with an Amazon account to host files and make them accessible to the entire Internet, without worries like ‘what if a hard drive fails’ or ‘do I have enough bandwidth’, or, “should I actually be sharing this with the world?”.Amazon S3 本身就是一个很好的解决方案 - 它允许任何拥有 Amazon 账户的人托管文件并使其可供整个 Internet 访问，而无需担心“如果硬盘驱动器出现故障怎么办”或“我是否有足够的带宽”，或者“我真的应该与全世界共享它吗？

In order to keep things neat and tidy, S3 gives users this magical space and place called a ‘bucket’ - effectively, a file-sharing space that can contain folders and folders.为了保持整洁，S3 为用户提供了这个称为“存储桶”的神奇空间和位置 - 实际上，一个可以包含文件夹和文件夹的文件共享空间。

For example, we might decide to use Amazon S3 to host memes and register an S3 bucket called ‘watchTowrs-finest-memes’. This would result in the S3 URL (ignoring regions - not our job to teach this!) of watchtowrs-finest-memes.s3.amazonaws.com (this doesn't exist, hijack it you nerds).例如，我们可能决定使用 Amazon S3 托管模因并注册一个名为“watchTowrs-finest-memes”的 S3 存储桶。这将导致 watchtowrs-finest-memes.s3.amazonaws.com 的 S3 URL（忽略区域 - 不是我们的工作来教这个！）（这不存在，劫持它，你们这些书）。

We could then upload files to this bucket, and reference said files within this S3 bucket anywhere we felt the need to via a regular HTTPS URL (like https://watchTowrs-finest-memes.s3.amazonaws.com/our-fav-meme.exe). It goes without saying that we could store anything here - code, PDFs, images, binaries, etc - and share the link with all and sundry, reaping the benefits of Amazon’s large storage and wide Internet pipes.然后，我们可以将文件上传到此存储桶，并通过常规 HTTPS URL（如 https://watchTowrs-finest-memes.s3.amazonaws.com/our-fav-meme.exe）在此 S3 存储桶中任何我们认为需要的任何地方引用所述文件。不用说，我们可以在这里存储任何内容 - 代码、PDF、图像、二进制文件等 - 并与所有人共享链接，从而获得 Amazon 的大型存储和广泛的 Internet 管道的好处。

‘World’s Easiest Bug Bounty Payout’“世界上最简单的漏洞赏金支付”

The problem, from a security standpoint, manifests when these S3 buckets are allowed to decay and subsequently abandoned, allowing bad actors to re-register them for themselves.从安全角度来看，当允许这些 S3 存储桶衰减并随后被放弃时，问题就会显现出来，从而允许不良行为者为自己重新注册它们。

This is a known bug class, known as any names, including ‘S3 bucket takeover’ (we know this is not new - bear with us). Second-order Amazon S3 bucket takeovers via broken links are also not new, before you tell us this also.这是一个已知的错误类，称为任何名称，包括“S3 存储桶接管”（我们知道这并不新鲜 - 请耐心等待）。在您告诉我们之前，通过断开链接进行二阶 Amazon S3 存储桶接管也不是什么新鲜事。

These issues have been common for a long time. This is partly due to the prevalence of website hijacking and defacement opportunities, stemming from takeovers of abandoned S3 buckets that were previously used to host static websites.这些问题已经存在了很长时间。这部分是由于网站劫持和污损机会的普遍存在，这些机会源于对以前用于托管静态网站的废弃 S3 存储桶的接管。

Take this random screenshot that we found on the Internet for example:以我们在 Internet 上找到的这张随机截图为例：

This is a random image from Google Images这是一张来自 Google 图片的随机图片

Here, the hostname blog.char49.com is set to reference an S3 bucket (blog.char49.com) via DNS in order to host a static website.此处，主机名 blog.char49.com 设置为通过 DNS 引用 S3 存储桶 （blog.char49.com），以便托管静态网站。

However, in this example that is not real, the specified S3 bucket no longer exists. Speed running this explanation - if a nefarious actor registers the bucket, they could then host malicious content, which would then be served directly on the legitimate domain blog.char49.com.但是，在此示例中，指定的 S3 存储桶不再存在。快速运行此解释 - 如果恶意行为者注册了存储桶，则他们可以托管恶意内容，然后直接在合法域 blog.char49.com 上提供这些内容。

It’s a simple attack, but extremely common. This is not exciting or new, and it is also not the supply chain attack we promised in the title - we promise we’re getting to that bit.这是一种简单的攻击，但非常常见。这并不令人兴奋或新鲜事，也不是我们在标题中承诺的供应链攻击 - 我们保证我们会达到这一点。

You're Back In The Room你回到了房间

Well, let’s take a step back and look at things from a more generalized viewpoint.好吧，让我们退后一步，从一个更普遍的角度来看事情。

While we’ve focused solely on instances where an S3 bucket is used as a backing store for a website’s static content, S3 is used for far more than just serving websites. A huge swath of the Internet’s resources are stored in S3, and the amount of infrastructure that uses it is considerable.虽然我们只关注将 S3 存储桶用作网站静态内容的后备存储的实例，但 S3 的用途远不止于为网站提供服务。大量的 Internet 资源都存储在 S3 中，使用它的基础设施数量相当可观。

Looking at the vulnerability class with a wider eye, we can make a key observation - the mere fact that website-based S3 bucket takeovers are so prolific suggests to us that there’s some inherent challenge around S3 bucket ownership. It follows that this inherent challenge - be it technical, political, organizational, or otherwise - is unlikely to be restricted to just static website resources, such as favicons and PDFs.从更广阔的眼光来看漏洞类别，我们可以做出一个关键的观察 - 基于网站的 S3 存储桶接管如此多产这一事实向我们表明，S3 存储桶所有权存在一些_固有的挑战_。因此，这种固有的挑战 - 无论是技术、政治、组织还是其他方面 - 不太可能仅限于静态网站资源，例如网站图标和 PDF。

We asked ourselves, ‘What other things use S3 buckets behind the scenes as a more general storage solution?’ We’re no DevOps gurus, but a few answers slid conveniently off the top of our collective heads and onto our whiteboard.我们问自己，“还有哪些其他东西在幕后使用 S3 存储桶作为更通用的存储解决方案？我们不是 DevOps 专家，但一些答案方便地从我们的集体脑海中滑落到我们的白板上。

• • Container applications (DevOps people love storing their containers in S3)容器应用程序（DevOps 人员喜欢将容器存储在 S3 中）
• • CI/CD tooling infrastructure (Dockerfiles, Jenkinsfiles, built artefacts, etc)CI/CD 工具基础设施（Dockerfile、Jenkinsfile、构建的工件等）
• • Source code repositories (yes, GitHub just isn’t enough for some people)源代码存储库（是的，GitHub 对某些人来说还不够）
• • Mobile applications移动应用程序
• • Software documentation软件文档
• • Deployment instructions部署说明

While we could continue our enumeration, we decided to focus mostly on these six areas (you’ll see as we progress that this didn’t go entirely to plan, as other resources popped into our field of vision).虽然我们可以继续进行列举，但我们决定主要关注这六个领域（随着我们的进展，你会看到这并没有完全按计划进行，因为其他资源突然出现在我们的视野中）。

Satisfied with our list, we extracted some of the existing capabilities that we hold in the watchTowr Platform into a standalone binary and modified it to focus on Internet-wide assets rather than just our client base.我们对我们的列表感到满意，我们将 watchTowr 平台中拥有的一些现有功能提取到一个独立的二进制文件中，并对其进行修改以专注于 Internet 范围内的资产，而不仅仅是我们的客户群。

The result? A curiously modified tool that we apparently decided to call kidwithafork.结果如何？一个奇怪的修改工具，我们显然决定将其命名为 kidwithafork。

After a quick ‘does it work’ smoke test, we then deployed our new tooling into a proper pipeline, and got to work.在快速的“does it work”冒烟测试之后，我们将新工具部署到适当的管道中，然后开始工作。

What Did We Target?我们的目标是什么？

Now, as you recall, we promised something “supply-chain-esque” against an “Internet-wide” attack surface.现在，如您所知，我们承诺了针对“互联网范围”攻击面的“供应链式”作。

However, we decided it was going to be fairly pointless to set our newly mashed-together tool to work on the entire Internet, so we decided to give ourselves some further parameters to work within.然而，我们认为将我们新组合的工具设置为_在整个_ Internet 上工作是毫无意义的，因此我们决定给自己一些进一步的参数来工作。

After a bit of deliberation (random ideas, and seeing what stuck), we decided to focus on the six selected asset types only when potentially previously owned by:经过一番深思熟虑（随机的想法，看看有什么卡住了），我们决定只关注可能以前由以下人员拥有的六种选定资产类型：

• • Governments政府
• • Fortune 500 companies财富 500 强公司
• • Technology companies科技公司
• • Cyber-security technology companies网络安全技术公司
• • Major open-source projects主要开源项目

The logic behind our decision is simple: These organizations have a large enough user base that an issue would impact numerous people. There’s no real benefit in pointing out that a website with five users has a supply-chain problem—the owners simply don’t have the resources to deal with this kind of detail, and we just don’t care.我们决定背后的逻辑很简单：这些组织拥有足够大的用户群，以至于一个问题会影响很多人。指出一个拥有 5 个用户的网站存在供应链问题并没有什么真正的好处——所有者根本没有资源来处理这种细节，我们根本不在乎。

Our broader aim, however, remained simple - we wanted to demonstrate an Internet-wide issue, grounded in the “abandoned infrastructure” class of weakness, ideally with a supply chain angle (software updates, build pipelines - something like that).然而，我们更广泛的目标仍然很简单 - 我们想展示一个互联网范围的问题，以“废弃的基础设施”为弱点，最好从供应链的角度（软件更新、构建管道 - 类似的东西）。

We’d like to take the opportunity now to make one thing very clear - we have not targeted any organization in particular, despite the outcomes that we detail below. We will not entertain any conversation or speculation that we targeted any organization. It is clear that, like expired and abandoned domain names, this issue is prolific and **not representative of any one organization’s approach to infrastructure or cyber security in isolation.**我们现在想借此机会非常明确地指出一件事 - **我们没有专门针对任何组织，尽管我们在下面详细介绍了结果。我们不会接受任何关于我们针对任何组织的对话或猜测。**很明显，与过期和废弃的域名一样，这个问题也非常多产，并不代表任何一个组织孤立地处理基础设施或网络安全的方法。

Any conclusion that you come to around any individual organization’s security posture as a result of this research would be incorrect, misguided, and likely due to your own bias.您根据这项研究得出的关于任何单个组织的安全状况的任何结论都是不正确的、被误导的，并且可能是由于您自己的偏见。

Over the course of two months, our technology ingested a huge amount of data to identify references to abandoned S3 buckets and subsequently alerted us if any were found.在两个月的时间里，我们的技术提取了大量数据来识别对废弃 S3 存储桶的引用，并在发现任何引用时提醒我们。

Once we saw S3 bucket names that looked interesting, we registered them and began logging any requests they received.一旦我们看到看起来有趣的 S3 存储桶名称，我们就注册了它们并开始记录它们收到的任何请求。

Note: We were not 'sniping' S3 buckets as they were deleted, nor employing any 'advanced' technique to register these S3 buckets. We just.. typed the name into the input box, and used the power of 1 finger to click register.注意：我们没有在删除 S3 存储桶时对其进行“狙击”，也没有采用任何“高级”技术来注册这些 S3 存储桶。我们只是..在输入框中键入名称，然后使用 1 根手指的力量单击 Register。

Our intent was twofold;我们的意图有两个;

• • Firstly, to get an idea of just how many people were requesting data from these previously abandoned S3 buckets, and,首先，要了解有多少人从这些以前被遗弃的 S3 存储桶中请求数据，以及
• • Secondly, what kind of data/files was requested from these previously abandoned S3 buckets.其次，从这些以前废弃的 S3 存储桶中请求了什么样的数据/文件。

The below aims to showcase some of our more interesting results. As you can imagine, given that we saw over 8 million inbound requests, there’s a lot we have to leave out simply for brevity’s sake.以下内容旨在展示我们一些更有趣的结果。可以想象，鉴于我们看到了超过 800 万个入站请求，为了简洁起见，我们不得不省略很多内容。

Since this is a long article, we’ve labelled each section with a ‘danger level’.由于这是一篇很长的文章，我们为每个部分贴上了“危险级别”的标签。

Poisoned Javascript中毒的 Javascript

_Danger level: North Koreans will use your web browser to mine crypto, it might catch fire__危险级别：朝鲜人会使用您的网络浏览器来挖掘加密货币，它可能会着火_

Being the uninspired primitives that we so keenly embody, our first thought was to see if we could identify any JavaScript files requested from any of the S3 buckets we registered—because we could theoretically return a BEEF Project implant (if it was 2003 and we'd just invented fire) or a crypto miner if we’re pretending it’s 2025.作为我们如此热衷于体现的平淡无奇的原语，我们首先想到的是看看我们是否能识别出从我们注册的任何 S3 存储桶中请求的任何 JavaScript 文件——因为理论上我们可以返回一个 BEEF Project 植入物（如果现在是 2003 年，我们刚刚发明了火）或一个加密矿工（如果我们假装现在是 2025 年）。

We took a quick look at our log entries and had our first inkling that we’d stumbled onto something interesting.我们快速浏览了一下我们的日志条目，并初步意识到我们偶然发现了一些有趣的事情。

Take, for example, this request for a JavaScript file, which came to one of our S3 buckets:例如，这个 JavaScript 文件请求进入我们的一个 S3 存储桶：

requestParameters.Host: s3.amazonaws.comrequestParameters.bucketName: echochamberjsrequestParameters.key: dist/main.js

This is a request for a JavaScript file that is involved in the echo-chamber-js project (could you guess?). 这是对 echo-chamber-js 项目中涉及的 JavaScript 文件的请求（您能猜到吗？

A quick look at the project’s GitHub page shows the project’s README file, revealing that it directed users to install the project into their own websites simply via the magic of an overly engineered web-two-point-zero <script src="">.快速浏览一下该项目的 GitHub 页面，可以看到该项目的 README 文件，它显示它引导用户将项目安装到他们自己的网站中，只需通过一个过度设计的 web-two-point-zero <script src="">. 的魔力。

If you were some sort of pentester, scraping the barrel for findings, you’d now launch into some theory about now being in a position to leak cookies and impersonate users on these websites (and you wouldn’t be entirely incorrect).如果你是某种渗透测试人员，在桶里搜寻结果，你现在就会提出一些理论，说现在能够泄露 cookie 并冒充这些网站上的用户（你不会完全错）。

For context, we saw 2000 or so requests for this JavaScript file alone (there were many more JavaScript files, with many more requests, but for the sake of everyone involved, we are not going to bother listing every single JavaScript file - this isn’t a $3000/day pentest report output).就上下文而言，我们仅看到针对此 JavaScript 文件的请求就有 2000 个左右（还有更多的 JavaScript 文件，也有更多的请求，但为了所有相关人员，我们不会费心列出每个 JavaScript 文件 - 这不是 3000 美元/天的渗透测试报告输出）。

We hope you get the point from this single example—loading JavaScript from abandoned S3 buckets— puts unimaginative hackers in a position to execute JavaScript in your web application, steal your cookies, and mine for crypto.我们希望您从这个示例中明白要点 — 从废弃的 S3 存储桶加载 JavaScript — 使缺乏想象力的黑客能够在您的 Web 应用程序中执行 JavaScript、窃取您的 Cookie 并挖掘加密货币。

CISA Secure-By-Wrong-PatchesCISA Secure-By-Wrong-Patches

_Danger level: CISA will tell you to install ‘security patches’ that send your hard drive contents to APTs (or watchTowr)__危险级别：CISA 会告诉您安装“安全补丁”，将您的硬盘内容发送到 APT（或 watchTowr）_

One hit that stood out, (and, if we’re honest, made us chuckle a little bit), was this hit our web crawler found on CISA.gov in a 2012 ICS Advisory:一个突出的点击（老实说，让我们有点发笑），是我们的网络爬虫在 2012 年 ICS 公告中 CISA.gov 发现的这个点击：

Insert some sort of secure-by-design meme here__在此处插入某种 secure-by-design 模因

This S3 bucket was likely valid way back in 2012 when this advisory was first released, complete with a well-intentioned link to an impossible-to-verify-the-integrity-of patch executable. It has since been abandoned, but as you can see, it is referenced from a place of authority - cisa.gov itself.这个 S3 存储桶可能在 2012 年首次发布此公告时是有效的，并附有一个指向_无法验证完整性的_补丁可执行文件的善意链接。它后来被放弃了，但正如你所看到的，它是从一个权威的地方引用的 - cisa.gov 本身。

Someone with just slightly less self-control than those of us here at watchTowr could easily register this (previously abandoned, now safely sinkholed) S3 bucket - providing insert-your-favourite-ransomware-binary-here.exe under the guise of TERMIS_2.10_18-01-2012.exe.比我们这些 watchTowr 的人的自制力稍差，可以轻松注册这个（以前被遗弃，现在安全地沉没了）S3 存储桶 - 以 TERMIS_2.10_18-01-2012.exe 为幌子提供_insert-your-favourite-ransomware-binary-here.exe_。

This is clearly well-intentioned by both the CISA and 7T teams, but regardless, it is an incredible example of how this challenge is ubiquitous and not limited to only the unenlightened—even security professionals inside governments trip up here.这显然是 CISA 和 7T 团队的善意，但无论如何，这是一个令人难以置信的例子，说明这种挑战无处不在，不仅限于不开明的人——甚至政府内部的安全专业人员也会在这里绊倒。

As a conclusion, we let CISA know ahead of the publication of this research - and the reference to the S3 bucket has now been removed:总而言之，我们在这项研究发布之前通知了 CISA - 现在已删除对 S3 存储桶的引用：

But we’re only getting started. What could be worse than unsigned executables on an abandoned s3 bucket referenced by a .gov domain, you might ask? 但我们才刚刚开始。您可能会问，还有什么比 .gov 域引用的废弃 s3 存储桶上的未签名可执行文件更糟糕的呢？

Well, buckle up, you’re about to find out.好吧，系好安全带，你很快就会发现。

Major AntiVirus Vendors Linux Server Agent主要防病毒供应商 Linux Server Agent

_Danger level: Sloppy, "not brilliant" and so much to read into - but perhaps not the end of the world__危险等级：草率，“不聪明”，有太多值得细读的地方——但也许不是世界末日_

Other than straight-up vulnerability, we found this research quite revealing regarding the general hygiene of various security solution vendors. 除了直接的漏洞之外，我们发现这项研究还非常揭示了各种安全解决方案供应商的一般卫生状况。

For example, here’s a condition that doesn't immediately signal an 'this is the end of the world' exploitable weakness but does strongly signal that the S3 buckets in question, associated with a security solution, perhaps aren't being handled or decommissioned with the due care and attention that they should be.例如，以下情况不会立即表明“这是世界末日”的可利用弱点，但确实强烈表明与安全解决方案相关的 S3 存储桶可能没有得到应有的谨慎和关注。

We’ll admit that we project our enjoyment of the mayhem and irony of security companies struggling to practice what they preach, an enjoyment that led us to this particular exposure. We searched our logs for keywords like ‘security’ and for the names of a few security vendors that came to the front of our collective minds.我们承认，我们投射了我们对安全公司努力实践他们所宣扬的混乱和讽刺的乐趣，这种享受导致我们获得了这种特殊的曝光。我们在日志中搜索了 'security' 等关键词，以及一些出现在我们集体脑海中的安全供应商的名称。

One of these searches revealed a huge amount of requests for the S3 bucket named repo.****************, presumably owned by the antivirus giant named majorantivirusvendor#1. 其中一项搜索揭示了对名为 repo.**************** 的 S3 存储桶的大量请求，该存储桶可能归名为 majorantivirusvendor#1 的防病毒巨头所有。

Our log entry looked similar to the following:我们的日志条目类似于以下内容：

requestParameters.Host: s3.amazonaws.comrequestParameters.bucketName:  repo.*****************requestParameters.key: *****************/ubuntu16/dists/*****************/ReleaseuserAgent: Debian APT-CURL/1.0 (1.2.32ubuntu0.2)

There’s a distinctive user-agent , paired with the tell-tale /Release file - this request, it seems, is a request sent by apt-get to a (former) APT repository, which we assume was maintained by majorantivirusvendor#1 to update their Linux antivirus agent.有一个独特的 user-agent ，与明显的 /Release 文件配对 - 这个请求似乎是 apt-get 发送到（以前的）APT 存储库的请求，我们假设该存储库由 majorantivirusvendor#1 维护以更新他们的 Linux 防病毒代理。

It seems likely that majorantivirusvendor#1, at some point in the past, distributed patches via the apt suite of tools, with their APT repository hosted in an S3 bucket - but subsequently, the S3 bucket has been abandoned, leaving existing deployments of their Linux antivirus agent to talk to uncontrolled infrastructure. Some web sleuthing reveals that they migrated to a new URL for software distribution.majorantivirusvendor#1 很可能在过去某个时候通过 apt 工具套件分发补丁，他们的 APT 存储库托管在 S3 存储桶中 - 但随后，S3 存储桶已被放弃，留下他们的 Linux 防病毒代理的现有部署与不受控制的基础设施通信。一些 Web 侦查显示，他们迁移到了一个新的 URL 进行软件分发。

While the naive reader may imagine that we can simply serve malicious content from this repo, this is not the case. 虽然天真的读者可能会认为我们可以简单地从这个仓库中提供恶意内容，但事实并非如此。

It should be noted that apt cryptographically signs packages (and package lists themselves) via gpg, terminated in a root-of-trust found on the install CD itself, and so we have not come across the huge 'we can compromise all of these Linux antivirus agent-running hosts' like it may initially appear. 应该注意的是，apt 通过 gpg 对软件包（和软件包列表本身）进行加密签名，以安装 CD 本身上的信任根终止，因此我们没有遇到像最初看起来那样巨大的“我们可以破坏所有这些 Linux 防病毒代理运行主机”的问题。

While security holes in apt itself are not unheard of, it is safe to say that this is not an actionable vulnerability, so much as an indicator of poor security hygiene.虽然 apt 本身的安全漏洞并非闻所未闻，但可以肯定地说，这不是一个可作的漏洞，而是安全卫生状况不佳的指标。

The same S3 bucket appeared to also serve have historically served data for the yum package management tool:相同的 S3 存储桶似乎也为 yum 包管理工具提供历史上的数据：

requestParameters.Host: s3.amazonaws.comrequestParameters.bucketName: repo.*****************requestParameters.key: *****************/rhel7/x86_64/repodata/repomd.xmluserAgent: [urlgrabber/3.10 yum/3.4.3]

yum is similarly sensible to apt, and uses strong cryptography to prevent an attacker from serving malicious updates in the case of a hijacked or compromised repository.yum 与 apt 类似，并使用强大的加密技术来防止攻击者在存储库被劫持或受损的情况下提供恶意更新。

This is a great example of security-by-design coming into play, and ultimately, it is more of an indicator of poor security hygiene on the part of the (former) S3 bucket owner (before they abandoned it).这是安全设计发挥作用的一个很好的例子，最终，它更多地表明（前）S3 存储桶拥有者（在他们放弃之前）的安全卫生状况不佳。

It should be noted that the requests coming into this S3 bucket originated from some incredibly sensitive organizations, presumably (we assume) because they use majorantivirusvendor#1 branded antivirus.应该注意的是，进入此 S3 存储桶的请求来自一些非常敏感的组织，大概（我们假设）是因为他们使用 majorantivirusvendor#1 品牌的防病毒软件。

Just Pipe It Into Bash只需将其管道传输到 Bash 中即可

_Danger level: please don’t do this, we keep telling you not to do this, please don’t do this__危险等级：请不要这样做，我们一直告诉您不要这样做，请不要这样做_

The security community loves to warn people of the dangers of “just pipe from curl into bash" as an installation technique. While this blanket advice may or may not be misguided, there are certainly instances where it is valid, and one of them is ‘when the source comes from an abandoned S3 bucket’.安全社区喜欢警告人们 “just pipe from curl into bash” 作为一种安装技术的危险。虽然这个笼统的建议可能是也可能没有误导，但肯定在某些情况下它是有效的，其中之一是“当源来自废弃的 S3 存储桶时”。

On this topic, we saw a whole bunch of requests to the S3 bucket airgap.svc.anaconda.com.s3.amazonaws.com for a file named misc/ae5-conda-latest-Linux-x86_64.sh - the installer for something related to the ‘Anaconda’ project.在这个主题上，我们看到了对 S3 存储桶的一大堆请求，airgap.svc.anaconda.com.s3.amazonaws.com 一个名为 misc/ae5-conda-latest-Linux-x86_64.sh 的文件 - 与“Anaconda”项目相关的安装程序。

Truth be told - we’ve had some difficulty ascertaining what Anaconda is or does, other than ‘full of buzzwords’. Something about AI.说实话 - 我们很难确定 Anaconda 是什么或做什么，除了 “充满流行语”。关于 AI 的一些东西。

After some quick searching, we also found the documentation for some kind of VSCode addin, seemingly related to Anaconda itself, which directs the user to install software. 经过一番快速搜索，我们还找到了某种 VSCode 插件的文档，似乎与 Anaconda 本身有关，它指导用户安装软件。

The documentation, however, seems to reference the same abandoned S3 bucket - instead of the domain airgap.svc.anaconda.com, the documentation referenced airgap.svc.anaconda.com.s3.amazonaws.com , which was (at the time) abandoned.但是，该文档似乎引用了同一个被遗弃的 S3 存储桶 - 而不是域 airgap.svc.anaconda.com，该文档引用了 airgap.svc.anaconda.com.s3.amazonaws.com ，它（当时）已被放弃。

It’s not clear if the S3 bucket was once owned, and maintained, by the Anaconda team, or if this is simply a typo. What we do know, though, is that a ‘ripple effect’ caused the domain to propagate to various other places on the Internet, where it is listed as an authoritative location.目前尚不清楚 S3 存储桶是否曾经由 Anaconda 团队拥有和维护，或者这只是一个拼写错误。不过，我们所知道的是，“涟漪效应”导致该域传播到互联网上的其他各个地方，在那里它被列为权威位置。

Perform a basic verification of installation by running the script通过运行脚本执行基本的安装验证

Absolute poetry.绝对的诗歌。

Major SSLVPN Appliance Vendors主要 SSLVPN 设备供应商

_Danger level: We swear, we did not go looking for anything to do with SSLVPNs and once again we’re stuck talking about SSLVPNs!!!!!__危险级别：我们发誓，我们没有去寻找与 SSLVPN 有关的任何事情，我们再次陷入了谈论 SSLVPN 的困境!!!!_

Once again, we turned back to our dataset for more gems, and started to get a real sense of just how unruly this particular can of worms was.我们再一次回到我们的数据集中寻找更多的 gems，并开始真正感受到这群特殊的蠕虫有多么不守规矩。

We admit that, as pretend security researchers instead of Big Data experts, we were slightly daunted by the sheer size of our results - as we say, 8 million requests - and so we scratched our heads for a while trying to figure out how to separate the wheat from the chaff.我们承认，作为假装的安全研究人员而不是大数据专家，我们对结果的庞大规模（正如我们所说的，800 万个请求）感到有点畏惧，因此我们摸不着头脑一段时间，试图弄清楚如何区分小麦和谷壳。

A list of requested files grouped by file extension seemed a good idea, so we figured out how to use Amazon’s query DSL and ran a suitable query.按文件扩展名分组的请求文件列表似乎是个好主意，因此我们想出了如何使用 Amazon 的查询 DSL 并运行了一个合适的查询。

Major Unnamed SSLVPN Appliance Vendor #1 - `*****************`主要未具名的 SSLVPN 设备供应商 #1 - `*****************`

Who can guess, from this request found in our logs, what might be going on here?谁能猜到，从我们日志中找到的这个请求中，这里可能发生了什么？

requestParameters.Host:    s3-us-west-2.amazonaws.comrequestParameters.bucketName:    *****************requestParameters.key: *****************.json

If you saw the name - templates-for-well-known-NGFW-appliance - and surmised this S3 bucket is related to sslvpnvendor#1, and providing deployment templates - you'd be right.如果您看到名称 templates-for-well-known-NGFW-appliance 并推测此 S3 存储桶与 sslvpnvendor#1 相关，并提供部署模板，那么您是对的。

Indeed, we can even find a reference to this file on sslvpnvendor#1’s GitHub itself, in an archived project. 事实上，我们甚至可以在 sslvpnvendor#1 的 GitHub 本身的存档项目中找到对此文件的引用。

The file that references this S3 bucket represents an Ansible playbook, designed to rapidly provision a sslvpnvendor#1 NGFW appliance. 引用此 S3 存储桶的文件代表一个 Ansible playbook，旨在快速预置 sslvpnvendor#1 NGFW 设备。

This appliance is a ‘hardened network device’ designed to sit at the border of an organization and police traffic, protecting a soft-and-cushy internal network from all the potentially malicious traffic originating from the big bad Internet.该设备是一种“强化网络设备”，旨在位于组织的边界并监管流量，保护软性内部网络免受来自大型恶意互联网的所有潜在恶意流量的侵害。

# Use a template from a URL    - name: *****************      cloudformation:        stack_name: "*****************"        state: present        region: "{{ region }}"        disable_rollback: true        template_url: <https://s3-us-west-2.amazonaws.com/*****************>       args:        template_parameters:          *****************: "{{ key_name }}"

Gather round security pros, we’ll be submitting this to ISC2 for your CISSP exam - is it a good idea to fetch your CloudFormation templates from untrusted locations, or abandoned infrastructure? No, stop it.召集安全专家，我们将将其提交给 ISC2 进行 CISSP 考试 - 从不受信任的位置或废弃的基础设施获取 CloudFormation 模板是个好主意吗？不，停下来。

It certainly appears that sslvpnvendor#1 once owned this S3 bucket and has subsequently decided that they do not need it, deleted it and abandoned it. 毫无疑问，sslvpnvendor#1 曾经拥有这个 S3 存储桶，后来决定不需要它，删除了它并放弃了它。

Unfortunately, though, there are evidently still systems and engineers out there that are looking to this bucket, trying to fetch the CloudFormation template it once held as we saw in our logs repeatedly.但不幸的是，显然仍有系统和工程师在寻找这个存储桶，试图获取它曾经持有的 CloudFormation 模板，正如我们在日志中反复看到的那样。

As you may be able to imagine, an attacker who can serve this file is in an extremely privileged position since they can direct CloudFormation to carry out any task they define.正如您可能能够想象的那样，可以提供此文件的攻击者处于极其特权的位置，因为他们可以指示 CloudFormation 执行他们定义的任何任务。

Exposure goes beyond just the built VM; as a CloudFormation template, it has more power than just the creation of instances. An attacker could, theoretically:曝光范围不仅限于构建的 VM;作为 CloudFormation 模板，它的功能不仅仅是创建实例。从理论上讲，攻击者可以：

• • Define new IAM roles定义新的 IAM 角色
• • Deploy any cloud object and grant external accounts access部署任何云对象并授予外部帐户访问权限
• • Remove entries from system logs从系统日志中删除条目
• • Access other, unrelated, cloud storage访问其他不相关的云存储
• • Subscribe to costly cloud products订阅昂贵的云产品
• • Deploy cloud-based ransomware malware, which can lock the entire cloud environment部署基于云的勒索软件恶意软件，可以锁定整个云环境

This is clearly a pretty damning theoretical attack, with real impact possible.这显然是一个相当糟糕的理论攻击，可能会产生真正的影响。

Much to our despair though, sslvpnvendor#1 wasn’t the only VPN appliance vendor we spotted in our logs.然而，令我们绝望的是，sslvpnvendor#1 并不是我们在日志中发现的唯一 VPN 设备供应商。

Major Unnamed SSLVPN Appliance Vendor #2主要未具名的 SSLVPN 设备供应商 #2

Bucket 1 - `*****************`存储桶 1 - `*****************`

Taking a look over our results, we spotted the file extension `.json`. This in itself is fairly benign, but we thought it deserved a second look.查看我们的结果，我们发现了`.json`。这本身是相当良性的，但我们认为它值得再看一遍。

Smacking us in the face was an S3 bucket suspiciously named sslvpnvendor#2-******-******. 打我们脸上的是一个可疑的 S3 存储桶，它被可疑地命名为 sslvpnvendor#2-******-******。

We sat there for a while trying to work out who this name might be referencing but were rapidly distracted by the number of incoming requests for the file *****************.template.json.我们在那里坐了一会儿，试图弄清楚这个名字可能指的是谁，但很快就被文件*****************.template.json的传入请求数量分散了注意力。

Looking at sslvpnvendor#2's ***************** Github repository that referenced this S3 bucket, you'd spot a pair of ‘Launch stack’ buttons.查看引用此 S3 存储桶的 sslvpnvendor#2 的 ***************** Github 存储库，您会发现一对“Launch stack”按钮。

These buttons are not as innocent as they look. They refer to an S3 bucket that, as mentioned above, had been abandoned.这些按钮并不像看起来那么无辜。它们指的是如上所述已被放弃的 S3 存储桶。

Clicking one of these buttons would’ve allowed you (so kindly) to deploy infrastructure based on the contents of the CloudFormation template that used to be hosted within the abandoned S3 bucket (but thankfully, nothing anymore, since watchTowr would never take advantage of your trusting click).单击其中一个按钮将允许您（非常友好地）根据 CloudFormation 模板的内容部署基础设施，该模板曾经托管在废弃的 S3 存储桶中（但谢天谢地，现在已经没有了，因为 watchTowr 永远不会利用您的信任点击）。

All of the previous attack scenarios apply here.上述所有攻击场景都适用于此处。

Major Unnamed SSLVPN Appliance Vendor #2主要未具名的 SSLVPN 设备供应商 #2

Bucket 2 -`*****************`存储桶 2 -`*****************`

The next unusual entry in our result set was the extension `.template` , fetched from the S3 bucket named `*****************`.结果集中的下一个不寻常的条目是扩展名 `.template` ，该扩展名是从名为 `*****************`.

What could that be, we thought? Some kind of website markup DSL template? We took a look at the incoming query that Amazon had logged to our bucket.我们想，那会是什么？某种网站标记 DSL 模板？我们查看了 Amazon 记录到我们存储桶的传入查询。

requestParameters.Host:    s3-us-west-2.amazonaws.comrequestParameters.bucketName:    *****************requestParameters.key: *****************.template

Er, wait, what? What on Earth have we stumbled on here? 呃，等等，什么？我们到底在这里偶然发现了什么？

Yet another request for a file called *****************.templatein a path suspiciously suggesting it’s likely a CloudFormation template, in an S3 bucket called sslvpnvendor#2-******-****** .在名为 sslvpnvendor#2-******-****** 的 S3 存储桶中，路径中对名为 *****************.template的文件的另一个请求可疑地表明它可能是 CloudFormation 模板。

We can’t be 100% sure exactly what this file is being used for, but we have a strong suspicion that it is related to autoscaling inside AWS - a system for automatically provisioning and auto-scaling new cloud-based sslvpnvendor#2 SSLVPN devices to meet unexpected demand. 我们不能 100% 确定这个文件的确切用途，但我们强烈怀疑它与 AWS 内部的自动扩展有关——一个用于自动预置和自动扩展新的基于云的 sslvpnvendor#2 SSLVPN 设备以满足意外需求的系统。

If one navigates to sslvpnvendor#2's``***************** Github repository, and takes a close look at yet another ‘Launch a demo’ link, you'll see a URL that references this very file to deploy a cloud-defined stack, and subsequently deploys a new SSLVPN appliance within your AWS account.如果导航到 sslvpnvendor#2's``***************** Github 存储库，并仔细查看另一个“启动演示”链接，您将看到一个 URL，该 URL 引用此文件以部署云定义的堆栈，然后在您的 AWS 账户中部署新的 SSLVPN 设备。

We can hazard a guess that, in addition to being used to spin up the demo appliance, the *****************.template is likely intended to define exactly what infrastructure is spun up to meet this demand.我们可以大胆猜测，除了用于启动演示设备之外，*****************.template 还可能旨在准确定义启动哪些基础设施来满足此需求。

If it were present in the bucket, it would describe the deployment of a sslvpnvendor#2 SSLVPN, and all the associated gubbins - subnets, VPCs, security groups, all of that fancy cloud stuff. This is clearly not something you would want to do from a malicious source, for all the given reasons above.如果它存在于存储桶中，它将描述 sslvpnvendor#2 SSLVPN 的部署，以及所有相关的 gubbins - 子网、VPC、安全组，以及所有花哨的云内容。由于上述所有给定的原因，这显然不是您想从恶意来源做的事情。

Interestingly, while most requests were anonymous, some were associated with AWS accounts referencing @sslvpnvendor#2.com usernames - allowing us to tie certain attempted deployment activity to specific sslvpnvendor#2 employees.有趣的是，虽然大多数请求都是匿名的，但有些请求与引用 @sslvpnvendor#2.com 用户名的 AWS 账户相关联，这使我们能够将某些尝试的部署活动与特定的 sslvpnvendor#2 员工联系起来。

Again, put simply, we watched as sslvpnvendor#2 employees attempted to spin up stacks of cloud-defined assets via CloudFormation templates expected to exist within an abandoned S3 bucket.同样，简单地说，我们看到 sslvpnvendor#2 员工试图通过预期存在于废弃 S3 存储桶中的 CloudFormation 模板来启动云定义资产堆栈。

Imagine the possibilities if we were bad people.想象一下，如果我们是坏人，会有什么可能性。

It got worse though.不过情况变得更糟了。

Coming into the S3 bucket ***************** were significant amounts of requests that had a URI that ended as such: *****************/baseconfig. 进入 S3 存储桶*****************的是大量请求，这些请求的 URI 以 *****************/baseconfig 结尾。

As far as we can tell and aligned to our theory (backed up by evidence) was that these appear to be swathes of requests from freshly autoscaled sslvpnvendor#2 SSLVPN appliances, looking to our S3 bucket to configure themselves. This functionality is known as 'autoscaling in AWS' or similar.据我们所知，并且与我们的理论（有证据支持）保持一致的是，这些似乎是来自新自动扩展的 sslvpnvendor#2 SSLVPN 设备的大量请求，这些设备希望我们的 S3 存储桶进行自我配置。此功能称为“AWS 中的自动扩展”或类似功能。

This theory was further reinforced via the naming conversion of the IAM role names associated with the incoming requests, once again indicating autoscaling infrastructure/tooling.通过与传入请求关联的 IAM 角色名称的命名转换，这一理论得到了进一步强化，再次表明了自动扩展基础设施/工具。

These configurations (which look like *****************) define everything from certs and keys, to routing information, and control of an SSLVPN appliance configuration is equivalent to superuser control of the SSLVPN appliance itself.这些配置（看起来像 *****************）定义了从证书和密钥到路由信息的所有内容，并且对 SSLVPN 设备配置的控制相当于超级用户对 SSLVPN 设备本身的控制。

And there were lots of requests.而且_有很多请求_。

We asked sslvpnvendor#2 if they themselves had any theories on how this happened, as after tearing through numerous branches of firmware we couldn’t find a reference to the S3 bucket that could blindly lead to this behaviour - but this question was never addressed (not that they owe us an explanation).我们询问 sslvpnvendor#2 他们自己是否对这是如何发生的有任何理论，因为在撕毁了固件的众多分支之后，我们找不到对 S3 存储桶的引用，这可能会盲目地导致这种行为 - 但这个问题从未得到解决（并不是他们欠我们一个解释）。

Bluntly though, once an attacker controls the configuration of an SSLVPN, they are able to:但坦率地说，一旦攻击者控制了 SSLVPN 的配置，他们就能够：

• • Silently connect to the victim’s network as if they were a legitimate user - taking advantage of access to internal resources (perhaps deploying ransomware malware),以合法用户的身份静默连接到受害者的网络 - 利用对内部资源的访问（可能部署勒索软件恶意软件），
• • Attacking specific endpoints via MiTM attacks (don’t forget, such VPN appliances often store SSL keys in order to inspect HTTPS traffic, which can be abused to perform man-in-the-middle attacks on endpoints inside the network perimeter),通过 MiTM 攻击攻击特定端点（不要忘记，此类 VPN 设备通常存储 SSL 密钥以检查 HTTPS 流量，该流量可能被滥用于对网络边界内的端点执行中间人攻击），
• • Subvert comms and redirect them by providing our own DNS servers通过提供我们自己的 DNS 服务器来破坏通信并重定向它们
• • Secure the appliance保护设备
• • etc等

You get the idea.你明白了。

Major Unnamed SSLVPN Appliance Vendor #2主要未具名的 SSLVPN 设备供应商 #2

Bucket 3 - `*****************`存储桶 3 - `*****************`

The final `sslvpnvendor#2` abandoned S3 bucket we discovered was `*****************`, which seemingly once held the file `*****************.zip`. Over the course of our research, we saw this archive requested by various systems and/or users.我们发现的最后一个 `sslvpnvendor#2` 废弃的 S3 存储桶是 `*****************`，它似乎曾经保存过文件`*****************.zip`。在我们的研究过程中，我们看到各种系统和/或用户都要求这个存档。

To work out why, we went sleuthing again. Rapidly we identified that within to-this-day published sslvpnvendor#2 documentation PDFs (page 8, in a previously linked but now redacted PDF), instructions are provided for users to download an archive from the abandoned S3 bucket, unzip it (without checking integrity, naturally), and feed it to AWS in order to bring up cloud assets.为了弄清楚原因，我们再次进行了侦查。我们很快发现，在今天发布的 sslvpnvendor#2 文档 PDF（第 8 页，以前链接但现在已编辑的 PDF）中，为用户提供了从废弃的 S3 存储桶下载存档、解压缩（自然无需检查完整性）并将其提供给 AWS 以启动云资产的说明。

Obviously, this can be abused to provide malicious CloudFormation templates - the same attack scenarios described above apply.显然，这可能会被滥用于提供恶意 CloudFormation 模板 - 上述攻击场景相同。

Breather Time喘息时间

As we mentioned, things began to get worse and worse.正如我们所提到的，情况开始变得越来越糟。

We want to again reiterate our comment from way above:我们想再次重申我们在上面的评论：

我们现在想借此机会非常明确地指出一件事 - **我们没有专门针对任何组织，尽管我们在下面详细介绍了结果。我们不会接受任何关于我们针对任何组织的对话或猜测。**很明显，与过期和废弃的域名一样，这个问题也非常多产，并不代表任何一个组织孤立地处理基础设施或网络安全的方法。

Any conclusion that you come to around any individual organization’s security posture as a result of this research would be incorrect, misguided, and likely due to your own bias.您根据这项研究得出的关于任何单个组织的安全状况的任何结论都是不正确的、被误导的，并且可能是由于您自己的偏见。

We’re getting closer to Internet-wide breakage, but we want to move on - we’re sick of anything to do with SSLVPN appliances.我们越来越接近 Internet 范围的破坏，但我们想继续前进 - 我们已经厌倦了与 SSLVPN 设备有关的任何事情。

Virtual Machines With No Integrity没有完整性的虚拟机

_Danger level: Come on, this is ridiculous__危险等级：拜托，这太荒谬了_

What’s more questionable than pulling a CloudFormation template from an untrusted location? 还有什么比从不受信任的位置拉取 CloudFormation 模板更值得怀疑的呢？

What about pulling entire virtual machine images out of abandoned S3 buckets?从废弃的 S3 存储桶中提取_整个虚拟机映像_怎么样？

Somewhat unbelievably, we found systems doing exactly this. Sorting our logs by user-agent, hoping to spot clusters of outliers, we spotted a good amount of requests sporting a user-agent indicating that the request was on behalf of the Vagrant tool.有点难以置信的是，我们发现系统正是这样做的。按用户代理对日志进行排序，希望能发现异常值集群，我们发现了大量带有用户代理的请求，表明该请求是代表 Vagrant 工具的。

We thought this was unusual, not just because of how wild this entire situation was (and unusual is really on a sliding scale at this point), but especially so given Vagrant is typically used to automate the creation of virtual machines (or cloud images).我们认为这很不寻常，不仅仅是因为整个情况有多么疯狂（在这一点上，不寻常实际上是在滑动的尺度上），而且特别是考虑到 Vagrant 通常用于自动创建虚拟机（或云镜像）。

We took a closer look. Take a look at this gem:我们仔细研究了一下。看看这颗宝石：

requestParameters.Host: s3.amazonaws.comrequestParameters.bucketName: bosh-lite-build-artifactsrequestParameters.key: bosh-lite-virtualbox-ubuntu-trusty-293.boxuserAgent: Vagrant Cloud/1.0 (+https://app.vagrantup.com; Vagrant Cloud box verifier)

This is someone using Vagrant's hosted solution to build a virtual machine (or perhaps a cloud image).这是使用 Vagrant 的托管解决方案构建虚拟机（或者可能是云镜像）的人。

In order to speed things up, and to avoid going through the whole process of installing the OS, they’ve (sensibly) specified that the ‘base’ of the new machine should be an image already containing a functioning Linux install.为了加快速度，并避免完成安装作系统的整个过程，他们（明智地）指定新机器的“基础”应该是一个已经包含正常运行的 Linux 安装的镜像。

However, they have (significantly less sensibly) requested that this base virtual machine image should be fetched from an abandoned S3 bucket, that could very well be under the control of a malicious entity (or watchTowr).但是，他们（明显不太明智）要求从废弃的 S3 存储桶中获取此基础虚拟机映像，该存储桶很可能处于恶意实体（或 watchTowr）的控制之下。

Basing the virtual machine on an untrusted image serves to destroy the entire chain of trust on which the resultant image relies. There’s almost no limit to what an attacker can do, but some quick ideas:将虚拟机基于不受信任的映像会破坏结果映像所依赖的整个信任链。攻击者可以做的事情几乎没有限制，但有一些快速的想法：

• • Adding users to the system将用户添加到系统
• • Including something that beacons back to us upon deployment, giving us full access包括一些在部署时返回给我们的信标，为我们提供完全访问权限
• • Supplying subtly backdoored system daemons, such as SSH提供巧妙的后门系统守护程序，例如 SSH
• • Loading our favourite version of Phalanx 2.6加载我们最喜欢的 Phalanx 2.6 版本
• • Waiting for the system to contain important data, and then deploying ransomware-style malware等待系统包含重要数据，然后部署勒索软件式恶意软件
• • Mining for cryptocurrency加密货币挖矿
• • Sniffing credentials of local users, and spraying them at other infrastructure嗅探本地用户的凭据，并将其喷洒到其他基础设施
• • Observing outgoing credentials, and replaying them to escalate access观察传出凭证，并重放它们以提升访问权限

While we have no idea what the resulting virtual machine was intended to be used for, and so we can’t really draw many conclusions about the consequences of this request - but given that watchTowr owned this bucket, we technically could’ve found out.虽然我们不知道生成的虚拟机是用来做什么的，因此我们无法真正得出关于此请求的后果的许多结论 - 但鉴于 watchTowr 拥有这个存储桶，我们从技术上可以找出答案。

We saw a considerable number of these requests, for varying virtual machine templates, all directed at the bosh-lite-build-artifacts bucket. This appears to be some form of VM orchestration software, referenced in many projects online.我们看到了大量针对不同虚拟机模板的此类请求，这些请求都指向 bosh-lite-build-artifacts 存储桶。这似乎是某种形式的 VM 编排软件，在许多在线项目中都有引用。

A Twilight for Sparkle闪闪发光的暮光之城

_Danger level: not-so-bad until you read to the very end and then it makes you wonder why you bother trying to secure things at all__危险程度：还不错，直到你读到最后，然后它让你想知道你为什么要费心去保护东西_

Beside the Vagrant tool, we saw some other unexpected user-agent strings, such as variations of Sparkle. This came in various forms, such as:除了 Vagrant 工具之外，我们还看到了一些其他意想不到的用户代理字符串，例如 Sparkle 的变体。这有多种形式，例如：

• • [GitUp/1.3.5 Sparkle/1.24.0][GitUp/1.3.5 Sparkle/1.24.0]
• • [Houseparty/1.4.1 Sparkle/1.18.1][Houseparty/1.4.1 Sparkle/1.18.1]
• • [hotkeyEVE/1.5.0 Sparkle/313][热键EVE/1.5.0 Sparkle/313]
• • [MongoHub/3.1.5b1 Sparkle/1.19.1][MongoHub/3.1.5b1 Sparkle/1.19.1]

These requests were voluminous, and mostly requested one specific file - appcast.xml.这些请求非常庞大，并且大多数请求一个特定的文件 - appcast.xml。

After musing over why we were seeing a lot of requests for this file, we discovered the ‘Sparkle Project’ (d’oh, the clue was in the user-agent all along!).在思考了为什么我们会看到很多关于这个文件的请求之后，我们发现了“Sparkle Project”（哦，线索一直在用户代理中！

This is a framework library for macOS applications, effectively providing out-of-the-box auto-update functionality.这是一个适用于 macOS 应用程序的框架库，有效地提供了开箱即用的自动更新功能。

While we expected it to be very easy to evaluate how open this Sparkle client was to accepting malicious updates, this topic turned into something of a rabbit-hole for us as we attempted to discern the tangible danger posed by the files.虽然我们预计很容易评估这个 Sparkle 客户端对接受恶意更新的开放程度，但当我们试图辨别文件构成的有形危险时，这个话题对我们来说变成了一个兔子洞。

As we say, the Sparkle Project is a tool for automatically distributing updates for macOS applications.正如我们所说，Sparkle Project 是一个用于自动分发 macOS 应用程序更新的工具。

When it decides to check if an update is available, the library will fetch - you guessed it - the appcast.xml file, which is typically hosted on the vendor’s website (or, in our case, an orphaned S3 bucket).当它决定检查是否有可用的更新时，该库将获取 - 您猜对了 appcast.xml 文件，该文件通常托管在供应商的网站上（或者，在我们的例子中，一个孤立的 S3 存储桶）。

This file contains important metadata about the distributed software, such as available versions, and the URL from which new versions can be fetched.此文件包含有关分布式软件的重要元数据，例如可用版本以及可从中获取新版本的 URL。

These appcast.xml files, in contrast to files used by yum and apt, are not signed by default. This means that we could theoretically serve a malicious appcast.xml, and thus a malicious update, to any of the macOS applications polling our S3 buckets for updates.与 yum 和 apt 使用的文件相比，这些 appcast.xml 文件默认_没有_签名。这意味着，理论上，我们可以向任何轮询 S3 存储桶以获取更新的 macOS 应用程序提供恶意appcast.xml，从而提供恶意更新。

You’d think this would mean instant RCE, but in reality, the situation is somewhat more nuanced (excuse the somewhat long-winded explanation that follows - we want to make sure we neither downplay nor overhype the issue).你可能会认为这意味着即时 RCE，但实际上，情况要微妙一些（请原谅接下来有点啰嗦的解释 - 我们想确保既不淡化也不夸大这个问题）。

As macOS users will no doubt be aware, each application is cryptographically signed, allowing it to be traced to the developer that published it. 正如 macOS 用户无疑会意识到的那样，每个应用程序都经过加密签名，因此可以追溯到发布它的开发人员。

Sparkle, it seems, is smart enough that it will check this cryptographic signature, and ensure that provided update packages are signed by the same developer that signed the application requesting the update - i.e. it won’t install v2.0 of the target software over v1.0 unless both v1.0 and v2.0 are signed by the same developer.Sparkle 似乎足够聪明，它会检查这个加密签名，并确保提供的更新包由对请求更新的应用程序进行签名的同一开发人员签名 - 即，除非 v1.0 和 v2.0 都由同一开发人员签名，否则它不会在 v1.0 上安装目标软件的 v2.0。

This means that we cannot simply serve malicious updates without also compromising the publisher’s signing key.这意味着，我们不能简单地提供恶意更新，而不会泄露发布者的签名密钥。

However, the story doesn’t end there, as attested to by a somewhat active debate on the Sparkle bug tracker over the value of signing the appcast.xml file that transpired a few years ago.然而，故事并没有就此结束_，几年前_在 Sparkle 错误跟踪器上关于签署 appcast.xml 文件的价值的激烈辩论证明了这一点。

A portion of posters believed it important to sign the appcast.xml, arguing that the lack of signature allows a particularly potent social engineering attack, while others felt it would impede legitimate usage of the software.一部分发帖者认为签署appcast.xml很重要，认为没有签名会让特别有效的社会工程攻击成为可能，而其他人则认为这会阻碍该软件的合法使用。

Ultimately, the decision seems to have been made not to sign the files.?最终，似乎已经决定不对文件进行签名。？

Spoiler: This is stupid, just do it.剧透：这太愚蠢了，就去做吧。

Let’s look closer at the ‘particularly potent social engineering attack’.让我们仔细看看“特别有效的社会工程攻击”。

We’re a sceptical bunch here at watchTowr, and when we hear the words ‘social engineering’, we mentally prepare ourselves for an attack with a very low success rate that generates an unacceptable amount of noise.在 watchTowr，我们是一群持怀疑态度的人，当我们听到“社会工程”这个词时，我们会做好心理准备，迎接成功率非常低的攻击，这种攻击会产生不可接受的噪音。

However, as one GitHub commenter explains, this attack is not only unusually potent, but has also been used in-the-wild to compromise developers in the past.然而，正如一位 GitHub 评论者所解释的那样，这种攻击不仅异常强大，而且过去还被在野外用于破坏开发人员。

The attack hinges on the fact that, while the unsigned appcast.xml file cannot persuade Sparkle to install nefarious binaries, it does allow an attacker to show release notes to the user before they apply an update - specifically for a situation in which you want users to update, but can’t provide a package signed with a previously used signing key (like if you're an attacker trying to deliver malware).攻击取决于这样一个事实，即虽然未签名的 appcast.xml 文件无法说服 Sparkle 安装恶意二进制文件，但它_确实_允许攻击者在用户应用更新之前向用户显示发行说明——特别是对于您希望用户更新，但无法提供使用以前使用的签名密钥签名的包的情况（例如，如果您是试图传递恶意软件的攻击者）。

Here’s the perspective of the victim:以下是受害者的观点：

HandBrake had been nagging me for some time to install an update. I finally decided, for whatever reason, to do the update. There was a note in HandBrake’s update dialog that the incremental update was not available, and that I’d have to download an entirely fresh copy from their server.** I didn’t think too much of this, as we’ve been in a similar situation with a broken Sparkle update channel once before (the worst).HandBrake 已经唠叨我安装更新了一段时间。无论出于何种原因，我最终决定进行更新。HandBrake 的更新对话框中有一条说明，指出增量更新不可用，我必须从他们的服务器下载一个全新的副本。 我没有想太多，因为我们之前也遇到过类似的情况，Sparkle 更新频道坏了一次（最糟糕的）。**

So, I managed to download within the three day window during which the infection was unknown, managed to hit the one download mirror that was compromised, managed to run it and breeze right through an in-retrospect-sketchy authentication dialog, without stopping to wonder why HandBrake would need admin privileges, or why it would suddenly need them when it hadn’t before. I also likely bypassed the Gatekeeper warning without even thinking about it, because I run a handful of apps that are still not signed by their developers. And that was that, my Mac was completely, entirely compromised in 3 seconds or less.

因此，我设法在感染未知的三天窗口内下载，设法击中一个被感染的下载镜像，设法运行它并轻松通过一个回顾粗略的身份验证对话框，而没有停下来想知道为什么 HandBrake 需要管理员权限，或者为什么它会突然需要它们以前没有。我也可能不假思索地绕过了 Gatekeeper 警告，因为我运行了一些尚未由开发人员签名的应用程序。就这样，我的 Mac 在 3 秒或更短的时间内就完全、完全受损了。

Clearly, while having the ability to serve malicious appcast.xml packages is not equivalent to code execution, it can be leveraged for a practical attack by a motivated attacker.显然，虽然提供恶意appcast.xml包的能力不等同于代码执行，但有动机的攻击者可以利用它来进行实际攻击。

This places a considerable number of users who are requesting appcast.xml from our S3 bucket at significant risk.这会使大量从我们的 S3 存储桶请求appcast.xml的用户面临重大风险。

When we say ‘considerable number’, we aren’t just hand-waving either - our S3 buckets logged thousands and thousands of unique IP addresses fetching appcast.xml manifests!当我们说“相当多”时，我们不仅仅是在挥手 - 我们的 S3 存储桶记录了成千上万个唯一的 IP 地址来获取appcast.xml清单！

It is worrisome that the software's distribution channel is subverted so easily, and this is made even more severe when you consider not only the number of requesters but also the identity of the requesting users themselves.令人担忧的是，该软件的分发渠道如此容易地被破坏，当您不仅考虑请求者的数量，还考虑请求用户本身的身份时，情况会变得更加严重。

Obviously, we can’t be sure who exactly is requesting these files, but some investigation is possible via the whois and plain old DNS.显然，我们无法确定究竟是谁在请求这些文件，但可以通过 whois 和普通的旧 DNS 进行一些调查。

Unfortunately, studying these records revealed things were even worse than first appeared - we saw hits from sources residing in government-owned IP ranges, and also those in military ranges - being a single step away from being able to compromise a host holding a .mil IP isn’t something you see every day.不幸的是，研究这些记录后发现情况比最初看起来_还要糟糕_ - 我们看到了来自政府拥有的 IP 范围以及_军事_范围内的来源的点击量 - 距离能够入侵拥有 .mil IP 的主机仅一步之遥并不是您每天都能看到的。

Our 12-year-old selves would be frothing at the vhost we could’ve had in #phrack.我们 12 岁的自己会对我们在 #phrack 中可能拥有的幽灵感到口吐白沫。

Regardless, this.. this is not good. We’re seeing a feasible, proven in-the-wild attack on high-value targets. The only consolation is that the appcast.xml file cannot deliver updates silently, due to Sparkle’s sensible certificate checking.无论如何，这个..这不好。我们看到了针对高价值目标的可行、经过验证的在野攻击。唯一令人欣慰的是，由于 Sparkle 的合理证书检查，appcast.xml 文件无法静默地传递更新。

No Signing Necessary无需签名

One application that uses Sparkle to update is the `houseparty` project, which caused many requests for the `appcast.xml` from our `houseparty-mac-builds` bucket.使用 Sparkle 进行更新的一个应用程序是 `houseparty` 项目，它导致许多来自我们的 `houseparty-mac-builds` 存储桶的 `appcast.xml` 请求。

When we found this, having done our research into Sparkle and appcast.xml, we were initially satisfied that we hadn’t stumbled upon a true no-click RCE - until we looked further in our logs. Lo and behold, we found:当我们发现这一点时，在对 Sparkle 和 appcast.xml 进行了研究后，我们最初很满意我们没有偶然发现真正的免点击 RCE - 直到我们进一步查看了我们的日志。瞧，我们发现：

requestParameters.Host: houseparty-mac-builds.s3.amazonaws.comrequestParameters.bucketName: houseparty-mac-buildsrequestParameters.key: Houseparty.dmguseragent: [Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36]

It seems that, in addition to using Sparkle to locate updates in an arguably secure manner, the houseparty project also makes their application available for download directly from the bucket. There’s no need to compromise the updater process after all - attackers can just place a malicious binary and wait for the unsuspecting user to download it with their web browser (note the user-agent, which tells us this is a request from an end-user, rather than a request coming via the Sparkle library, which has its own user-agent).看起来，除了使用 Sparkle 以一种可以说是安全的方式定位更新之外，houseparty 项目还让他们的应用程序可以直接从存储桶中下载。毕竟，没有必要破坏更新程序过程 - 攻击者可以放置一个恶意二进制文件，然后等待毫无戒心的用户使用他们的 Web 浏览器下载它（注意 user-agent，它告诉我们这是来自最终用户的请求，而不是来自 Sparkle 库的请求，该库有自己的 user-agent）。

One interesting thing about this case in particular is that the houseparty app is actually the front end to a defunct social network, which has ceased operations and is no longer accessible. Despite this, we’re still seeing requests to download it, both for the unsigned Houseparty.dmg file, and from Sparkle itself to appcast.xml files.这个案例特别有趣的一点是，houseparty 应用程序实际上是一个已不存在的社交网络的前端，该社交网络已停止运营，无法再访问。尽管如此，我们仍然看到下载它的请求，无论是针对未签名Houseparty.dmg 文件，还是从 Sparkle 本身下载到 appcast.xml 文件。

This strongly implies that the software, somewhere, is still running, trying hard to beacon and find updates to download and run. It’s not an insignificant amount of machines either, as we saw requests coming from almost 3,000 different source IP addresses - all for an app that ceased to function in 2021.这强烈意味着该软件在某个地方仍在运行，努力寻找信标并查找要下载和运行的更新。这也不是一个微不足道的机器数量，因为我们看到来自近 3,000 个不同源 IP 地址的请求——所有这些都是为了一个在 2021 年停止运行的应用程序。

GitUp GitDownGitUp GitDown

This non-functional social network wasn’t the only application we saw, either - another popular entry was the macOS Git UI tool `GitUp` . This is clearly a popular tool, having some 11,000 ‘stars’ on the project’s [GitHub](https://github.com/git-up/GitUp?ref=labs.watchtowr.com) page, a statistic backed up by the number of requests we saw - we saw 10s of thousands of different source IP addresses request the `appcast.xml` holding update information for this package.这个无法正常工作的社交网络也不是我们看到的唯一应用程序 - 另一个流行的条目是 macOS Git UI 工具 `GitUp` .这显然是一个流行的工具，在项目的 [GitHub](https://github.com/git-up/GitUp?ref=labs.watchtowr.com) 页面上有大约 11,000 个“星标”，我们看到的请求数量支持了这一统计数据 - 我们看到数十万个不同的源 IP 地址请求保存此包更新信息的`appcast.xml`。

Again, the package not only fetches updates via the arguably-secure appcast.xml, but also provides an unsigned zip, stored in an orphaned bucket, which is fetched from an abandoned bucket, gitup-builds.s3.amazonaws.com/stable/GitUp.zip.同样，该软件包不仅通过可以说是安全的 appcast.xml 获取更新，而且还提供了一个未签名的 zip，该 zip 存储在孤立的存储桶中，该 zip 是从废弃的存储桶 gitup-builds.s3.amazonaws.com/stable/GitUp.zip 中获取的。

The icing on the cake is the open issue requesting that hashes of built files are provided as part of the build process.锦上添花的是，要求在构建过程中提供构建文件的哈希值是一个未解决的问题。

Just as further icing on the cake, we can see at some point that the macOS Homebrew Cask for GitUp was configured to download .zip archive from said abandoned S3 bucket, with an equally tasty sha256: no_check. 同样锦上添花的是，我们可以看到，在某些时候，适用于 GitUp 的 macOS Homebrew Cask 被配置为从所述废弃的 S3 存储桶下载.zip存档，同样美味 sha256: no_check。

Because why bother checking package integrity?因为为什么要费心检查包的完整性呢？

Please, Make It End拜托，让它结束

_Danger level: entire build process subverted, RIP__危险等级：整个构建过程被颠覆，RIP_

If you’re familiar with the popular gradle suite for managing and downloading build-time dependencies during the compilation of a software project, you’ll know where this is going when we tell you that our logs contained a huge amount of requests for .pom files.如果您熟悉在软件项目编译期间用于管理和下载构建时依赖项的流行 gradle 套件，那么当我们告诉您我们的日志包含大量 .pom 文件请求时，您就会知道这是怎么回事。

Since these files contain a list of build-time dependencies, among other things, it would be trivial to subvert a build process using a file provided by our trusty S3 bucket.由于这些文件包含构建时依赖项列表等，因此使用我们值得信赖的 S3 存储桶提供的文件来破坏构建过程将变得微不足道。

While we concede that it’s theoretically possible that these .pom files could be checked for a valid cryptographic signature - the software technically supports this - the chance is vanishingly small, on a par with the likelihood that there will be no RCE vulnerabilities announced in any hardened SSLVPN appliance for the duration of 2025 (for additional context, we write this knowing that several will be published before this is actually published).虽然我们承认理论_上_可以检查这些 .pom 文件是否具有有效的加密签名（软件在技术上支持这一点），但这种可能性非常小，这与在 2025 年期间不会在任何强化的 SSLVPN 设备中宣布 RCE 漏洞的可能性相当（有关其他上下文， 我们写这篇文章时知道，在实际发布之前会发布几个）。

There were a truly huge (million+) number of requests for these files in our logs, attempting to find files contained in S3 buckets such as fabric-artifacts-private (a misnomer if we ever saw one).在我们的日志中，确实有_大量 （million+）_ 针对这些文件的请求，试图查找 S3 存储桶中包含的文件，例如 fabric-artifacts-private（如果我们见过，那就用词不当了）。

This bucket, in particular, seems to be a hot resource - many projects seem to use it to fetch Maven packages since it appears it was once the official source of the fabric.io package, used as a crash-reporting tool for many packages.特别是这个存储桶，似乎是一个热门资源 - 许多项目似乎使用它来获取 Maven 包，因为它似乎曾经是 fabric.io 包的官方来源，用作许多包的崩溃报告工具。

However, time has taken its toll on fabric.io, and it first became deprecated, and then entirely replaced. Users were urged to move to the firebase project as a replacement, but somewhere along the way, it seems that the distribution S3 bucket - fabric-artifacts-private - was abandoned, and - well, you know the story from there.然而，时间对 fabric.io 造成了影响，它首先被弃用，然后完全被取代。他们敦促用户迁移到 firebase 项目作为替代，但在此过程中的某个时候，分发 S3 存储桶 fabric-artifacts-private 似乎被放弃了，而且 - 嗯，你从那里知道故事。

Instant RCE on hundreds of sensitive build servers.在_数百个_敏感构建服务器上即时 RCE。

The most dangerous thing about this case in particular, however, is the amount of packages using it. Ignoring the hundreds of affected build servers, the significant element here is that each of these servers is building a software package, presumably to be distributed to unsuspecting end-users, or (worse) to be supplied to further developers for even more widespread distribution.然而，这种情况最危险的地方在于使用它的软件包数量。忽略数百个受影响的构建服务器，这里的重要元素是这些服务器中的每一个都在构建一个软件包，大概是为了分发给毫无戒心的最终用户，或者（更糟糕的是）提供给更多的开发人员以进行更广泛的分发。

We are now - technically speaking - in a position where we are able to inject malicious code (be it ransomware, botnets, credential stealers, you name it) into all of these packages (which may be libraries or applications).从技术上讲，我们现在能够将恶意代码（无论是勒索软件、僵尸网络、凭据窃取程序，应有尽有_）注入所有这些_包（可能是库或应用程序）中。

The implications cannot be understated.其影响不容低估。

Ultimately, though, we can only speculate on the intention of the build servers that requested these .pom files. Plus, we’re not particularly keen to obtain analytics or whatever the excuse was, by putting OASTIFY URLs into packages on popular package repositories to see if they get used (ahemSnykahem).不过，最终，我们只能推测请求这些 .pom 文件的构建服务器的意图。另外，我们并不是特别热衷于获得分析或任何借口，通过将 OASTIFY URL 放入流行的包存储库的包中，看看它们是否被使用（ahemSnykahem）。

All we know for sure is that they’re building software.我们唯一可以肯定的是，他们正在构建软件。

Please, Download Binaries From Us请从我们这里下载二进制文件

As we alluded to at the start of the post, there’s a whole world of things we were forced to omit from the post, for brevity’s sake. 正如我们在文章开头提到的，为了简洁起见，我们被迫在文章中省略了一大堆内容。

Nevertheless, we couldn’t resist sharing some of the things we found, so here’s a cassoulet of ‘honourable mentions’.尽管如此，我们还是忍不住分享了我们发现的一些东西，所以这里有一个 “荣誉奖 ”的案例。

One thing truly did surprise us even more than we thought was possible. Once we’d discarded requests associated with user-agent strings such as those for apt and yum, which are invariably protected with strong cryptography, we were left with an alarming list of executable files being retrieved.有一件事确实让我们感到惊讶，甚至比我们想象的还要惊讶。一旦我们丢弃了与用户代理字符串相关的请求，例如 apt 和 yum 的请求，这些字符串总是受到强加密技术的保护，我们就会留下一个令人震惊的可执行文件检索列表。

For example, take this request - it’s from our old friend ‘bosh’ again.例如，以这个请求为例 - 它又来自我们的老朋友 'bosh'。

Bosh is a package for managing virtual machines, so it is clearly something that should be protected with care - there is, by necessity, a clear path from breaching the Bosh tool to breaching all the virtual infrastructure it manages.Bosh 是一个用于管理虚拟机的软件包，因此它显然应该小心保护 - 从破坏 Bosh 工具到破坏它管理的所有虚拟基础设施，必须有一条明确的路径。

requestParameters.Host: s3.amazonaws.comrequestParameters.bucketName: bosh-gcsclirequestParameters.key: bosh-gcscli-0.0.6-windows-amd64.exeuserAgent: curl/8.4.0

This one looks looks pretty bad!这个看起来挺糟糕的！

Why is someone downloading what appears to be a setup program from an abandoned bucket? And why are they doing so with curl, which doesn’t do any signature verification beyond TLS? Are they doing the signature validation manually themselves, via gpg? 为什么有人要从废弃的存储桶下载看似安装程序的内容？为什么他们使用 curl 这样做，而 curl 不执行 TLS 之外的任何签名验证？他们是否通过 gpg 自己手动进行签名验证？

Well, we really hoped that they were checking this file for some kind of cryptographic signature.嗯，我们真的希望他们正在检查这个文件是否有某种加密签名。

These hopes were obliterated when we found a script (perhaps one of many?) which requests this very file, in plain sight on GitHub.当我们在 GitHub 上发现一个请求此文件的脚本（也许是众多脚本中的一个）时，这些希望就破灭了。

Taking a quick look showed that users of this script, at least, do not verify anything at all.快速浏览一下就会发现，至少这个脚本的用户根本没有验证任何内容。

BOSH_GCS_URL = '<https://s3.amazonaws.com/bosh-gcscli/bosh-gcscli-0.0.6-windows-amd64.exe>'..assets/local/bosh-blobstore-gcs.exe:    @echo "### Creating assets/local/bosh-blobstore-gcs.exe"    curl -o assets/local/bosh-blobstore-gcs.exe -L $(BOSH_GCS_URL)..assets/local/agent.zip: assets/local/bosh-agent.exe assets/local/pipe.exe assets/local/service_wrapper.xml assets/local/service_wrapper.exe assets/local/bosh-blobstore-dav.exe assets/local/bosh-blobstore-gcs.exe assets/local/bosh-blobstore-s3.exe assets/local/job-service-wrapper.exe assets/local/tar.exe    @echo "### Creating/Updating assets/local/agent.zip"    mkdir -p assets/temp/deps    $(CP) assets/local/service_wrapper.exe \        assets/local/service_wrapper.xml \        assets/local/bosh-agent.exe \        assets/temp    $(CP) assets/local/bosh-blobstore-dav.exe \        assets/local/bosh-blobstore-gcs.exe \        assets/local/bosh-blobstore-s3.exe \        assets/local/job-service-wrapper.exe \        assets/local/pipe.exe \        assets/local/tar.exe \        assets/temp/deps    cd assets/temp && zip -r ../local/agent.zip * && cd -    rm -rf assets/temp..

This is clearly Not Good—a binary is being fetched from a now abandoned S3 bucket and packaged directly into the built tooling, in the agent.zip package no less (which, we understand, is designed to run on every single VM that Bosh manages).这显然不是好事 — 从现已废弃的 S3 存储桶中获取二进制文件，并直接打包到构建的工具中，至少在 agent.zip 包中（据我们了解，该工具旨在在 Bosh 管理_的每个_ VM 上运行）。

This is clearly a large supply chain compromise, leading not to a compromise of the build machine, but a compromise of all VMs managed by it.这显然是一个大型供应链泄露，不会导致构建机器的泄露，而是它管理的所有 VM 的泄露。

Again, we can’t - in almost all cases - confirm exactly who is attempting to fetch the files on our S3 buckets, beyond identifying by IP address (which are usually dynamically allocated). 同样，在几乎所有情况下，我们无法准确确认_谁_在尝试获取 S3 存储桶上的文件，只能通过 IP 地址（通常是动态分配的）进行识别。

There are a couple of notable examples, however, and one was for a similar fetch, to the Linux version of the bosh-init package, a highly privileged tool used to manage virtual machines as part of Bosh.然而，有几个值得注意的例子，其中一个是针对 bosh-init 包是一个用于管理虚拟机的高特权工具，是 Bosh 的一部分。

requestParameters.Host: s3.amazonaws.comrequestParameters.bucketName: bosh-init-artifactsrequestParameters.key: bosh-init-0.0.103-linux-amd64UserAgent: [curl/7.64.0]

While this may appear to be boring - "it’s yet another system fetching an unsigned binary" - it gets a little more interesting when we identify through DNS PTR records that this binary was requested by several sensitive entities - including (what appear to be) **production card processing servers for a major global payment card processor. 虽然这看起来很无聊 - “这是_另一个_获取未签名二进制文件的系统” - 当我们通过 DNS PTR 记录确定该二进制文件是由多个敏感实体请求的时，它就变得更加有趣了 - 包括（似乎是）一个主要全球支付卡处理商的生产卡处理服务器。 **

**There are some things money can’t buy; this includes common sense.**有些东西是金钱买不到的;这包括常识。

We don’t want to get Watt’d here, so we’re going to leave this nameless. But, please - who cares about popping your shopping cart with MageCart tier attacks when you have (what appear to be) card processing servers downloading unsigned binaries from random places off the Internet.我们不想让 Watt 在这里，所以我们要让它无名无姓。但是，拜托 - 当您有（似乎是）卡片处理服务器从 Internet 上的随机位置下载未签名的二进制文件时，谁会在乎用 MageCart 层攻击弹出您的购物车。

Sigh.叹息。

S3 Bucket ArchaeologyS3 存储桶考古

We hope we’ve made our point - we’re seeing some high-profile organizations with big budgets and big security departments fetching (and, presumably, _trusting_) executable content from our shiny and antique S3 buckers. 我们希望我们已经阐明了我们的观点 - 我们看到一些拥有大量预算和大型安全部门的知名组织从我们闪亮而古老的 S3 模板中获取（并且可能_信任_）可执行内容。

There is one important question we have not yet answered, though.不过，有一个重要的问题我们还没有回答。

To really characterize just how dangerous this truly is, we need to have at least some idea of how much time has elapsed between these S3 buckets being abandoned and our adoption of them.要真正描述这到底有多危险，我们至少需要了解从放弃这些 S3 存储桶到我们采用它们之间经过了多少时间。

Did we just get lucky and time our research just after a whole bunch of organizations abandoned their S3 buckets?我们是否只是幸运地在一大堆组织放弃了他们的 S3 存储桶之后才开始我们的研究？

Spoiler: No.剧透：没有。

This timebomb has been sitting unwatched for years, just waiting for someone to think, ‘Wait a minute, what if I registered that?’. 这个定时炸弹多年来一直无人看管，只等着有人想，'等一下，如果我注册了呢？

While the only organization that can answer this question with any real certainty is Amazon itself, we can get a rough indication of the scale of the time periods involved if we pay close attention to a few specific cases.虽然唯一能够真正确定地回答这个问题的组织是 Amazon 本身，但如果我们密切关注一些具体案例，我们可以大致了解所涉及的时间段的规模。

A good example stems from the following log entry:一个很好的示例源于以下日志条目：

requestParameters.Host: s3.amazonaws.comrequestParameters.bucketName: mozilla-gamesrequestParameters.key: emscripten/releases/emsdk-1.5.6.1-full.exe

As you will no doubt be aware by now, it’s yet another request for an .exe file, and a prime target for an attacker to inject malware.正如您现在无疑已经意识到的那样，这是对 .exe 文件的又一次请求，也是攻击者注入恶意软件的主要目标。

This time, the S3 bucket was previously owned by the the emscripten project - a very popular open-source WebAssembly compiler. While it is notable for this reason alone, we’re going to quietly disregard that factor, and instead focus on a different revelation that it can bring us.这一次，S3 存储桶以前由 emscripten 项目拥有，这是一个非常流行的开源 WebAssembly 编译器。虽然仅凭这个原因就值得注意，但我们将悄悄地忽略这个因素，而是专注于它可以给我们带来的不同启示。

As with previous cases we’ve seen, it seems that at some point in the past they stored their release binaries in this bucket - mozilla-games - and distributed them from there. At some point after this, the S3 bucket was abandoned - like all the other examples.正如我们之前看到的案例一样，他们似乎在过去某个时候将他们的发布二进制文件存储在这个桶中 - mozilla-games - 并从那里分发它们。在此之后的某个时候，S3 存储桶被放弃了 - 就像所有其他示例一样。

This S3 bucket was even referenced in places like the Android toolchain source code:此 S3 存储桶甚至在 Android 工具链源代码等位置被引用：

https://android.googlesource.com/toolchain/rustc/+/809ee4ad5082233770316fd4303aafde8eaebcb9^1..809ee4ad5082233770316fd4303aafde8eaebcb9/https://android.googlesource.com/toolchain/rustc/+/809ee4ad5082233770316fd4303aafde8eaebcb9^1..809ee4ad5082233770316fd4303aafde8eaebcb9/

What’s interesting about this specific example, though, is that the S3 bucket is referenced directly from the documentation of the emscripten project itself, which is archived with full commit history on GitHub.不过，这个特定示例的有趣之处在于，S3 存储桶直接引用自 emscripten 项目本身的文档，该文档与 GitHub 上的完整提交历史记录一起存档。

This means we are able to pinpoint the exact commit in which this S3 bucket was removed from the documentation and ergo the point in time in which the process of decay began.这意味着我们能够精确定位从文档中删除此 S3 存储桶的确切提交，并因此确定衰减过程开始的时间点。

It’s important to note that this doesn’t definitively answer the question of exactly when the S3 bucket was abandoned. However, it gives us a good indication and enough to get a feel for the size of the ‘window of opportunity’ that attackers are afforded.请务必注意，这并不能明确回答 S3 存储桶被放弃的确切时间的问题。但是，它为我们提供了一个很好的指示，足以让我们了解攻击者获得的“机会之窗”的大小。

Worryingly, the commit to remove mention of this S3 bucket from the documentation was made in March 2015. **2015!**令人担忧的是，2015 年 3 月承诺从文档中删除此 S3 存储桶。2015 年！

It is very scary to think that the ‘window of exploitation’ for this issue is so large - it seems reasonable to assume that at any point in (we are educated-guessing) those nine years, attackers were given the opportunity to claim this abandoned S3 bucket and start serving malware, subsequently compromising hosts.考虑到这个问题的“利用窗口”如此之大，这非常可怕 - 似乎可以合理地假设，在这九年中的任何时候（我们是受过教育的猜测），攻击者都有机会索取这个被遗弃的 S3 存储桶并开始提供恶意软件，随后破坏主机。

Conclusion结论


(but for infrastructure and S3 buckets)（但对于基础设施和 S3 存储桶）

Our aim with this research is to demonstrate a challenge, raise awareness, and hopefully make the Internet a little more secure. 我们这项研究的目的是展示挑战，提高认识，并希望使互联网更加安全。

Please understand - we haven’t included everything that we saw. It would be repetitive, so we’ve tried to paint a clear picture that this gets pretty bad the more we look—and more results showing the same bad are not interesting.请理解 - 我们没有包括我们所看到的所有内容。这将是重复的，因此我们试图描绘出一幅清晰的画面，即我们看得越多，情况就越糟糕——显示相同_坏_结果的结果越多，情况就越好就没什么意思了。

The reality is that there is a "simple" root cause of all this strife. It’s not Amazon, S3, or even ‘the cloud’.现实情况是，所有这些冲突都有一个 “简单 ”的根本原因。它不是 Amazon、S3，甚至不是“云”。

The root cause stems from a mindset that has grown as friction to acquiring Internet infrastructure - be it S3 buckets, domain names, IP addresses, or whatever - has lessened.根本原因源于一种心态，随着购买 Internet 基础设施（无论是 S3 存储桶、域名、IP 地址还是其他任何内容）的摩擦减少，这种心态越来越大。

This mindset lulls us in and persuades us that Internet infrastructure is ‘easy come, easy go’. 这种心态让我们沉浸其中，并说服我们 Internet 基础设施是“来得容易，去得容易”。

In a world where registering a domain name costs a mere few dollars, and registering an Internet resource like an S3 bucket takes even less, it takes very little to inadvertently commit to maintaining a finite resource.在一个注册域名只需几美元，而注册 S3 存储桶等 Internet 资源需要更少的世界里，只需很少的时间就可以无意中致力于维护有限的资源。

What we’re only just beginning to see, though, is that all these resources that were carelessly acquired are not only assets, as expected, but also bring with them their own obligations. 然而，我们才刚刚开始看到的是，正如预期的那样，所有这些被粗心收购的资源不仅是_资产_，而且还带来了自己的义务。

We showed this to great effect in our previous research, where we demonstrated the significant impact of an abandoned whois server - but what we truly want to impress upon our readership in this post is that this emerging phenomenon is not limited to major Internet Infrastructure—it affects each and every one of us as well.我们在之前的研究中证明了这一点，我们展示了废弃的 whois 服务器的重大影响 - 但我们真正想在这篇文章中给我们的读者留下深刻印象的是，这种新兴现象不仅限于主要的互联网基础设施，它还影响着我们每一个人。

Our final S3 bucket inclusion, that of the abandoned mozilla-games S3 bucket, is a great example of this. 我们最后的 S3 存储桶包含，即已废弃的 mozilla-games S3 存储桶，就是一个很好的例子。

This S3 bucket was removed from the emscripten documentation back in 2015 - that’s nine years ago, a veritable eternity in Internet years - yet we’re still seeing requests attempting to retrieve executables and more to this day.这个 S3 存储桶早在 2015 年就从 emscripten 文档中删除了 - 那是九年前的事了，在互联网年代是名副其实的永恒 - 但直到今天，我们_仍然_看到试图检索可执行文件的请求等等。

The fact that an attacker could theoretically register a resource abandoned such a long time ago, and instantly serve malware to trusting hosts should alarm us all - and especially those who use the Internet in a non-paranoid way, not checking the integrity of every binary they download (i.e. 99.9999% of us).事实上，攻击者理论上可以注册很久以前就被遗弃的资源，并立即将恶意软件提供给信任的主机，这一事实应该让我们所有人都感到警惕 - 尤其是那些以非偏执的方式使用互联网的人，不检查他们下载的每个二进制文件的完整性（即我们 99.9999% 的人）。

Even the ~150 S3 buckets we acquired to carry out this research posed some hazards regarding their disposal.即使是我们为进行这项研究而购买的 ~150 个 S3 桶，也对它们的处理构成了一些危险。

Clearly, it would be reckless for watchTowr to release the S3 buckets back to the general pool after releasing a research piece disclosing their names. However, we can’t realistically take care of these S3 buckets ad infinitum.显然，watchTowr 在发布一篇披露 S3 存储桶名称的研究文章后将 S3 存储桶释放回通用池是鲁莽的。但是，我们实际上无法_无限_期地处理这些 S3 存储桶。

Fortunately, AWS themselves agreed to ‘sinkhole’ the S3 buckets for us. We transferred ownership of almost all of the S3 buckets to AWS, who have ensured they are now unavailable for general use and removed from general circulation.幸运的是，AWS 自己同意为我们“沉坑”S3 存储桶。我们将几乎所有 S3 存储桶的所有权转让给了 AWS，后者确保它们现在不可用于一般用途，并且不再进行一般流通。

This has the net effect of removing all the risk associated with the S3 buckets we used for the research - no attacks can be carried out, leaving us free to discuss the issues in depth.这具有消除与我们用于研究的 S3 存储桶相关的所有风险的净效果 - 无法进行任何攻击，让我们可以自由地深入讨论问题。

The exception to this arrangement was a few vendor-specific S3 buckets for which we had a pre-existing relationship through numerous PSIRT interactions historically - for example, ***************** - where we had open communications and, therefore, were able to verifiably transfer the S3 buckets back to their correct and original owners.这种安排的例外是一些特定于供应商的 S3 存储桶，我们在过去通过多次 PSIRT 交互建立了预先存在的关系（例如， ***************** ），我们进行了开放式通信，因此能够以可验证的方式将 S3 存储桶转移回其正确的原始所有者。

Please also understand though that in other cases, transferring S3 buckets back to their original owner was not as simple as 'emailing 1 person in a 20,000-person organization' - we have to somehow determine that we are handing these S3 buckets to the correct person, correct department - and not a bad actor that may even exist in the same organization - or we feel that we would be partially responsible for the transfer of an S3 bucket to a malicious individual/party.另请理解，在其他情况下，将 S3 存储桶转移回其原始拥有者并不像“向 20000 人组织中的 1 人发送电子邮件”那么简单 - 我们必须以某种方式确定我们将这些 S3 存储桶交给正确的人、正确的部门 - 而不是甚至可能存在于同一组织中的不良行为者 - 或者我们认为我们将对 S3 的转移负有部分责任存储桶分配给恶意个人/参与方。

Like anyone who calls themselves a ‘hacker’, we love looking into the future, and divining new threats and dangers from the ether - like we have done in today’s post, and in our previous post concerning WHOIS infrastructure.就像任何自称“黑客”的人一样，我们喜欢展望未来，并从以太中预测新的威胁和危险 - 就像我们在今天的博文和上一篇关于 WHOIS 基础设施的博文中所做的那样。

However, we’re starting to get just a little bit tired of warning the world of the dangers of abandoned infrastructure, so we want to assure our dear readership that our next research venture will be focused on some wholly unrelated topic.然而，我们开始有点厌倦了向世界警告废弃基础设施的危险，因此我们想向我们亲爱的读者保证，我们的下一次研究将专注于一些完全不相关的主题。

(Unfortunately, our next most recent Internet-wide research is a minefield at the moment from a coordination perspective, and is likely some time away from public disclosure). （不幸的是，从协调的角度来看，我们最近的下一个 Internet 范围的研究目前是一个雷区，并且可能还需要一段时间才能公开披露）。

来自: 8 Million Requests Later, We Made The SolarWinds Supply Chain Attack Look Amateur