Operation cookie-based XSS | $ 2300 Bug Bounty story

Already for quite a long time I have been hunting for vulnerabilities on the HackerOne platform, allocating a certain amount of time outside the main work to check out my favorite and new programs. Countless times I had to stumble upon a cookie-based XSS vulnerability, which will become the main character of this article. This type of vulnerability occurs when the value of the cookie parameter is reflected on the page. By default, they are considered self-XSS if we, in turn, do not prove their danger. Actually, today I will tell you how to exploit cookie-based XSS vulnerabilities, and also give an example from testing a single company, from which I received $ 7,300 in general for research.

In order to execute javascript on the user's side, you need to find a way to set a cookie and, if necessary, lure the victim to a page where, in turn, the cookie is embedded. Possible ways to exploit this bug:
')
⠀ 1. CRLF injection. This vulnerability occurs when there is no proper checking and blocking of newline characters. We can inject a Set-cookie header in response with the desired name, as well as the value of the cookie and set it in the browser. Real life example: Slippery CRLF injection on twitter.com domain in redirect, - https://twitter.com/login?redirect_after_login=/jjjkkk 嘍 嘍 Set-Cookie: jjjjj = a; domain = twitter.com



You can read reports about this type of vulnerability on HackerOne hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=crlf%20injection

2. XSS vulnerability on the subdomain. It is necessary that XSS is publicly available and located on wildcard * .vulnerabledomain.com. For many bug bounty programs, subdomains are out of scope, that is, in most cases, bugs are either not accepted at all, or are accepted with the label “not eligible for the bounty”. In such cases, you should not retreat, but for the sake of a bunch of cookie-based XSS, you can invest your time searching for XSS to get a reward. If XSS is detected, we can set or remove cookies using the document.cookie function.

Increasing Impact: Often, the victim trusts the main domain vulnerabledomain.com more than, for example, jira.vulnerabledomain.com, and even with the URL /plugins/servlet/oauth/users/icon-uri?consumerUri=https://maliciousdomain.com . It is more likely that it will go to the main domain, rather than a subdomain, if this subdomain is not associated with a personal account or authorization. Based on the above, we can use in-site redirect functionality to redirect to the subdomain of vulnerabledomain.com/login?redirectUrl=https : //jira.vulnerabledomain.com/path for the best effect.

If the victim has an active session, the redirect will be automatic; if not, authorization is needed. When the user clicks on such a link, the cookie will be installed and from the subdomain, on which Reflected XSS is present, it can be sent further downstream - to the cookie-based XSS page, where the exploit can trigger, which, in turn, will capture the CSRF token value and fulfill the request to change the email address. Thus, a combination of two XSS vulnerabilities can lead to account takeover, if there are no associated problems, such as additional confirmation of changing email with a password or a code from an old mailbox.

3. Detection of test files that allow you to set cookies. It is enough to uncover the content discovery tool (dirb, dirserach, etc), start digging, and if the developers forgot to perform the cleanup, you can stumble upon such files.

Recently I discovered a test servlet html page on which it was possible to set a cookie with an arbitrary name and value. Protection on the POST request, of course, was absent, so if the victim would visit the CSRF exploit (or you can change the POST to GET), it would be possible to install a cookie in her browser.



This bug was qualified as an under-alternative to CRLF injection, fixed by removing / examples / and paid $ 150 as for the low-severity bug. Although the h1 triager set medium, the developers still tended to think that it was low severity.



4. Man in the middle attack (MITM). This method can be applied only if there is no secure flag on the cookie. If you don’t know what this flag is or just want to refresh your memory, I advise you to view the “Cookie security” presentation from OWASP London 2017 www.owasp.org/images/a/a0/OWASPLondon20171130_Cookie_Security_Myths_Misconceptions_David_Johansson.pdf .

For a successful attack, it is necessary that the victim be in the attacker's network or the dns resolving can be influenced. In order to check the vulnerability, you must:

1) to file the index.php file with the following contents:

<?php if ($_SERVER['HTTP_HOST'] == 'non-existed-subdomain.vulnerabledomain.com') { setrawcookie("VID",'\'+alert(123123123)+\'', time()+36000, "/", ".vulnerabledomain.com",0,1); } ?> 

2) Add the following line to your / etc / hosts / file: 127.0.0.1 non-existed-subdomain.vulnerabledomain.com

3) Visit non-existed-subdomain.vulnerabledomain.com and then open the page where the cookie will reflect.

A remarkable example of the MITM operation on e.mail.ru, - https://hackerone.com/reports/312548, - as you can see, MITM was enough to prove a slight danger of vulnerability, but the reward did not correspond to the level of Stored XSS, as only “Local” mode of exploitation, that is, not “in-the-wild”. If the researcher had spent some time searching for XSS or CRLF injection (of which there are countless) on * .mail.ru, it would be possible to increase the reward somewhat.

