CertiK 技术团队：谨防 CORS-anywhere 漏洞，可导致第三方软件配置错误

原文标题：《漏洞分析 | CORS-anywhere ：第三方软件配置错误的危险》
原文作者 | CertiK 渗透测试团队
编辑及出品 | CertiK （ID：certikchina）

在最近一次进行的 Web 应用程序渗透测试中，CertiK 技术团队发现了一个预料之外的严重漏洞。在获得客户的许可后，我们将此发现写入本文以做分享，帮助相关开发人员未来规避同样的错误。

目标 Web 应用程序是一个区块链浏览器，它具备区块信息查找、交易历史记录查找、部署的智能合约等功能。

该应用程序的前端是用 React 编写的，React 是一个 Web 框架，可以很好地预防 XSS （跨站点脚本）和 HTML 注入等攻击。

在实现方面，前端 JavaScript 定期从区块链 RPC API 中获取新的块数据。因为区块链是一个简单的应用程序，没有“传统的”后端服务器，不涉及身份验证和授权，也不需要处理大量的用户输入。因此一般来说，很难在区块链浏览器应用程序中找到严重漏洞。

然而，在渗透测试期间，CertiK 团队发现了一些关于用于获取块数据的请求 URL 有些异常。该 URL 看起来像这样：

https://cors.x.y/http://load-balancer.us-east-1.elb.amazonaws.com/blocks/270865

如果仔细观察，就能发现这个完整的 URL 由两个前后连接的 URL 组成。

第二个 URL 看起来像一个 AWS 负载均衡器的 DNS 名称，那第一个指向的又是什么？

单独访问第一个 URL「https://cors.x.y」后，它进入一个名为「CORS-anywhere」的开源工具的默认页面。CertiK 技术团队发现该工具配置错误，从而能够访问敏感信息。

下文将进一步解释背景，并叙述 CertiK 技术团队的发现及进行的其他研究。

在了解调查结果之前，先来了解一下 CORS （跨源资源共享）。如果你有 Web 开发的经验，应该无数次遇到这种 bug:

当一个 Web 应用从与该资源本身所在的服务器不同的域、协议或端口请求一个资源时，Web 应用会发起一个跨域 HTTP 请求。如果响应中没有正确的“access-control-allow-origin”标头（引用），浏览器将阻止发起跨域请求的网页，读取跨域请求返回的内容。

在本文中，将不会太过深入地讨论 SOP （同源政策）和 CORS （跨源资源共享）机制。简而言之，SOP 会阻止 JavaScript 读取跨源请求中的响应，而 CORS 则是一种绕开由同源策略施加的限制的方法。

在这种情况下，上面提到的区块链浏览器的后台是 Cosmos 链。在 Cosmos 中，与节点进行交互的方式是利用 JSON RPC API （https://cosmos.network/rpc) 。节点的主机名通常是由开发人员分配的，或者是 AWS 应用程序负载平衡器的 DNS 名称。

如果区块链浏览器的主机名是「explorer.mychain.com」，而 RPC API 的主机名是「api.mychain.com」。

那么当浏览器「explorer.mychain.com」向「api.mychain.com」发出请求时，它就会成为一个跨域请求。如果其中没有正确的 CORS 标头，浏览器就会阻止应用网站读取 RPC API 的 HTTP 响应。

目前有很多可以解决跨源请求问题的方法，文章末尾处会给出解释。

对于此区块链浏览器，CertiK 技术团队发现它使用名为「CORS-anywhere」的类似代理工具作为处理 CORS 标头的解决方案。因此团队就此对「CORS-anywhere」展开研究。

CORS-anywhere 是一个开源工具，为开发人员提供了一种处理跨域请求的方法。该项目存储库在 Github 上有 3 千多颗星，这足以证明它的受欢迎程度。

「CORS -Anywhere 是一个 NodeJS 代理 ，它将 CORS 标头添加到代理请求中」。

在着手研究这一工具时，Github （Github issue）上有一个关于 CORS-anywhere 的潜在安全风险的提问。就此问题，作者（Rob--W）给出了他的观点。

简而言之，他的回答列出了 3 个要点：

在对于 Web 应用程序渗透测试中，最有趣的是最后一个要点——服务器端请求伪造。

服务器端请求伪造（也称为 SSRF）是一个网络安全漏洞，攻击者可以利用该漏洞诱使服务器端应用程序向攻击者选择的任意域发出 HTTP 请求。在典型的 SSRF 示例中，攻击者的操作可能导致服务器建立自身连接，或者在组织基础结构中构建其他基于 Web 服务或外部第三方系统的连接。

如果想要了解更多关于 SSRF 的信息，可访问参考文献 8。

有了执行 SSRF 的方法，那么使用 SSRF 可以获得什么呢？

提示：区块链浏览器使用的 CORS-wheres 托管在 AWS EC2 云服务器上。

AWSEC2 云服务器有一个特殊端点：

http://169.254.169.254/latest/meta-data/

此端点只能在服务器内部访问。这个端点包含 AWS 实例元数据，例如实例 ID、主机名、公共 / 私有 IP 和 AWS 角色凭据。

用 Google 检索时，http://169.254.169.254 被 Y Combinator 定义为「EC2 最危险的功能」。

如果 EC2 云服务器被分配了 IAM （身份和访问管理）角色，则对应的 credentials 将出现在元数据中。有了 role credentials，就有了附加到 EC2 云服务器的 IAM 角色特权。

例如，IAM 角色具有一个名为「aws-elasticbeanstalk-ec2-role」的角色。这是在使用 Elastic Beanstalk 服务启动环境时创建的角色。根据 AWS 文档，此角色具有对 s3 存储库的完全访问权限。如果能从元数据端点获取凭据，就可以访问组织中的 s3 存储库。

