abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  pfsense-api-acme-key-dump

pfsense-api-acme-key-dump

Classe : Résidu de privilège Portée : Distante

pfSense Plus Nexus Multi-instance Management Boîte à outils OpenAPI b4acd7ca - Netgate

GET /services/acme (GetACMEConfig) renvoie ACMEConfig sans indicateur write-only ni de caviardage. Le schéma 200 inclut la clé privée du compte ACME, chaque clé privée de feuille émise, toute clé de feuille personnalisée, ainsi que les jetons du fournisseur DNS utilisés pour la validation. Le gestionnaire de certificats dispose au moins d'un GET .../export-key dédié. ACME n'en a aucun. Le GET de configuration est la fuite.

Une session de contrôleur capable de faire un GET sur ce chemin copie chaque clé de nom d'hôte que le pare-feu enrôle, ainsi que les identifiants DNS qui prouvent le contrôle de ces noms.

Cet arbre est l'OpenAPI public plus un client Python généré. Ce n'est pas le paquet REST CE. Le contrôleur MIM est réservé à Plus et n'est pas dans le dépôt GitHub. Je n'ai pas communiqué avec un contrôleur en production. plus-not-executed=1.

ID	pas encore de CVE
Classe	Résidu de privilège (fuite de secret lors du GET de configuration)
Portée	Distante (contrôleur MIM authentifié ; non prouvé sans authentification)
CWE	CWE-200
CVSS	Élevé : 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N si un rôle de lecture des services reçoit le corps. Si seul le superutilisateur peut faire le GET, la fuite reste une mauvaise forme pour un listing de configuration.
Produit	Netgate/pfsense-api OpenAPI pour pfSense Plus Nexus MIM
Affecté	main public b4acd7ca21dbca739a530403a1f62a7440f7726f (2026-05-25, Add Snort-3 API definitions). Aucun tag.
Auth	JWT du contrôleur depuis POST /login. Les exemples envoient Bearer. La spécification n'a pas de securitySchemes.
Licence	GNU Affero GPL v3.0
Lab	127.0.0.1:19151 uniquement. Pas d'image Plus.

Hub de la série : pfSense Plus MIM leftovers. Ceci est la partie 5. S'enchaîne avec G9 stolen JWT (les exemples définissent verify_ssl=False) et G6 fleet token (un seul Bearer de connexion est réutilisé pour chaque device_id). Fuite sœur : G4 cert-manager export-key.

Ce qu'un attaquant peut faire

Nécessite une session de contrôleur capable de GET /services/acme. La documentation associe cela à mim_services_read / mim_services / mim_superuser. La spécification n'attache pas ces rôles au chemin. Le RBAC de Plus n'a pas été exécuté.

Un JWT volé issu de G9 (MITM des exemples officiels) ou un jeton de flotte de helpdesk issu de G6 suffit pour pointer ce GET vers chaque machine enrôlée. Cette chaîne est déduite. Ce résidu est le corps du GET.

Reconnaissance

Méthode	Point de fuite	Privilège
GET /services/acme	ACMEConfig.account_keys[].account_key (format: byte)	Prouvé en laboratoire sur la spécification publiée et le mock : le schéma 200 inclut account_key ; le corps du mock effectue un aller-retour avec PFSENSE-API-ACME-KEY-DUMP-WITNESS. Déduit sur Plus : copier la clé privée du compte Let's Encrypt (ou autre ACME). Communiquer avec le compte ACME depuis l'extérieur de la machine.
Même GET	certs[].issued_cert.privateKey (format: byte)	Prouvé en laboratoire spec+mock. Déduit sur Plus : copier chaque clé privée de feuille émise que le pare-feu a enrôlée. Usurpation TLS hors machine pour ces noms.
Même GET	certs[].custom_key (format: byte)	Prouvé en laboratoire spec+mock. Déduit sur Plus : copier une clé de feuille personnalisée lorsque key_type=custom.
Même GET	certs[].domain_list[].config.credentials (additionalProperties: string)	Prouvé en laboratoire spec+mock. Déduit sur Plus : copier les secrets de validation DNS (jetons Cloudflare, clés AWS, secrets RFC2136). Ceux-ci prouvent le contrôle des noms.
Même GET	e-mails de compte, URL de serveur personnalisées, action_list.command	Prouvé en laboratoire que les champs figurent sur le schéma. L'exécution de hook est un chemin de modification, pas ce GET.

Intégrité

Aucune par le GET lui-même. L'utilisation ultérieure des clés volées et des jetons DNS se fait hors machine (émettre un certificat frauduleux, communiquer avec le compte ACME, modifier le DNS). Non exercé.

Disponibilité

Aucune. Le listage de configuration ne révoque ni ne réécrit les certificats.

Nécessite : un accès authentifié au contrôleur MIM autorisé à effectuer un GET sur le tag ACME. Non prouvé sans authentification. Le _get_kwargs généré pour cette opération n'ajoute pas d'Authorization ; les exemples se connectent toujours et envoient un Bearer.

Surface adjacente qui reste fermée

Surface	Raison
Contrôleur pfSense Plus / Nexus en production	Non exécuté. plus-not-executed=1.
Internet vers 8443 sans authentification	Les exemples nécessitent POST /login. L'absence de security dans l'OAS est une lacune de spécification, pas une preuve de serveur renvoyant 200 sans JWT.
POST /services/acme/cert/{name}/issue et .../renew	Modification de services prévue.
POST /services/acme/genprivatekey	Génération et renvoi prévus d'une nouvelle clé de compte. Pas ce résidu.
POST /diag/cmd/php / POST /diag/cmd/shell	Console d'administration prévue. Surface distincte. Le fournisseur considère Diagnostics: Command comme prévu (CVE-2025-69691 contesté).
GET /system/certificates/{refid}/export-key	Résidu distinct : export de clé dédié sur le gestionnaire de certificats. ACME n'a pas d'opération d'export équivalente.
GET /services/acme/validmethods	Catalogue de méthodes. Aucune clé.
CE jaredhendrickson/pfsense-api	Produit différent.

Comment je l'ai trouvé

J'ai épinglé le dépôt public Netgate/pfsense-api b4acd7ca après la vague CE 2.9.0-DEVELOPMENT. Cette arborescence est OpenAPI 3.0.3 (pfapi_openapi.yml, 486 chemins, 755 opérations) plus un client Python généré pour le contrôleur MIM Plus sur :8443. Aucun tag. Le dernier commit public au jour de mon clonage était le 2026-05-25, « Add Snort-3 API definitions. »

Douze recherches sur login/JWT, diagnostics, enrôlement MIM, TLS client, utilisateurs/certificats, paquets, VPN/pare-feu, sécurité OpenAPI, IDOR d'appareil, git/firmware/feeds, plus un mock loopback de chaque opération générée.