滥用反向代理,第 1 部分:元数据

2022-01-17 16:45:50 浏览数 (1)

介绍

许多云服务提供商在他们的虚拟机上提供“元数据”服务。这些服务提供有关实例和云操作环境的敏感细节。 元数据服务提供 REST API 以编程方式检索此数据。Amazon 的 AWS 服务在其 EC2 实例上定义了 IMDSv1“标准”,从那时起,许多其他公司也采用了这种 IMDSv1 方案,包括 AWS、Google 和 Azure。 除了阿里巴巴的 100.100.100.200 之外,服务一般都选择 IP 地址 169.254.169.254 进行元数据访问。

蓝队:如果您的使用允许,则阻止对外围元数据 IP 的传入请求。如果技术上可行,请阻止任何名称解析为元数据 IP 的入站请求。

出于安全原因,此服务通常只能通过 localhost 访问。然而,一旦服务器受损或 SSRF 漏洞,攻击者就可以访问此服务(已经支付了不止一些披露和赏金)。 访问元数据服务的另一个可能途径是通过错误配置的反向代理(有些人确实将其归类为 SSRF)。

开放代理类型入门

  • 转发:典型的用例是允许私有网络用户通过一个公共出口点访问互联网。这允许组织为用户可以访问哪些类型的互联网服务制定规则。

内部专用网络客户端通过代理服务器访问 Internet。

  • 反向:典型的用例是允许互联网用户通过网关访问某些可访问互联网的服务,并阻止对其他后端系统的访问。这样做的原因有很多,包括负载平衡、故障转移、安全等,以及何时有助于限制来自 Internet 的攻击面。

Internet 用户使用代理从内容服务器检索信息。

如果配置不正确,反向代理可以允许对代理可以访问的其他主机(包括本地接口上的自身)进行超出意图的访问。 如果代理服务在带有 IMDS 的云系统上运行,则可以访问元数据服务,因为代理请求来自本地主机(反向代理工作的副产品)。

IMDSv1(在此处讨论)缺少任何身份验证/授权。许多服务提供确实需要身份验证/授权的 IMDSv2。强烈建议使用这个更安全的版本(如果有)。

让我们仔细看看与普通反向代理相比,攻击是如何工作的。 如上所示,由于代理规则不正确(或缺少),客户端可以访问任何主机。这可能导致私有网络访问(对运行代理的 VM 可访问的任何主机)以及元数据服务。 当客户端配置为使用代理时,HTTP 请求遵循如下格式:

代码语言:javascript复制
 GET http://example.com/page.html HTTP/1.1
 Host: example.com

复制

这将指示代理从example.com获取“page.html”并将结果提供给客户端。 作为攻击者,我们可以修改目标站点和 Host 头来访问 IMDSv1 服务(Digital Ocean):

代码语言:javascript复制
 GET http://169.254.169.254/metadata/v1/ HTTP/1.1
 Host: 169.254.169.254

复制

预期的功能是访问内容服务器,但是,错误配置允许访问元数据 API。

如果服务可访问,我们将收到实例元数据。

来自 Digital Ocean 虚拟机的实例元数据。

由于元数据服务有据可查,因此攻击者可以探索通过 API 提供的路径。如果找到云角色、帐户名、密钥或密码,则可以转向主机访问或其他云服务(例如,s3)。

来自 bug 赏金测试的 OpenStack user_data 方法示例。在这种情况下,构建脚本包含加密的根密码。

随着公司直接阻止带有元数据 IP 的传入请求变得越来越普遍,核心模板还使用解析为元数据服务的正确 IP 地址的主机名。

Nuclei现在包含模板,可跨多个云提供商查找此问题。所有都可以在misconfigurations/proxy/目录中找到

0 人点赞