Skip to content
KitploitKITPLOIT
工具博客
提交
工具博客
提交

黑客、渗透测试和网络安全工具,武装您的安全武器库!

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新,查找漏洞、分析系统、自动化测试并加强你的安全。

··订阅源·联系·隐私·© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
工具/GitHubGitHub/sarpantkeltiek/cve-2024-37010
密码破解权限提升漏洞分析漏洞利用横向移动Web应用程序漏洞利用数据泄露信息收集
GitHubsarpantkeltiek/cve-2024-37010

CVE-2024-37010

针对CVE-2024-37010的利用程序:访问其他用户的外部存储及横向移动

查看仓库
71年前尚未审核

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
分享

CVE-2024-37010

针对CVE-2024-37010的利用:访问其他用户的外部存储及横向移动:

https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/

https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage

简介

Owncloud 将服务器转变为一个用于存储文件的云服务,类似于 Google Drive。这使得例如公司能够为员工提供云服务,而无需由第三方进行管理。

如果管理员以这种方式配置,用户还可以连接外部存储(例如其他云、FTP 或 Google Drive),将文件集中到单一云上,从而为用户提供便利。

一旦我们创建了外部存储,就可以更新此表单以修改,例如"文件夹名称"字段。当表单更新时,会以 JSON 格式发送整个表单的请求。在此表单中,'ID' 字段(一个整数)是我们外部存储的标识符,由服务器在创建存储时生成。

2. IDOR IDOR

假设 Owncloud 上的另一个用户(例如管理员)也有外部存储,其 ID 为"18"。

现在,让我们以"normal_user"用户身份(无特殊权限)重新发送表单更新请求,但将 ID 改为 18(管理员的外部存储)。

[images/req.png]

  1. 输入管理员存储的 ID
  2. 设置任意存储名称"storage_pwned"。
  3. 为保险起见,我们还指定了一个任意主机,此处为 Burp collaborator。重要提示:更改主机并非强制要求。更改主机会破坏存储配置,Owncloud 服务器将无法再从原始存储中检索文件。

一旦请求发送,服务器会返回 404 错误(4),并告知我们没有找到具有指定 ID 的存储(5)。

然而,当我们登录管理员账户时,看到的是:

[pwned_article.png]

管理员的存储已被更新。

  1. 存储名称已更改为"storage_pwned"。
  2. 主机已被替换为 collaborator 的地址。
  3. 最重要的一点:用户"normal_user"已被添加到授权访问该存储的用户列表中。

如果我们重新以"normal_user"身份登录,可以看到我们现在可以访问"storage_pwned"(管理员的存储)。

[access.png]

用户 A 成功更新了用户 B 的存储并重新获得了对其的访问权限。需要提醒的是,在更新请求中,用户 A 不得修改主机,以免破坏用户 B 的配置,从而能够访问后者的文件。

以下是用于更新外部存储的代码。

[Pasted image 20241016114714.png]

首先,我们可以看到代码没有验证发出请求的用户的权利。代码未检查该存储是否属于发出请求的用户。这就解释了为什么"normal_user"能够更新管理员的存储。

其次,我们可以看到在每次更新时,代码都会将刚刚发出请求的用户添加到授权连接该存储的用户列表中,从而解释了为什么"normal_user"在更新后奇迹般地获得了管理员的存储访问权限。

总结

在本例中,我们看到了一个用户如何获得完全访问另一个用户外部存储的权限,从而访问后者的个人文件。仅凭这一点,这已经是一个相当严重的漏洞。

3. 更进一步……

在这个阶段,如你所见,这种 IDOR(不安全的直接对象引用)本身已是一个重大漏洞。但让我们尝试进一步利用它,以扩大其可能造成的影响。

为此,让我们理解 Owncloud 服务器为检索文件而对外部存储执行的身份验证过程。对于使用简单登录/密码对的基本身份验证系统,云服务器会直接……

[Pasted image 20241017162909.png]

现在,假设攻击者能够通过将主机更改为其控制的地址来更新此配置。这意味着 Owncloud 服务器现在会将凭证发送到这个由攻击者控制的新地址。

[Pasted image 20241017163143.png]

这正是我们通过漏洞可以做到的。

当我们重新发送更新请求并指定另一个用户的存储 ID 时,我们只需更改主机,例如指定我们的 Burp collaborator。

[Pasted image 20241017163326.png]

这样,当用户重新连接时,Owncloud 服务器会尝试向我们的 collaborator 进行身份验证,并发送该用户的凭证。

[Pasted image 20241017163644.png]

神奇的是,collaborator 收到了来自 Owncloud 服务器的身份验证请求,其中包含 Base64 编码的凭证。

[Pasted image 20241017163945.png]

因此,我们刚刚检索了管理员外部存储的明文凭证。

额外收获……

对于外部存储的身份验证,如果使用相同的密码,你可以使用自己的 Owncloud 凭证登录。在请求更新外部存储时,可以在"authMechanism"字段中指定"password::sessioncredentials"。

然后,Owncloud 服务器会在下次连接时以明文保存我们的凭证,并将其传输到我们的外部存储设备进行身份验证。

所以你可以预见到……

这意味着攻击者也可以为其他用户的外部存储激活此机制,从而将受害者 Owncloud 会话的明文凭证传输到其控制的主机,正如我们刚才所做的那样。

4. 风险总结

因此,CVE-2024-37010 允许拥有 Owncloud 服务器帐户的攻击者:

  • 获得读取/写入其他用户外部存储中文件的权限。
  • 获取已连接外部存储设备的明文标识符。
    • 跳转至外部存储。
  • 获取拥有外部存储的用户的未加密 Owncloud 帐户凭证。
    • 帐户接管与权限提升。

时间线

  • 2024年11月3日 - 发现漏洞
  • 2024年12月3日 - 向 Owncloud 提交报告
  • 2024年9月9日 - Owncloud 公开发布公告及 CVE
下载工具