CVE-2026-0300 Audit-Tooling

Schreibgeschützte Audit-Tooling für CVE-2026-0300 — den nicht authentifizierten Pufferüberlauf im PAN-OS User-ID Authentication Portal (früher bekannt als „Captive Portal") auf PA-Series- und VM-Series-Firewalls.

Dieses Repository begleitet das Sicherheitsadvisory TRG-SA-2026-003 der Tailwind Resource Group und bietet:

• audit_portal.py — Stufe 1: Audit einer einzelnen Firewall
• audit_fleet.py — Stufe 2: Panorama-gesteuerter Fleet-Sweep (parallel)
• panos_audit.py — gemeinsame Bibliothek, die von beiden CLIs verwendet wird

Die Skripte sind schreibgeschützt. Sie senden show-artige Abfragen an die PAN-OS-XML-API und ändern niemals die Konfiguration. Der API-Schlüssel wird über den HTTP-Header X-PAN-KEY gesendet und nicht als URL-Abfrageparameter, sodass er weder in den Zugriffsprotokollen der PAN-Verwaltungsebene, in TLS-prüfenden Proxy-Protokollen noch in den Prozessargumenten des Auditors auftaucht.

Warum es das gibt

Der CVE-Eintrag verwendet den modernen Feature-Namen „User-ID Authentication Portal". Das PAN-OS-XML-Schema, die CLI-Optionen und die Dokumentations-URL-Pfade verwenden weiterhin die veraltete captive-portal-Terminologie. Administratoren, die Flotten mit show config running | match authentication-portal prüfen, übersehen stillschweigend jede Konfiguration, da diese Zeichenfolge niemals als Konfigurationselement erscheint. Dieses Tooling durchsucht den schemakorrekten Elementnamen, unabhängig davon, wann die Konfiguration erstellt wurde.

Die vollständige Tailwind-Analyse zu dieser Namensfalle finden Sie in TRG-SA-2026-003, „Captive Portal's legacy footprint".

Anforderungen

• Python 3.10 oder neuer
• Nur Standardbibliothek — kein pip install erforderlich
• Ein PAN-OS-API-Schlüssel mit Lesezugriff auf die Firewall (oder, für Stufe 2, auf Panorama)
• Ein CA-signiertes (oder vom Betreiber vertrauenswürdiges) Zertifikat auf der Verwaltungsschnittstelle der Firewall; --insecure ist nur für einmalige Bring-up-Audits vorgesehen

Stufe 1 — einzelne Firewall

export PAN_API_KEY="<key>"
./audit_portal.py --hostname fw1.example.com

Beispiel für Tabellenausgabe:

vsys: vsys1
  configured:    True
  enabled:       True
  redirect_host: auth-portal.internal.example.com
  mode:          redirect
  bound:         ethernet1/3(internal-trust), ethernet1/4(guest)
  tls_verified:  True
  risk:          EXPOSED_LIKELY

Weitere Ausgabeformate: --output json oder --output csv.

Weitere Flags: --vsys <name> für das Audit eines einzelnen vsys, --timeout/--retries für langsame Upstreams, --debug für ausführliche Fehlerdetails auf stderr.

Stufe 2 — Panorama-Fleet-Sweep

export PAN_API_KEY="<panorama-key>"
./audit_fleet.py --hostname panorama.example.com --workers 16 --output csv > fleet-audit.csv

Jede Zeile in der CSV ist ein Gerät-vsys mit Portalstatus, Redirect-Host, Modus, Schnittstellenbindungen und einer Risikoklassifizierung. Das Skript verwendet den Panorama-API-Parameter target=<serial>, sodass es niemals direkt eine Verbindung zu verwalteten Firewalls herstellt — eine Verbindung zu Panorama durchsucht die gesamte Flotte.

Bemerkenswerte Flags:

• --workers N — parallele Audit-Threads (Standard 8, max. 32). Eine Flotte mit 1000 Geräten wird in Minuten statt in über einer Stunde abgeschlossen, die ein serieller Sweep benötigen würde.
• --timeout, --retries — Einstellungen pro API-Aufruf. Vorübergehende URLError- und HTTP-5xx-Fehler werden mit begrenztem Backoff erneut versucht.
• --exclude-disconnected — standardmäßig werden getrennte Geräte mit risk=DISCONNECTED einbezogen, damit sie während des Patch-Fensters sichtbar bleiben. Verwenden Sie dieses Flag, um sie auszuschließen.
• --min-expected-devices N — Warnung (stderr), wenn Panorama weniger Geräte als N zurückgibt. Nützlich, um eine Antwortkürzung bei bekannter Flottengröße zu erkennen.
• --serial-filter '0007*' — Glob-Filter nach Seriennummer, um eine Teilmenge zu prüfen.
• --debug — ausführliche Fehlerdetails pro Gerät auf stderr ausgeben (enthält Upstream-reason-Zeichenfolgen; standardmäßig deaktiviert, um zu vermeiden, dass Hostnamen in kundenorientierte CSVs gelangen).

Risikoklassifizierung

Die Spalte risk in der Ausgabe ist eine der folgenden:

Label	Bedeutung
INFO_NOT_CONFIGURED	Kein <captive-portal>-Block auf dem Gerät. Außerhalb des Geltungsbereichs von CVE-2026-0300.
INFO_DISABLED	Portal ist konfiguriert, aber enabled=no. Der anfällige Codepfad ist nicht aktiv.
REVIEW_POLICY_NO_BINDINGS	Portal aktiviert, aber keine Schnittstellenbindungen in der Konfiguration gefunden. Über die WebUI verifizieren.
EXPOSED_LIKELY	Portal aktiviert und an eine Zone gebunden, deren Name auf ungeschützte Exposition hindeutet (untrust, dmz, guest, external, internet, wan, public). Zuerst untersuchen.
REVIEW_POLICY	Portal aktiviert und an intern benannte Zonen gebunden. Sicherheitsrichtlinie prüfen, um die Erreichbarkeit zu bestätigen.

EXPOSED_LIKELY ist ein Hinweis, kein Urteil — Zonennamen sind Betreiberkonventionen, keine Durchsetzung. Das Skript kann eine Sicherheitsrichtlinien-Prüfung nicht ersetzen; es sortiert eine Flottenausgabe so, dass zuerst dort Aufmerksamkeit entsteht, wo sie nötig ist.

Was die Skripte tun — und was nicht

Tun:

• <captive-portal>-Blöcke pro vsys abfragen (der Schem-Elementname ist immer captive-portal, unabhängig von der UI-Benennung oder der PAN-OS-Version).
• Aktiviert/deaktiviert, Redirect-Host, Modus und zonenaufgelöste Schnittstellenbindungen melden.
• Risiko nach Zonennamen-Heuristik klassifizieren, sodass EXPOSED_LIKELY-Zeilen zuerst in der Flottenausgabe erscheinen.
• Den API-Schlüssel über den X-PAN-KEY-Header senden, damit er nicht in URL-Zugriffsprotokollen und Prozessargumenten auftaucht.
• Antwortkörpergröße begrenzen (50 MB), um sich gegen Entity-Expansion-Angriffe auf den XML-Parser zu verteidigen.
• Vorübergehende Fehler mit begrenztem Backoff erneut versuchen.

Tun nicht:

• Sicherheitsrichtlinie umfassend prüfen. Ob das Portal von einem ungeschützten Netzwerk aus erreichbar ist, hängt von Richtlinienregeln, NAT und Zonenbindungen ab — der Betreiber muss diese Prüfung anhand der Audit-Ausgabe durchführen.
• Erreichbarkeit durch Netzwerkprobe testen. Nur reine Konfigurationsprüfung.
• Konfiguration ändern. Alle API-Aufrufe sind schreibgeschützt.

Generieren eines PAN-OS-API-Schlüssels

Der PAN-OS-API-Schlüssel erbt die Rolle und Berechtigungen des Benutzers, der ihn generiert.

Wichtiger Hinweis: Es gibt keine schreibgeschützte XML-API-Berechtigung in PAN-OS.

Die Berechtigungen der Admin-Rolle auf der Registerkarte XML-API sind binär Aktivieren/Deaktivieren pro Kategorie — Konfiguration, Betriebsanfragen, Commit, Export, Import, Report, Log, User-ID-Agent. Das Aktivieren von Konfiguration für die XML-API erlaubt sowohl show- als auch set/edit/delete/move/rename/clone-Aktionen. Das Aktivieren von Betriebsanfragen erlaubt beliebige <request>-Operationen, einschließlich <request><restart>. Die Registerkarten Web-UI und REST-API bieten „Nur Lesen" als Option an; die Registerkarte XML-API nicht.

Ein „Audit-Benutzer", der durch Aktivieren dieser XML-API-Kategorien erstellt wird, besitzt volle XML-API-Schreibberechtigung auf dem Gerät. Behandeln Sie den resultierenden Schlüssel als privilegierte Anmeldeinformation: Begrenzen Sie seine Lebensdauer auf das Audit-Fenster, speichern Sie ihn in einem Secrets-Manager und deaktivieren Sie den Benutzer, wenn die Arbeit abgeschlossen ist.

Kanonische PAN-Referenz: Get Your API Key (PAN-OS XML API).

Über die WebUI