架构重用
TL;DR: This is a story how I accidentally found a common vulnerability across similar web applications just by reusing cookies on different subdomains from the same web application.
TL; DR：这是一个故事，我只是在重用同一Web应用程序的不同子域上的cookie的情况下，偶然发现了一个跨类似Web应用程序的常见漏洞。
意外 (The accident)
I usually do bug bounty in my free time and for every single target I always try subdomain takeover using a tool called tko-subs. Of course even before running tko-subs I need to enumerate all possible subdomains that I can find and for that I use Amass and SubFinder tools.
我通常会在闲暇时间进行赏金活动，对于每个目标，我总是尝试使用称为tko-subs的工具进行子域接管。 当然，即使在运行tko-subs之前，我也需要枚举我可以找到的所有可能的子域，为此，我使用了Amass和SubFinder工具。
I was playing with a private bug bounty program for a big private company called as Example in this post. For obvious reasons I cannot reveal the name of the company but this is not important in this case.
在本文中，我正在为一家名为Example的大型私营公司使用私有Bug赏金计划。 由于明显的原因，我无法透露公司的名称，但是在这种情况下，这并不重要。
While analyzing possible subdomains for takeover I found a subdomain (dashboard.example.com) not vulnerable to takeover but kind of interesting. There was a CNAME pointed to a third party service called Geckoboard that I’ve never heard before.
在分析可能的子域进行接管时，我发现一个子域(dashboard.example.com)并不容易受到接管，但很有趣。 有一个CNAME指向我从未听说过的第三方服务Geckoboard 。
$ dig +short dashboard.example.comexample.geckoboard.com.34.195.20.13934.238.88.6935.169.145.217When access https://dashboard.example.com it redirects to https://dashboard.example.com/login/ which has a link “Don’t have an account? Start your free trial” pointing to https://www.geckoboard.com/try-geckoboard/. Through this link Geckoboard provides to anyone on the web a free account for 30 days. Why a big private company would have a link under it own domain for a registration page to a third party service? It doesn’t make much sense to me so I decided to investigate more.
访问https://dashboard.example.com时，它将重定向到https://dashboard.example.com/login/，该链接具有“ 没有帐户？ 开始免费试用”，指向https://www.geckoboard.com/try-geckoboard/。 通过此链接， Geckoboard为网络上的任何人提供30天的免费帐户。 大型私人公司为何在其自己的域下具有指向第三方服务的注册页面的链接？ 这对我来说没有多大意义，所以我决定进行更多调查。
In order to research a little bit more I’ve created an trial user with the email mytestemail+example@gmail.com which gave me access to my own dashboards under https://app.geckoboard.com. While checking my dashboards I noticed there was a common cookie called _geckoboard_session under https://app.geckoboard.com and https://dashboard.example.com.
为了进行更多研究，我使用电子邮件mytestemail+example@gmail.com创建了一个试用用户，该用户可以在https://app.geckoboard.com下访问自己的仪表板。 在检查仪表盘时，我注意到在https://app.geckoboard.com和https://dashboard.example.com下有一个名为_geckoboard_session的通用cookie。
By just coping the value of _geckoboard_session cookie from https://app.geckoboard.com to the same cookie under https://dashboard.example.com it gave me admin access to my own account but now under https://dashboard.example.com which means that now I can publish any public dashboard under https://dashboard.example.com. I don’t think reusing cookies like this is something new but I couldn’t find the name of this simple technique. If you know the name please share with me through my twitter @ricardo_iramar or email ricardo.iramar@gmail.com.
通过仅将https://app.geckoboard.com的_geckoboard_session cookie的值对应到https://dashboard.example.com下的同一cookie，就可以让管理员访问我自己的帐户，但现在位于https：// dashboard下。 example.com，这意味着我现在可以在https://dashboard.example.com下发布任何公共仪表板。 我不认为像这样重复使用Cookie并不是什么新鲜事，但我找不到这种简单技术的名称。 如果您知道名字，请通过我的Twitter @ricardo_iramar或通过电子邮件ricardo.iramar@gmail.com与我分享。
There are a lot of possibilities since I have total control of my own account. An attacker could use his own account under https://dashboard.example.com to create a malicious dashboard and perform a phishing attack or host any malicious content which could damage the Example company image.I didn’t research too much but maybe it’s possible to run JavaScript code through a dashboards widget which would be the same as stored XSS.I’ve opened a report on Hackerone and the report was accepted with medium severity (4.9). The report was closed yesterday and I got $300 of reward.
由于我可以完全控制自己的帐户，因此有很多可能性。 攻击者可以使用自己在https://dashboard.example.com上的帐户创建一个恶意仪表板并进行网络钓鱼攻击或托管任何可能破坏Example公司形象的恶意内容。我没有做太多研究，但也许可以通过与存储的XSS相同的仪表板小部件来运行JavaScript代码。我已经打开了有关Hackerone的报告，该报告的严重性为(4.9)。 该报告昨天关闭，我得到了300美元的奖励。
这不是一个错误，这是一个功能！ (It’s not a bug, it’s a feature!)
Since I was able to get one valid Hackerone report I decided to search for other Geckoboard customers with public bug bounty program. To check that I went to my local dataset from Rapid7’s Project Sonar to quickly search all the CNAMEs pointed to *.geckoboard.com.
由于我能够获得一份有效的Hackerone报告，因此我决定搜索具有公共漏洞赏金计划的其他Geckoboard客户。 为了检查我是否从Rapid7的Project Sonar转到本地数据集，以快速搜索指向* .geckoboard.com的所有CNAME。
$ egrep '"type":"cname","value":".*geckoboard.com"}' fdns_cname_2019-08-23-1566518677.json{"timestamp":"1566554318","name":"insights.redacted1.com","type":"cname","value":"redacted2.geckoboard.com"}{"timestamp":"1566581590","name":"redacted3.com","type":"cname","value":"redacted4.geckoboard.com"}Only two? It seems Geckoboard doesn’t have much customers or maybe most of the customers do not use custom domains to host their Geckoboards.
只有两个？ Geckoboard似乎没有太多客户，或者也许大多数客户没有使用自定义域来托管他们的Geckoboards。
Everything was fine so far until I decided to report the security issue to Geckoboard itself. Luckily (or unlucky, perhaps) it was easy to find that Geckoboard has a policy describing how to report a vulnerability.
到目前为止，一切都还不错，直到我决定向Geckoboard本身报告安全问题。 幸运的是(或不幸的是，很容易)发现Geckoboard具有描述如何报告漏洞的策略。
On Oct 8 I’ve sent almost the same content that I described before to security@geckoboard.com and got the nice replay below from Megan.
10月8日，我已经将几乎与我之前介绍的内容相同的内容发送到了security@geckoboard.com，并在下面从梅根那里得到了很好的重放。
In the next day for my surprise I got another email from Megan.
第二天，令我惊讶的是，我收到了梅根的另一封电子邮件。
I agree this is not a critical vulnerability but it’s a security issue for sure. For Geckoboard it was a “function of the system” and by coincidence they were removing such feature.
我同意这不是一个关键漏洞，但可以肯定地它是一个安全问题。 对于Geckoboard来说，这是“ 系统功能 ”，巧合的是，他们正在删除此类功能。
After a lot of discussions with Megan and Matt both from Geckoboard they offered me $100 as a token of thanks. I replied back asking to donate the reward to a non-profit organizations helping poor children. In the end we decided to donate the money to Against Malaria Foundation.
在与来自Geckoboard的Megan和Matt进行了大量讨论之后，他们给了我100美元，以表示感谢 。 我回信要求将奖励捐赠给帮助贫困儿童的非营利组织。 最后，我们决定将这笔钱捐赠给对抗疟疾基金会 。
狩猎 (The Hunting)
Geckoboard is just one example of a shared applications that’s provide custom domain capability. Nowadays a lot of cloud services use the same approach and maybe these applications could have the same or similar issues like Geckoboard.
Geckoboard只是提供自定义域功能的共享应用程序的一个示例。 如今，许多云服务都使用相同的方法，也许这些应用程序可能具有相同或相似的问题，例如Geckoboard。
My curiosity didn’t let me sleep well with this question in my head so I decide to hunt other applications with similar problems and explicit policy for reporting vulnerabilities.
我的好奇心使我无法很好地思考这个问题，因此我决定寻找其他具有类似问题和明确报告漏洞的策略的应用程序。
Since I accidentally found this issue when I was looking for subdomain takeover I though the best place to start was this page https://github.com/EdOverflow/can-i-take-over-xyz. In the EdOverflow words this page is “a list of services and how to claim (sub)domains with dangling DNS records”.
由于我在寻找子域接管时意外发现了此问题，尽管最好的开始之处是此页面https://github.com/EdOverflow/can-i-take-over-xyz 。 用EdOverflow的话来说，该页面是“ 服务列表以及如何使用悬挂的DNS记录声明(子)域 ”。
As expected after checking a few applications I found another cloud service vulnerable to the same technique with some particular and interesting attack vector different from Geckoboard with a higher impact. Unfortunately I cannot reveal the company name since they have a private bug bounty program on Bugcrowd and I don’t want to be banned. Let’s call this company as Crusade Auditor.
不出所料，在检查了几个应用程序之后，我发现另一个云服务易受相同技术的影响，其某些有趣的攻击媒介与Geckoboard不同，影响更大。 不幸的是，我无法透露公司名称，因为他们在Bugcrowd上有一个私人漏洞赏金计划，而且我也不想被禁止。 我们将此公司称为“十字军东征审计员”。
Even before report the issue to Crusade Auditor I decided to check if they have any customer that I could first report the security issue and there was a Crusade Auditor customer under the huge Verizon Media bug bounty program scope on Hackerone plataform. Of course I cannot reveal this customer name either otherwise it’d be really easy for anyone find out who is the real Crusade Auditor company. Let’s call this customer as The Vulnerable Customer.
甚至在向Crusade Auditor报告问题之前，我还是决定检查他们是否有任何客户可以首先报告安全问题，并且在Hackerone平台的Verizon Media错误赏金计划范围内有一个Crusade Auditor客户。 当然，我也不能透露这个客户名称，否则，任何人找出谁才是真正的十字军东征审计员公司，这真的很容易。 我们将此客户称为“弱势客户”。
I wasn’t invited to Crusade Auditor private bug bounty program at the time but they provide a Bugcrowd form in their website to report security issues. Before go to the Bugcrowd form I went to https://hackerone.com/verizonmedia and report the issue under the The Vulnerable Customer domain.
当时我没有受邀参加Crusade Auditor私人漏洞赏金计划，但他们在网站上提供了Bugcrowd表单来报告安全问题。 在转到Bugcrowd表单之前，我去了https://hackerone.com/verizonmedia，并在“弱势客户”域下报告了该问题。
The Vulnerable Customer report on Hackerone was quite easy to handle and I’ll talk about this one first. The Bugcrowd report was a pain and they deserve one specific episode for that.
关于Hackerone的Vulnerable Customer报告很容易处理，我将首先讨论。 Bugcrowd的报告很痛苦，为此，他们值得一集。
Like before dig helped me to identify the The Vulnerable Customer subdomain (news.vulnerablecustomer.com) which is pointing to the common Crusade Auditor subdomain (cname.crusadeauditor.com).
像之前一样， dig帮助我确定了The Vulnerable Customer子域(news.vulnerablecustomer.com)，该子域指向常见的Crusade Auditor子域(cname.crusadeauditor.com)。
In the case of Crusade Auditor application let’s call the reused cookie as ABLoginx9. An attacker can sign up to Crusade Auditor service in order to get a valid ABLoginx9 session cookie for his own account. Under his own account an attacker can change the Domain attribute from ABLoginx9 cookie to news.vulnerablecustomer.com and manage his own account but now under https://news.vulnerablecustomer.com. What is the impact to manage his own account under The Vulnerable Customer subdomain? Let’s check this out.
对于Crusade Auditor应用程序，我们将重用的cookie称为ABLoginx9。 攻击者可以注册Crusade Auditor服务，以获得自己帐户的有效ABLoginx9会话cookie。 攻击者可以使用自己的帐户将Domain属性从ABLoginx9 cookie更改为news.vulnerablecustomer.com并管理自己的帐户，但现在位于https://news.vulnerablecustomer.com之下。 在“弱势客户”子域下管理自己的帐户有什么影响？ 让我们检查一下。
Host any malicious image
托管任何恶意映像
The impact is almost none but an attacker can provide any public image under https://news.vulnerablecustomer.com which can be useful to bypass an access control based on the domain and also helped me with the following attack scenarios that I’ll describe later. Since it can be any image imagine if the attacker upload a big ad from the biggest The Vulnerable Customer competitor.
影响几乎没有，但攻击者可以在https://news.vulnerablecustomer.com下提供任何公共映像，这对于绕过基于域的访问控制很有用，并且还可以帮助我解决以下将要描述的攻击情形后来。 由于可以是任何图像，因此可以想象攻击者是否从最大的“弱势客户”竞争对手上载了大型广告。
Open Redirect
公开重定向
An attacker can create pages under https://news.vulnerablecustomer.com and redirect to another domain with full control. This can be useful to bypass content-security-policy like presented on http://accounts.vulnerablecustomer.com.The open redirect was possible because actually the page is a preview of email web version. For the PoC I’ve create a trial account which requires approval to get access to all Crusade Auditor functionalities. I tried to get an approval for my test account under Crusade Auditor but no lucky. Probably for a valid account an attacker would be able to provide any content under https://news.vulnerablecustomer.com.
攻击者可以在https://news.vulnerablecustomer.com下创建页面，并在完全控制下重定向到另一个域。 这可以绕过http://accounts.vulnerablecustomer.com上显示的内容安全策略。开放重定向是可能的，因为实际上该页面是电子邮件Web版本的预览。 对于PoC，我已经创建了一个试用帐户，该帐户需要获得批准才能使用Crusade Auditor的所有功能。 我试图在Crusade Auditor下获得测试帐户的批准，但并不幸运。 对于有效的帐户，攻击者可能能够在https://news.vulnerablecustomer.com下提供任何内容。
Stored XSS + Clickjacking
存储的XSS +点击劫持
The Crusade Auditor service provide a feature called signup form where any user can create a custom form in order to sign up new users to a list.The signup form has two custom URL fields for Privacy policy URL and Cookie policy URL which is filtered on the client side only. Intercepting and changing the raw HTTP request the custom URL fields are allowing “javascript:alert(document.domain)” as value which means almost the same as Stored XSS under https://news.vulnerablecustomer.com but requires one click of user interaction. An attacker can create a malicious signup form where the links to Privacy policy URL and Cookie policy URL will trigger a JavaScript execution on the victim browser. Unfortunately the page is including the attribute rel=”noopener” inside the a tag restricting this vulnerabilities to IE11 and Edge latest version only.
Crusade Auditor服务提供了一种称为注册表单的功能，任何用户都可以创建自定义表单以将新用户注册到列表。注册表单具有两个自定义URL字段，用于隐私策略URL和Cookie策略URL ，并在仅客户端。 截取并更改原始HTTP请求，自定义URL字段允许使用“ javascript：alert(document.domain) ”作为值，这意味着与https://news.vulnerablecustomer.com下的Stored XSS几乎相同，但需要单击一次用户交互。 攻击者可以创建一个恶意注册表单 ，在该表单中，指向隐私策略URL和Cookie策略URL的链接将触发受害者浏览器上JavaScript执行。 不幸的是，该页面在标签内包含rel =“ noopener”属性，该漏洞仅将此漏洞限制为IE11和Edge。
The same sign up form page is not returning the response header X-Frame-Options so clickjacking is possible making the attacker life easier to combining the XSS with clickjacking.Noticed for this PoC I’ve reused the same form from the next vulnerability that I’ll describe later just for demo propose. An creative attacker could create a totally different page that make sense in a different malicious context.
相同的注册表单页面没有返回响应标头X-Frame-Options，因此可以进行点击劫持，使攻击者的生活更容易将XSS与点击劫持结合起来。对此PoC的说明是，我在下一个漏洞中重用了相同的表单稍后将仅出于演示建议进行描述。 富有创造力的攻击者可以创建一个完全不同的页面，该页面在不同的恶意上下文中有意义。
Phishing + Steal Credentials
网络钓鱼+窃取凭据
I left this one last because I liked it the most.The same signup form described before can be abused by an attacker to steal credentials. Basically signup form is totally customized so instead of using for real signup process the attacker can create signup form faking login page using the name field as password field and receive the credentials by email or in his own Crusade Auditor account. The only downgrade is when typing the password the characters will echo inside the form. Notice the links used from the vulnerability described before (“Click Here!”) can be removed in order to be more realistic.Of course since the form is totally customized a creative attacker can create a lot of different malicious scenarios. Faking login page is just one scenario that I think is interesting.
我留下了最后一个，因为我最喜欢它。攻击者可能会滥用前面所述的注册表单来窃取凭据。 基本上， 注册表单是完全自定义的，因此攻击者可以使用名称字段作为密码字段来创建注册表单伪造登录页面，而不用进行真正的注册过程，并通过电子邮件或自己的Crusade Auditor帐户接收凭据。 唯一的降级是在键入密码时，字符将在表单内回显。 请注意，可以删除之前描述的漏洞中使用的链接(“单击此处！”)，以便更加真实。当然，由于表单是完全自定义的，创造性的攻击者可以创建许多不同的恶意方案。 伪造的登录页面只是我认为有趣的一种情况。
Notice the victim GeoIP location and IP address are also in the email notification. I think other malicious scenarios are possible but for now these are sufficient to prove my point.
请注意，受害人的GeoIP位置和IP地址也在电子邮件通知中。 我认为其他恶意场景也是可能的，但目前这些足以证明我的观点。
Unfortunately after few weeks later and I got the comment below in my Hackerone report.
不幸的是，几周后，我在Hackerone报告中得到了下面的评论。
At least they closed as Informative and I’ve learned a lot during the process. Since the Bugcrowd report about Crusade Auditor service is still open this vulnerability is still exploitable on The Vulnerable Customer.
至少他们关闭了Informative，在此过程中我学到了很多东西。 由于有关Crusade Auditor服务的Bugcrowd报告仍处于打开状态，因此该漏洞仍可在“弱势客户”上利用。
Now let’s go back in time and let me tell you in the next episode of this story how bad was my second time trying to work with Bugcrowd.
现在，让我们回到过去，让我在本故事的下一集中告诉您，我第二次尝试与Bugcrowd合作是多么糟糕。
臭虫在你身上！ (Shame on you Bugcrowd!)
Basically I’ve reported to Bugcrowd the issue on Crusade Auditor service using almost everything that I reported to The Vulnerable Customer since it was exactly the same issue. In this episode I’ll talk about how for the second time I had a really bad experience working with Bugcrowd. If you don’t like gossip I suggest you to jump to the next episode.
基本上，我已经使用几乎我报告给“弱势客户”的所有内容向Bugcrowd报告了有关Crusade Auditor服务的问题，因为这是完全相同的问题。 在本集中，我将第二次谈论如何与Bugcrowd一起工作时经历非常糟糕的经历。 如果您不喜欢八卦，建议您跳到下一集。
After filling the Bugcrowd form on Crusade Auditor website I got the email below notifying me about my report.
在Crusade Auditor网站上填写Bugcrowd表单后，我收到以下电子邮件，以通知我有关我的报告的信息。
Notice the email date was Oct 8 and I was able to claim the submission but I couldn’t see anything under Submissions in my Bugcrowd account.
请注意，电子邮件日期为10月8日，我可以声明提交，但在“提交”下看不到任何内容 在我的Bugcrowd帐户中。
On Oct 29 I decided to contact them since I couldn’t see the report under my Bugcrowd submissions and Wellington from Bugcrowd replied the email below.
10月29日，我决定与他们联系，因为在我的Bugcrowd提交内容中看不到该报告，Bugcrowd的Wellington回复了以下电子邮件。
At this point I was glad because if they were working on the fix so I was assuming my report was valid. After I few days I checked my Bugcrowd account again and I got the worst news in bug bounty, DUPLICATE!
在这一点上，我很高兴，因为如果他们正在研究此修复程序，那么我会认为我的报告是有效的。 几天后，我再次检查了我的Bugcrowd帐户，并得到了错误赏金中最糟糕的消息： DUPLICATE！
By previous experiences the only good side in a duplicated report is to have access to the original report where you can check if it’s a duplicate for sure and possibly learn something new or something you’ve may missed. I decided to ask access to the original report for this reason described above but as you are going to see it seems the Bugcrowd engineer didn’t read my entire report before mark it as duplicate.
根据以前的经验，重复报告中唯一的好处就是可以访问原始报告，在该报告中您可以确定它是否是重复报告，并可以学习到一些新的知识或可能错过的知识。 出于上述原因，我决定要求访问原始报告，但是正如您将要看到的那样，Bugcrowd工程师似乎并没有将我的整个报告标记为重复报告。
The first guy sent me the ID of the original report but I got 404 when I tried to access it. A second guy called San came and commented something not related to my report and asking me a video demonstrating the exploit but not the one that I described in my report.
第一个人向我发送了原始报告的ID，但是当我尝试访问它时得到了404。 第二个叫San的家伙来了，发表了评论，评论与我的报告无关，并问我一个视频，演示了该漏洞利用程序，但没有我在报告中描述的那个。
It was clear that San didn’t read my report entirely so I decided to play his game. I copied and pasted the relevant part from my own report and explained in details again so he could understand what I was reporting.
很明显，San没有完全阅读我的报告，所以我决定玩他的游戏。 我从自己的报告中复制并粘贴了相关部分，并再次进行了详细说明，以便他可以理解我的报告。
San replied back again with another wrong assumption and them the things started to get really bad. At this point I was furious and the only thing that could change my mind it’d be having access to the original report. I replied to San one more time starting the comment with the text below and basically copied and pasted the relevant part of my report again.
San用另一个错误的假设再次回答，结果事情开始变得非常糟糕。 在这一点上我很生气，唯一可以改变主意的事情是可以访问原始报告。 我再三回覆San，开始用下面的文字发表评论，并基本上再次复制并粘贴了报告的相关部分。
In the end of this comment I’ve asked him a simple question: “ Could you please give me access to the original report or can I talk to another security engineer from Bugcrowd?”. I’ll include some part of the following report comments and you are going to understand what happened.
在此评论的最后，我问了他一个简单的问题：“能否请您访问原始报告，或者我可以和Bugcrowd的另一名安全工程师交谈？” 我将在下面的报告注释中包含一些内容，您将了解发生了什么。
San tried to blame me because he were unable to read and understand my report and I was glad that Verizon and Hackerone got the issue at the first time with no questions.
San试图怪我，因为他无法阅读和理解我的报告，我很高兴Verizon和Hackerone毫无疑问地在第一时间解决了这个问题。
The report is still unresolved and I didn’t get access to the original report. There is nothing else to say about it than shame on you Bugcrowd!
该报告仍未解决，我无法访问原始报告。 除了对您的虫口感到羞耻外，没有什么可说的了！
帮助童军，改天换个bug (Help Scout, another day another bug)
After the disaster with Bugcrowd I decided to continue with my hunting to find other vulnerable applications by reusing cookies and it didn’t take much time to find Help Scout.
Bugcrowd灾难发生后，我决定通过重复使用cookie继续寻找其他易受攻击的应用程序，而且并没有花太多时间找到帮助侦查员 。
From their words “Help Scout is the all-in-one platform designed to convert, support, and delight your customers” so this looks like promising. Before report the security issue to Help Scout I first tried to find Help Scout customers that could have a policy to report security vulnerabilities or maybe a bug bounty program.
用他们的话说：“ Help Scout是旨在转换，支持和使客户满意的多功能平台”，因此这看起来很有希望。 在将安全问题报告给Help Scout之前，我首先尝试找到可以制定报告安全漏洞或漏洞奖励计划政策的Help Scout客户。
A quick grep again on my local project sonar dataset to search all the CNAMEs pointed to *.helpscoutdocs.com and it returned a total 3766 subdomains. Help Scout seems to have much brighter future than Geckoboard.
再次对本地项目声纳数据集进行快速grep搜索，以搜索指向* .helpscoutdocs.com的所有CNAME，它返回了总共3766个子域。 帮助Scout似乎比Geckoboard的前途光明。
From those 3766 subdomains I was able to find a lot of companies with a properly channel to report vulnerabilities and I’ve reported to some of them. Just to have an idea through this security issue I was able to get credentials, sensitive documents, internal diagrams, process documentation, etc.
从这3766个子域中，我能够找到许多具有适当渠道来报告漏洞的公司，并且我已经向其中一些报告了漏洞。 为了对这个安全问题有一个了解，我能够获取凭据，敏感文档，内部图，流程文档等。
Only one of these companies has a open Hackerone program but unfortunately there was almost no impact so decided to report it directly to Help Scout. Since this issue has already been fixed and it’s an open program I can reveal everything. The company is VHX and you can check their BBP here https://hackerone.com/vhx. Let’s take a look how I confirmed that Help Scout service was vulnerable through VHX using the same technique described before.
这些公司中只有一个拥有开放的Hackerone程序，但不幸的是几乎没有影响，因此决定直接向Help Scout报告。 由于此问题已得到解决，并且是一个开放程序，因此我可以透露所有内容。 该公司是VHX，您可以在https://hackerone.com/vhx上查看其BBP。 让我们看一下我如何使用前面所述的相同技术，通过VHX确认Help Scout服务容易受到攻击。
As usual I found the subdomain support.vhx.tv which has a CNAME pointed to vhxsupport.helpscoutdocs.com.
像往常一样，我发现子域support.vhx.tv的CNAME指向vhxsupport.helpscoutdocs.com。
So I created an account (e.g. Test1) for me to see the difference from https://support.vhx.tv and my own trial instance. During some investigation I’ve noticed that my doc site trial instance (e.g. test1.helpscoutdocs.com) has the same cookies (PLAY_SESSION and hs.login.link) as support.vhx.tv.
因此，我为我创建了一个帐户(例如Test1)以查看与https://support.vhx.tv和我自己的试用实例的区别。 在进行一些调查时，我注意到我的文档站点试用实例(例如test1.helpscoutdocs.com )具有与support.vhx.tv相同的cookie(PLAY_SESSION和hs.login.link)。
In order to test if the write protections was implemented on https://support.vhx.tv I’ve changed the “Domain” attribute from my instance to support.vhx.tv. After changing the “Domain” attribute I’ve noticed now I can see the “Edit this Article” and the HTML source code was leaking the URL https://secure.helpscout.net/docs/5307a75ae4b0479ea072e554/article/54f63981e4b034c37ea934c2 which contains the internal ID of the document.
为了测试是否在https://support.vhx.tv上实现了写保护，我将实例的“ Domain ”属性更改为support.vhx.tv 。 更改“ 域 ”属性后，我现在注意到了，我可以看到“ 编辑本文 ”，并且HTML源代码泄漏了URL https://secure.helpscout.net/docs/5307a75ae4b0479ea072e554/article/54f63981e4b034c37ea934c2文件的内部ID。
So I clicked on the “Edit this Article” button but I got a redirection to https://secure.helpscout.net/ooops/ with an error below which make sense since I don’t have access to this document.
因此，我单击了“ 编辑本文 ”按钮，但重定向到https://secure.helpscout.net/ooops/ ，但由于我无权访问此文档，因此出现以下错误。
I didn’t report this problem to the bug bounty program because there is almost no impact on that URL (https://secure.helpscout.net/docs/5307a75ae4b0479ea072e554/article/54f63981e4b034c37ea934c2) so I decided to do more investigation.
我没有向漏洞赏金计划报告此问题，因为对该URL几乎没有影响( https://secure.helpscout.net/docs/5307a75ae4b0479ea072e554/article/54f63981e4b034c37ea934c2 )，所以我决定进行更多调查。
By reading the Help Scout documentation I saw that Doc Sites and Collections can be Public or Private so I created another account (e.g. Test2) with only one private Doc Site and Collection (e.g. test2.helpscoutdocs.com) .
通过阅读Help Scout文档，我看到文档站点和集合可以是公共的也可以是私有的，因此我创建了另一个仅具有一个私有文档站点和集合的帐户(例如Test2)(例如test2.helpscoutdocs.com )。
Logged as Test1 account in another browser instance I tried to access the the Doc Site from my Test2 account and got the error below which make sense since I don’t have access.
在另一个浏览器实例中作为Test1帐户登录时，我尝试从Test2帐户访问Doc Site，但由于我没有访问权限，因此出现下面的错误是有意义的。
I’ve replaced the “Domain” attribute from the “PLAY_SESSION” cookie from “test1.helpscoutdocs.com” to “test2.helpscoutdocs.com” and after that I was able to access the Test2 account Private Article logged as Test1 account.
我已经将“ PLAY_SESSION” cookie中的“ 域”属性从“ test1.helpscoutdocs.com” 替换为“ test2.helpscoutdocs.com ”，之后，我可以访问以Test1帐户登录的Test2帐户“私有商品”。
Basically reusing the same cookie but changing the “Domain” attribute an attacker can access Private Articles from any Help Scout customer.
基本上重复使用相同的cookie，但更改“ Domain ”属性，攻击者可以从任何Help Scout客户访问私有文章。
This report was sent on Oct 7th. After talked to five different people finally someone got the problem and on Oct 30th Help Scout sent the notification below to their customers.
该报告已于10月7日发送。 与五个不同的人交谈之后，终于有人遇到了问题，Help Scout在10月30日将下面的通知发送给他们的客户。
I didn’t get any reward but it worth for the learning.
我没有得到任何奖励，但是值得学习。
自述文件，最后一个 (ReadMe, the last one)
As you can see from this episode title I’ve continued with my hunt and found another service vulnerable called ReadMe. That’s how they describe their own solution: “ ReadMe gives teams the tools they need to create and manage beautiful documentation with ease, monitor their APIs, and connect with their users in more personal ways”.
从本集标题中您可以看到，我继续进行搜寻，发现另一个名为ReadMe的服务漏洞。 他们就是这样描述他们自己的解决方案的：“自述文件为团队提供了他们轻松创建和管理精美文档，监视其API以及以更加个性化的方式与用户联系所需的工具”。
Let’s jump directly to the report that I sent following the instructions from here https://docs.readme.com/docs/bug-bounty-program.
让我们直接跳转到我按照此处https://docs.readme.com/docs/bug-bounty-program中的说明发送的报告。
ReadMe platform incorrectly restricts access to an Internal Documentation (Project Members Only and Site-wide Password) and Not Yet Active published projects from an unauthorized user. An attacker can Sign Up under https://readme.com in order to get a valid trial documentation page (e.g. https://any-attacker.readme.io) and target an specific company or maybe search by subdomains under readme.io. In my PoC I’ve created another account under https://readme.com with 3 projects (Not Yet Active, Project Members Only and Password Protected) as a victim.
自述文件平台错误地限制了未经授权的用户对内部文档(仅限项目成员和站点范围的密码)和尚未发布的项目的访问。 攻击者可以在https://readme.com下注册以获得有效的试用文档页面(例如https://any-attacker.readme.io )并定位特定的公司，或者可以按readme.io下的子域进行搜索 。 在我的PoC中，我已经在https://readme.com下创建了另一个帐户，并以3个项目(尚未激活，仅项目成员和受密码保护)作为受害者。
Accessing these 3 projects from the attacker page the ReadMe Platform will display the messages below.
从攻击者页面访问这3个项目，ReadMe Platform将显示以下消息。
From his own ReadMe page (https://any-attacker.readme.io) the attacker can change his own connect.sid cookie domain attribute from “any-attacker.readme.io” to the target page “not-yet-active.readme.io”. After that the attacker access the page “https://not-yet-active.readme.io” without any restrictions. The same attack can be performed on “https://project-members-only.readme.io” and “https://password-protected.readme.io”.
攻击者可以从自己的R eMeMe页面(https://any-attacker.readme.io)将其自己的connect.sid cookie域属性从“ any-attacker.readme.io ”更改为目标页面“ not-yet- active.readme.io ”。 之后，攻击者可以不受任何限制地访问页面“ https://not-yet-active.readme.io ”。 可以在“ https://project-members-only.readme.io ”和“ https://password-protected.readme.io ”上执行相同的攻击。
This is actually a design flaw instead of application vulnerability. From the attacker perspective the ReadMe platform doesn’t seems to be a multi-tenant solution but just one single big application and each customer an single user. The attacker can also change documentation and add questions. It seems the attacker has exactly the same rights from his own pages.
这实际上是设计缺陷，而不是应用程序漏洞。 从攻击者的角度看，ReadMe平台似乎不是一个多租户解决方案，而只是一个大型应用程序，每个客户一个用户。 攻击者还可以更改文档并添加问题。 看来攻击者在他自己的页面上拥有完全相同的权利。
After a few emails, escalations and fixes I got only $250.
经过几封电子邮件，升级和修复，我只得到了250美元。
最后一集 (The Final Episode)
I didn’t get much bounties but it was cool to work in this research. I’ve learned something new and noticed most of the companies even with a policy are not really prepared to receive a vulnerability report. Probably that’s why companies that provide vulnerability coordination and bug bounty platform services are increasing a lot in the last few years.
我没有得到太多的赏金，但是从事这项研究很酷。 我学到了一些新知识，并且注意到即使有政策，大多数公司也并没有真正准备好接收漏洞报告。 也许这就是为什么提供漏洞协调和错误赏金平台服务的公司在最近几年中增长很多的原因。
I didn’t try to find more applications vulnerable to this same technique but I’m confident there are more out there.
我没有尝试找到更多易受此技术影响的应用程序，但我相信还有更多的应用程序。
If you have any question or know the name of this technique please send me an email ricardo.iramar@gmail.com or twitter @ricardo_iramar.
如果您有任何疑问或知道此技术的名称，请给我发送电子邮件ricardo.iramar@gmail.com或twitter @ricardo_iramar 。
翻译自: https://medium.com/@ricardoiramar/reusing-cookies-23ed4691122b
架构重用
700
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
