[Bug bounty | mail.ru]Access to the admin panel of the partner site and the disclosure of data of 2 million users

 [Bug bounty | mail.ru]Access to the admin panel of the partner site and the disclosure of data of 2 million users  
Relatively recently, I switched from searching for vulnerabilities on random sites to Bug Bounty sites, and for many such a choice seems obvious - in such programs, a researcher in 90% of cases will receive not only good experience, but also a guaranteed reward for valid vulnerability, while random site can stumble upon misunderstanding and threat. Actually, in order to gain reputation and “acceleration” on the largest Bug Bounty - HackerOne, it was decided to focus on finding vulnerabilities on one of the major bugbounty programs - mail.ru.
This article will deal with several bugs at mail.ru itself, as well as a vulnerability in one of the mail.ru subdomains, which allowed access to the admin panel, and therefore it was possible to view the personal data of 2 million users (such as email addresses, phone numbers, home address, etc.) with more than 10 popular online stores in the CIS, as well as to enter their accounts without a password. bug bounty mail.ru on hackerone , ?000 subdomains were sorted and checked each. A small part of my time was allocated to work with this Bug Bounty and in ~ 3 months I managed to send 45 valid vulnerabilities (3r3321. 40 are now fixed 3r33226., 5 with the status “triaged”).
Some time ago I began to research the subdomain redacted_shop.mail.ru - this is an online store of branded products.
Most often, testing begins with a personal account, this case is also no exception. Authorization on the site is done using o2.mail.ru Oauth, or by entering the email address. If we take into account the second method, then the authorization is as follows: the user enters an email, they send him a code by mail, he sends it through the form and enters the account. was found here. The first vulnerability is Improper Authentication :
The fact is that in addition to the code itself, which needs to be entered into the form, a link is also sent to the input of the form redacted_shop.mail.ru/?login=hV8oUH, when you visit which you are automatically logged into the account. This link is usually called "autologin", this functionality was present in the old WAP sites. Now this way to enter the account is almost not used due to its insecurity.
Impact of this vulnerability:
You can carry out a brute-force attack, find out a lot of identifiers for autologin and enter other people's accounts;
The login link can be indexed by search engines and get into issuing google responses on the site, the attacker can sparse them. Sometimes, even when banned in robots.txt, urls can be indexed without content.
After a careful search of directories (I use the dirb program with a custom dictionary for this), I began to test forms for changing personal data, delivery addresses, etc. CSRF tokens were present in the forms, and attempts to bypass the protection were unsuccessful. There was no XSS and no hints on other vulnerabilities (such a conclusion was made after fuzzing).
Finally, I changed my data and delivery address to js payloads and made a test order of goods, where I entered another js payload in the comment.
At 00:1? I found that my blind xss script was executed in the admin panel of the admin.undefined.com/index site that I don’t know, and I received logs on the server. At that time, there was not even a thought that it would be possible to gain access to the admin panel, since most often cookies are protected by the http only flag.
But, to my surprise, there was no flag and I successfully entered the admin area. The site itself looked like a CMS 2000-2006 with a very old design, poor performance (the pages were loaded for a long time) and a lot of php and sql errors.
After viewing the main page, it became absolutely clear that the admin panel was connected to mail.ru and orders on the redacted_shop.mail.ru subdomain were entrusted to manage a third-party site (later the team reported that it was a partner and redacted_shop.mail.ru developed not mail.ru). In the admin panel it was possible to view, edit and delete orders of all users from 10 online stores (some large ones), as well as view personal data of ?01?271 users. The second vulnerability Blind XSS confirmed.
If an intruder would have access to the admin panel, he could download the database with information about all users with one click, but there was a php error in the functionality itself, so I would have to limit myself to searching the users id in the admin panel and burp intruder.
In addition, a link for autologin was attached to the page of each user in the admin panel. 3r3394. Maybe one of the readers remembers the unsafe autologins in the old Russian social networks that were popular in 2007 — spaces.ru and others. 3r395.
As soon as I got access to the admin panel and made a couple of screenshots, I immediately went to write a report on hackerone.
A report with details was sent at 00:20. Approximately at 00:43 in the report I was answered by the head of information security in the mail.ru company Sergey Belov. He asked to stop the post operation of my blind xss and immediately exit the admin panel, which I naturally did.
The next morning I checked the bug, and since the logs did not come to my server, we can assume that it was fixed. Also, access to the admin panel was closed, this was only replaced by IP access (most likely).
Unfortunately, the redacted_shop.mail.ru subdomain was not in the scope Bug Bounty of the mail.ru program and the vulnerability could not claim to be rewarded. Therefore, in order for the efforts and time spent on vulnerability to be rewarded, I contacted the developers of the admin panel itself and I was paid a reward.
I also sent a report with the first Improper Authentication vulnerability in Bug Bounty, while knowing full well that the bug is difficult to exploit and I will only get reputation points. As a PoC, autologin was sent to the vulnerability redacted_shop.mail.ru/?login=hV8oUH, which worked well during the writing of the report. But, later I received a message from the analyst and that he could not reproduce the bug, that is, apparently, the autologin functionality was disabled by the developers and it was no longer possible to recover the password to the account or enter using the link.
After a couple of months, it was found that the autologin functionality was turned on again. I reported this to the developers and a few days ago the bug was finally fixed.


