攻击者可以利用 AWS VPC 提供的一个功能隐藏自身 IP

安全
VPC就是一个AWS用来隔离你的网络与其他客户网络的虚拟网络服务。在一个VPC里面,用户的数据会逻辑上地与其他AWS租户分离,用以保障数据安全。

[[404095]]

Amazon Virtual Private Cloud (Amazon VPC)允许你在已定义的虚拟网络内启动AWS资源。这个虚拟网络与你在数据中心中运行的传统网络极其相似,并会为你提供使用AWS的可扩展基础设施的优势。简单来说,VPC就是一个AWS用来隔离你的网络与其他客户网络的虚拟网络服务。在一个VPC里面,用户的数据会逻辑上地与其他AWS租户分离,用以保障数据安全。可以简单地理解为一个VPC就是一个虚拟的数据中心,在这个虚拟数据中心内我们可以创建不同的子网(公有网络和私有网络),搭建我们的网页服务器、应用服务器、数据库服务器等等服务。VPC有如下特点:

  •  VPC内可以创建多个子网;
  •  可以在选择的子网上启动EC2实例;
  •  在每一个子网上分配自己规划的IP地址;
  •  每一个子网配置自己的路由表;
  • 创建一个Internet Gateway并且绑定到VPC上,让EC2实例可以访问互联网;
  •  VPC对你的AWS资源有更安全的保护;
  • ……

AWS VPC努力在整个企业中识别和检测攻击者的技术;在终端、本地和云上,Hunters 团队研究了一种使用 VPC 功能的技术,允许客户控制他们的 IP 地址。攻击者可以使用它来控制在访问受感染账户时写入 AWS CloudTrail 日志的 IP 地址。这可能使攻击者能够欺骗依赖 Cloudtrail 日志的各种安全保护措施,例如 SIEM 和云安全工具。其中包括但不限于 GuardDuty、Rapid7 和 Lacework。此外,寻找攻击证据的分析师可能会忽略它。

这篇文章回顾了混淆处理技术的技术细节,并提供了可行的措施建议。

攻击者控制CloudTrail SourceIP

通过控制他们的源 IP 地址,攻击者可以隐藏起来,从而可能绕过完全依赖于 AWS CloudTrail 的安全措施。

因此,通过使恶意行为看起来好像是由合法对象执行的,这就可以使恶意行为看起来是无害的,并且很难检测攻击痕迹并将入侵归因于特定的来源。

如果你的安全工具仅依赖 AWS CloudTrail 日志中的 sourceIP 字段,缓解措施如下。

技术分析

为了成功执行这种技术,攻击者需要从受害者账户获得合法 AWS 凭证的访问权限,然后创建 VPC 终端,该功能允许你的 VPC 中的 EC2 实例和 AWS 服务在他们自己的账户内进行直接通信。创建一个IP范围的VPC,当他们使用被破坏的凭证时,可以混淆他们的流量。以下是我们需要描述的关键功能,以解释如何使用该技术:

CloudTrail 日志有一个“sourceIPAddress”字段。该字段包含攻击者的 IP 地址,在大多数情况下是公共 IPv4 地址。

但是,如果攻击者在AWS VPC内通过VPC的终端发出AWS API请求,则CloudTrail日志中登录的IP地址就是VPC中“内部”EC2的IP地址,即攻击者能够控制的IP地址。

用户可以在VPC内设置任意IPv4地址范围,包括rfc1918地址范围和可对外路由的IP地址范围。可公开路由的IP块只能通过虚拟专用网关访问,不能通过Internet网关访问。这允许攻击者创建一个IP寻址方案,模仿受害者自己的网络或信誉良好的外部服务。

另一个重要的事实是,登录到CloudTrail中的userAgent字段显示了攻击者的userAgent字符串,它完全由进行API调用的攻击者控制。然而,这并不是该技术的直接组成部分,当使用它时,它可以帮助进一步使模拟过程看起来合法。