But not all hackerone programs accept cookie-based XSS through MITM. If scope exclusions says “Self XSS”, then this operation can be considered as Self XSS and set to informative or n / a, which is not always pleasant. Now I will talk about a similar case that happened to me during the next hunt on the platform.

While testing the site, I suddenly saw that the value of the redacted cookie is reflected in one of the subdirectories of the site. The first thing I did was check the display of the characters "" / <>. It turned out that only <> characters are filtered, which tells us that we cannot go beyond the limits, but it also becomes clear that the other characters are not filtered Without hesitation we embed '-alert (document.domain) -' and js is executed.

Since the developers did not give the cookie the secure flag, in this case the MITM method works. It was decided to send the report to the program with the following impact:



HackerOne staff (triager) made it clear that this is self-XSS and I should try-harder:



After that, I began to surf the site and try to find CRLF injection or XSS to prove the danger.

⠀ I had to expand the list of subdomains with the help of brute for a large dictionary, scraping subdomains with SSL certificates and with the help of some other tricks. The result was not long in coming, as I run most of the tools with VPS. From time to time other bugs were also found in passing, which I reportable, doing in-scope from out-of-scope, if necessary. There were a lot of Open Redirect and even Improper Access Control bug for $ 5000, but the necessary vulnerabilities for the bundle could not be caught. The above mentioned bug is quite interesting and dangerous, a whole subdomain was taken offline immediately after the report, perhaps in the future I will reveal the report on the page hackerone.com/w2w if the program becomes public.

A week later, the results of the script for detecting content were found, where endpoint / verification was found, which I did not attach much importance to at first, but I still set a script on it - the verification / login subdirectory was found. After the transition, the /verification/login/?redirect_uri=https://vulnerabledomain.com page was shown, which redirected to the redirect_uri value after logging in or immediately redirected if there was a session. After the flight to the intruder, open redirect protection bypass was discovered - vulnerabledomain.com@anotherdomain.com. I tried to unleash the bug before XSS - payload javascript: alert (1) failed, javascript: alert (1) // too. But payload javascript: // https: //vulnerablesite.com/%250A1? Alert (1): 0 shot, because due to the presence of vulnerablesite.com , the parameter passed the white-list validation.



After driving the mouse madly around the alert window (I always do this), I immediately started on my cookie-based XSS. Using javascript: https: //vulnerabledomain.com/%0A1? Document% 2ecookie% 20% 3d% 20% 27SID% 3d137gf6g67f76fg6766123% 5c% 27-alert% 28document% 2edomain% 29-% 5c% 27% 3b% 20expires% 3dFri% 2c% 203% 20Aug% 202019% 2020% 3a47% 3a11% 20UTC% 3b% 20path% 3d% 2f% 3b% 20domain% 3d% 2evulnerabledomain% 2ecom% 3b% 27% 3a0 The cookie successfully sat on * .vulnerabledomain.com . After the transition to the page with the cookie, the coveted alert has taken off! Double XSS, hooray! :) I added a report and waited for an answer.



On the same day, a nice catch arrived from the triger (if you can call it that), and the bounty was paid. God bless the companies that pay on the triage!

For the DOM based XSS, with which I installed the cookie, bounty also flew.

Test results

$ 1000 + $ 1000 + $ 200 (OR) + $ 100 (OR) = $ 2300

This program has been operating for more than a year, but in less than a month I was able to take first place in it and get away with testing quite far, I tried to phase out most endpoints, evaluate their reaction, understand how the site works and even tested the desktop application. This bounty bug has become one of HackerOne’s favorite programs. I hope you will find the same one too! :)



Also, it was this program that gave me a new boost (mail.ru is the first), - with the help of it, I got to 2500 reputation (hello hoodie) and got 36th place in the leaderboard for reputation in 90 days, which should be given by fresh bars . Although it seems that private snaps come regardless of their presence in the leaderboard, I often cancel old ones and wait for new ones in the queue.

Brief brief

• Cookie-based XSS is fully exploitable. If you try and dig a little deeper, you can get a bounty instead of n / a, signal destruction and -5 reputation.
• If the program is old, it does not mean that there will be no vulnerabilities in it. If the fruit hangs on a tree for a long time, low-hanging fruit will be picked and immediately taken home (subdomain takeovers, etc.). Other fruits continue to hang, but higher. In order to get them, you need to make some effort.
• Sometimes it is better to focus on one program for a long time, find as many vulnerabilities as possible and monitor it. It is better to find the program that you prefer and break it.
• Perseverance and the desire to understand how a web application works, as well as certain functionalities and their interaction with each other, is the key to successfully finding vulnerabilities in a bounty bug.

If you want to keep abreast of my latest articles and news, I advise you to subscribe to the telegram channel / twitter, links to which can be found below.