如何找到 AWS 环境下应用程序中易于得手的漏洞？
编译：代码卫士
本文作者介绍如何从AWS环境下的应用程序中找到易于发现的漏洞。如下是全文。
毋庸置疑，云环境已主导当前市场。服务提供商中，AWS 的地位正在上升。我将简要说明如何找到 AWS 环境下应用程序中的“低垂果实”，对安全策略设置和错误配置可能引发的风险稍作解释。此外，我还将列出一些有助于恢复 accesskey 和 secretkey 的某些常见漏洞以及一些利用后程序。不过，由于我并非云专家，这里的内容只是基于我的几次亲身实践。
在AWS环境配置某用户的访问策略过程中，会进行很多操作，例如，EC2 资源很可能会提供450多种操作。这就要求我们在配置过程中尤其小心，因为任何应用不当的规则都可导致访问控制缺陷。例如，如下所示MFA的配置：
从中可发现，每个MFA操作都具有唯一的规则，如禁用设备、启用设备、获取用户数据、为用户列出设备等。然而，对规则的任何不慎删除或增加都可导致严重问题。在上述案例中，如果我们将 Resource 字段的值更改为 *，则可使所有用户控制其它用户的设备和令牌。
这种选项的多样性是很好的解决方案，因为它允许精细配置。然而，在未规划的情况下采取某些措施可带来严重风险。
因此，需要记住的一个要点是，在黑盒分析过程中，我们应当了解可分配给和资源相关的所有规则，并测试自己是否具有该权限。
尽管我们可能会发现，被暴露的 AWS 密钥对（后续将讨论相关方法）对于利用某个特定 EC2 实例几乎毫无用处，但访问策略的颗粒度告诉我们仍然发生很多配置不当的情况，如 S3 桶访问或者甚至是完全控制IAM。
众所周知，每个漏洞都很重要而且都应该得到缓解，然而，在AWS 上通过EC2 起作用的应用程序中，某些漏洞可导致 Secretkey 和 Accesskey 被暴露，而组合所分配的策略，可导致严重的安全后果。在这里不再赘述这些特定的漏洞，不过可将这些信息概括如下:
1、 在 JS 或 Mobile App 中硬编码。开发人员常常会在应用程序的客户端对accesskey和secretkey进行硬编码，或以明文形式或以编码形式进行。这就是为何说仔细分析客户端代码或目标的移动应用非常重要。在名称中搜索带有 “accesskey” 或 “secretkey” 或者 “access” 和后缀 “aws” 的变量。搜索前缀为”AKIA”（IAM 中Access 密钥的前缀）的字符串也很重要。
2、 SSRF。这种漏洞可使攻击者通过服务器提出请求，如果易受攻击的应用程序是一个 EC2 实例，那么就会有元数据API；在元数据中，如果存在与该实例相关联的 IAM 角色，则路径 security-credentials/role-name 中包含可使用的安全凭据。例如，在如下路径中：
http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name}
尽管，API新版本要求认证令牌，但IMDSv1 仍在使用。
3、路径遍历。由于该漏洞可允许读取任意文件，因此可利用它读取如下内容：
环境变量。accesskey和secretkey被用作内存中变量的情况非常常见。如果在 Linux 环境中搜索，就能够读取路径 /proc/self/environ 路径上的文件；
配置文件。在很多应用程序中，该配置文件中包含很多服务的凭据和变量，包括AWS 资源在内（例如，../../.env 或 ../../config/config.inc.php）；
配置 AWS-CLI：通常在使用AWS 资源的应用程序中，开发人员会安装 aws-cli 对功能和权限进行测试。因此尝试阅读 /home 路径中的路径 .aws/credentials 起着重要作用。因为我们不知道用户名，因此AWS 环境中常会测试服务器中是否存在 ec2-user 和 Ubuntu 用户。
老旧文件。开发人员通常会在生产环境中创建开发环境的配置文件副本，末尾是旧名称或保存 backup.zip。需要注意的一个要点是，如果不存在路径遍历漏洞，则记得在外部尝试这些路径。
4、 调试报文。在操纵AWS 环境的操作中，尝试引发错误，根据报文的情况，可能会披露密钥。例如，将文件上传至S3存储桶。
如之前所述，某些漏洞可被用于获取secretkey和accesskey，那问题来了：之后该怎么办？
我已经在利用后进程中列出了一些需要观察的非常有意思的内容。记住，很多规则可适用于一种资源，因此建议检查所有的可能性，不过我列出了开始探索时可找到的一些低垂果实。
1、列出可用的S3存储桶：
我认为，这是利用后进程中最重要的任务，因为存储在S3桶中的权限和数据可能确保攻陷成功。如果够幸运，你甚至可以找到数据库备份。
另外，这一操作有助于开展余下步骤，例如，可以找到 SSH Keys 的备份，之后发现它有权更新安全组的规则，获得访问SSH权限。
因此，我认为这一步很重要，因为它有助于用户实现评估目标或有助于开展其它操作。如下代码展示的是查看S3存储桶的命令：
aws s3 ls BucketName/
2、 SSM
AWS 指出，SSM 是一种能力集合，有助于自动化管理任务如收集系统清单、应用操作系统补丁、自动化创建 AMIs，并大规模配置操作系统和应用程序。
该特性的最佳之处在于，它可通过以权限用户（系统或根）运行命令文档 AWS-RunPowerShellScript 和 AWS-RunShellScript 的实例中远程执行代码。
当资源活跃时就有意思了，因为用户可通过简单方法获取反向 shell。如下案例是可被执行的命令：
aws ssm send-command \
— instance-ids “instance-ID” \
— document-name “AWS-RunShellScript” \
— comment “IP config” \
— parameters commands=ifconfig \
— output text
3、 UserData 属性
UserData 属性可能会加载初始化脚本，之后当实例开始时，脚本将运行。这是在实例中你执行命令的另一种简单方法，并很可能获得特权反向 shell。如果用户有权修改该实例属性，则可插入自身的脚本，它将和实例一起启动：
aws ec2 modify-instance-attribute \
— instance-id=”instance-ID” \
— attribute userData \
— value file://UserData.base64.txt
4、 更新SecurityGroup：
我们可将AWS中的 Security Groups 规则看作是Firewall 的规则。这些规则允许或拒绝向 EC2 实例导入流量或从中导出流量。通常而言，开发人员会拦截不重要的进展流量，如流量SSH或RDP，它和SMB是一样的情况。
比如，你发现了一个密码或找到了SSH密钥的备份，但流量遭拦截。那么更新安全组的权限有助于接触这种流量拦截。同时也可以更新安全组，启用某些端口的进展流量实施密码攻击（暴力攻击、喷射攻击、填充攻击）。
aws ec2 authorize-security-group-ingress \
— group-id SecurityGroup-ID \
— protocol tcp \
— port 22
5、跳出盒子
如本文所述，可应用多种操作。保持开放心态，发现用户规则中应用的任何缺陷很重要。
我们假设你已经恢复了凭据、测试了最重要资源（EC2、S3、RDS） 的所有危险操作但并未成功。机组，需要探索更多的资源，如以员工身份发送邮件，从而获得钓鱼攻击的窗口。
在此之前，我写的是某些利用后技术，但实际上AWS 也有很多资源，而且每种资源都有很多操作。有时候我们必须借助工具自动化枚举。
因此，我们对NCC SecurityGroup 开发的我最喜欢的工具 ScoutSuite 稍作说明。
ScoutSuite 能让我们更轻松地执行自动化任务，它有助于我们：
查看可用RDS；
查看公开分享的截屏数据库；
检测很酷的资源和不同寻常的SES，例如我们可使用ScoutSuite 检查是否启用了SES，因而你可以发送伪造的邮件；
检查安全组及其规则；
发现在单一仪表盘中（在所有区域中）运行的所有 EC2 实例；
探索S3存储桶，并检测是否存在弱点；
检查IAM中的权限
以及其它很多特性
当红队陷入艰难之地，而且也无法找到低垂果实时，我会使用 ScoutSuite 进行枚举，而且总会实现目标。
开源云原生平台 Apache Kafka暴露多家大企业的敏感数据
因服务器配置不当，热门直播平台 Twitch 的125GB 数据和源代码被泄露
微软在 Linux 虚拟机偷偷安装Azure App，后修复严重漏洞但Linux虚拟机难以修复
【BlackHat】黑帽大会上值得关注的安全工具
https://medium.com/stolabs/hunting-for-low-hanging-fruit-in-applications-at-aws-environments-658737dc7983
题图：Pixabay License
本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。