Field
RedTeam
Beginner
Free
Tags
fuff
iam
s3
secrets manager
web
assume role
external id
cloud shell
Status
Done
Huge Logistics, a global force in the logistics and shipping industry, has reached out to your firm for a comprehensive security evaluation spanning both their on-premises and cloud setups. Early reconnaissance pointed out the IP address 52.0.51.234 as part of their digital footprint. Your mission is clear: use this IP as your entry point, navigate laterally through their system, and determine potential areas of impact. This isn't just a test of their defenses, but a test of your skill to find weak spots in a vast network. Time to dive in and uncover what lies beneath!
这次题目就提供了一个 IP：52.0.51.234
看了一下网页源码，好像没啥，扫一下目录
这里发现用 ffuf 也是不错的，针对性更强
访问 config.json
发现 aksk
拉下来看了下，没什么特别的
枚举一下 aksk 权限
有
ListSecrets 权限，看一下一个个获取，会发现，除了
ext/cost-optimization 都失败这个账户密码可以登录 AWS 控制台，IAM ID 是 427648302155
登录进去后，在不知道该用户权限的情况下，一下可能会不知道干嘛，点了下 s3 并没有权限。
通过 CloudShell 获取一个 STS
可以方便查看当前的凭证信息
把相应的信息
aws configure 和 aws configure set aws_session_token "<token>” 一下，然后通过 aws-enumerator 并不能枚举出什么权限
只能手动了
第一个权限应该是 CloudShell 的，第二个我们看看
查看策略
查看
role/ExternalCostOpimizeAccess 角色查看
policy/Payment attach 到这个 policy 的 role查看策略描述
查看最新策略版本详情
估计是为了让该用户获取公司的账单
一个个来 assume
失败了
其实 assume 还有个 externel-id 参数，就是
aws iam get-role --role-name ExternalCostOpimizeAccess 拿到时显示的 Condition配置一下该 STS
这时再来看一开始 secret 列表，发现
billing/hl-default-payment 能看了而且 flag 也在里面！
防御
- 不要把配置文件放在 Web 根目录下，导致所有人可以访问
- 创建策略时，最好是不复用已承担业务功能的 IAM 用户和角色进行测试。应额外创建单独的用户
data-botIAM 用户貌似并不需要访问ext-cost-userIAM 账户，应该禁止data-bot用户 get-secret-value 获取ext-cost-userIAM 账户的账号密码
- 一般 External ID 会是 GUID（全局唯一标识符），不像本题是一个简单的 5位数字
- 在 AD 域中，攻击者可能会通过利用访问控制列表（ACL）的配置错误和不当的组成员分配来在不同对象间横向移动。同样，在云环境中，我们也可以通过利用宽松的策略设置和过度的权限分配，在不同资源间横向移动，以实现我们的目标。
进一步阅读
- https://hackerone.com/reports/1704035 原来 config.json 是 h1 上美国国防部的一个真实漏洞
- https://research.nccgroup.com/2019/12/18/demystifying-aws-assumerole-and-stsexternalid/ external id 使用场景介绍