The adversary simulation activity allowed the security team to demonstrate a complete compromise path while not using any usual, “exploitable” vulnerabilities.
The penetration testing team was tasked with mobile and web application security assessments for an undisclosed banking institution. The scope was limited and only included the API provided to the Client’s customers.
In the end, chaining the two vulnerabilities allowed the penetration testing team to conduct any transactions from other accounts without proper authentication.
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.
To further exploit gained access to other accounts, the payment protection mechanism also would need to be bypassed. All payment requests in the application required an OTP password to be entered, but the implementation of the mechanism had a critical vulnerability, allowing us to complete any transaction. The request for payment authorization did not only include the OTP password, but also the UUID returned by the OTP request to the API gateway. It was discovered that while the OTP is properly validated, the application does not store any information on the UUID ownership. This allowed us to validate any transaction requests by issuing OTP requests from our own accounts, receiving the OTP normally, and using the UUID/OTP pair to validate transactions from other accounts.
Your Cyber Resiliency is Our Passionschedule a call
WHY WORK WITH TENENDO?
Reducing high-severity vulnerabilities’ exposure by up to
Reducing the cost of security testing, audit, and consulting by up to
About security testing:
During this social engineering engagement, it was possible to achieve persistent internal access, exfiltrate confidential and personal information, and compromise the internal segmented infrastructure.
Tenendo specialists discovered an unattended staging environment and leveraged its vulnerabilities for sensitive information disclosure. This information was later reused in an attack against the main application, that allowed us access to the payment API on behalf of other customers of our Client.