亚马逊AWS官方博客

Amazon GuardDuty 增强了对 EC2 实例凭证泄露的检测

Amazon GuardDuty 是一项威胁检测服务,可持续监控恶意活动和未经授权的行为,以保护您的 AWS 账户、工作负载和存储在 Amazon Simple Storage Service (Amazon S3) 中的数据。GuardDuty 以大量公共和 AWS 生成的数据源为信息来源,并在机器学习的支持下,分析数十亿个事件,以追踪趋势、模式和异常现象,将其作为可识别的问题迹象。只需单击一下即可启用,几分钟之内便可看到第一批结果。

今天,我们向 GuardDuty 增加了一项功能,可检测您的 Amazon Elastic Compute Cloud (Amazon EC2) 实例凭证何时被另一个 AWS 账户使用。EC2 实例凭证是AWS Identity and Access Management (IAM) 角色附加到实例上时,通过 EC2 元数据服务向实例上运行的任何应用程序提供的临时凭证。

有哪些风险?
当您部署在 EC2 实例上的工作负载访问 AWS 服务时,它们会使用访问密钥、私有访问密钥和会话令牌。向工作负载传递访问密钥证书的安全机制是定义工作负载所需的权限,创建一个或多个具有这些权限的 IAM 策略,将策略附加到 IAM 角色,最后将角色附加到实例。

在附加了角色的 EC2 实例上运行的任何进程都可以通过调用 EC2 元数据服务来检索安全证书:

curl 169.254.169.254/latest/meta-data/iam/security-credentials/role_name
{
  "Code" : "Success",
  "LastUpdated" : "2021-09-05T18:24:45Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "AS...J5",
  "SecretAccessKey" : "r1...9m",
  "Token" : "IQ...z5Q==",
  "Expiration" : "2021-09-06T00:44:06Z"
}

这些凭证在时间和范围上都受到限制。它们的有效期最长为六个小时。它们仅限于附加到与 EC2 实例关联的 IAM 角色的权限范围。

所有 AWS SDK 都能自动检索和续订此类凭证。您的应用程序中不需要额外的代码。

现在想象一下,在 EC2 实例上运行的应用程序遭到破坏,恶意行为者设法访问了实例的元数据服务。恶意行为者将提取凭证。这些证书具有您在附加到实例的 IAM 角色中定义的权限。根据您的应用程序,攻击者可能会从 S3 或 DynamoDB 中泄露数据,启动或终止 EC2 实例,甚至可以创建新的 IAM 用户或角色。

自推出 GuardDuty 以来,它已检测到何时从 AWS 以外的 IP 地址使用此凭证。因此,聪明的攻击者可能会对另一个 AWS 账户隐藏其活动,以便在 GuardDuty 视线之外进行操作。从今天开始,GuardDuty 还将检测何时从 AWS 网络内的其他 AWS 帐户使用凭证。

生成哪些警报?
与 AWS 服务 API 通信的源 IP 地址可能与 EC2 实例 IP 地址不同,这可能是有正当理由的。考虑一下将流量路由到一个或多个 VPC 的复杂网络拓扑;例如 AWS Transit GatewayAWS Direct Connect。此外,多区域配置,或者不使用 AWS Organizations,导致检测使用证书的 AWS 账户是否属于您并非易事。大型公司已经实施了自己的解决方案来检测此类安全漏洞,但是这些类型的解决方案不容易构建和维护。只有少数组织拥有应对这一挑战所需的资源。当这样做时,他们会分散对核心业务的工程工作。因此我们决定解决这个问题。

从今天开始,GuardDuty 在检测到滥用 EC2 实例凭证时会生成警报。当使用来自关联账户的凭证时,警报将被标记为中等严重性。否则,将生成严重性较高的警报。关联账户是由同一 GuardDuty 管理员账户(也称为 GuardDuty 成员账户)监控的账户。他们可能是你组织的一部分,也可能不是。

在实践中
为了了解它是如何工作的,让我们从我的一个 EC2 实例中捕获并泄露一组 EC2 凭证。我使用 SSH 连接到我的一个实例,我使用 curl 来检索凭证,如前所示:

curl 169.254.169.254/latest/meta-data/iam/security-credentials/role_name
{
  "Code" : "Success",
  "LastUpdated" : "2021-09-05T18:24:45Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "AS...J5",
  "SecretAccessKey" : "r1...9m",
  "Token" : "IQ...z5Q==",
  "Expiration" : "2021-09-06T00:44:06Z"
}

实例拥有一个 IAM 角色,该角色具有允许读取此 AWS 账户中 S3 存储桶的权限。我复制并粘贴了凭证。然后,我连接到在不同的 AWS 账户中运行的另一个 EC2 实例,该账户不隶属于同一 GuardDuty 管理员账户。我使用 SSH 连接到另一个实例,然后使用泄露的凭证配置 AWS CLI。我尝试访问私有 S3 存储桶。


# 首先验证我没有访问权限 
[ec2-user@ip-1-1-0-79 ~]$ aws s3 ls s3://my-private-bucket

调用 ListObjectsV2 操作时发生错误 (AccessDenied):访问被拒绝

# 然后我使用泄露的凭证配置 CLI
[ec2-user@ip-1-1-0-79 ~]$ aws configure
AWS Access Key ID [None]: AS...J5
AWS Secret Access Key [None]: r1...9m
Default region name [None]: us-east-1
Default output format [None]:

[ec2-user@ip-1-1-0-79 ~]$ aws configure set aws_session_token IQ...z5Q==

# 最后,我再次尝试访问 S3
[ec2-user@ip-1-1-0-79 ~]$ aws s3 ls s3://my-private-bucket
                     PRE folder1/
                     PRE folder2/
                     PRE folder3/
2021-01-22 16:37:48 6148 .DS_Store

不久之后,我使用 AWS 管理控制台访问我窃取了证书的 AWS 账户中的 GuardDuty。我可以验证是否生成了严重程度较高的警报。

GuardDuty EC2 凭证泄露警报

然后呢?
当攻击者在实例上具有远程代码执行 (RCE)、本地存在或利用 Server Side Request Forgery (SSRF) 和 XML External Entity (XXE) 注入等应用程序级漏洞时,他们可能会提取凭证。有多种方法可以缓解 RCE 或本地访问,包括从安全且已修补的 AMI 重建实例以消除远程访问、轮换访问凭证等。当漏洞位于应用程序级别时,您或应用程序供应商需要修补应用程序代码以消除漏洞。

当您收到提示凭证被泄露风险的警报时,首先要做的是验证账户 ID。它是否是贵公司的账户? 在分析过程中,如果业务案例允许,您可以终止受危害的实例或关闭应用程序。这可防止攻击者在过期时提取已续订的实例凭证。如有疑问,请使用举报亚马逊 AWS 滥用表格或联系 abuse@amazonaws.com,与 AWS 信任与安全团队联系。提交请求时,请提供所有必要的信息,包括可疑的 AWS 账户 ID、明文日志等。

可用性
此新功能在所有 AWS 区域均可使用,无需额外付费。当您的 AWS 账户上已启用 GuardDuty 时,默认情况下会启用此功能。

否则,请立即启用 GuardDuty,然后开始 30 天的试用期。

– seb