Cookie-based XSS Operation | $ 2300 Bug Bounty story

For quite some time now, I have been hunting for vulnerabilities on the HackerOne platform, and have been allocating a certain amount of time outside the main work to check my favorite and new programs. Countless times I came across 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 unless we, in turn, prove their danger. Actually, today I will tell you how to exploit cookie-based XSS vulnerabilities, and I will also give an example from testing one company from which I received $ 7300 in total for the study.

Для того, чтобы выполнить javascript на стороне пользователя, необходимо найти способ установки cookie и, если потребуется, заманить жертву на страницу, где, в свою очередь, внедряется кука. Возможные способы эксплуатации данного бага:

⠀1. CRLF injection. Данная уязвимость возникает, когда отсутствует надлежащая проверка и блокировка символов переноса строки. Мы можем внедрить хедер Set-cookie в ответ с желаемым названием, а также значением куки и установить её в браузере. Пример из реальной жизни: Скользкая CRLF injection на домене twitter.com в редиректе, - https://twitter.com/login?redirect_after_login=/jjjkkk嘊嘍Set-Cookie:jjjjj=a;domain=twitter.com



Репорты о данном типе уязвимости можно почитать на HackerOne hackerone.com/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Apublic&querystring=crlf%20injection

2. XSS subdomain vulnerability. XSS is required to be publicly accessible 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 received with the mark “not eligible for the bounty”. In such cases, you should not back down, but for the sake of connecting with cookie-based XSS, you can invest your time in searching for XSS in order to get a reward. If XSS is detected, we can set or remove the cookie using the document.cookie function.

Impact enhancement: Often, the victim trusts the main domain of 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 switch to the main domain than to the subdomain if this subdomain is not associated with a personal account or authorization. Based on the foregoing, we can use in-site redirect functionality to redirect to the vulnerabledomain.com/login?redirectUrl=https : //jira.vulnerabledomain.com/path subdomain for a better 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 also be installed from the subdomain on which Reflected XSS is present it can be sent further upstream - to the page with cookie-based XSS, where the exploit could work, which, in turn, will capture the CSRF value of the token and complete the request to change the email address. Thus, a combination of two XSS vulnerabilities can lead to an account takeover if there are no associated problems, such as additional confirmation of the change of email password or code from the old mailbox.

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

Recently, I found a test servlet html page on which it was possible to install 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 the cookie in its browser.



This bug was qualified as an under-alternative to CRLF injection, fixed by removing / examples / and paid $ 150 as for a low-severity bug. Although the h1 triager delivered medium, the developers were still inclined to believe that this is 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 kind of flag it is or just want to refresh your memory, I advise you to watch 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 is in the attacker's network or that dns resolution could be affected. In order to check the vulnerability, it is necessary:

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

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 after that open the page on which the cookie is reflected.

A wonderful example of MITM exploitation on e.mail.ru is https://hackerone.com/reports/312548, as you can see, MITM was enough to prove a small danger of vulnerability, but the award did not match the level of Stored XSS, since it was shown only "Local" mode of operation, that is, not "in-the-wild". If the researcher spent a little time searching for XSS or CRLF injection (which are countless) located on * .mail.ru, the reward could be slightly increased.

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

While testing the site, I suddenly saw that the value of redacted cookies 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 the characters <> were filtered, and this tells us that we can not go beyond, but it also becomes clear that the other characters are not filtered . Without thinking twice, we implement '-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 a 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 a large dictionary, scraping subdomains with SSL certificates and using some other tricks. The result was not long in coming, as most of the tools I run with VPS. From time to time, other bugs were also detected along the way, which I reported, making in-scope from out-of-scope, if necessary. I came across many Open Redirects and even an Improper Access Control bug for $ 5000, but I still couldn’t catch the necessary vulnerabilities for the bundle. The above mentioned bug is quite interesting and dangerous, the whole subdomain was taken offline immediately after the report, maybe in the future I will open the report on hackerone.com/w2w, if the program becomes public.

A week later, the results of the script for detecting content were checked, where the endpoint / verification was found, to which I did not attach particular importance at first, but still set the script on it - the / verification / login subdirectory was found. After the transition, the /verification/login/?redirect_uri=https://vulnerabledomain.com page was displayed, which redirected to the redirect_uri value after login or immediately redirected if there was a session. After flying to the intruder, an open redirect protection bypass was discovered - [email protected]. Tried to unwind the bug to XSS - the javascript: alert (1) payload failed, javascript: alert (1) // too. And here is the javascript payload: // https: //vulnerablesite.com/%250A1? Alert (1): 0 shot, because due to the presence of vulnerablesite.com, the parameter passed the white-list validation.



After frantically driving the mouse through the notification window (I always do), I immediately set to work 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 going to the page with the cookie, the treasured alert took off! Double XSS, cheers! :) I supplemented the report and waited for an answer.



On the same day, “Nice catch” flew in from the triadger (if you can call it that), and bounty was paid. God bless the companies that pay on triage!

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

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 go quite a bit with testing - I tried to phase the majority of endpoints and evaluate their reaction , understand how the site works and even tested the desktop application. This bug bounty program has become one of the most beloved on HackerOne. I hope you too someday find the same one! :)



Also, it was this program that gave me a new boost (mail.ru - the first one) - with it I got to 2500 reputation (hello hoodie) and got to 36th place in the leaderboard for reputation in 90 days, which should give fresh inoculations. Although it seems that grafts arrive regardless of presence on the leaderboard, I often cancel old grafts and wait for new ones in line.

Brief brief

• Cookie-based XSS are fully exploitable. If you try and dig a little deeper, you can get a bounty instead of n / a, destroying the signal and -5 reputation.
• If the program is old, this does not mean that there will be no vulnerabilities in it. If the fruits hang on the tree for a long time, the low-hanging fruits will be picked and taken immediately (subdomain takeovers, etc.). Other fruits continue to hang, but higher. In order to get them, you need to make some effort.
• Sometimes it’s 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 a desire to understand how a web application works, as well as certain functionalities and their interaction with each other, is the key to successfully searching for vulnerabilities in a bug bounty.

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.