I got a private invitation to hack on this fintech application, mind you this is an old program that was launched as far as 2022. At this point I knew the top hunters had already squeezed every juice out of this one, and a VDP merchant like me can never feast here.
Well, the program had two domains in scope, since it’s a private program, I won’t be using any information that may expose the company, I will use these two domain representations:
Simply put, the two applications ride on the same session via SSO. You authenticate to the main application and when you visit the forum, you get automatically logged in there too as the user you are authenticated as on the main application. The implementation in this application was flawed:
So, I signed up to the main application (www.app.target.com) — this required I set up a 2FA due to the sensitive nature of the application (money transaction, wallet operations, etc.). Afterwards, I decided to login. After entering username:password combo, I got sent to the 2FA verification page. I took a notice of the URL; it looked something like this:
www.app.target.com/v2/verify-blah
So, while still on this verification page, I opened the forum (www.forum.target.com) in a new tab, and boom! I was fully authenticated. Mind you, I hadn’t verified the OTP on the main app. Ideally since the two applications ride on the same session via SSO, if I haven’t bypassed the OTP verification page on the main app’s login page, I shouldn’t have access to the forum.
This vulnerability came about due to the main application assigning an initial session token upon a valid username:password login. This initial session token is not enough to take you to the application’s dashboard for you to perform transactions and wallet operations — because it would have been exchanged for a final session token after a valid OTP verification. However, the initial token was enough to get you access to the forum.
The forum had a lot of functionalities including adding a secondary email, where we can request user data. The user data included CSV files that contained logs. These logs contained old and current API tokens, IP addresses used to authenticate, etc. It was possible to request the user data to be sent to the secondary email added by the attacker.