首发|漏洞分析：开源工具CORS-anywhere第三方软件配置错误的危险

背景

在最近一次进行的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（跨源资源共享）

在了解调查结果之前，先来了解一下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介绍

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

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

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

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

拒绝服务(Denial of Service)

IP地址欺骗

SSRF（服务器端请求伪造）

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

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

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

利用SSRF漏洞的常见方法

在内部网络中执行端口扫描和网络侦察

将请求发送到内部服务器的API

访问内部网络中的敏感资源

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

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

AWSEC2 EC2 metadata

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提供了额外的安全措施。简而言之，有几个优点：

必须通过PUT请求获取通证，而大多数SSRF攻击仅支持GET和POST方法。

PUT请求包含一个HTTP标头“X-aws-ec2-metadata-token-ttl-seconds”。在SSRF攻击中，攻击者通常无法在请求中插入其他HTTP标头。

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

利用SSRF漏铜

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

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

针对IMDSv1的利用：

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

针对IMDSv2的利用：

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

网络中的“CORS-Wherewhere”案例

由于“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通信时，有更安全的方法来处理跨域请求：

在config / config.toml配置文件中为“ cors_allowed_origins”指定允许的值。

在相同的主机名下配置应用程序和RPC API。

将Nginx反向代理放置在节点（链）服务器的前面，以将CORS标头插入HTTP响应中

使用WebSocket而不是HTTP与RPC API进行通信。

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

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

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

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

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

原文作者?|?CertiK渗透测试团队

编辑及出品?| CertiK（ID：certikchina）

参考文献：

https://github.com/Rob--W/cors-anywhere/issues/152

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/iam-instanceprofile.html

https://cosmos.network/rpc/v0.37.9

https://www.shodan.io/

https://www.zoomeye.org/

https://portswigger.net/web-security/ssrf

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

https://github.com/Azure/WALinuxAgent/wiki/VMs-without-WALinuxAgent

https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity

—-

编译者/作者：CertiK中文社区

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