abraxas/lago-invite-atoProof-of-concept лаборатория, демонстрирующая критический обход аутентификации acceptInvite в Lago GraphQL, позволяющий захватить учётную запись в другой организации через принятие приглашения без аутентификации.
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · lago-invite-ato
Lago v1.53.0 - GetLago
Mutations::Invites::Accept не имеет AuthenticableApiUser. Create/revoke имеют. Accept — нет. register_from_invite загружает пользователя по email из приглашения. Если у этой учётной записи уже есть членства, отправленный пароль отбрасывается. AuthToken.encode(user:) всё равно выполняется. JWT привязан к пользователю. Без claim организации. Клиент отправляет x-lago-organization для той организации, к которой этот пользователь уже принадлежит. Включая организацию жертвы. createInvite уже возвращает токен приглашающему.
Пригласите cfo@victim в одноразовую организацию, примите приглашение сами — и вы станете этим человеком во всех организациях, где уже присутствует этот email. Почтовый ящик не задействован. Пароль жертвы не изменён.
| ID | CVE пока нет |
| CWE | CWE-287, CWE-306 |
| CVSS | Critical: 9.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N |
| Продукт | Lago / lago-api |
| Затронуто | вплоть до v1.53.0 acceptInvite по email/паролю |
| Аутентификация | администратор организации (organization:members:create); достаточно регистрации в Cloud |
| Лицензия | GNU Affero GPL v3.0 |
| Лаборатория | только 127.0.0.1 |
Вам нужна организация под вашим контролем. Достаточно регистрации в Cloud (LAGO_DISABLE_SIGNUP по умолчанию false). Пригласите email жертвы, примите приглашение без аутентификации с фиктивным паролем, затем переключитесь заголовком на Victim Corp. Счета, API-ключи, Stripe, кошельки.
Это не случайный посетитель без учётной записи. Не сброс пароля. Фиктивный вход не сработает. Настоящий пароль жертвы по-прежнему работает. Принятие через Google/Okta привязывает email IdP и не является этой уязвимостью. Самостоятельный хостинг с одной организацией, где в БД нет чужих email, не даёт вам другого мерчанта. Та же база данных, две организации, один email: даёт.
Та же ветка, что и Stripe one-time invoice IDOR. Другая уязвимость.
Я прочитал Accept (нет AuthenticableApiUser), затем find_or_initialize_by(email:), затем ветку с наличием членств, которая пропускает пароль, затем AuthToken.encode(user:). Затем Google accept, который проверяет google_oidc["email"] == invite.email. Accept по email/паролю не привязывает пароль существующего пользователя.
Первый клиент, который посмотрит на это, пригласит неиспользуемый адрес, примет приглашение и получит совершенно нового пользователя Lago с паролем, который он отправил. Это и есть фича. Свидетельство — возврат id существующего пользователя-жертвы.
Уже зафиксированные неверные пути: принятие через Google/Okta; трактовка 401 от createInvite без JWT как всей истории (create аутентифицирован, accept — нет); просмотр только организации атакующего в currentUser (признак — Victim Corp в списке); вход с фиктивным паролем (это означало бы, что хеш был перезаписан — лаборатория утверждает, что нет); reverse shell. Театр. Без почтового ящика.
Затем: два вызова registerUser создают Victim Corp и Attacker Corp. Свежие email при каждом запуске, чтобы грязный том не выдал 422 user_already_exists. createInvite на email жертвы. Неаутентифицированный acceptInvite с фиктивным паролем. Возвращённый id пользователя совпадает с жертвой. currentUser.organizations перечисляет обе. Переключение заголовка возвращает Victim Corp.
cd lab
./run.sh
Цель только http://127.0.0.1:13000. Stripe IDOR использовал 13001. Порт 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
Если пользователь уже существует, требуйте, чтобы он аутентифицировался как сам себя (или подтвердил почтовый ящик / IdP), прежде чем прикреплять членство. Не выпускайте JWT для существующего пользователя из неаутентифицированного accept. Прекратите возвращать приглашающему token приглашения, если это capability.
accept.rb · accept_service.rb · users_service.rb · create.rb · object.rb · google_service.rbGNU Affero GPL v3.0. См. LICENSE. Только loopback-лаборатория. Без гарантий.