Getting another opportunity to become part of a hall of fame for security related contributions is pretty cool and this was because of a very simple bug which was not noticed during the development of the system. Last time I saw this kind of issue was a few months ago when I was working on a back-end system for a client and finding this again on another website basically means that it’s probably common out there.
During my initial non-intrusive information gathering, I found a lot of API links which made me test them for some basic responses and they seemed pretty secure until I opened the console of Chrome. After noticing that the APIs were throwing console logs, I visited a few pages and guess what popped up? It was the password hash!
This happened when the page “Account Settings” was visited and it also means details from the database are being dumped in the console without having restrictions. I thought that it should have been a small error on the developer’s side because I even experienced this in my real job. What happened on a project of mine was when I created a query in SQL through PHP which went something like “SELECT * FROM …”. Now I’ll stop there. Notice the “*” symbol which basically means “EVERYTHING” in SQL. From there, the front-end developer saw the function which retrieved the details that she needed and just used the function to grab those details from the database.
After sometime, I realized that the hash was being dumped in the client side because of the function that I did! Talk about my own negligence. Discovering this, I immediately created a function that retrieved only the necessary information that the front-end developer needed which went something like “SELECT username, address, … FROM …”. There’s no question that a similar scenario happened in Trovisio and I happen to be there in the right place and the right time (Thank you Google Chrome Console).
You probably might ask, what could be the risks of having the password hash being leaked? Well, two things:
- Being able to make an educated guess about the internal algorithm used to hash the password. Once this happens, a remote user will be able to see if the algorithm is secured or not. Remember MD5? It was actually secured years back but now, it can be cracked through brute-forcing or rainbow tables. This means time will come that a secure hashing algorithm might get obsolete. Now if the algorithm used is obsolete (not in Trovisio as what I learned), then what if a breach occurs and you happen to be a member there? Would you be happy that your “very secured and very long” password has a publicly released hash? I guess not?
- Having the password hash sent in the client-side means that it is susceptible to client-side attacks. If a cross-site scripting can happen, then it just got easier for the attacker to grab a copy of your password hash. Once the attacker gets that, brute-forcing would be the next step without it being protected by the system!
This was reported to Trovisio last May 10, 2018 at around 13:00. The following day, Trovisio has replied to my report:
By May 14, Erik from Trovisio sent an update:
As of the day of writing this article, I confirm that the password hash has been removed from the console log and finally, the acknowledgement found here:
June 7 update: They’ll be sending a small reward! Exciting!
June 30 update: They’ve sent the small reward!
July 17 update: “I hacked Trovisio and all I got was this lousy t-shirt” + an Amazon gift certificate!
