Программное обеспечение OpenReception для записи на прием предоставляет платформу для записи на прием со сквозным шифрованием. До версии 1.0.2 TENANT_ADMIN повышал себя до GLOBAL_ADMIN всей платформы с помощью одного запроса PUT. Обработчик обновления роли принимает значение перечисления GLOBAL_ADMIN от любого администратора арендатора, обновляющего персонал своего арендатора.
Никакая проверка политики не гарантирует, что «только существующий GLOBAL_ADMIN может предоставить GLOBAL_ADMIN», поэтому проверка схемы ЯВЛЯЕТСЯ решением об авторизации. После повторного входа в систему JWT содержит новую роль, и администратор, ранее находившийся в области клиента, обращается ко всем остальным клиентам на платформе. В размещенной службе OpenReception это эскалация с измененным объемом: один администратор клиента на стороне клиента получает полный административный контроль на всей платформе над конфигурацией всех других клиентов, пользователями, записями персонала, операционными метаданными и жизненным циклом клиента.
Содержание встреч в виде открытого текста остается предметом модели E2E, если только оно не связано с проблемой отравления крипты персонала (V-4) или перехватом пароля персонала (V-1). При самостоятельном развертывании с одним арендатором это по-прежнему является повышением привилегий, поскольку TENANT_ADMIN не должен иметь возможности создавать новых клиентов, изменять глобальную конфигурацию или управлять другими администраторами. Тот же обработчик также принимает обновления, предназначенные для любого коллеги в клиенте.
Администратор клиента может продвигать отдельную учетную запись сотрудника вместо себя, оставляя свой собственный контрольный журнал чистым, в то время как взлом всей платформы происходит через отдельный идентификатор. Версия 1.0.2 устраняет проблему.
Показать оригинальное описание (EN)
OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.2, a TENANT_ADMIN promotes themselves to platform-wide GLOBAL_ADMIN through a single PUT request. The role-update handler accepts the `GLOBAL_ADMIN` enum value from any tenant admin updating their own tenant's staff. No policy check enforces that "only an existing GLOBAL_ADMIN may grant GLOBAL_ADMIN", so the schema validation IS the authorization decision. After re-login, the JWT contains the new role and the formerly-tenant-scoped admin reaches every other tenant on the platform. On the hosted OpenReception service this is a scope-changed escalation: a single customer-side tenant administrator gains full platform-wide administrative control over all other tenants' configuration, users, staff records, operational metadata, and tenant lifecycle. Plaintext appointment contents remain subject to the E2E model unless chained with the staff-crypto poisoning issue (V-4) or with staff-passkey hijacking (V-1). On a single-tenant self-hosted deployment it is still a privilege escalation because TENANT_ADMIN should not be able to create new tenants, modify global configuration, or manage other administrators. The same handler also accepts updates targeted at any colleague within the tenant. A tenant admin can promote a separate collaborator account instead of themselves, leaving their own audit trail clean while the platform-wide breach happens through a separate identity. Version 1.0.2 fixes the issue.
Характеристики атаки
Последствия
Строка CVSS v3.1