abraxas/lago-invite-atoProof-of-concept lab che dimostra un bypass di autenticazione critico in Lago GraphQL acceptInvite che consente il takeover di account tra organizzazioni tramite l'accettazione di inviti non autenticata.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · lago-invite-ato
Lago v1.53.0 - GetLago
Mutations::Invites::Accept non ha AuthenticableApiUser. Create/revoke sì. Accept no. register_from_invite carica l'utente tramite l'email dell'invito. Se quell'account ha già delle membership, la password inviata viene scartata. AuthToken.encode(user:) viene comunque eseguito. Il JWT è user-scoped. Nessun claim di org. Il client invia x-lago-organization per qualunque org a cui quell'utente appartiene già. Inclusa quella della vittima. createInvite restituisce già il token all'invitante.
Invita cfo@victim in un'org usa e getta, accettalo tu stesso, e sei quella persona su ogni org in cui quell'email è già presente. La casella di posta non è mai coinvolta. La password della vittima resta invariata.
| ID | nessuna CVE al momento |
| CWE | CWE-287, CWE-306 |
| CVSS | Critico: 9.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N |
| Prodotto | Lago / lago-api |
| Affetto | fino alla v1.53.0 acceptInvite email/password |
| Auth | admin dell'org (organization:members:create); la registrazione su Cloud è sufficiente |
| Licenza | GNU Affero GPL v3.0 |
| Lab | solo 127.0.0.1 |
Ti serve un'org che controlli. La registrazione su Cloud è sufficiente (LAGO_DISABLE_SIGNUP è false di default). Invita l'email di una vittima, accetta senza autenticazione con una password fittizia, poi cambia header verso Victim Corp. Fatture, chiavi API, Stripe, wallet.
Non un visitatore casuale senza account. Non un reset della password. Il login con la password fittizia fallisce. La vera password della vittima funziona ancora. L'accept con Google/Okta vincola l'email dell'IdP e non è questo bug. Un self-host con una sola org e nessuna email di altri nel DB non ti dà accesso a un altro merchant. Stesso database, due org, stessa email: sì.
Stesso albero dello Stripe one-time invoice IDOR. Bug diverso.
Ho letto Accept (nessun AuthenticableApiUser), poi find_or_initialize_by(email:), poi il ramo con membership presenti che salta la password, poi AuthToken.encode(user:). Poi l'accept con Google, che verifica google_oidc["email"] == invite.email. L'accept email/password non vincola la password di un utente esistente.
Il primo client che guarda questo inviterà un indirizzo inutilizzato, lo accetterà, e otterrà un utente Lago nuovo di zecca con la password che ha inviato. Questa è la funzionalità. Il testimone è l'id dell'utente vittima esistente che ritorna.
Vicoli ciechi già registrati: accettare con Google/Okta; trattare il 401 di createInvite senza JWT come l'intera storia (create è autenticato, accept no); guardare solo l'org dell'attaccante su currentUser (l'indizio è Victim Corp nella lista); il login con la password fittizia (significherebbe che l'hash è stato sovrascritto - il lab verifica che non lo sia stato); una reverse shell. Teatro. Nessuna inbox.
Poi: due chiamate registerUser piantano Victim Corp e Attacker Corp. Email nuove a ogni esecuzione così un volume sporco non dà 422 user_already_exists. createInvite sull'email della vittima. acceptInvite non autenticato con una password fittizia. L'id utente restituito corrisponde alla vittima. currentUser.organizations elenca entrambe. Il cambio di header restituisce Victim Corp.
cd lab
./run.sh
Target solo http://127.0.0.1:13000. Lo Stripe IDOR usava 13001. Nessuna porta UI.
IOC victim_password_unchanged
IOC victim_real_password_still_works
SUCCESS LAGO-INVITE-ATO acceptInvite JWT is existing victim; lists Victim Corp; no inbox
Se l'utente esiste già, richiedi che si autentichi come se stesso (o provi la casella di posta / l'IdP) prima di associare la membership. Non generare un JWT per un utente esistente da un accept non autenticato. Smetti di restituire il token dell'invito all'invitante se è una capability.
accept.rb · accept_service.rb · users_service.rb · create.rb · object.rb · google_service.rbGNU Affero GPL v3.0. Vedi LICENSE. Solo lab su loopback. Nessuna garanzia.