Portuguese version: Como eu descobri uma falha de segurança em um sistema na minha universidade

Hi everybody, today i will tell you how did I discover a security vulnerability in a system of my university, what i did i do in next, how we can avoid this and my conclusions.

I want to be clear that my objectives weren't stain company image, university or developers, but only can contribute with system security and also contribute for information security scenario in Brazil.

How did I discover vulnerability ?

Well, at the time we were in the pandemic when classes were mostly online and that's why the use of online system was most frequent than in person. Then, in this class was introduced for us a system (already utilized for a some time by university) and that we should utilised to post exercicies and follow our grade. Being a new system, I was curious to see what was traffing between the application and my network and I have started to look for something interestant.

So, I founded two requests interestant:

• One that returned my personal data
• Another that returned some numbers of my credit card, card flag, expiration date and etc

But Iaan, we only found two requests that show our self data, and?

You're right, that's why i decided to test if that routes was allow made if I haven't a token or a valid token.

Did not work. :(

It was then i thought, and if my token is valid but my request has a ID different of my user id?

And... THATS WORKED!!

I made a request using the curl command and changing my id what which was a parameter in the route.

Same happened with route that return some info about my credit card.

This happens because the application back-end only verified if my token is valid to make the request but not verify if the id was requesting really belonged to my user.

Suppose my id is 21 and I have be authenticate in application, so the route to show my personal data were something like:

http://myapi.com.br/personal-data?id=21

Then, I was already authenticate and my token was valid, if i changed my id in the request to 22, I could get all personal data of id 22.

Ok, vulnerability found and now?

What did I do after finding the vulnerability?

I started documenting all I have done to discover this vulnerability to report to those responsibles.
I created abstract of vulnerability .
In this document I described a abstract of vulnerability, how to execute, possible solution, a tiny script to prove the vulnerability (Proof-of-concept) and the source code.

PoC:https://www.youtube.com/watch?v=tU1qOoPhwtg

I didn't know responsible's email of application so i asked for help to my professor and he helped me to send document to them.
In the next day, I receveid a response email:

(Google translate bellow xD)

Dear,
We hope to find you all well.
We have received your notification regarding a security flaw in one of our applications and we would like to inform you that we have immediately submitted this notification to our engineering team for analysis and correction.
After analysis, it was found that in fact there was a vulnerability that would allow the consultation of other people's registration data, only when in possession of a valid token. The token in this context is similar to a key, generated from the successful authentication of a student after entering their username and personal password. People without this token, that is, without a valid login, would not be able to access said personal data.

All necessary corrections and validations have been implemented so that this scenario no longer occurs.
Regarding credit card data, it is important to note that we do not store any critical or sensitive student credit card data. For the avoidance of doubt, below is a brief explanation of how credit card use works in our solutions:

When a student wants to make any payment via credit card, when entering their card information, this data is sent directly to the Banking Institution through a process called "Transparent Checkout" where the data is being sent directly to the bank within of our platform. In other words, it is as if the student were on the bank's website while still on our platform. This communication with the bank is carried out using a secure and encrypted connection, in addition to all the latest security protocols available for the internet. At no time do we collect any information transacted in this transaction. After completing the payment, the Banking Institution returns us whether it was successful or not, and, when successful, sends us a token that identifies that student's card with the bank. Accompanied by this token comes the masked number of the card and its brand, so that if the student needs to make another payment through the platform, he can do it more easily and quickly. This token by itself has no validity because, in the event of a new payment, the insertion of the verification code printed on the credit card and a public and a private key created between the bank and our system will be required for the transaction be validated, reinforcing that the entire transaction will be carried out in a secure environment provided by the Banking Institution.

We highly value the quality and integrity of the services we provide. Our innovation cycle includes reviewing services already built to measure performance and safety criteria. We are deeply sorry that this failure has gone unnoticed. Therefore, we carefully check all the points that were raised and these have already been corrected. We also emphasize our commitment to follow and keep an eye on all
current legislation regarding information security, in particular the Law
no. 13.709/18 (General Law for the Protection of Personal Data - "LGPD") and the Law
12.965/2014 (Marco Civil da Internet).

On all our platforms, our privacy policy is publicly available, which explains how personal data is treated in our solutions. Questions related to XX's Privacy Policy or any other questions related to the topic of security and protection of Personal Data, can be sent via the support contact email
Certain of our understanding, we make ourselves available for any clarifications. Yours sincerely,

Then, I checked if the vulnerability was fixed.

What we can learning about this?

Never trust the user, remember that any validation you do on the client side is susceptible to changes by the user. Validate everything on the backend that needs validation and run tests to make sure your result is as expected. Could we change the id from int to a UUID? It depends, if it's just for that, it's not a good idea because a validation would already make it impossible and only with this change you would be solving only part of the problem. You have to understand the trade-offs in adopting this technique. (I recommend the article Are you going to use UUID as PK instead of Int/BigInt in your database? Think again..., it has some pretty good insights)

Conclusion

Thanks for reading, this is one of my posts that is part of my new way of learning using learn in public.

If you're interested, you can check out what it is: https://www.swyx.io/learn-in-public/

I intend to continue doing this and I already have the next post prepared.

Spoiler: This one also involved my university

:)

PS: I'm learning English too, feel free to comment on my grammatical errors.