April 1? 00:20:50 - Report sent via HackerOne.
April 1? 00:43:03 - The first answer.
April 1? 00:47:15 - Triaged.
April 2? 19:14:38 - Report marked as “Resolved”.
June 2? 00:59 - Vulnerability reward paid.
Most of the found bugs are XSS, Open Redirect and CSRF, but I would like to tell you about the most interesting ones separately:
1. IDOR support service lootdog.io https://hackerone.com/reports/328337 who uncovered several million tickets.
2. I would also like to talk about the Double Authentication Bypass bug on mail.ru, but, unfortunately, the vulnerability has not yet been fixed and marked as “Informative”, therefore, alas, it will not be here. I can only say that protection costs by switching to the mobile version while protection is working in the web version. And yet, when they fix it, you can see the information about it on my channel t.me/vulns .
3. Blind XSS on pets.mail.ru in a pet name, which allowed you to hack the admin panel.
4. Stored XSS was found on ****. Mail.ru, with the help of which it was possible to de-anonymize any user of mail.ru and find out his email in case he simply follows the link. It was necessary only to create a page with js.
Due to the fact that the user automatically logs in to ****. Mail.ru and the user's email is automatically substituted in the subscription field, we can find out the email address of any mail.ru user who will follow the link of our consultation. It is possible to see the email address in the html source of the page, as well as in local storage, the value of which will come to our sniffer.
5. Blind XSS on 3r3206. kayako.support.my.com/staff/index.php?/ (in-scope support at lootdog.io), which was later labeled “Duplicate”.
6. No Rate limit in the entrance to your account on am.ru. The site has a login functionality using otp, which came to the phone number, there was no restriction on enumerating the numbers, so the bruteforce attack would help to hack any account knowing only the phone number.
[b] 7. 3r3244. Disclosure of email addresses from articles on ****. Mail.ru with the help of a picture cp-filin.mail.ru/pic?email=*******@mail.ru, similar to report Isaeva.

Conclusions from this article:

NEVER use autologins in authorization.
Close access to the admin panel with error 403 via .htaccess (if you have an apache server), restrict access by IP address, require authentication. Thus, it will be more difficult for an attacker to find vulnerabilities in the admin panel, in addition, if he learns cookies or other data, he will not be able to use them.
Do not use outdated software in the admin panel.
Always filter forbidden["<>'/]characters. in the information that comes into the admin area to avoid XSS.

Tips for security testers[Blind XSS]:

Try to find all the possible places where you can send your script, for example, a complaint to the page /user, site evaluation, logging (try replacing your user agent with a script, it may be in the logs of the admin panel where there is no filtering) and so on.
Often you do not get logs about successful blind xss attack due to filtering or CSP settings. Bypassing the filters in the admin panel by using other scripts (for example meta, img - in many cases these scripts will be enough to prove the vulnerability), and also close tags so that they do not interfere with the execution.
If the admin panel is worth filtering on <>, попробуйте испытать удачу и выполнить js инъекцию "; alert(1);//.
P.S: I recommend to subscribe to my telegram channel on information security, link below or in profile.
+ 0 -

Add comment