Skip to content
KitploitKITPLOIT
ИнструментыЭксплойтыБлог
Log in
Отправить
ИнструментыЭксплойтыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

ЛентыКонтактыКонфиденциальность© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
Инструменты/GitHubGitHub/abraxas/keycloak-manage-users-composite
Аутентификация и авторизацияПовышение привилегийАнализ уязвимостейЭксплуатацияЭксплуатация веб-приложенийУправление идентификацией и доступом (IAM)Лаборатории и Практика

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
GitHub
abraxas/keycloak-manage-users-composite

keycloak-manage-users-composite

Репозиторий
21 день назадЕщё не проверено

Описание

Keycloak 26.8.1 Средний 6.6 Удалённая аутентифицированная аутентификация, оставшаяся. Администратор службы поддержки с правами manage-users может закрепить за собой заранее созданный композит manage-realm, а затем прочитать полный документ realm. Требуется, чтобы этот композит уже существовал. PoC через loopback.

Поделиться

Abraxas Labs - keycloak-manage-users-composite

keycloak-manage-users-composite

Учётная запись службы поддержки, которой положено только сбрасывать пароли и создавать пользователей, может повысить собственные привилегии. Пользователь с ролью Keycloak manage-users находит в realm оставшуюся без присмотра должность (композитную роль, которая незаметно включает manage-realm), закрепляет эту должность на своей учётной записи и затем читает полный документ realm, который был скрыт от него одним запросом ранее. Создать этот композит он не может. Настоящий администратор realm должен был создать его заранее. Это «родственный» по механизму сопоставления ролей аналог CVE-2026-94000, который закрыл тот же трюк при присоединении к группам.

Класс: Auth leftover Доступ: Удалённый (аутентифицированный manage-users)

Keycloak 26.8.1 (24ed1dad) - Red Hat

IDCVE пока нет
КлассAuth leftover
ДоступУдалённый (аутентифицированный Admin REST; требуется manage-users плюс заранее созданный композит)
CWECWE-269 / CWE-266
CVSSСредний: 6.6 CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
ПродуктKeycloak
Затронуто26.8.1 (24ed1dadf3f246a555adb6d3d4a99e9b3003fb3b); образ quay.io/keycloak/keycloak:26.8.1
Аутентификацияделегированный администратор с realm-management / manage-users. FGAP v2 — оценщик по умолчанию.
ЛицензияGNU Affero GPL v3.0
Лабораториятолько 127.0.0.1:18082

Что может сделать атакующий

Требуется существующая учётная запись Keycloak, которая уже имеет manage-users, и роль realm или клиента, чьё собственное имя не является административной ролью и чьи композиты включают manage-realm или realm-admin. Не требуется manage-realm в токене. Создать этот композит невозможно. Прямое назначение роли с именем manage-realm / realm-admin по-прежнему отклоняется.

ПривилегияМетод / точка назначенияРазведка / целостность / доступностьДоказано в лаборатории или выведено
Сопоставить неадминистративный композит самому себеPOST /admin/realms/{realm}/users/{id}/role-mappings/realm с id и именем композитаЦелостность (выдача роли)Доказано в лаборатории. HTTP 204. Свидетельство kcr02m7q4
То же назначение для роли клиентаPOST /admin/realms/{realm}/users/{id}/role-mappings/clients/{client}ЦелостностьИсходный код. Тот же canMapRole в ClientRoleMappingsResource.java:184
Прочитать полный документ realm с тем же токеном доступаGET /admin/realms/{realm} после сопоставленияРазведкаДоказано в лаборатории. До: HTTP 200 частично (без атрибутов, без accessTokenLifespan). После: HTTP 200 полностью, внедрённый атрибут присутствует
Использовать вложенный manage-realm в последующих административных вызовахUserAdapter.hasRole обходит композиты; KeycloakIdentity.hasClientRole доверяет модели пользователяЦелостностьВыведено из исходного кода. Оракул в лаборатории — полный GET realm
Вложенный realm-admin, когда именно он является композитомТот же обходЦелостностьВыведено. В лаборатории использовался manage-realm
Негативный контрольВторой пользователь с manage-users, который не сопоставляет композитн/дДоказано в лаборатории. Контрольный GET остаётся частичным

