termireum

I found a critical unauthenticated account takeover that let me log in as any customer on the platform. No password, no account of my own. It earned a $5,000 bounty. Quick context: the platform runs unattended devices, and those devices sign in with no human present. So instead of a password, each account has an "auto login key." A device presents the key and gets a session. The key is the credential. That design is fine right up until a key leaks. The chain came down to 3 things: - Keys are the credential: by design, holding an account's auto login key gets you a session for that account, no password. - Wildcard injection: the lookup endpoints ran input through a SQL `LIKE` query, so a single `%` let me pull any account's key out of the database. - No rate limiting: I could iterate the whole customer table and lift every key. Here's how I chained them: 1. Leak accounts with a wildcard The lookup took a `key` and found it in the database with a `LIKE` query. So I sent: `GET /autologin/lookup?key=%` Instead of one record, it returned matching accounts: user IDs, tenant IDs, emails. A single `%` dumped account rows. 2. Pull a victim's real key A second endpoint resolved a key to an account. Same flaw. I sent a wildcard plus an ID I'd just leaked: `POST /autologin/resolve?key=%` `{"user_id": {victim-id}, "tenant_id": {tenant-id}}` It handed back that victim's actual auto login key. 3. Trade the leaked key for a session The device endpoint does exactly what it's built to do: present a valid auto login key for an account, get a session token for that account. The catch is the key was the victim's, leaked in the steps above, and should never have been in my hands. `POST /autologin/devices` `{"user_id": {victim-id}, "key": "{victim-key}", ...}` It registered my device under the victim's account and returned a fresh session token for them. 4. Full takeover `GET /me` with that token returned the victim's full profile. PII, billing identifiers, all of it. No authentication, no account of my own, and no notification to the victim that a new device had appeared. The wildcard enumerated the entire customer table, there was no rate limiting, so this worked against every account on the platform at scale. #BugBounty tip: Any endpoint that takes a secret and looks it up is a candidate for wildcard injection. If `%` returns more than it should, it's a `LIKE` query and you can enumerate the table.

I found a critical privilege escalation that took a brand new free trial account all the way to platform superadmin, with read access to every customer's data on the platform. It earned a $5,000 bounty. The chain came down to 3 things: - Mass assignment: a PUT endpoint let a user write their own `admin_permissions` field, including the superadmin flag. - MFA bypass: escalating to admin triggered MFA on login, but a separate "auto login" flow handed out session tokens with no MFA at all. - Broken tenant isolation: a superadmin token could read any user's data in any org on the platform. Here's how I chained all three together: 1. Escalate my own account As a new free trial user, I sent: `PUT /api/admin/{my-user-id}` `{"admin_permissions":"0000000f"}` The server accepted it. No check that I was already an admin. My account was now superadmin. 2. The MFA wall The moment I escalated, the backend started enforcing MFA on my logins: `POST /token` → MFA challenge Self-enrollment to MFA was disabled, so I couldn't even complete it. Dead end. Then I remembered the auto login flow. 3. Why that flow exists The dashboard has a feature for signing in unattended devices. Things that need a session but have no human to type a password (or MFA code). You generate an "auto login" key, a base64 blob of `{userId}:{tenantId}:{random}`, and the device authenticates itself, headless. MFA is skipped there by design, because there's nobody at the device to challenge. So I asked: what's stopping me from logging in as a "device" instead of a user? 4. Bypass MFA with the auto login flow Before escalating, I'd already generated an auto login key for my own account. I replayed it against the device login endpoint: `POST /autologin/devices` `{"access_key":"{my-key}", ...}` It returned a full session token. No MFA challenge, because this path was never meant to need one. And since my account was now superadmin, that token was a superadmin session. The order is the whole trick. First I created the device key, then I performed the escalation, then I logged back in through the device flow, bypassing MFA. The key was minted before the MFA wall went up, so it still worked after. 5. What this unlocked With that token: `GET /api/users/{any-user-id}` returned full PII for users in completely different orgs, not just mine. User IDs were sequential, so this exposed records across the entire platform. #BugBounty tip: When an app adds a second auth factor, check whether every token issuing path enforces it. One legacy or "convenience" flow, like auto login, device pairing, or an API key, that skips MFA can undo the whole thing. And always ask: can I grab a credential before a security boundary goes up, then reuse it after?