通过错误配置的 AWS Cognito 接管 AWS 帐户

VSole2022-07-26 17:05:33

环境背景

  1. 被测应用程序只有一个登录页面,没有公开注册功能
  2. 目标应用程序使用披露应用程序客户端 ID、用户池 ID、身份池 ID 和区域信息的 AWS Cognito JavaScript 开发工具包
  3. AWS cognito 配置错误以允许注册新用户
  4. 注册并登录以获得经过身份验证的身份的 AWS 临时令牌
  5. AWS 令牌可以访问用于提升访问权限的 Lambda 函数

Amazon Cognito

Amazon Cognito 管理用户身份验证和授权 (RBAC)。用户池允许登录和注册功能。身份池(联合身份)允许经过身份验证和未经身份验证的用户使用临时凭证访问 AWS 资源。

简而言之,用户池存储所有用户,身份池使这些用户能够访问 AWS 服务。

下图显示了 AWS Cognito 身份验证和授权流程。用户通过用户池进行身份验证,成功身份验证后,用户池将 3 个 JWT 令牌(ID、Access 和 Refresh)分配给用户。ID JWT 被传递到身份池,以便接收分配给身份提供者角色的临时 AWS 凭证。

攻击过程

在最近的一次渗透测试中,我们偶然发现了一个登录页面。它没有暴露其他与身份验证相关的功能,例如忘记密码或注册页面。

经过进一步调查,我们发现该应用程序使用 AWS Cognito 通过 JavaScript 开发工具包进行身份验证和授权。客户端上的 JavaScript SDK 通过 JavaScript 配置文件公开了 App Client ID、User Pool ID、Identity Pool ID 和区域信息等数据。对于 AWS Cognito 的 JavaScript SDK需要此信息才能访问 Cognito 用户池并验证用户。

Amazon Cognito 具有经过身份验证和未经身份验证的模式来为用户生成 AWS 临时凭证。任何人都可以使用特定的 API 调用获得未经身份验证的访问权限。因此,我们尝试通过使用未经身份验证的身份访问 AWS 凭证,但对未经身份验证的身份的访问被禁用。

此处列出了将 AWS 服务暴露给未经身份验证的身份领域的 一个有趣的案例研究:

我们发现该应用程序通过 AWS Cognito 错误配置无意中暴露了一些功能。使用 AppClientId,我们在 Amazon Cognito 用户池中创建了一个用户。确认电子邮件与确认代码一起发送到指定的电子邮件。

测试后发现:我们可以使用 ConfirmSignUp API 从注册电子邮件中收到的令牌确认用户帐户。

现在,当我们使用新注册的帐户登录应用程序时,应用程序响应错误,“用户不属于任何组”。故该应用需要应用程序内授予的组权限才可以访问。

我们意识到,该应用程序实际上验证了一个新创建的用户并返回了访问令牌,但不允许该用户访问任何页面,因为该用户不属于任何有权访问该应用程序的组。

现在我们已经验证了访问权限和 ID 令牌。这些值可用于为经过身份验证的身份生成临时 AWS 凭证。

现在我们可以使用 AWS 命令行界面 (CLI) 与 AWS 服务进行交互:

使用“aws sts get-caller-identity”命令,可以确定令牌工作正常。

通过利用我们的云服务枚举脚本,可以观察到 AWS 令牌对 AWS Lambda 函数具有完全权限。这使我们能够探索客户端的 AWS Lambda 配置。我们首先查看 Lambda 函数列表:

aws lambda 列表函数

我们发现其中一个 Lambda 函数 (RotateAccessKeys-CIS) 的 IAM 策略过于宽松。

aws iam list-attached-role-policies --role-name IAM-CIS

我们决定修改 Lambda 函数代码 (RotateAccessKeys-CIS),使其按要求工作,但另外执行了一个允许从环境变量读取 AWS 凭证的命令。

我们从突出显示的代码位置下载了 Lambda 函数代码。

aws lambda get-function --function-name RotateAccessKeys-CIS --query 'Code.Location'

下载代码中的“lambda_handler”函数被修改为打印环境变量。

