Geekly Articles each Day
📜 ⬆️ ⬇️

How to compromise the workflow system in a few clicks

2018 is already on the threshold. But most bearded vulnerabilities continue to live in developed systems. And despite the fact that OWASP Top-10 2017 appeared . And the priority of certain things has changed a lot. Still nothing prevents to stumble upon situations that were relevant in 2010 .




The story began with a commonplace curiosity about the product of the company in which my friend works. The product is interesting. They buy this product very thoughtfully and for price tags with 6 characters. This company has no bug-bounty official. But I thought that even if I found something, I would pass it through a friend and pass it on.


Find the main product of the company was not difficult. There is an official site with a demo application. Climbed up there to watch what was there, simultaneously turning all traffic through a proxy into Burp Suit .


Seeing the input field, I immediately wanted to stick xss there. Stuck banal vector


<script>alert(xss);</script>

And what do you think happened? Of course it worked!




I searched for possible input fields, and my XSS attack was absolutely everywhere. And no, I'm lying! In one place for some reason did not work. But, having spent some time, I was able to overcome it with another payload vector and a screening bypass. So, on hand there are at least 8 xss vectors. It was possible to increase this number several times, but it was very lazy to waste time on bypassing the functionality of the system. Yes, and it was clear that the problem is complex.


Already wanted to go look, through a friend, responsible for this disgrace. But I thought that if everything is so bad with shielding, then maybe there is something else. Postponed a possible contact later and it is useful to still look.


In the logs there were hints to suspect the application of the ability to implement a CSRF attack. That is, there were no CSRF tokens that prevent the possibility of such an attack. To confirm my concerns, I needed a real example. And in order to treat my comments as responsibly as possible, I needed an example that shows the maximum damage to the system.


A few words about CSRF, even though you could google it .


Imagine that you went to the web client of your bank. And here they send you a link to "funny cats" in contact. You put aside the card number of the relative you just wanted to transfer money to, and went to have a look at the seals. The cats were really funny. And after that you decided to transfer the relative a little bit of money. When you return to the next tab of the web client of the bank, you are trying to make a transfer, but you don’t have enough money. And in your life you will not guess that your gangsters have surrounded your bank account. These cats pretended to be funny, while their relatives transferred money to your account to cat food and valerian sellers.



This is a clumsy example. And, of course, this will not turn out in any bank. But this example should help you understand the seriousness of the CSRF vulnerability.


And now without seals and with details.


In the application under study there is a simple opportunity to logout. You can check for user logins through csrf. You say: what's wrong with that, it's not dangerous! But this is not a vector of attack. This is just a test of our theory that our idea works.


For this we needed to build a test site in our subnet as follows.


 <html> <body> <form action="https://example.com/client/api/logout"> <input type="submit" value="Submit request" /> </form> </body> </html>

Then we log in with another browser. We open in this browser a test application with an active login session, and in the second tab is our saytik. Click on our submit button. Returning to the previous tab with our test applications, we find that they are no longer logged in.


Once our example has worked, it means that the probability of 80% will work in other places. 20% I left to the fact that the developers in important places use the means of protection against CSRF attacks. But this is rare. Either CSRF tokens are everywhere, or not at all.


Since our demo site with the application allowed us to log in from the system administrator, I could see what the administrator can do and, most importantly, how he does it. An interesting find was a password reset by a system user. He looked like this


 <method="POST"> <input name="Id" value="1" /> <input name="newPassword" value="testerok" /> <input name="confirmPassword" value="testerok" />

And if it didn’t bother you that in order to change the password you don’t need to enter the old password, then you should definitely be confused by the fact that users are sent via ID.


And then the attack script is something like:



Page Code


 <html> <body> <form action="http://example.ru/main/Security/Users/ChangePassword" method="POST"> <input type="hidden" name="Id" value="5" /> <input type="hidden" name="newPassword" value="test3" /> <input type="hidden" name="confirmPassword" value="test3" /> <input type="submit" value="Submit request" /> </form> </body> </html>

All that remains is for us to log in as a user to whom the administrator “accidentally” set a new password. By the same example, a case with the creation of a new user in the system works. You can still hide it and create a super-user! Under which you can sit in the system and merge a bunch of valuable information about the company - orders, documents, financial information.


Separately, in this whole story I want to highlight the reaction to the problems. And the speed of their correction.


The XSSs responded quickly enough. There were no questions with them at all. But with the CSRF, I began to receive the following questions and objections from the responsible person.


Let's see what the developers say. In theory, we have an ip session tied, and there should be a few tokens (c) Head of Testing Department


Only at this moment my eye twitched? What kind of protection through whitelisted IP can there be, if the admin does everything from his computer. This is a CSRF chip. But further more. Responsible stated the following.


Bug # 7 I do not understand how to implement it yet (c) Head of Testing Department

This is a massive change of passwords to all users of the system. Then I had to come straight with screenshots and tell why it is not worth leaving this opportunity at all.


You can go through all the id at once



Well, to dwell on those who are not interested in us



And, to tell the truth, it was sad to receive clarifying questions for such obvious and well-known vulnerabilities.


After all the correspondences, clarifications, a bunch of time spent, I was notified that I would be paid a reward for a special bugbaunt especially for me. At the same time, the calculation of this reward remains for me some kind of magic. Although I was given a formula by which everyone counted.


All XSS except one were considered duplicates and summed up by a reduction factor. CSRF on a different coefficient.


In the end, I got 100 Euro .



But it's good that I got something at all!


Due to the “interesting” user support policy, most customers will remain without these critical updates and patches.


Just because these customers do not have an annual support subscription. So in some large company that uses this expensive product, you can still drag off cookies or do something on behalf of the user by slipping a picture of cats. The customer list is impressive - banks, insurance, industrial holdings ...


In a sense, 0day turned out (the vulnerability has no fix).


In my opinion it would be possible to act more intelligent and nobler. Microsoft still patches release for Windows XP.


I did not disclose the name of the company and the company's clients for moral and ethical reasons.


Well, the representatives for the reputation of experiencing.


Timeline:
July 19th - reports were made
August 9 - all reports are confirmed and rewards accrued
August 28 - XSS filtering issues fixed
November 14 - implemented a CSRF correction for customers who have a support subscription


')

Source: https://habr.com/ru/post/345168/

More articles:


All Articles