abraxaslabs.tech  ·  github.com/abraxas  ·  @abraxas_null  ·  [email protected]  ·  pfsense-api-acb-userkey

pfsense-api-acb-userkey

Класс: IDOR Достижимость: Удалённая

pfSense Plus MIM API (Netgate/pfsense-api b4acd7ca) - Netgate

GET /services/acb и GET /services/acb/bkp принимают userkey как неограниченный параметр запроса. Сгенерированный Python-клиент помещает этот ключ в строку запроса. В YAML нет securitySchemes. Проверкой является наличие ключа устройства Auto Config Backup. Это capability URL.

Украденный или утёкший ACB userkey перечисляет размещённые резервные копии этого устройства и извлекает тело ревизии. Полная конфигурация находится в этих блобах. Тот же класс, что и ключ CE ACB CVE-2024-57273 / SA-25_03, если ключ утечёт. Та CVE была выводом из SSH-баннера. Этот остаток — родственный случай с параметром запроса в Plus MIM API. Я не подаю повторно вывод из баннера.

Это публичный OpenAPI + сгенерированный клиент для pfSense Plus Nexus Multi-instance Management (контроллер на :8443). Это не CE REST-пакет (jaredhendrickson/pfsense-api / pfrest.org). Сервер только для Plus (платный). Я не запускал pfSense Plus.

ID	пока нет CVE
Класс	IDOR (capability URL)
Достижимость	Удалённая
CWE	CWE-639
CVSS	High: 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, если эти GET-запросы принимают userkey без привязки JWT к устройству
Продукт	Netgate/pfsense-api (pfSense Plus MIM OpenAPI + сгенерированный клиент)
Затронуто	пин b4acd7ca21dbca739a530403a1f62a7440f7726f (2026-05-25). Тегов нет.
Аутентификация	Спецификация: отсутствует (securitySchemes нет). userkey — секрет в запросе. Plus JWT/RBAC не выполнялся.
Лицензия	GNU Affero GPL v3.0
Лаборатория	только 127.0.0.1:19171. Образа Plus нет.

Хаб серии: pfsense-api-nexus-mim (это часть 7).

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

Требуется украденный или утёкший ACB userkey (спецификация: "hexidecimal encoded 32-byte random bytes", 64 hex). Спецификация не привязывает этот ключ к JWT или к устройству вызывающего. GET /services/acb/config класса G11 возвращает живой userkey. Примеры G9 устанавливают verify_ssl=False, поэтому MITM на :8443 может увидеть ключ в трафике. Это пути утечки. Этот остаток — то, что даёт ключ, когда он оказывается снаружи.

Разведка

Метод	Sink	Привилегия
GET /services/acb?userkey=<stolen>	GetACBList (pfapi_openapi.yml). Сгенерированный get_acb_list.py params["userkey"].	Подтверждено в лаборатории (mock): список размещённых на этом устройстве резервных копий. Свидетельство в backups[].reason.
GET /services/acb/bkp?userkey=<stolen>&revision=	GetACB -> RetrievedBackup.backup. Сгенерированный get_acb.py params["userkey"] + params["revision"].	Подтверждено в лаборатории (mock): получение тела ревизии. Свидетельство в backup.
Та же строка резервной копии на живом контроллере	размещённый ACB blob	Предположительно: полный config.xml (пользователи, ключи, пакеты) при возможности чтения. Mock вернул открытый текстовый XML-свидетель. Я не обращался к acb.netgate.com и не расшифровывал живой blob.
GET /services/acb/config	ACBConfigInfo.userkey, ACBConfig.encryption_password	Спецификация, не эта лаборатория: секрет живой возможности и пароль расшифровки. Класс G11 secrets-on-GET. Не проверялось.

Целостность

Метод	Sink	Привилегия
POST /services/acb/restore	RestoreACB тело { timestamp }	Смежное закрыто: образцы всё ещё отправляют JWT. Не этот остаток. Не выполнялось.
POST /services/acb/config замена userkey	SaveACBConfig	Смежное закрыто: не GET-URL возможности. Не выполнялось.

Доступность

GET list / GET bkp не удаляют. DELETE /services/acb/bkp/{timestamp} — другая операция. Не проверялось.

Неверный userkey и отсутствующий userkey не вернули свидетельства (подтверждено в лаборатории).

Подтверждено в лаборатории vs предположительно: список и bkp с украденным ключом вернули свидетельство. Неверный ключ и отсутствующий ключ — нет. Plus не выполнялся. Содержимое живого config.xml и расшифровка предполагаются из публичной схемы (RetrievedBackup.backup — строка; encryption_password находится в ACBConfig).

Требуется: сетевой путь к ACB GET-запросам MIM-контроллера, плюс украденный/утекший userkey. CVSS 7.5, если эти GET-запросы принимают ключ из запроса без привязки JWT к устройству. Честно: этот пакет доказывает, что публичная спецификация моделирует такой контракт, на loopback.

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

Поверхность	Почему
Контроллер pfSense Plus	не выполнялся. В этом пакете нет образа Plus.
Пакет CE REST	другой сервер (jaredhendrickson/pfsense-api / pfrest.org).
Вывод ключа ACB из SSH-баннера	CVE-2024-57273 / SA-25_03. Не подавать повторно.
POST /services/acb/restore как эта находка	образцы всё ещё отправляют JWT.
Неаутентифицированный php/shell из пропущенного OAS security	остаток документации. Mock не является доказательством сервера 200-без-JWT.
Отсутствующий userkey	лаборатория 403, нет свидетельства.
Неверный userkey	лаборатория: список пуст / bkp 403, нет свидетельства.
Сгенерированная библиотека verify_ssl	по умолчанию True. G9 — это образцы, отключающие его, а не значение по умолчанию пакета.

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

Я зафиксировал Netgate/pfsense-api main b4acd7ca (2026-05-25, "Add Snort-3 API definitions"). Двенадцать поисков по login/JWT, диагностике, MIM-регистрации, клиентскому TLS, пользователям/сертификатам, пакетам, VPN/фаерволу, безопасности OpenAPI, IDOR устройств, git/прошивке/фидам, плюс loopback-mock каждой сгенерированной операции.

Сначала список пропуска: остатки CE WebGUI уже отправлены (QinQ parent if, OpenVPN wizard CRLF, CARP VHID, limiter number, IPsec login banner). Диагностические PHP/shell как предполагаемые админские полномочия. Сторонний пакет CE REST. Вывод из баннера CVE-2024-57273.