此外,我们创建了一个包含修改后代码的 ZIP 文件,以便它在上传和调用包后执行修改后的 Lambda 函数。

Lambda 函数“RotateAccessKeys-CIS”现已更新。

aws lambda update-function-code --function-name RotateAccessKeys-CIS --zip-file fileb:///root//lambda_function.zip

一旦 Lambda 函数代码按预期更新,我们使用下面提到的命令调用它。此命令调用该函数并在包含 AWS 临时凭证的屏幕上打印日志。

aws lambda invoke --function-name RotateAccessKeys-CIS out --log-type Tail --query 'LogResult' --output text | base64 -d

我们重复了相同的步骤,并确定了一组具有完全 IAM 访问权限的临时凭证。

接下来,我们使用新的 AWS 凭证配置 AWS CLI 以创建新用户“nirahua”,并使用以下命令将名为 AdministratorAccess 的 AWS 托管策略附加到用户。

awslambda
本作品采用《CC 协议》,转载必须注明作者和本文链接
前言 1、这篇文章讲了什么? 文本围绕三个问题 lambda会遇到什么攻击场景 什么情况下,在lambda中读取到的env环境变量密钥可以让我们接管服务器甚至整个账号 什么情况下,可以通过lambda权限去横向到其他的EC2服务器 本文会对这三个问题进行解答,并且进行演示
尽管发现的首个样本危害不大,但已经能够看到攻击者是如何利用云专业知识入侵复杂的云基础设施。
这种新的恶意软件被Cado安全研究人员称为Dennia。
用户池允许登录和注册功能。经过进一步调查,我们发现该应用程序使用 AWS Cognito 通过 JavaScript 开发工具包进行身份验证和授权。任何人都可以使用特定的 API 调用获得未经身份验证的访问权限。因此,我们尝试通过使用未经身份验证的身份访问 AWS 凭证,但对未经身份验证的身份的访问被禁用。故该应用需要应用程序内授予的组权限才可以访问。
来自关于在AWS EC2实例中使用错误配置、公开允许的IAM策略和应用程序安全漏洞getshell并超越攻击面的演讲幻灯片 —来自2019年8月旧金山湾区的OWASP会上演讲。概要该演讲主要涵盖了三个场景,它们是使用渗透测试练习的真实环境案例来搭建的,即可用于练习shell访问和访问EC2实例之外的数据的环境。我们使用此信息来发现其他存储桶,其中一个包含多个 SSH 密钥。
在安全防御端的研究中,或者作为安全防御端研究人员,我们常常都会站在攻击者的角度或攻击向量切入点来思考安全防御问题,这些攻击者一般来说都是来自信任区域之外的威胁行为者。但是,如果攻击者已经成功进入了我们的信任区域,并且想要获取我们的数据,此时该怎么办呢?
他们直接联系AWS API,进一步枚举帐户,进而收集信息和泄露数据。不幸的是,AWS集群角色错误配置,拥有过大的读取权限。本意是允许读取特定的S3存储桶,但权限允许角色读取帐户中的一切,这使攻击者得以进一步了解AWS帐户,包括Lambda。受影响的AWS帐户中有不同的Lambda函数,主要与帐户自动化有关。还有证据表明攻击者执行了盗取的软件。
在过去十年中,数字化转型主要是通过采用云服务来推动的,与传统的本地基础设施相比,这些服务提供了无与伦比的敏捷性并缩短了上市时间。大多数组织都投资于公共和混合云架构以保持竞争力,近 94% 的组织至少使用一种云服务。新冠疫情只是加速了向云转移的计划,因为安全、高优先级和IT团队的规模扩大,以满足远程劳动力对IT资源的需求。
1、Borat RAT:新型远程访问恶意软件 2、攻击者利用3LOSH加密器规避检测 3、FFDroider Stealer:针对社交媒体平台用户的新型窃取恶意软件 4、Denonia:首个公开披露的针对 AWS Lambda 的恶意软件 5、攻击者使用SocGholish和BLISTER释放LockBit有效载荷 6、Colibri Loader使用新技术以保持持久性 7、Shark
VSole
网络安全专家