pfSense Plus MIM API toolkit b4acd7ca - Hoch - Remote - Privilegien-Rest - GET export-key private keys
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · pfsense-api-export-key-get
Klasse: Privilegien-Überrest Reichweite: Remote
pfSense Plus MIM API (Netgate) Pin b4acd7ca – öffentliches OpenAPI + generierter Python-Client für den Nexus Multi-instance Management Controller.
GET /system/certauth/{refid}/export-key ist dokumentiert als „Download the CA certificate signing key". GET /system/certificates/{refid}/export-key ist „Download the certificate's private key". GET /system/certificates/{refid}/export-p12 ist eine einheitliche PKCS12-Datei ohne Passwortschutz. Die Dokumentation ordnet GET unter /system mim_system_read / mim_read_system zu. mim_view ist dokumentiert als ohne vertrauliche Informationen. Die Spezifikation hat keine securitySchemes und keine per-Operation-Sicherheit. Das generierte _get_kwargs ist Methode plus eine quotierte URL. Autorisierung wird dort nie hinzugefügt.
Dies ist kein PHP, keine Shell und kein Firmware-POST. Ein gestohlenes JWT aus dem G9 Sample TLS Skip oder ein G6 Fleet-Token reicht aus, um diese GETs aufzurufen. Ob ein lese-förmiges MIM-JWT auf Plus ausreicht, ist der Überrest. Ich habe Plus nicht ausgeführt. Plus RBAC wurde nicht ausgeführt.
| ID | noch keine CVE |
| Klasse | Privilegien-Überrest |
| Reichweite | Remote (authentifiziertes HTTP an den Nexus-Controller; das Lab ist der öffentliche Client-Vertrag) |
| CWE | CWE-200, CWE-862 |
| CVSS | Hoch: 8.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, falls ein lese-förmiges MIM-JWT diese GETs aufrufen kann |
| Produkt | Netgate/pfsense-api (pfSense Plus Nexus MIM Controller OpenAPI + generierter Client) |
| Betroffen | Pin b4acd7ca21dbca739a530403a1f62a7440f7726f (2026-05-25). OpenAPI 3.0.3 Titel pfSense API Version 1.0. Plus 25.11+. Nicht das CE-REST-Paket. |
| Auth | Dokumentiertes Nexus-JWT (POST /login, Bearer). Das Lab ist der öffentliche OpenAPI- plus generierte _get_kwargs-Vertrag. Plus RBAC wurde nicht ausgeführt. |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1:19141. Kein Plus-Image. |
Ich habe github.com/Netgate/pfsense-api b4acd7ca21dbca739a530403a1f62a7440f7726f gepinnt. Nicht master nach diesem Tag. Nicht das Drittanbieter-CE-Paket jaredhendrickson/pfsense-api.
Serien-Hub: pfsense-api-nexus-mim. Dieses Paket ist Teil 4.
Die Dokumentation ordnet GET unter /system mim_system_read / mim_read_system zu. mim_view ist dokumentiert als ohne vertrauliche Informationen. Der Überrest ist der Private-Key-Export per GET, mit PKCS12 dokumentiert als ungeschützt, und generiertem _get_kwargs, das nie Authorization hinzufügt.
| Methode | Pfad | Berechtigung |
|---|---|---|
GET DownloadCAKey | /system/certauth/{refid}/export-key | Recon (im Lab auf Mock nachgewiesen): application/octet-stream-Body mit dem Witness-PEM. Auf Plus vermutet: CA-Zertifikatssignaturschlüssel, falls RBAC das GET erlaubt. |
GET GetCertKey | /system/certificates/{refid}/export-key | Recon (im Lab auf Mock nachgewiesen): Witness-PEM. Auf Plus vermutet: Leaf-Privatschlüssel. |
GET GetCertP12 | /system/certificates/{refid}/export-p12 | Recon (im Lab auf Mock nachgewiesen): derselbe Witness-Body. Auf Plus vermutet: Zertifikat plus Schlüssel als PKCS12 ohne Passwortschutz (OpenAPI-Zusammenfassung). |
Generierte _get_kwargs | alle drei Operationen | Recon (im Lab nachgewiesen): kwargs sind nur method plus quotiertes url. Keine headers, kein Authorization, kein Bearer. |
Client (kein Token) | alle drei Operationen | Recon (im Lab nachgewiesen): drei Mock-Treffer mit has_authorization=false und Witness-Body (client-no-auth=yes, witness-body=yes). |
AuthenticatedClient | alle drei Operationen | Recon (im Lab nachgewiesen): drei Mock-Treffer mit Authorization: Bearer mock-token (authed-bearer=3). Bearer ist eine Wrapper-Eigenschaft, nicht _get_kwargs. |
| Gestohlenes JWT aus G9-MITM oder G6-Flottentoken | dieselben drei GETs, plus /api/device/pfsense/{device_id}/api, falls der Flottenrest Bestand hat | Recon (vermutet, verkettet): CA-/Leaf-Schlüssel für den Controller und jede eingetragene Instanz abrufen, die das Token benennen kann. |
| Gestohlene CA-/Leaf-Schlüssel verwenden | TLS-, VPN-, IPsec-, WebGUI-Zertifikate | Integrität (vermutet, nicht im Lab getestet): Nachkommen-Zertifikate als die CA ausstellen; den Nexus-TLS-Namen imitieren; Tunnel entschlüsseln, die diese Zertifikate verwenden. Nicht Unix-Root an sich. |
| Verwandte Listen-/Detail-GETs | /system/certauth?withprivkey=true, Zertifikatsfelder prv / private_key | Recon (Spezifikation, nicht dieses Lab): Massenausgabe derselben Geheimnisse. Hier nicht ausgeführt. |
Verfügbarkeit: keine erforderlich.
Im Lab nachgewiesen vs. vermutet: Die drei OpenAPI-GET-Pfade, die PKCS12-Formulierung „ohne Passwortschutz", _get_kwargs ohne Authorization, drei Client-Treffer ohne Auth mit Witness-PEM, drei AuthenticatedClient-Bearer-Treffer und der Pin-Klon von pfapi_openapi.yml sind im Lab nachgewiesen. Plus mim_system_read / mim_view 200er, das Ausstellen von Nachkommen-Zertifikaten und der flottenweite Schlüsselabruf sind vermutet. Plus RBAC wurde nicht ausgeführt.
Erfordert (vermutet, Plus nicht ausgeführt): Nexus-Login plus eine Gruppe, die GET unter /system/certauth und /system/certificates erlaubt. Nicht admins / mim_superuser, falls der Rest real ist. Nicht Diagnostics: Command. Netzwerkpfad zum Controller :8443 (oder zum Geräteproxy) mit einem JWT.
