InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties…

Follow publication

[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.

user_login_status.php

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.

Leaking user_id and email address

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.

Linkedin: https://www.linkedin.com/in/vipul-sahu-a7a420174/

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Published in InfoSec Write-ups

A collection of write-ups from the best hackers in the world on topics ranging from bug bounties and CTFs to vulnhub machines, hardware challenges and real life encounters. Subscribe to our weekly newsletter for the coolest infosec updates: https://weekly.infosecwriteups.com/

No responses yet

Write a response