SQL-инъекция в LibreNMS позволяет обычному пользователю читать хеши паролей и стирать историю портов

Открытая платформа сетевого мониторинга LibreNMS получила исправления для пяти уязвимостей. Одна из них, внедрение SQL-кода, превращает самую обычную учётную запись в инструмент чтения чужих данных. Две другие позволяют выполнить чужой код в браузере сотрудника, ещё одна даёт стирать историю портов без права на удаление, а последняя открывает графики трафика устройств, к которым у пользователя доступа нет. Патчи вошли в версию 26.9.0, её разработчики опубликовали 23 сентября 2026 года. Уязвимы все сборки LibreNMS до этой версии.

Детали уязвимостей

Внедрение SQL-кода прячется в обработчике уведомлений. Когда оператор отмечает уведомления прочитанными, форма передаёт на сервер их идентификаторы, и сервер подставляет полученное значение прямо в запрос к базе. Защита рассчитана на число. Если отправить значение массивом, проверка пропускает его дальше без фильтрации. Права здесь не проверяют вовсе, поэтому хватает любой действующей учётной записи, включая наблюдателя без административных полномочий. Исследователь вытащил через эту уязвимость длину хеша пароля другого пользователя. Прочитать сам хеш тоже ничто не мешает. Ответ базы сохраняется в служебной таблице уведомлений, откуда его забирают через веб-интерфейс. Обычно в таких случаях данные приходится восстанавливать по косвенным признакам, здесь этого не требуется. Издатель отнёс уязвимость к высокому уровню риска.

Вторая уязвимость связана с удалением портов. Обработчик очистки проверяет только то, какие устройства пользователь видит, и не смотрит, есть ли у него право на удаление. Пользователь с доступом на чтение стирает запись о порте из базы безвозвратно. Режим массовой очистки удаляет все записи об удалённых портах по всем доступным ему устройствам. В остальных разделах LibreNMS удаление требует отдельного разрешения, так что здесь нарушена логика, которой проект следует сам. Историю портов применяют для аудита и планирования ёмкости сети, поэтому потерю замечают не сразу. Уязвимость обнаружил Вэньхао У из Юго-Восточного университета.

Третья уязвимость - межсайтовый скриптинг на странице списка узлов Oxidized. LibreNMS забирает данные у внешнего сервиса резервного копирования конфигураций и выводит их в таблицу без экранирования. Годом ранее похожую уязвимость на странице конфигурации устройства исправили, но соседнюю страницу не тронули. Под удар попадают имя узла, статус, модель, группа и время из ответа сервиса, а также системное имя устройства, полученное по SNMP (протокол управления сетевыми устройствами). Строка со временем выводится как есть, если разбор даты не удался. Управлять этими данными может тот, кто отвечает за содержимое ответа сервиса: ошибка в настройках, взломанный или подменённый узел, перенаправление с внешнего адреса. Системное имя обходится атакующему дешевле, поскольку приходит от самого наблюдаемого оборудования и не требует действий администратора. Уязвимость нашёл Такуя Тацуяма.

Четвёртая уязвимость - тот же межсайтовый скриптинг, но в списке беспроводных датчиков. Описание датчика LibreNMS берёт из текстового поля, которое устройство сообщает по SNMP, например из имени беспроводной сети. Значение сохраняется в базе как есть и печатается на странице без экранирования. На странице редактирования и в табличном контроллере ту же строку экранируют, поэтому расхождение возникло только на просмотре. Учётные данные LibreNMS атакующему не нужны. Достаточно управлять SNMP-агентом наблюдаемого устройства, а среди сетевого оборудования хватает моделей со слабыми строками доступа. Скрипт срабатывает в браузере любого авторизованного пользователя, который откроет вкладку беспроводных датчиков. Дальше он может забрать сессионную метку и действовать от имени жертвы.

Пятая уязвимость - обход путей в модуле NFSen. Значение параметра, отвечающего за канал сбора данных, подставляется в имя файла с данными графиков без ограничения на переходы вверх по дереву каталогов. Пользователь, которому разрешено видеть одно устройство с включённым NFSen, добавляет в параметр последовательность переходов и получает график трафика другого устройства, недоступного ему напрямую. Соседний параметр защитили раньше, а этот пропустили. Издатель оценил уязвимость как умеренную: утечка ограничена сведениями о трафике, целостность и доступность системы не страдают. Проверяли её на версии 26.8.1.

Разработчики исправили все пять уязвимостей в версии 26.9.0, она же и минимальная безопасная сборка. Ни одной из них не присвоили идентификатор CVE, поэтому в сторонних сканерах и системах учёта их не найти. Обновиться стоит всем, у кого LibreNMS развёрнут для мониторинга сети, включая организации с сотнями устройств. Полезно заодно проверить, включена ли интеграция с Oxidized, закрыт ли SNMP-доступ от посторонних подсетей и заменены ли стандартные строки доступа на оборудовании. Права пользователей тоже стоит пересмотреть. Учётная запись с доступом только на просмотр оказалась в этой системе достаточно опасной.

Системы мониторинга видят всю сеть и хранят доступ к оборудованию, поэтому ошибки в их коде приводят к более тяжёлым последствиям, чем похожие уязвимости в обычном веб-приложении. Данные, которые приходят от наблюдаемых устройств по SNMP, разработчики таких платформ до сих пор считают доверенными. Эта привычка даёт атакующему возможность действовать, не имея учётной записи в самой системе. Два случая из пяти в сентябрьском наборе исправлений показывают, что менять подход придётся.

Детали уязвимостей

Ссылки