Остаётся закрытым в этом leftover

ОсьМетод / точка назначенияПочему закрыто
ЦелостностьПрямое сопоставление manage-realm / realm-admin / других AdminRoles.ALL_ROLESRolePermissionsV2.isRealmAdminRole по-прежнему отклоняет
ЦелостностьСоздать композит, включающий административную рольcanMapComposite по-прежнему вызывает checkAdminRoles
ЦелостностьПрисоединиться к группе, чей композит включает административную рольCVE-2026-94000 обходит композиты в GroupUtils.checkAdminGroupRoles
ЦелостностьСоздать пользователя, уже состоящего в этой группеТот же обход в UsersResource.createUser
РазведкаАнонимный Admin RESTТребуется токен manage-users
ЦелостностьRCE на хосте, выдача realm-admin через realm-adminВне класса

GET /admin/realms/{realm} не возвращает HTTP 403 для manage-users. Эта роль сама по себе является административной ролью, поэтому сервер возвращает 200 с частичным документом. Остаток — это поля, которые появляются только после маппинга композита.

Как я это нашёл

Я зафиксировал Keycloak 26.8.1. Детализированные административные разрешения v2 включены по умолчанию. RolePermissionsV2.canMapRole возвращает true для каждой роли, которая не проходит isRealmAdminRole, и никогда не обходит композиты. Исправление CVE-2026-94000 обходит их только на пути групп.

Уже зафиксированные неверные шаги: трактовка v1 isRealmAdminRole как актуальной проверки (v2 переопределяет её); ожидание HTTP 403 на GET realm до выдачи разрешения (фактический результат — частичный 200); повторная подача CVE-2026-94000 (вступление в группу, уже закрыто); обратная оболочка. Театр.

Лаборатория

python3 keycloak-manage-users-composite-Abraxas-Labs.py

или:

cd lab
./run.sh

Цель — только http://127.0.0.1:18082. Образ quay.io/keycloak/keycloak:26.8.1. Требуется Docker. Лаунчер выполняет chdir в lab/ и запускает run.sh.

IOC image=quay.io/keycloak/keycloak:26.8.1 label-version=26.8.1
IOC serverinfo-version=26.8.1
IOC admin-composite=manage-realm
IOC limited-direct=manage-users
IOC control-direct=manage-users
IOC before-status=200 witness=0 full=0
IOC available=sneaky-composite
IOC post-status=204
IOC after-get attempt=1 status=200 witness=1 full=1
IOC control-status=200 witness=0 full=0 same-token=1
SUCCESS KC-H02-ROLEMAP kcr02m7q4

Исправление

Обходите композитные роли в RolePermissionsV2.canMapRole так же, как это уже делает GroupUtils.checkAdminGroupRoles при присоединении к группе. Роль, включающая manage-realm или realm-admin, является административной ролью, даже если её собственное имя таковым не является.

Ссылки

  • github.com/keycloak/keycloak тег 26.8.1 (24ed1dadf3f246a555adb6d3d4a99e9b3003fb3b)
  • RolePermissionsV2.canMapRole (RolePermissionsV2.java:59-61)
  • RoleMapperResource.addRealmRoleMappings (RoleMapperResource.java:289-290)
  • Рядом (не этот путь): CVE-2026-94000 обход композитных ролей при присоединении к группе
  • CWE-269 · CWE-266

Лицензия

GNU Affero GPL v3.0. См. LICENSE. Только для лаборатории с обратной петлёй. Без гарантий.

Abraxas Labs [email protected]

Пожалуйста, указывайте авторство CVE за Abraxas Labs.

Скачать инструмент