Unraveling vulnerability on sites

After my first article published on codeby, which entered the top 3 publications of the week, I was very motivated to write the following. But the 11th class imposes restrictions on free time by preparing for the exams and olympiads. Therefore, I write the second only after several months having flown from all the Olympiads .

In this publication, an interesting case will be told, when a vulnerability found on one resource entailed finding them on several other sites along the chain.

Beginning

It all started with checking the site of one major manufacturer of forged products. The user's personal account was not there, and the search area for vulnerabilities was not too extensive.

When testing the order submission form, a number of vulnerabilities were discovered in it.
First of all, this is a fairly standard stored XSS in the buyer's data, from which this tangle stretched. XSS is standard, and the absence of the “httponly” flag on the cookie was clearly not standard. Already many times I received cookies from various sites, but I have never received authorization, and already began to doubt that there are nature sites that do not use the “httponly” flag, because using it significantly reduces the risk of XSS attacks. It was all the more surprising to find such an event on the website of a large company. But, as it turned out, the service that made this misstep was much larger than I expected. But more about that after.
')
I substituted the received cookies and logged into the site system’s crm account (could not resist, for the first time so lucky). The rights were not admin, but they were enough to access any statistics on orders, including and customer data.



Made screenshots to prove the vulnerability and sent a report. More than a week has passed and I have not waited for an answer. According to statistics, if you do not respond within three days, you can forget about them. But after 8 days, an unexpected answer came. And even more, they were the first to pay me for the found vulnerability.



Returning to testing the order submission form, I found another iDOR vulnerability that allows changing the order price by editing the “json_order [0] [price]” and “json_order [0] [total]” parameters in the POST request domain.ru/shop.php . Substituting a link to an order in the same request in the json_order [0] [href] field resulted in RFI.

No response was received to the message about new discoveries ...

Continuation

At that site the crm system was not self-written, but was provided for payment by one well-known service. After their mistake with the cookie, it was logical to assume that there would be other vulnerabilities there.

If the script sent by me through the order form has worked, it means there was no field validation both on the sought site and in the crm system. x2. Therefore, having received a trial account, I began by searching for the fields vulnerable to xss.

After long journeys through the extensive crm system, more than a dozen fields with insufficient validation were identified. Somewhere you could directly insert the script tag, somewhere you had to use in-line scripts of the type "onmouseover = alert ()". And in some places it was possible to embed the script, and in some not, I wonder what logic they were guided by, adding filtering to some places, but not to others? From the point of view of the logical purpose of the fields, I did not see the patterns. In some places where almost everything would not go, everything worked fine, and, for example, they did not bother to add filtering in the name of the counterparty.

Most of the vulnerable fields could not be influenced "from the outside." They could only be used by employees to enhance their rights in the system, which is also important.

On this with xss it was over, it was possible to move on to more interesting things.

Previously, I never looked for CSRF vulnerabilities, the sites I tested were not of the class against which phishing would be used. Therefore, I did not want to kill with this head neither myself nor the site owners with vulnerabilities that would never be used against them. This was a completely different case. This crm system was popular, it was also used by large online stores, plus there was the ability to connect cash registers to offline retail outlets, which made the security issue even more important.

Surprisingly, there was no protection against CSRF. It was possible to send any requests, checks where they were not carried out.
- Change account details? - You are welcome
- Change the name and price of the goods? - No problem

At the same time, the cookies contained something called “csrftoken”.

Then I still thought, what's the point of putting a csrf token in a cookie? Googling, I learned that there is a rather convenient way to protect against csrf with a token in cookies and duplicating it in a post request, which does not require to store the token on the server. Read more here .

But in our case, only half of the work was done, the token was placed in the cookie, and it was absent in the requests to the server. And even more, its complete removal from the cookies did not change anything. Why was it added?

In conjunction with the detected csrf, our xss, not previously accessible from the outside, get a second life. We now do not need to get into the account to edit the vulnerable fields.

