[Account Takeover] Don’t Send a Message to anyone Before Reading This [External Audit]
The security of a web application relies heavily on the strength and effectiveness of its authentication and authorization mechanisms. If these are not carefully designed, implemented, and maintained, the application can become vulnerable to a range of different attacks. One particularly dangerous attack vector is authentication bypass, where an attacker can gain access to the system without providing valid credentials.
During my recent penetration test, I discovered a critical account takeover vulnerability in the target system. This vulnerability can be exploited through response manipulation and requires the victim to send a message to the attacker. In the interest of protecting the target’s privacy, we will refer to it as “redacted.com” throughout this blog post.
During my security testing, I inspected the response to a valid login request. Although the user_id was present, which is considered sensitive information, no cookies were set. Upon realizing this, I probed for response manipulation by inputting incorrect credentials and modifying the response with the correct one. To my surprise, I was granted access for a brief moment before being immediately logged out of the dashboard. This unexpected behavior led me to believe that the application was performing additional checks.
After further investigation, I stumbled upon an endpoint named user_login_status.php. Utilizing the match and replace function, I modified the response by changing any instance of user_signed_out to user_is_signed_in, thus mimicking a successful login. Although this allowed me to gain access to my account, I encountered an obstacle — I still required a user_id to carry out the account takeover.
In the redacted system, I discovered a vulnerability in the way it handles the response to a get_message request. When a user sends a message to another user, redacted sends a get_message request to retrieve the message. However, the response to this request not only includes the message content but also the sender_id and sender_email, where the sender_id is actually the user_id.
By exploiting this vulnerability, I was able to intercept the response and gain access to the user’s account by using the sender_email and a random password on the login page. By modifying the response from
{“user_profile”:{“sign_in_status”:”invalid_password”}}
to
{“user_profile”:{“sign_in_status”:”login_success”,”user_id”:”<user_id_string>"}}
I was able to gain full access to the user’s account, allowing me to execute a complete takeover.
In conclusion, the vulnerability in redacted that allowed me to bypass authentication and take over any user’s account is a severe threat to the security of the application. To mitigate this vulnerability, the application should improve the design and implementation of its authentication and authorization mechanisms. The application can start by ensuring that responses to requests do not contain sensitive information such as user IDs or email addresses. It is also essential to validate responses properly to prevent tampering. Furthermore, implementing multi-factor authentication and session management can reduce the risk of account takeover.
