(Не)безопасность систем мониторинга: NagiosXI
Сейчас в компании любого размера зачастую используется та или иная система мониторинга, переодически то в одной, то в другой находят уязвимости (которые закрываются патчами) и слабости (на которые закрываются глаза). Сегодня мы поговорим о системе мониторинга NagiosXI и расскажем о способах ее эксплуатации в ходе пентеста. А также приведем мнение разработчиков относительно проблемы безопасности их продукта.
Старые версии никуда не уходят
Хоть мы и упомянули об исправлениях уязвимостей, однако, зачастую можно наткнуться на устаревшую систему мониторинга. Дальнейшие действия достаточно тривиальны. Проверяем версию (например, с помощью этого скрипта), потом находим список уязвимостей для конкретной сборки и без труда продолжаем эскалацию в сети. Актуальности проблеме придает тот факт, что многие пользователи CM никак не ограничивают доступ извне. Сканер Censys.io по запросу nagiosxi сообщает о 1002 доступных сервисах, а быстрый анализ сразу находит уязвимые к RCE системы.
Зачастую злоумышленнику не нужно обладать никакими специализированными навыками. Для случайной системы из нашей выборки достаточно запустить готовый эксплоит.
Казалось бы, что может быть хуже компрометации сервера? Самое время вспомнить про существование вспомогательных плагинов, которые обновляются практически никогда, а уязвимостей в них от этого не меньше. Популярный плагин NRPE можно встретить довольно часто, он используется для выполнения удаленных команд на мониторящихся хостах. Он является бомбой замедленного действия, если в его конфиге включена опция dont_blame_nrpe (что как бы намекает), но мало кто думает о рисках безопасности при решении своих краткосрочных задач таким образом.
В туториалах и гайдах рекомендуется использовать dont_blame_nrpe=1 в своих конфигурациях для исправления многих ошибок.
Переодически мы натыкаемся на использование устаревшей версии данного плагина, уязвимость в котором позволяет произвести удаленное выполнение кода.
У разработчиков есть время думать о вашей безопасности
Время идет, уязвимости устраняются, и ответственные сисадмины своевременно обновляют свои системы, полагая, что таким образом они становятся защищенными от злоумышленников. Отчасти это так — в подобных условиях script-kiddy не сможет нанести никакого вреда, не имея под рукой рабочего exploit«a —, но если мы говорим о варианте, при котором атакующий начинает исследование системы, то тут можно найти много интересного.
Этим летом мы рассматривали самую актуальную на тот момент версию NagiosXI 5.4.8, и нашли в ней ряд слабостей и уязвимостей, несколько xss и возможность загрузки вредоносного компонента, который добавит шелл на веб-сервер и будет доступен неавторизованному пользователю. Об этом мы сообщили разработчикам системы, спустя непродолжительное время мы получили ответ.
Не баг, а фича!
Как это часто бывает, спасение утопающих — дело рук самих утопающих. Учитывая беспрепятственную возможность перебирать пароли, не говоря уже о системах с стандартными учетными данными, уязвимых систем будет достаточно для небольшого ботнета. Судя по всему, возможность оставить шелл после проникновения в административную панель не будет устранена еще довольно долго, до тех пор, пока эта проблема не воспринимается разработчиками как баг.
Мы, конечно же, понимаем, как происходит разработка продуктов в IT-компаниях.
Но не можем не обратить внимание на то, что в августе был представлен POC вектора социальной атаки, которая после одного неаккуратного клика пользователя добавляет шелл на удаленный сервер. Разработчики пообещали фильтровать значения, которые попадают в переменные, но спустя полгода в версии 5.4.12 в этом плане ничего не изменилось.
С целью облегчить задачу исследователям и обозначить угрозы для администраторов систем мониторинга, появился переодически обновляющийся читщит по эксплуатации СМ. По ссылке вы найдете более подробную информацию о перечисленных выше векторах для атаки в ходе тестирования на проникновение.
В заключение
Также хочется отметить, что ведется подготовка аналогичных материалов и по другим популярным (и не очень) системам мониторинга. Отдельные благодарности этим ребятам: ro421, PenGenKiddy, sabotaged, NetherNN.
Кроме того, все неравнодушные могут внести свой вклад в формирование данной памятки и дополнить ее своими материалами по любой известной вам системе мониторинга.
