# Account Takeover via SMS Authentication Flow

Zenly's /SessionCreate returned the same pre-verification session token to any caller for a given phone number, so an attacker's token became valid once the victim entered their SMS code.

- Payout: hidden
- Severity: high
- Program: Zenly
- Found by: yetanotherhacker
- Disclosed: 2022-01-12
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/1245762
- Library page: https://bugbountylibrary.com/r/h1%3A1245762
- Tags: area:mobile domain:api domain:mobile impact:ato impact:data-leak kind:bounty platform:hackerone sev:high technique:recon vuln:account-takeover vuln:auth-bypass

**Target:** Mobile app authentication API (rpc.znly.co /SessionCreate, /SessionVerify, /Me)
**Root cause:** The /SessionCreate endpoint deterministically returns the same session token for a given phone number instead of generating a unique token per request, so multiple parties requesting a session for the same number share one token.
**Steps:**
1. Intercept the login flow and observe POST /SessionCreate with the victim's phone number returns a session token.
2. Attacker sends their own /SessionCreate with the victim's phone number and receives the identical session token.
3. Victim receives SMS code and enters it, triggering /SessionVerify which validates the shared token.
4. Attacker polls /Me with the token; 401 before verification, session info (phone, user id) after.
5. Attacker uses the now-valid token against notification, geolocation, and conversation endpoints.
**How found:** Researcher intercepted the mobile login flow, noticed /SessionCreate responses contained a session token before verification, and hypothesized that repeating the call for the same phone number would yield the same token — confirmed by issuing a second /SessionCreate and comparing tokens.
**Exploitation:** Attacker calls /SessionCreate with the victim's phone number at any point before the victim completes /SessionVerify, obtaining the same session token the victim holds. When the victim enters their SMS code, the token becomes valid for both parties, giving the attacker a fully authenticated session without knowing the code.
**Insight:** In SMS/OTP flows, check whether the pre-verification session identifier is deterministic per phone number rather than random per request; if two /SessionCreate calls for one number return the same token, the attacker's token inherits validity when the victim verifies.