Reusing Cookies
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.
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.
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.
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.
$ dig +short dashboard.example.comexample.geckoboard.com.34.195.20.13934.238.88.6935.169.145.217
When 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.
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.
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.
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.
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.
$ 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.
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.
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.
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.
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.
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.
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”.
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.
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.
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.
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.
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).
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.
- 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.
- 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.
- Stored XSS + Clickjacking
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.
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.
- 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.
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.
Unfortunately after few weeks later and I got the comment below in my Hackerone report.
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.
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.
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.
After filling the Bugcrowd form on Crusade Auditor website I got the email below notifying me about my report.
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.
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.
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!
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.
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.
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 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.
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.
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.
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!
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.
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.
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.
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.
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.
As usual I found the subdomain support.vhx.tv which has a CNAME pointed to 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.
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.
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.
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.
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) .
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.
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.
Basically reusing the same cookie but changing the “Domain” attribute an attacker can access Private Articles from any Help Scout customer.
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.
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”.
Let’s jump directly to the report that I sent following the instructions from here 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.
Accessing these 3 projects from the attacker page the ReadMe Platform will display the messages below.
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”.
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.
After a few emails, escalations and fixes I got only $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.
