Ошибка в проверке привилегий веб-интерфейса pfSense позволяет пользователю с действующими учётными данными внешней службы аутентификации выполнить произвольный код на межсетевом экране. Netgate исправила проблему 26 августа 2026 года, а публично о ней рассказали 15 сентября вместе с бюллетенем безопасности pfSense-SA-26_22. Затронуты выпуски pfSense CE до версии 2.9.0 и pfSense Plus до версии 26.07. Условие одно, но важное: вход администраторов должен быть настроен через внешний сервер каталогов, а не через локальные учётные записи устройства.
Детали уязвимостей
pfSense - свободный дистрибутив межсетевого экрана на основе FreeBSD. Он закрывает почти всё, что ждут от коммерческого устройства этого класса: фильтрацию трафика, VPN, балансировку каналов, ведение журналов. Настройка идёт через веб-интерфейс, поэтому командная строка нужна редко. Этим pfSense отличается от многих сборок на Linux, где правка конфигурации вручную остаётся привычной практикой. Именно веб-интерфейс содержит ошибку. Netgate развивает и платную ветку Plus для своих устройств и облачных провайдеров, тогда как CE остаётся свободной сборкой.
Проблема сидит в интерфейсе удалённого вызова процедур, известном как XML-RPC. Через него администраторы синхронизируют настройки между несколькими межсетевыми экранами, выгружают резервные копии, меняют параметры кластера. Перед вызовом метода система проверяет права учётной записи. Логика проверки ломается, когда аутентификация настроена через LDAP (протокол обращения к службе каталогов) или RADIUS (протокол централизованной проверки подлинности). В корпоративной сети такие настройки обычны, поскольку избавляют от ручного заведения учётных записей на каждом узле.
Проверка запрашивает данные об учётной записи в локальной базе устройства. Если совпадающей записи нет, набор сведений приходит неполным. Ошибка в логике мешает коду заметить нехватку прав, и запрос уходит дальше. В результате внешний пользователь может вызывать методы, для которых нужно отдельное право на синхронизацию конфигурации отказоустойчивого кластера. Действительного пароля каталога при этом достаточно.
Среди доступных методов есть запуск кода на PHP. Он равносилен выполнению произвольных команд оболочки от имени веб-сервера. Дальше всё зависит от изобретательности атакующего. Он может прочитать конфигурацию, вытащить ключи VPN, добавить правило фильтрации или закрепиться в системе. Межсетевой экран стоит на границе сети, и контроль над ним даёт доступ к внутренним сегментам. Право на синхронизацию конфигурации здесь не формальность: оно позволяет менять правила сразу на всех узлах кластера.
Для атаки нужны действующие учётные данные каталога. Это снижает риск, поскольку случайный сканер интернета до уязвимой функции не доберётся. Зато корпоративные каталоги нередко содержат десятки и сотни записей. Часть из них принадлежит подрядчикам и уволенным сотрудникам, и такие учётные данные забывают отключать. К тому же пароли каталога утекают при целевом фишинге. Уязвимость нашёл Алекс Уильямс из Pellera Technologies, работавший вместе с TrendAI Zero Day Initiative. В бюллетене нет сведений о том, что кто-то применял её в реальных атаках.
Заметить чужой вызов через интерфейс удалённого управления трудно. В журналах останутся записи о подключении к веб-интерфейсу, но они мало отличаются от обычной работы администратора. Помогает ограничение доступа к панели управления по спискам адресов и запрет входа из интернета. Проверить, подходит ли устройство под условие уязвимости, можно в настройках аутентификации. Если там указан сервер LDAP или RADIUS и вход через него включён, риск есть.
pfSense выбирают небольшие компании, промышленные площадки, учебные заведения и государственные структуры. Причина простая: продукт бесплатный или недорогой, а возможностей хватает для замены проприетарного межсетевого экрана начального уровня. Если такой экран защищает сеть с сотнями рабочих мест, компрометация обернётся остановкой сервисов и утечкой данных. Правила фильтрации, туннели между офисами и списки доступа к внутренним ресурсам окажутся в руках чужого человека.
Исправленные сборки появятся после 26.07 для pfSense Plus и после 2.9.0 для pfSense CE. Обновиться можно из веб-интерфейса или с консоли. Администраторам на более старых выпусках стоит поставить пакет System Patches и применить рекомендованные исправления из его списка. Если обновление пока невозможно, есть два обходных пути. Первый: завести локальную учётную запись для каждого внешнего пользователя каталога, чтобы проверка прав всегда находила совпадение. Второй: отказаться от внешней аутентификации для входа в саму систему. Обе меры снижают риск, но не убирают уязвимость полностью.
С момента исправления до публикации бюллетеня прошло около трёх недель. Такой разрыв даёт производителю время разослать сборки, зато сокращает запас у тех, кто обновляется медленно. Ошибки в логике проверки прав встречаются реже, чем переполнение буфера или внедрение команд, и потому остаются незамеченными дольше. Интеграция с корпоративными каталогами добавляет продуктам функций и одновременно расширяет поверхность атаки. Управление исправлениями в небольших сетях часто держится на одном человеке, и очередь обновлений доходит до межсетевого экрана в последнюю очередь. Администраторам pfSense стоит сверить версию устройства с перечнем уязвимых выпусков. Заодно не помешает вычистить каталог от неактуальных учётных записей: даже после установки исправления лишние права никому не полезны.
Ссылки
