OTP Bypass to Full Data Exfiltration & Loan Fraud — A Full Writeup

🧠 TL;DR

A backend trust boundary failure allowed an attacker to replace PAN/mobile in requests after OTP verification and access or submit another user's loan data — resulting in full data exfiltration and the ability to create fraudulent loans.

🎯 Vulnerability Overview

The application used PAN + mobile OTP verification to authenticate users. After OTP verification, the frontend continued sending PAN/mobile in request bodies to load loan offers and submit applications. The backend trusted those client-supplied identifiers instead of binding actions to the server-side session user id. By swapping PAN/mobile mid-session (via an intercepted request), an attacker could load victim data and submit loans on their behalf.

🔍 Discovery — How I found it

While testing loan endpoints on staging, I observed that the loan offer API accepted PAN/mobile in the JSON body. That raised a red flag — post-auth requests should use the session identity, not client-supplied primary keys.

Observed login flow

I performed a standard login + OTP verify flow using my test account and intercepted the subsequent requests.

Login screen (PAN + mobile) — initial authentication uses OTP.

OTP verification step — after this the frontend proceeds to fetch loan offers.

🧑‍💻 Proof: Intercept & Replace

I intercepted the loan-offer API call and edited the JSON body to use a victim's PAN & mobile. The backend returned the victim's loan dashboard without any further authentication.

Intercepted POST to loans/getOffer showing PAN & mobile in body (edited in Burp).

🕵️ Victim Data Returned

The server returned full PII and loan details for the victim. No re-OTP, no additional checks.

API response showing victim loan and personal data returned to the attacker-controlled session.

💸 From Viewing to Abusing: Loan Submission

With the victim's loan context loaded, I intercepted the loan submission request. I changed the destination account and increased loan amount; the server accepted it and produced a valid sanction document.

Complete victim profile — personal info + bank details visible in the response.

Intercepted submission where the destination account is visible and changeable.

Modified submission payload — attacker increased loan and replaced destination account.

Server returned a formal loan sanction letter — generated without verifying the session owner matched the PAN in the payload.

⚠️ Impact Summary

• Massive PII exposure (PAN, bank accounts, salary & employer data)
• Ability to generate legitimate loan sanction documents in victims' names
• High-risk financial fraud at scale with low attacker effort
• Regulatory & reputational consequences for the platform

🛠 Remediation & Hardening

🔎 Detection & Monitoring

• Alert when Authorization user != request body PAN/MOBILE
• Flag loan submissions where destination account is new/unverified
• Log & monitor unusual loan amount jumps and rapid account target changes

🏁 Final Thoughts

This case is a reminder that authentication primitives (OTP) must be coupled with strict server-side session scoping. Business logic mistakes are easy to miss and catastrophic in financial systems.