Account Takeover in an Android App via OTP Bypass

Hi everyone! We are back with another interesting write-up. This time, we will share how we found an easy Account Takeover (ATO) vulnerability in an Android application during a penetration test. The app we tested was for healthcare, mainly used for patient engagement and support. For privacy reasons, let's call the app test.apk.

What is OTP?

OTP stands for One-Time Password. It's a temporary code sent to your phone or email to confirm your identity during login or signup. Instead of using just a regular password, apps use OTPs to add another layer of security. Each OTP is valid only for a short time and can be used only once, which helps protect against unauthorized access even if someone knows your password.

Target Overview

The app (test.apk) helps patients connect with healthcare services. To protect user data, the app had a proper authentication process with several steps, such as verifying personal information, OTP code, and PIN code. But I found a serious bug in the OTP validation process that allowed me to bypass authentication and take over accounts. Let's look at how the login flow works.

Authentication Process in the Test.apk

Here's how a user logs in to the app:

1. Personal Info Step. The user enters First Name, Last Name, and Date of Birth (DOB).
2. Verification Step. The app checks the data and displays a partially hidden phone number (like ******1234) and a partially hidden email (like t****@****.com).
3. OTP Step. The user selects either phone or email to receive the OTP.
4. PIN Step. After entering a valid OTP, the app asks the user to create a new PIN code (normally used as an app-lock on mobile devices).

OTP Bypass via Response Tampering

The main issue was with the OTP verification API. When the user enters an OTP, the app sends it to the server and receives a response in JSON:

{
  "stat": 0
}

• "stat": 0 means the OTP is invalid.
• "stat": 1 means the OTP is valid.

Here's the problem: the validity check was only enforced on the client. The backend did not re-verify state before moving the user to the next step. So we tried response manipulation.

The Bypass

We opened the app and entered the target's first name, last name and DOB. We chose email as the OTP channel, then entered a bogus OTP like 111111.

Using Burp Suite, we intercepted the response from the server. It returned:

{
  "stat": 0
}

We changed stat: 0 to stat: 1 in the response body and forwarded it:

{
  "stat": 1
}

And we were allowed to move to the next step without entering the real OTP. The app then asked us to set a new PIN. We did that and successfully logged in. OTP was bypassed completely via response tampering, and we had taken over the account.

Impact

This vulnerability enables Account Takeover (ATO), with one meaningful prerequisite: the attacker needs to know the victim's first name, last name and date of birth to reach the OTP screen. DOB is usually the hardest piece to guess, which reduces the risk, but not by much. In a hospital setting, an insider threat, or a target who's been the subject of a data breach, these fields are often already known.

Once reached, the attacker can:

• Load the victim's OTP screen
• Bypass OTP via response tampering
• Set a new PIN
• Gain full access to the victim's account

In a healthcare app, this is a serious issue: medical history, appointments and contact information are all exposed.

How This Can Be Exploited

An attacker can combine OSINT and leaked-data lookups to collect names and DOBs, input them into the app to reach the OTP screen, intercept and tamper with the response, bypass OTP, set a new PIN, and gain full access to the victim's data, including medical history and appointments.

Why Healthcare Data Must Stay Private

Healthcare data is one of the most sensitive categories of personal information. It contains medical history, test results, prescriptions, mental-health records, and personal identifiers like home address and contact information. If any of this falls into the wrong hands, the consequences go beyond inconvenience:

• Privacy violations: leaked medical detail is often embarrassing, and can damage personal relationships and employment.
• Identity theft: full name, DOB and insurance identifiers are precisely what fraud rings need to impersonate a victim.
• Targeted scams: attackers can tailor extortion and emotional-manipulation messages using specific conditions or treatments.

Protecting healthcare data isn't just technical hygiene. The psychological consequences for victims are real.

Conclusion

This OTP bypass shows how a single client-side trust assumption, one integer in a JSON response, can collapse an otherwise layered authentication flow. The fix is mundane and specific: validate every security-relevant state transition on the server. Do not rely on any flag the client chooses to believe. If you have questions or want to dig deeper into this finding, reach out to the Secure Purple team.