In addition, through the substitution of the mime-type file, arbitrary files could be uploaded to the server. But the server was configured correctly and php scripts were not executed there.

Further more interesting. All data about the goods online store took from crm. Those. name, description, photo. The link to the product image looked like "yyyy.domain.ru/file/get/id=xxx". In order for an online store to take images, they must have read rights for everyone. 122.

Checking the ways in which other, more private files are stored, I saw the same url. It seems, no wonder, they probably also have other access rights. Not lower than 022 definitely. But, the reality turned out to be slightly different, they also had free access for unauthorized users.

- Have you made a request to import order data in an exel file? - Great, now anyone can download it.

Perhaps there id looked like "yt5bjFb54hb # HJ% $ p" and did not succumb to brute force? Also no. All id files had a number format and were in the range of several thousand. I didn’t notice protection from brute either. I tried all the id from 1 to 10,000 obstacles I did not meet. Repeated several times, nobody was interested in such activity.

Answered my report after 3 days.

Regarding the absence of the flag httponly said that he was absent "Apparently for a long time, since the update version of php." Included on the same day.

By xss they said that they themselves all know, the filter was turned off at the beginning of summer (at that moment it was already August), this certainly does not explain why there was filtering somewhere, but not somewhere, but pretend that we didn’t notice this inconsistency. Also assured that the filter will be launched in a couple of days. In fact, it turned out that after a couple of months. But, here I understand them perfectly: I, too, then planned to start preparing for exams in a couple of days ...

Uploading arbitrary files to the server didn’t worry them much, because they aren’t executed on the server, so there’s nothing to worry about. Only while writing the article I had an idea, if the site, which is already on a hosting other than crm, is trying to take an image of the product for the storefront, and receives a php script, will it execute it? Or due to the fact that it is intended for the img tag, it will be processed only as an image? Or does it depend on the server settings? Please reply knowledgeable people.

The response to the csrf message was quite interesting. They answered with the question: “What do you consider token to protect against csrf attacks?” Indeed, what am I talking about?



They said that they did not take into account this moment about free access to any files. Shut down immediately.

I must say that it was the only time when I really expected to receive a cash reward. The site is large, except crm there is more than one paid project. Popular online magazine. But received only verbal gratitude.
I must say thank you to them, it has become even quieter about the issue of payment. Working for gratitude in any form will not lead to anything. Over time, you will get used to any praises and other honors, and they will no longer bring satisfaction. And if you did everything for them, then the meaning of something to do will be lost. And you cannot lose the pleasure from the very process of your activity, solving new problems, creating something new. Work for work, however banal it may sound. Work during which you do not notice how the hours go by, how the sun managed not only to go beyond the horizon, but also to rise again because of it.

'' '
Satisfied with small, happiness is not in big money
“Do what you love” - valued in our circles
'' '© Kolya Manyu - Everyday

nding

In technical support of the previous site, a third-party UserEcho ticket acceptance system was used. I did not fail to check it. In dreams, of course, it was possible to achieve the opportunity to read any private tickets. This I, of course, failed. I had to settle for little.



When testing api working with tickets, no anomalies were initially noticed, the right not to look into someone else’s, not to subscribe to it was not possible. But, upon further study of the site, it turned out that the developers did allow a small defect.
In the profile it was possible to find a section on how to manage your tickets, it indicated those that you subscribed to or were previously subscribed to.



If we send a request to unsubscribe from someone else's ticket, we, as it should be, are informed that we do not have rights to this action. But at the same time it is entered into our list of tickets, as one of those for which we were subscribed earlier. In this way, we get the opportunity to find out its name and the url of the format “number-nickname_kiteta_v_translit”. It didn’t bear any harm, of course. In very rare cases, it will be possible to learn something important and valuable from the title. But it was better than nothing at all.

A couple of weeks later the bug was fixed.

I thank everyone who read to the end!