在私有 AWS 账户(攻击者账户“A”)中创建了一个带有我们选择的私有 IP CIDR 块 (12.34.56.0/24) 的 VPC。

然后,我们在这个 VPC 中创建了一个 EC2 实例,并选择了它的私有 IPv4 地址为 12.34.56.78。

 

带有“外部”私有IPv4地址的攻击者设备

我们在受害者的帐户(“B”)中生成了 API 凭据,作为在使用该技术之前被攻击者破坏的凭据。

然后,我们在攻击者 EC2 实例上的 ~/.aws/credentials 文件中配置了这些“被盗”凭证,以便从攻击者控制的账户 A 中的实例发出的 AWS CLI 调用将使用它们。

接下来,我们在攻击者帐户中为我们打算进行 API 调用的服务创建了 VPC 终端。

我们从可以创建VPC终端的125个AWS服务中选择了44个最重要服务的子集,并且为每个服务选择了一个不需要任何特定参数的API调用。

为了验证该技术,我们进行了测试。为了进行比较,我们首先从 EC2 实例对服务执行 API 调用,而不是通过 VPC 终端进行隧道传输。这些调用以实例的公共 IP 地址作为源 IP 显示在 CloudTrail 日志中。

在下一步中,我们为上述服务创建了 VPC 终端节点,并在每个服务中重新运行 AWS CLI 命令,这次是通过 VPC 终端节点。

测试成功,在 CloudTrail 日志中显示了攻击者选择的“内部”IP 地址作为源 IP。

攻击者可以出于许多不同的目的混淆他们的 IP 地址,以下是一些示例:

1.“组织”公共 IP 地址:如果攻击者收集有关受害组织的公共 Internet 基础设施的信息,则攻击者可以使用与其公共基础设施的某些部分相对应的公共 IP。比如公司的外部 VPN IP 地址。

2.员工“家庭”外部 IP 地址:如果攻击者获得有关员工在离开办公室时使用的外部 IP 地址的情报,他们可以选择该 IP,从而错误地将任何调查指向“无辜”员工。比如云 IT 管理员的家庭 IP 地址。

3.第三方服务提供商的公共IP地址:攻击者可以在 AWS 客户环境中使用属于第三方服务提供商的已知公共 IP 地址,从而增加逃避威胁情报和信誉服务的机会。由于有时这些 IP 可能被 AWS 客户列入白名单,攻击者甚至可以执行更大量的敏感 API 调用。

示例 1:使用属于企业云安全产品的 IP 地址(最好是受害组织使用的 IP 地址)。

示例 2:使用 198.20.69.74,流行的互联网扫描 Shodan 从中扫描整个互联网。

4.一个特殊的私有、保留、测试或仅用于文档的 IPv4 子网块:有 4-5 个子网被定义为用于临时目的的“保留 IP”,使用其中一个还可以帮助规避信誉服务,完整列表可在此处获得。

示例:使用 TEST-NET 子网中的 IP 地址(192.0.2.0/24、198.51.100.0/24 或 203.0.113.0/24)。

哪些 AWS 服务支持 VPC 终端节点访问

此技术只能用于对可以为其创建 VPC 终端节点的 AWS 服务进行 API 调用。但是,截至 2021 年 5 月,可以为 125 种不同的 AWS 服务创建 VPC 终端节点,包括大多数著名的 AWS 服务(例如 EC2、S3、Lambda、STS、DynamoDB、Secrets Manager 等),唯一重要的例外是我们已经看到是 IAM。

此外,AWS 正在不断扩展 VPC 终端支持的服务列表。可以在 AWS 门户中查看受支持服务的完整列表。

需要注意的是:

1.该技术不会影响攻击者在使用受害者已泄露的 AWS API 凭证时拥有的实际 IAM 权限,他们只能进行被盗凭证具有 IAM 权限的 API 调用。

