我如何入侵一个托管服务提供商



最近,我开始收到一项建议,以检查各种服务的操作是否存在错误和漏洞。 在这样的建议中,我尝试为结果而努力,并从过程中获得最大的乐趣。 但是最后一个“项目”的结果至少使我震惊。

我被要求测试托管服务提供商。

我不会透露名字。 在我的故事中,我将使用Hoster这个名字。 对于网站本身,托管服务完全是标准的。 提供购买VDS,域,SSL证书的报价。

首先,我对用户的个人帐户的实施方式感到惊讶。 注册期间不需要电子邮件地址的所有权证明。 也就是说,您可以使用电子邮件地址steve.jobs@apple.com进行注册。 或更好的是,support @ hoster.com。

但是幸运的是,通过类似这个故事 ,没有发生服务支持台敏感信息的泄露。

但是,当我创建测试支持请求并立即检查其他支持请求的相邻ID请求的可用性时,确实发生了这种情况。 令人惊讶的是它们可用。 并且可以观察谁和什么向托管人注册。 用户会面对什么问题? 通常,标准IDOR漏洞现在不会使任何人感到惊讶。 当然,她立即得到纠正。

Storeed XSS也有几个地方。 还有Blind XSS,它向我返回了服务管理员Cookie。 由于有了此XSS,我得以找出管理员界面的位置,并且总的来说,它揭示了很多有趣的信息。

  • 有多少活跃用户。
  • 有多少个域受控制。
  • 部署了多少个VDS。

还有更多...



CSRF令牌存在各种错误,这些错误使代表用户可以在您的帐户中进行许多危险的操作。 如果有CSRF令牌被转移的地方,那么它们就被简单地转移了。 没有人打算在后端检查它们。 根据我的发现,部分功能被完全禁用。 例如,决定将2FA身份验证暂时删除,因为它在实施中并未发生。

在工作过程中,我不仅关注安全问题,还关注实现错误或某些功能的操作中的问题。 我喜欢质量检查无法像这样通过。 结果,我的问题跟踪器达到了数字-22。我发现并修复了这么多问题(非常值得注意)。

结果令人信服。 我已经计划完成这个项目。 但是由于某种原因,我再次想起了在注册过程中缺少电子邮件地址所有者确认的问题。 并且他开始提出这样的情况,在这种情况下,主机和所有者可能会遇到最大的麻烦。 在某个时候,我开始考虑此托管服务的所有者与我认识的同一家公司的其他项目之间的关系。 几分钟后,我用同一公司的另一个项目的电子邮件地址注册了一个帐户(让它为support@example.com)。 然后,我设法将域example.com绑定到我创建的帐户suppot@example.com。 但是我仍然无法控制绑定域的内容。

但是他可以代表example.com服务完美地收发电子邮件。



答复信件的来源尚不清楚。 因为我给自己回了一封这样的测试信。 但是我自己没有得到答案。 响应电子邮件帐户support@example.com的真实所有者,它可能消失了。

然后我决定写这篇文章。

我设法解决了被遗忘的子域。 经典子域接管漏洞。 您可以在此处了解更多信息。

我不知道为什么,但是我尝试将绑定添加到不存在的域。 而我做到了。



子域已成功添加,我可以控制该子域的内容。 并显示了内容。



但这不可能是一样的! 怎么这样?! 毕竟,经典子域接管漏洞仅适用于现有子域。

这种情况绝对不适合我。 就是说,好的,我能够绕过对example.com的态度验证级别,这绝不是我的(可能是由于我的帐户名来自example .com)。 但是如何在不检查A,TXT,CNAME记录中的任何组件的情况下完全添加子域并控制它们呢?

通常我会看到这个-我们会向您添加一个子域,只有您证明自己可以做到。 去并将此哈希ololopyshpyshpyshbdysh123添加到TXT。

但这不在那里。 需要admin.example.com子域吗? 没问题!



好像是子域接管V2漏洞。

由于能够与经过测试的托管服务的所有者快速沟通,因此Pandora开启了此框。

原来是这样。 托管通过CloudFlare进行。 他的工作方式非常狡猾。
我将尝试用简单的词来解释。

粗略地说,我告诉你,来找我,我会接待你的。 将您的域名委托给我。
然后,我认为所有呼叫正确无误地将所有传入呼叫发送到CloudFlare。
并且,如果您信任我的vasya.ru域,并且有一个邻居来,用test.vasya.ru将站点zapilit并也将其交给我进行托管,那么我的服务器(可以访问CloudFlare并已经拥有vasya.ru的权限)就可以添加第三个级别,而不会出现问题为邻居和所有规则制定域,并且毫无疑问。 对于所有DNS,CloudFlare的正确信息已经到来。 CloudFlare相信我。

通常,托管提供商通常会配置其DNS服务。 但是事实证明,他们被骗了,只是将所有内容从一个用户转移到CloudFlare。

因此,我们有一个子域接管god_mode。 没错,这仅适用于托管已经控制的那些地址。 但是,结合先前发现的服务管理面板-这可能对托管人和托管服务客户端都起到了作用。

目前,几乎所有关键漏洞和错误均已修复。 我希望没有人会在读完这个故事后决定这种建筑的乐趣。

PS:欢迎对本文发表评论和建议。 特别感谢Patriot2k的技术咨询! 我也乐意接受有关测试有趣事物的建议。

Source: https://habr.com/ru/post/zh-CN431398/


All Articles