EC2 云服务器 metadata 服务有两种版本：IMDSv1 （Instance Metadata Service Version 1）；IMDSv2 （Instance Metadata Service Version 1）。

对于 IMDSv1，检索实例元数据仅需要 GET 请求：

对于 IMDSv2，在查询任何元数据之前，必须创建定义会话持续时间的会话通证。

通过将 PUT 请求发送到“http://169.254.169.254/latest/api/token”来创建会话。然后就可以使用 PUT 请求返回的通证请求元数据。

针对于保护 Web 应用程序中的 SSRF 漏洞的保护，与在 IMDSv1 相比，IMDSv2 提供了额外的安全措施。简而言之，有几个优点：

更多有关 IMDSv1 和 IMDSv2 区别的信息，可访问 AWS security blog （参考文献 3）。

如上所述，CORS-anywhere 可被用于执行 SSRF 攻击，并且被部署在 EC2 云服务器上，是时候对此进行利用了。

CertiK 技术团队使用 Elastic Beanstalk 启动一个 EC2 云服务器。为了方便演示假设访问 EC2 云服务器上部署的 cors-anywhere 的 URL 是 http://cors.x.y：

针对 IMDSv1 的十分简单直接。CertiK 技术团队向部署 CORS-anywhere 的服务器发出 GET 请求，去获取附加了 IAM 角色的 AWS 凭证。

尽管 IMDSv2 比 v1 更安全，但仍然可以通过在 CORS-anywhere 中的 SSRF 漏洞来访问 metadata，获取 role credentials。这是因为 CORS-anywhere 支持 HTTP PUT 方法，能将所有标头转发到元数据服务。

要利用 IMDSv2 中的此漏洞，需要发送两个请求。首先，发送一个包含「X-aws-ec2-metadata-token-ttl-seconds」HTTP 标头的 PUT 请求以获取会话通证。然后，发送一个包含「X-aws-ec2-元数据通证」HTTP 标头的 GET 请求，该标头的值是从上一个请求中获取的。

可以使用这些证书来获得对 S3 储存库和 Cloudwatch 日志的完全 (读+写) 访问权限。

由于「CORS-wherewhere」的流行和 AWS 云的大量使用。究竟有多少 EC2 云服务器遭受「CORS-wherewhere」造成的 SSRF 漏洞？

默认的 CORS-anywhere 页面自动生成页面内容，使潜在的黑客更容易找到它们，包括这句第一行就非常引人注目 :「This API enables cross-origin requests to anywhere」。所以 CertiK 技术团队使用 Shodan.io 和 Zoomeye 这两个搜索引擎寻找连接到互联网的设备，并在搜索中寻找可利用的实例。

CORS-anywhere 的默认页面

「Shodan」返回 6 个结果，「Zoomeye」返回 447 个结果。

为了消除误报并进一步验证来自搜索引擎的结果，CertiK 技术团队编写了脚本用来确认主机在线，并且可以在「CORS-anywhere」的帮助下访问元数据服务。最终发现互联网上总共有 100 个 AWS EC2 云服务器因为部署了 CORS-anywhere，而会受到 SSRF 攻击。但因为没有被授权，所以没有继续尝试获取检索 AWS role credentials。

ZoomEye

在渗透测试期间，CertiK 技术团队利用区块链浏览器使用的 CORS-anywhere 中的 SSRF 漏洞，获取 EC2 role credentials，从而获得对公司 S3 存储库和 CloudWatch Logs 的完全（读取和写入）访问权限。但没有在 AWS 云中执行进一步的渗透，因为这不在渗透测试的范围之内。

重点：

1. Web 应用程序中的漏洞不仅可以在系统的前端和后端找到，而且可以在基础设施中找到。

2. 在系统上部署第三方工具之前，请谨慎操作并了解潜在的安全风险。

3. 无论是由内部安全团队还是第三方公司执行安全审计和渗透测试，对于确保系统的安全都至关重要。安全专业人员将尝试从恶意黑客的角度破坏系统，在黑客真的利用漏洞之前提前帮助识别和修复。

4. 了解 AWS 共享责任模型。客户应对其系统上运行的软件负责。不要让配置错误的软件成为破坏云基础架构的关键。

5. 可以关闭 AWS EC2 云服务器中的 matadata 服务：

在 AWS 中，可以通过禁用对元数据服务的 HTTP 端点的访问来关闭对元数据服务的访问。这可以通过在 AWS CLI 中执行以下命令来完成：

6. 与 Cosmos RPC API 通信时，有更安全的方法来处理跨域请求：

这个渗透测试故事的寓意是，当你受益于第三方代码的价值和功能时，你也需要承担其中可能存在的风险和安全漏洞。

在此次渗透测试服务中，CertiK 技术团队能够在恶意黑客利用 SSRF 漏洞之前就将漏洞捕获。但并不是每次都能这么幸运。因此无论是接使用内部还是外部安全团队的审计，对于识别并降低风险因素，以及确保代码和用户安全都是至关重要的。

CertiK 团队在区块链的各方面，诸如 Solidity，RUST 和 Go 等不同语言；以太坊，Cosmos 和 Substrate 等多种平台方面，都拥有丰富的经验和专业知识。此外，在涵盖非区块链特定的应用程序，包括前端、后端和基础设施渗透测试等方面，CertiK 的技术团队也十分专业。

如果你希望对区块链生态系统（包括智能合约，底层区块链协议的实现以及网络应用程序等）进行彻底的安全审计，CertiK 都可以为你提供帮助。

我们绝不仅仅是寻找漏洞，而是要消除哪怕只有 0.00000001% 被攻击的可能性。

参考文献

来源链接：mp.weixin.qq.com

—-

编译者/作者：CertiK

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。