从用户注册绕过到纵向权限提升接管SaaS平台

admin 2025年1月14日08:37:03评论29 views字数 4510阅读15分2秒阅读模式

 

从用户注册绕过到纵向权限提升

0. 引言

在我进行漏洞挖掘活动时,遇到了一个相当独特的案例——一家使用 SaaS 平台的公司,其业务专注于合作伙伴管理领域。

从总体概览来看,该应用为两种不同的用户群体提供了两个独立的登录页面:

•面向客户的登录页面(https://partner.company.tld),在 HTTP 请求中会重定向到“https://org-entity-name.saas-platform.tld”端点;
•面向为企业提供合作机会的内部员工的登录页面(https://portal.saas-platform.tld)。

1. 合作伙伴页面上的应用类型和通用登录流程

在测试的初始阶段,我们从为合作伙伴提供的页面着手开始测试。
从用户注册绕过到纵向权限提升接管SaaS平台

img
就像一般的登录表单一样,我们遇到了一个包含登录表单和账户创建链接的界面。在这种情况下,测试人员可以考虑以下初步步骤:
在合作伙伴区域执行文件/目录爬取。
尝试在协作工具(如 GitHub、GitLab、Atlassian 产品)和类似平台中查找登录凭据。
尝试猜测默认凭据的可能使用情况(用户名和密码)。
执行常规测试,例如观察随机登录尝试的响应、进行简单的注入测试等类似活动。
尝试注册账号,以更深入地了解目标的功能,从而有助于识别潜在的漏洞。
或者进行其他至少可以帮助测试人员更好理解系统的操作。
从用户注册绕过到纵向权限提升接管SaaS平台

img
不幸的是,我们尝试的方法似乎都没有成功。甚至连注册功能似乎也无法正常工作。
为什么会这样呢?当我们尝试在 partner.company.tld 上注册时(会重定向到 https://org-entityname.saas-platform.tld/api/register 端点),应用显示注册成功(因为出现了注册成功的提示信息,并且提示注册者查看邮件),但实际上我们并未收到任何邮件中的确认链接。
最初我们怀疑可能对免费电子邮件服务(例如 Google、Yahoo、Microsoft 等)存在某种限制,但当我们尝试使用个人邮箱时,结果相同——也没有收到激活链接。
从这里开始,我们尝试使用新创建的凭据登录,希望应用程序可能不需要账户激活。然而,应用程序通知我们账户仍未激活。我们还尝试了重置密码,期望这可能会间接验证我们的账户,但这一方法同样无效。
因此,此时我们的测试步骤停滞不前。随后,我们暂时将测试重点转移到另一个页面,即为员工访问(公司)指定的登录页面。

2. 员工页面(公司)的通用流程

2.1. 检查 portal.saas-platform.tld 的登录流程

注意公司员工的登录页面会将用户引导到 https://portal.saas-platform.tld 子域名。
从用户注册绕过到纵向权限提升接管SaaS平台

img
为了简化和缩短术语,我们将公司的员工登录页面简称为“公司页面”。
在公司页面上,情况并没有变得更好,因为页面带有验证码,并且甚至没有注册链接。虽然我们最终成功绕过了验证码保护,但我们还是优先关注最初测试的流程。
与合作伙伴页面一样,我们在这里也进行了完全相同的测试。
在尝试暴力破解(当然从提交用户名开始)时,我们发现了一个非常有趣的过程,即应用程序会通过以下端点先验证提交的用户名是否已注册:
从用户注册绕过到纵向权限提升接管SaaS平台

img
如果用户名正确,应用程序将继续提交密码。但如果用户名不正确,应用程序仍然会提示输入有效的用户名值。
注意:从技术上讲,这样的流程会导致应用程序在用户名枚举问题上存在隐患。然而,如果我们无法获得已注册用户的列表(尤其是用户使用了非常独特的用户名值),这个问题本身就很难被利用。不管情况如何,风险仍然是风险。

2.2. 通过URL操作进行注册测试

2.2.1. 公司页面概览

有一个非常重要的规则我们需要牢记,那就是:“当某个功能在前端不可用时,这并不意味着该功能‘不存在’。”其含义是,这个端点很可能是“可访问的”,只是该功能没有在前端明显展示出来。
基于这一规则,如果我们尝试通过修改URL(例如:URL操作)来实现我们想要的功能。
在这种情况下,我们的目标是在公司页面测试注册功能,尽管该功能在前端不可见。我们是如何处理这一情况的呢?最简单的方法是“模拟相同开发者创建的其他地方的流程”。为什么这么做?因为开发者或公司在不同产品中的开发风格往往具有一致性。例如,如果产品A使用 /api/register 进行注册,那么在产品B中采用类似方法的可能性很高。
因此,在这一情境下,我们尝试将 /register/ 添加到 user-portal.saas-platform.tld,无论它是否从 /api/ 路径开始。例如:
从用户注册绕过到纵向权限提升接管SaaS平台

img
或者
从用户注册绕过到纵向权限提升接管SaaS平台

img
如果你在想:公司和合作伙伴的登录处理端点难道不是不同的吗?答案是肯定的,它们确实不同——这一点可以通过不同的子域名证明。因此,我们尝试在公司页面上“复制”之前在合作伙伴端点中观察到的注册端点(该端点重定向到 https://org-entity-name.saas-platform.tld/api/register)。
那么结果如何呢?遗憾的是,这次尝试再次未能获得积极的结果。我们收到的信息是“资源未找到”。

2.2.2. 密码重置请求——获取不同端点的“关键”

从用户注册绕过到纵向权限提升接管SaaS平台

img
考虑到我们在登录页面上没有找到太多线索,我们转向了下一个功能,即密码重置功能。在没有凭证访问权限或已注册用户名的情况下,为什么要深入研究密码重置功能?是的,正是在这里发现了一些有趣的事情。
在此功能中,我们发现处理密码重置请求的端点位于一个不同的位置,即:https://admin-portal.saas-platform.tld
从用户注册绕过到纵向权限提升接管SaaS平台

img
从这里开始,我们再次像对待 https://user-portal.saas-platform.tld一样添加了一个路径,即添加“register”路径。令人惊讶的是,系统提示我们提供各种详细信息,包括名字、姓氏、电子邮件和公司名称。
从用户注册绕过到纵向权限提升接管SaaS平台

img
从用户注册绕过到纵向权限提升接管SaaS平台

img
总结一下,以下是一些成功获取的 URL:
从用户注册绕过到纵向权限提升接管SaaS平台

img
2.2.3. 在公司页面注册我们自己的账户
在前面的结果中,可以看出应用程序要求 JSON 数据,内容包括:名字、姓氏、电子邮件和公司名称。因此,我们需要做的就是将这四个参数添加到请求中。
当我们输入所有参数后,立即将请求发送到主机。长话短说,我们的注册尝试成功了。(尽管应用程序拒绝接受使用 Gmail 等电子邮件服务的注册,但我们利用了诸如 fakemailgenerator 这样的免费电子邮件提供商)。
一旦所有必要的数据被提供并传递到主机,主机似乎接受了我们的请求。令人惊讶的是,HTTP 响应中包含了一个激活链接,这引发了对潜在滥用的担忧,例如攻击者可以通过利用公司的域名显得“合法”。不过,这并不是本文关注的重点。
无论我们是使用通过电子邮件获取的激活链接还是 HTTP 响应中获取的激活链接,我们都会立即被重定向到密码创建页面,以便登录 saas-platform.tld 服务。

3. 登录公司仪表板

在填写密码后,我们还被要求填写子域的名称,该子域将在相关实体的合作伙伴页面中执行活动,例如:https://newentity.saas-platform.tld
长话短说,在填写所有必要的详细信息后,我们被重定向到我们自己实体内的员工仪表板页面。记住一个简单的事情,即使这只是我们自己的实体,InshaAllah,我们仍然可以对该员工仪表板中的每个流程有所了解。

4. 寻找用户创建功能

既然我们可以访问员工仪表板(在我们创建的公司内),InshaAllah,我们将能够深入了解应用程序的功能。那么,接下来我们应该采取哪些行动呢?
考虑到我们的目标是确定潜在的入口点,以便通过 saas-platform.tld 控制已发布的公司页面,我们正在积极探索与用户相关的功能。
也许会有另一个问题,为什么是“与用户相关”的功能?因为任何使用 saas-platform.tld 服务的公司主要是在 http://portal.saas-platform.tld子域登录(该子域会重定向到 http://user-portal.saas-platform.tld/api/login*端点)。识别与访问控制漏洞相关的潜在问题,可能使我们能够在不同的实体中生成用户。
在稍微了解了应用程序的流程后,我们最终找到了一个创建用户的功能,该功能位于“设置” -> “用户管理”菜单中。
注:为了使本文更易于阅读,我们在其中包含了一些草图。
从用户注册绕过到纵向权限提升接管SaaS平台

img
在这个菜单中,我们遇到了一项功能,允许创建一个管理员级别的账户,该账户仅限于管理我们自己注册的实体内的内容。另一方面,还有一个选项可以生成员工级别的账户,其访问要求可以根据现有需求进行调整。
长话短说,我们立即创建了一个随机的管理员用户,并发现有一些独特的参数很难预测,即账户和实体的哈希值。以下是请求的示例:
从用户注册绕过到纵向权限提升接管SaaS平台

img
在这里,我们假设,如果我们成功获取这两个哈希值(即实体的ID哈希和账户ID哈希),这可能会允许我们在另一个实体中创建账户。记住,这只是一个可能性。然而,这项测试无疑值得进行。
从这里,我们回到了我们正在测试的实体的主页,即 https://partner.company.tld

5. 寻找实体ID哈希和账户ID哈希

重新访问合作伙伴实体页面的初步步骤是使用浏览器的“查看源代码”功能检查前端源代码。接下来,我们搜索像“-ID”或“account-ID”这样的关键词(基于之前请求中获得的数据)。令人惊讶的是,我们发现了我们正在寻找的两个东西,即账户ID哈希和实体ID哈希。
从用户注册绕过到纵向权限提升接管SaaS平台

img
然而,我们不能轻易下定论,因为不能保证这个执行一定会成功。

6. 将实体和账户哈希ID放入请求中(https://admin-portal.saas-platform.tld/api/user)

此时,获得了这两个哈希ID后,我们重新访问了本报告第4点中详细描述的请求。
总结来说,我们尝试重新发送用户创建请求,修改了特定的参数,即:
用“account_id”值替换请求头中的Account-ID值。
用“entity_id”值替换请求头中的Entity-ID值。
那么结果是什么呢?结果是,主机接受了这个修改后的请求,并视其为有效。
从用户注册绕过到纵向权限提升接管SaaS平台

img
然后我们检查了我们的邮箱,收到了来自我们测试的实体的有效邀请。随后,我们通过提供的激活链接生成了一个密码。
从用户注册绕过到纵向权限提升接管SaaS平台

img
从用户注册绕过到纵向权限提升接管SaaS平台

img
在我们创建了密码后,我们成功控制了目标的合作伙伴仪表板。从本质上讲,使用相同的方法,我们有可能控制所有其他实体的已注册仪表板。

7. 总结

当一个功能在前端不可用时,并不一定意味着该功能不可用。在这个案例中,我们在公司的子域中找到了注册功能,尽管它并不显眼。
开发人员或公司很可能在不同产品之间保持一致的开发风格。在这个案例中,很明显开发人员为两个不同的应用功能使用了相同的端点。
即使应用程序似乎使用了难以猜测的哈希值或UUID,仍然要记住,从应用程序的某个公开可访问的页面中获取这些信息的可能性是存在的。

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

原文始发于微信公众号(白帽子左一):从用户注册绕过到纵向权限提升接管SaaS平台

 

免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉。
  • 左青龙
  • 微信扫一扫
  • weinxin
  • 右白虎
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2025年1月14日08:37:03
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                   从用户注册绕过到纵向权限提升接管SaaS平台http://cn-sec.com/archives/3625083.html
                  免责声明:文章中涉及的程序(方法)可能带有攻击性,仅供安全研究与教学之用,读者将其信息做其他用途,由读者承担全部法律及连带责任,本站不承担任何法律及连带责任;如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截,联系方式见首页),望知悉.

发表评论

匿名网友 填写信息