How did I find my first vulnerability?
Foreword
Hello. I am 20 years old. Until recently, I studied at the Lyceum and was preparing to enter a medical university, and now I am a full-stack developer in an American company. In fact, I am very glad that I did not succeed with medicine - programming was my hobby, and now I can do it all the time. Now I would rather not write about success in IT. Right now I want to talk about how I read a couple of books on vulnerabilities (to protect my projects) and I managed to put this knowledge into practice.
Disclaimer
All materials, screenshots, as well as links to third-party resources, are posted for educational purposes. The author is not responsible for their use by other visitors to the Habr. The company was notified in advance of 48 hours of the vulnerability and received enough data to fix it.
How it all began
It was a very ordinary day. I completed several tasks at work and brewed a cup of coffee. At the same time, I decided to read one article about the deployment of the application on AWS, which I once reposted to myself in VK (by the way, I never read the article). The column to the right of the article displays several other articles and a partner banner for the hosting provider .
I don’t remember what exactly made me go to the site, but upon the transition, I noticed one interesting feature: the link leads to the registration page and it immediately filled out one field - a promotional code.
If we compare the promotional code, which is located in the input field and in the address bar, we will see that they completely coincide.
What can we do about it?
It’s commonplace to try to change. If the promotional code is compared with the value in the database - with a high probability we will get an error. But When changing in the input - there is no request to the server and it turns out that the input is checked only when you click on the registration button.
I think it’s already possible to do something more interesting here: we change our promotional code directly in the address bar and see what happens. If they do not have a promotional code specifically for the Habr, which I guessed right away,
The next step is to watch the HTML. RMB on the input field -> View item code.
Here you can see right away that we are changing the value of the input field. Let's try to exit it and add for example a link. To do this, it is enough for us to change the link and we can change the content of the page:
Result: we just found an xss vulnerability on the site of the hosting provider.
So, what is next?
I think it's worth going deeper. The link is somehow shallow and not interesting. We want to tell all this to the owners of the service and, ideally, get a reward (the company, by the way, does not have a bug bounty, which means that all this is not paid, but then I did not know about it). Let’s try to place the block, stabilize it and insert the image. What is needed for this? all the same - change url.
I think it's not worth describing html and css, so I just put what happened here. Habr blocks a part of tags, discards others - I can not put the link code here.
I will post a link here. I don’t know if she works at the moment, but when she posted the post she worked. Who needs it - pulls out the link and parses.
Remuneration
Do not think that upCloud completely refused to pay. Instead, they offered their services for free. But I refused this type of payment, since I am not interested in renting a server now.
How can this vulnerability be exploited?
Everything is simple here: you can start by collecting data from all new users, and end with phishing sites and using someone else's hosting as your own. You can replace all links on the page with your own or replace the form with users. It’s enough to send them as referrals. And of course, you can substitute a request to the server from the form so that it does not check the promotional code (when registering, the promotional code is checked, and the response is returned to the client with an error, but this is all solved by enabling zhs).
What the developers forgot to do:
It's simple - validate user input. SQL-Inj does not work there - the service hangs on WordPress, and it, in turn, processes incoming lines.
Therefore, we can:
- Check the promo code with the base when rendering the page.
This is slow and not justified. There is no additional load on the database, and there is no point in it if it is still checked during registration. - Running the input promo code
/ ^ [A-Z0-9] + $ / through the regular season is quite enough to validate values and protect against vulnerability. And it works faster than querying the database, and the effect is no worse - XSS is removed.
Conclusion
The owners of the service were notified 48 hours + 2 days before that I was negotiating by email and LinkedIn with those who at least somehow related to the development. All conversations came to: “Please tell us how you did it, but of course we will not pay for vulnerabilities.” I’ll also add that in exactly the same way the site accepts third-party js-scripts: both through a third-party source and by direct code writing, however, in the second case, Google Chrome automatically detects xss and renders an error page instead of a service page.
I hope every programmer will validate all the input data and will not forget about querystring. And I’m also sure that the article will help someone notice in advance + fix this problem at home.
Thank you very much for your attention.