2.使用此技术时,攻击者控制的源 IP 是在 AWS 管理控制台中查看 CloudTrail 服务中的 CloudTrail 事件历史记录以及 CloudTrail 以 JSON 文件写入 S3 的事件中记录的源 IP。

3.仅根据记录的 IP 无法将攻击者识别为组织外部的攻击者,也无法确定其真实来源。但是,可以确定所涉及的 VPC 不属于该组织。

这可以用于绕过基于 IP 的 IAM 策略吗

我们测试了是否可以使用此技术绕过基于 IAM 源 IP 的策略(使用 aws:SourceIp 密钥)。该测试假设,在某些情况下,组织配置此类策略,只允许来自特定子网的某些敏感 AWS 操作。

在这种假设下,我们测试了在这种情况下,如果攻击者使用相应的“内部”IPv4 CIDR 块创建 VPC 并使用 VPC 终端,他们是否可以成功调用敏感的 AWS API,从而“绕过”此类策略。

我们发现(详情点这里https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceip)当 API 调用通过 VPC 终端完成时,aws:SourceIp 密钥不可用(相反,aws:VpcSourceIp 可用),因此该技术不能用于绕过此类 IAM 策略。

如何在你的运行环境中检测此类活动:

通常,当 AWS API 调用通过 VPC 终端节点完成时,可选的 vpcEndpointID CloudTrail 字段会被填充(使用 VPC 终端节点的 ID),与所有其他调用不同,这些调用不填充该字段。这是该技术在日志中唯一的残留用法。

鉴于此,我们的第一个建议是查看 vpcEndpointID 字段。

检测使用不在你在 VPC 中使用的任何私有 IP 范围内的 IP 地址的攻击者相对容易,这可以通过查找通过 VPC 终端节点(带有填充的 vpcEndpointId 字段)和不在你的 VPC 中使用的私有 IP 范围内的源 IP 地址执行的任何 AWS API 调用来完成。

SQL 检测查询示例

但是,检测攻击者使用的IP地址在你的任何vpc中都是有效的私有IP地址,这是非常困难的。这是因为当你在环境中使用VPC终端时,攻击者的合法行为和攻击者的行为产生的日志唯一的区别就是记录的特定 VPC 终端节点 ID。我们建议使用更多基于异常的检测逻辑来解决这个用例,检测组织中从未见过的新 VPC 终端节点 ID 的使用情况

最后,我们建议 AWS CloudTrail 用户将他们的云事件与终端、本地、电子邮件、身份等上的其他传感器进行交叉引用。跨攻击面的综合自动检测是发现被忽略威胁的最有效方法。

本文翻译自:https://www.hunters.ai/blog/hunters-research-detecting-obfuscated-attacker-ip-in-aws如若转载,请注明原文地址。

 

责任编辑:姜华 来源: 嘶吼网
相关推荐

2021-04-29 09:36:23

攻击漏洞Kubernetes

2021-04-10 10:33:00

黑客TCPIP

2021-10-09 14:07:03

iPhone漏洞攻击

2020-12-23 10:52:25

网络安全漏洞5G

2022-02-13 23:12:34

网络钓鱼谷歌Google

2022-07-09 16:34:42

网络攻击恶意软件

2011-08-30 09:39:10

2021-05-26 05:41:42

攻击隐藏踪迹网络安全

2016-01-05 15:54:32

2021-11-04 05:48:43

SSL加密攻击勒索软件

2022-03-05 12:00:11

网络钓鱼网络攻击

2022-01-07 07:51:58

Log4j漏洞攻击微软

2011-05-16 09:19:51

2020-12-30 09:27:55

漏洞DDoS攻击网络攻击

2014-08-20 09:44:57

2010-07-07 09:38:27

2021-11-03 12:49:25

验证码网络钓鱼恶意软件

2022-01-04 11:58:49

Docker API网络攻击文件加密

2023-04-21 19:01:55

2021-11-11 12:03:37

勒索软件攻击漏洞
点赞
收藏

51CTO技术栈公众号