[Bug bounty | mail.ru] Access to the admin panel of the partner site and data disclosure of 2 million users
Relatively recently, I switched from searching vulnerabilities on random sites to Bug Bounty sites, and for many people this choice seems obvious — in such programs, a researcher in 90% of the cases will receive not only good experience, but also a guaranteed reward for valid vulnerability, while on a random site, you can stumble upon misunderstanding and threats. 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, telephone numbers, home address, etc.) with more than 10 popular online stores in Russia, as well as to enter their accounts without a password.
In order to participate in bug bounty mail.ru on hackerone, 3,000 subdomains were sorted and checked one by one. 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 (40 are now fixed, 5 with “triaged” status).
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 from the functionality of a personal account, this case is also not exception. Authorization on the site occurs via o2.mail.ru Oauth, or by entering the email address. If we take into the account the second method, the authorization wil be like follows: the user enters an email, web app send him a code, he sends it through the form and enters the account. Here the first vulnerability was discovered, — 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 never used because of its insecurity.
- Attacker can make 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 the Google results issue, an attacker can parse them. Sometimes, even when search robot banned in robots.txt, urls can be indexed without content.
After a careful search for 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:10, 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 access 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 2000–2006 y. CMS 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 quite clear that the admin panel was related to mail.ru and orders on the redacted_shop.mail.ru subdomain were trusted to manage a third-party site (the team later said that it was a partner and
redacted_shop.mail.ru was not developed by 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 2,017,271 users. The second vulnerability Blind XSS is 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 download functionality itself, so he would have to limit himself to searching the users by id in the admin panel and parse them with burp intruder.
In addition, a link for autologin was attached to the page of each user in the admin panel. Maybe some readers remember about unsafe autologins in old social networks that were popular in 2007 — spcs.me and others.
As soon as I got access to the admin panel and made a couple of screenshots, I immediately wrote a report on hackerone.
A report with details was sent at 00:20. At about 00:43, Sergey Belov, head of application security at mail.ru, answered me in a report. He asked to stop the post exploitation of my blind xss and immediately exit the admin panel, which I 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 restricted 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 effort 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 for the vulnerability I sent autologin url redacted_shop.mail.ru/?login=hV8oUH, which worked well during the writing of the report. But, later I received a message from the analyst that he could not reproduce the bug, that, apparently, the autologin functionality was disabled by the developers and it was no longer possible to recover the password to the account or enter to the account using the link.
After a couple of months, it was discovered that the autologin functionality was turned on again, I told the developers about it and a few days ago the bug was finally fixed.
- April 12, 00:20:50 — Report sent via HackerOne.
- April 12, 00:43:03 — The first answer.
- April 12, 00:47:15 — Triaged.
- April 26, 19:14:38 — Report marked as “Resolved”.
- June 27, 00:59 — Vulnerability reward paid.
Most of the found bugs are XSS, Open Redirect and CSRF, but the most interesting ones are:
- IDOR in lootdog.io support service https://hackerone.com/reports/328337, which revealed several million tickets.
- I would like to tell you about the Double Authentication Bypass bug on mail.ru, but unfortunately, for 7 months, the vulnerability was never fixed and marked as “Informative”, they are not going to fix it in the near future, so, unfortunaely, this bug will not be here.
I can only say that protection was bypassed by the transition to the mobile version, while in the web version protection was working. And yet, when they fix it, you can see information about it in my twitter.
- Blind XSS on pets.mail.ru in pet name, which allowed to hack the admin panel.
- Stored XSS was found on ****.mail.ru, with the help of which it was possible to de-anonymize any user of mail.ru and get his email in case if 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.
- Blind XSS at kayako.support.my.com/staff/index.php (in-scope support at lootdog.io), which was later marked as “Duplicate”.
6. No Rate limit in the login to account on am.ru. The site has a login functionality using otp, code 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.
7. The disclosure of email addresses of users on page with article on ****mail.ru using pictures @mail.ru”>firstname.lastname@example.org, similar to Isaeva report https://hackerone.com/reports/258318.
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 steal cookies or other data, he will not be able to use them.
- Do not use outdated software in the admin panel.
- Always filter the 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 is no filtering) and so on.
- Often you do not receive logs about successful blind xss attack due to filtering or CSP settings. Bypass 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 filtering on <>, try your luck and perform js injection “; alert (1); //.
P.S: I recommend to subscribe to my twitter to keep abreast of the latest articles.