Authentication compromise
During the testing, we found out that a session token is provided not only for authenticated users but also to conduct password resets. The application provided a so-called “anonymous” session, which allowed access to a restricted subset of API endpoints. After enumerating the session attributes, the team discovered that the username field of the session object was filled before the password reset was completed. Then, we decided to test all requests that accepted an anonymous token, and a mobile-only request was found that handled repeated authentication from a mobile device. To our surprise, it was found out that the androidID required to authenticate is not validated. Additionally, as the request is a part of an authentication chain and is meant to be processed after proper authentication, it regenerated the session object and provided the caller with an updated token, no longer an anonymous one. (It should also be noted that even if the androidID was properly validated, the vulnerability would still be considered critical as it is possible to gather the ID by an attacker).
The vulnerability allowed access to any other account in the system in case the attacker knew relevant details to start the password reset procedure.