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

pfsense-api-acme-key-dump

Класс: Остаточные привилегии Доступ: Удалённый

pfSense Plus Nexus Multi-instance Management OpenAPI-инструментарий b4acd7ca — Netgate

GET /services/acme (GetACMEConfig) возвращает ACMEConfig без флага write-only или redacted. Схема ответа 200 включает приватный ключ учётной записи ACME, каждый выпущенный приватный ключ конечного сертификата, любой пользовательский ключ конечного сертификата и токены DNS-провайдеров, используемые для валидации. У менеджера сертификатов хотя бы есть выделенный GET .../export-key. У ACME такого нет. GET конфигурации — это и есть дамп.

Сессия контроллера, способная выполнить GET по этому пути, копирует каждый ключ hostname, который регистрирует межсетевой экран, а также учётные данные DNS, подтверждающие контроль над этими именами.

Это дерево — публичный OpenAPI плюс сгенерированный Python-клиент. Это не пакет CE REST. Контроллер MIM доступен только в Plus и отсутствует в репозитории GitHub. Я не взаимодействовал с живым контроллером. plus-not-executed=1.

ID	CVE пока нет
Класс	Остаточные привилегии (дамп секретов при GET конфигурации)
Доступ	Удалённый (аутентифицированный контроллер MIM; неаутентифицированный доступ не доказан)
CWE	CWE-200
CVSS	Высокий: 6.5 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, если роль с доступом на чтение сервисов получает тело ответа. Если GET доступен только суперпользователю, дамп всё равно имеет неправильную форму для листинга конфигурации.
Продукт	Netgate/pfsense-api OpenAPI для pfSense Plus Nexus MIM
Затронуто	публичная ветка main b4acd7ca21dbca739a530403a1f62a7440f7726f (2026-05-25, Add Snort-3 API definitions). Тегов нет.
Аутентификация	JWT контроллера из POST /login. Примеры отправляют Bearer. В спецификации нет securitySchemes.
Лицензия	GNU Affero GPL v3.0
Лаборатория	только 127.0.0.1:19151. Образ Plus отсутствует.

Хаб серии: pfSense Plus MIM leftovers. Это часть 5. Связывается с G9 stolen JWT (примеры устанавливают verify_ssl=False) и G6 fleet token (один Bearer от логина переиспользуется для каждого device_id). Родственный дамп: G4 cert-manager export-key.

Что может сделать атакующий

Требуется сессия контроллера, способная выполнить GET /services/acme. Документация сопоставляет это с mim_services_read / mim_services / mim_superuser. Спецификация не привязывает эти роли к пути. RBAC в Plus не выполнялся.

Украденного JWT из G9 (MITM официальных примеров) или fleet-токена службы поддержки из G6 достаточно, чтобы направить этот GET на каждый зарегистрированный узел. Эта цепочка выведена предположительно. Данный остаток — это тело ответа GET.

Разведка

Метод	Sink	Привилегия
GET /services/acme	ACMEConfig.account_keys[].account_key (format: byte)	Лабораторно подтверждено на опубликованной спецификации и mock: схема 200 включает account_key; тело mock выполняет round-trip PFSENSE-API-ACME-KEY-DUMP-WITNESS. Предполагается на Plus: скопировать приватный ключ аккаунта Let's Encrypt (или другого ACME). Обратиться к ACME-аккаунту извне.
Тот же GET	certs[].issued_cert.privateKey (format: byte)	Лабораторно подтверждено спецификацией+mock. Предполагается на Plus: скопировать каждый выданный приватный ключ leaf-сертификата, который зарегистрировал firewall. TLS-имперсонация извне для этих имён.
Тот же GET	certs[].custom_key (format: byte)	Лабораторно подтверждено спецификацией+mock. Предполагается на Plus: скопировать пользовательский leaf-ключ при key_type=custom.
Тот же GET	certs[].domain_list[].config.credentials (additionalProperties: string)	Лабораторно подтверждено спецификацией+mock. Предполагается на Plus: скопировать секреты DNS-валидации (токены Cloudflare, ключи AWS, секреты RFC2136). Они доказывают контроль над именами.
Тот же GET	email аккаунта, пользовательские URL серверов, action_list.command	Лабораторно подтверждено, что поля присутствуют в схеме. Выполнение hook — это путь модификации, а не этот GET.

Целостность

Отсутствует в самом GET. Последующее использование украденных ключей и DNS-токенов происходит вне устройства (выпуск подложного сертификата, обращение к ACME-аккаунту, изменение DNS). Не проверялось.

Доступность

Отсутствует. Листинг конфигурации не отзывает и не перезаписывает сертификаты.

Требуется: аутентифицированный доступ к MIM-контроллеру, которому разрешён GET тега ACME. Не подтверждено как неаутентифицированное. Сгенерированный _get_kwargs для этой операции не добавляет Authorization; примеры всё равно выполняют вход и отправляют Bearer.

Смежная поверхность, которая остаётся закрытой

Поверхность	Причина
Живой контроллер pfSense Plus / Nexus	Не выполнялось. plus-not-executed=1.
Неаутентифицированный доступ из Интернета к 8443	Примеры требуют POST /login. Отсутствие security в OAS — это пробел в спецификации, а не доказательство ответа сервера 200 без JWT.
POST /services/acme/cert/{name}/issue и .../renew	Предназначено для модификации сервисов.
POST /services/acme/genprivatekey	Предназначено для генерации и возврата нового ключа аккаунта. Не этот остаток.
POST /diag/cmd/php / POST /diag/cmd/shell	Предназначено для админ-консоли. Отдельная поверхность. Вендор считает Diagnostics: Command предназначенным (CVE-2025-69691 оспаривается).
GET /system/certificates/{refid}/export-key	Отдельный остаток: выделенный экспорт ключа в менеджере сертификатов. В ACME нет эквивалентной операции экспорта.
GET /services/acme/validmethods	Каталог методов. Без ключей.
CE jaredhendrickson/pfsense-api	Другой продукт.

Как я это нашёл

Я зафиксировал публичный Netgate/pfsense-api b4acd7ca после волны CE 2.9.0-DEVELOPMENT. Это дерево — OpenAPI 3.0.3 (pfapi_openapi.yml, 486 путей, 755 операций) плюс сгенерированный Python-клиент для MIM-контроллера Plus на :8443. Тегов нет. Последний публичный коммит на день клонирования — 2026-05-25, "Add Snort-3 API definitions."

Двенадцать поисков по login/JWT, диагностике, MIM-регистрации, клиентскому TLS, пользователям/сертификатам, пакетам, VPN/firewall, безопасности OpenAPI, IDOR устройств, git/прошивкам/фидам, а также loopback-mock каждой сгенерированной операции.