11 июня 2016 года состаялась первая Defcon-встреча в Казахстане, а именно в Астане, площадкой докладов стал университет ЕНУ.
Я долго думал на какую тему сделать доклад, но либо темы были заезжены до дыр, либо темы казались очень сложными для восприятия публикой (студенты, сисадмины, веб-разработчики, гос. сектор), нужно было найти что-то нейтральное. В итоге меня вдохновил один из ранее проведенных пентестов, в котором для преодоления большинства «барьеров» мне помог Zabbix, обнаруженный в локальной сети Заказчика.

Для тех, кто не знает, вкратце в двух словах:

ZABBIX — опенсорс система мониторинга серверов и активного сетевого оборудования. Умеет мониторить абсолютно все ОС с помощью «агентов», серверная часть Zabbix преимущественно функционирует на Linux/UNIX системах, агент и сервер написаны на Си, данные хранятся в SQL-базе, а веб-интерфейс написан на PHP.
Не буду описывать все функциональные прелести Zabbix, ибо это займёт ни один час. Скажу кратко, судя по моим наблюдениям — данную систему, из-за её гибкости, очень любят сисадмины…, сетевикам она тоже нравится, т. к. умеет работать с SNMP-протоколом.
В связи с этим, невольно встаёт вопрос — насколько защищена система мониторинга, в которой мы храним данные о нашей ИТ-инфраструктуре?
Как показывает практика, Zabbix’ом в основном мониторят крайне чувствительные узлы ИТ-инфрастуктуры, доступность которых в идеале должна быть — 99%, это App, DB, Mail, активное сетевое оборудование (SNMP) и т. д.

Итак, перейдём собственно к безопасности самого Заббикса.

Я разернул небольшой тестовый стенд на виртуальных машинах с последними версиями Zabbix-сервера и Zabbix-агентов:2

Zabbix-сервер на Debian 8.4 x64 (Zabbix-server 3.0.3 LTS)

3

Zabbix-агент на Centos 6.8 x64 (v. 3.0.3 LTS)

4

Zabbix-агент Windows 7 pro x86 (v. 3.0.0 LTS)

Установка серверной части и агентов производилась строго по оффициальной документации (Раздел №3, Установка из пакетов)

Для чего я развернул весь этот тестовый стенд, расскажу далее:

Начнём с самого начала, в процессе установки серверной части,  вручную импортируются SQL-дампы, с заранее подготовленным пользователем — Admin, и паролем — zabbix, и как показывает практика, админы забывают или не хотят его менять, создают дополнительных пользователей, вешают на них права администраторов, а пользователя Admin не блокируют, и пароль ему почему-то тоже не меняют…

5

Проводя пентесты, я очень часто обнаруживаю, что Zabbix особо никто не скрывает в локальной сети, мало того, иногда его выставляют в интернет😮. В локальном DNS в основном присваивают имя zabbix, либо его кототкие вариации, перебрать которые даже вручную не составляет особого труда, не говоря уже о брутфорсе DNS =)

Отыскав Zabbix в локальной сети или на периметре, обычно мы встречаем стандартную форму авторизации, также очень часто по дефолту доступен гостевой вход.

6

Под гостевым доступом, обычно можно обнаружить различные граффики, схемы сети, IP-адреса, и много еще чего-нибудь полезного, что может упростить жизнь злоумышленнику.

Предположим, что сисадмин забыл отключить учетную запись Admin, или не поменял пароль. Что это нам даёт? Конечно же, кучу информации о внутренней ИТ-инфраструктуре (IP, исользуемое ПО и т. д.).

Но, это не самое страшное как может показаться на первый взгляд.

В панели администрирования, для облегчения жизни сисадминам, присутствует такой функционал, как возможность создания скриптов для автоматизации рутинных задач, например, можно пингануть какой-нибудь хост, сделать трассировку, поискать Zabbix-агентов в локальной сети и т. д.

7

Созданием скриптов можно заниматься конечно же через веб-интерфейс, но я этим заниматься не буду, т. к. у Zabbix есть своё API, которое хорошо документировано. Через API можно взаимодействовать с Zabbix-сервером и Zabbix-агентами через RPC в формате JSON.

Не долгая думая, мне захотелось воспользоваться всем этим замечательным функционалом.

В результате, был написан экслойт на Python, который позволяет нам проводить RCE на Zabbix-сервере, имея при этом полноценную консоль, которая работает через API.

8

Хочу напомнить, что при установке серверной части из пакетов (deb, rpm), создается пользователь zabbix, в результате, команды выполняются от имени пользвателя zabbix.

Таким образом, залив веб-шелл, у нас появляется доступ к двум системным пользователям (zabbix & www-data). Два —  лучше одного =)

9

Залив веб-шелл, проще визуализировать файловую систему, использовать SQL-клиент, совершать бэк-коннект и т. д. Всё это конечно же можно сделать из консоли. Ну и естественно, если ядро старое и не пропатченное, то можно попытаться поднять права до root, но в нашем случае нам это не нужно.

Также, я очень часто наблюдаю такую ситуацию, когда сетевики сильно не заморачиваются, и разрешают Zabbix-серверу на сетевом уровне ходить не только на порты необходимые для мониторинга (10050, 80, 443, 161, etc), но и на другие TCP/UDP-порты, и в другие подсети.

Что нам это даёт? Дело в том, что в последних дистрибутивах Linux (Debian/Ubuntu, RHEL/CentOS, etc) уже установлены интерпретаторы Python 2.х & Perl 5.х , с помощью которых мы можем проксировать свой трафик через Zabbix-сервер в другие подсети, и юзать свои SSH и RDP-клиенты, ну и конечно же свои нмапы, метасплойты, и прочий полезный софт =)

Казалось бы, что еще можно взять с уже уставшего от нас Zabbix-сервера?

Дело в том, что в Zabbix существует такая фишка, которая позволяет выполнять скрипты на удаленных Zabbix-агентах, но есть один ньюанс, в конфиге Заббикс-агента параметр EnableRemoteCommands должен иметь значение «1»

В случае с линуксом, выставить параметр EnableRemoteCommands=1 немного проблематично, т. к. в основном всё ставится из пакетов, в которых существует пост-инсталл скрипт, который в свою очередь создает системного пользователя zabbix, и запускает демон от его имени, редактирование конфиг-файла доступно только пользователю root.

В случае ручной сборки Заббикс-агента из исходников, существует вероятность, что сисадмин ошибётся, и запустит Zabbix-агент от имени root, но такое бывает крайне редко =)

Что в итоге полезного в линуксе мы можем сделать для себя?

Т.к. мы не можем прибить текущий процесс Zabbix-агента, который использует конфиг недоступный нам для редактирования, ТО! почему бы нам не создать свой конфиг, и не запустить его от своего же пользователя?!

Так и сделаем, создаём свой конфиг со своими параметрами =)

Не долго думая, я копирую рабочий конфиг, добавляю в него параметр EnableRemoteCommands=1 , и прячу куда-нибудь его подальше, а лучше маскирую, например, под .cache в домашней директории пользователя.

Добавляем еще один параметр в наш замаскированный конфиг

ListenPort = 10051 , тем самым изменяя порт прослушивания Заббикс-агента.

Ну вот и всё, второй экземпляр нашего агента функционирует, шлёт данные мониторинга на Заббикс-сервер, и позволяет нам выполнять RCE на Заббикс-агенте =)

10

В результате, имеем вполне легитимный руткит, правда с ограниченными правами, но опять же, этих прав вплолне хватит для того, чтобы реализовать проксирование трафика, как описывалось ранее на примере Zabbix-сервера.

Ну а что же с Windows-системами?! Тут гораздо всё проще и в ту же очередь, гораздо веселей =D (для нас естественно!)

В большинстве случаев, сисадмины устанавливают Zabbix-агент для винды в директорию C:\zabbix , в которой лежит скомпиленный бинарник и конфиг-файл. Установка сводится к двум командам выполненым от имени Локального (Доменного) администратора, первая команда — устанавливает Zabbix-агент как сервис, вторая — стартует сервис подхватывая конфиг.

После того, как сервис был установлен с правами админа, рестартануть его под обычным пользователем мы конечно же не сможем, НО! Под обычным пользователем у нас хватает прав отредактировать конфиг-файл Заббикс агента C:\zabbix\conf\zabbixd_agent.conf , внести в него необходимые изменения, ждать перезагрузки системы, чтобы сервис подхватил «обновленный» конфиг-файл, либо предпринять определённые действия чтобы система перезагрузилась =)

После перезагрузки Zabbix-клиента на винде, через RCE мы получаем доступ к системе с правами SYSTEM, далее можем делать всё что захотим с системой =)

11

Что в итоге?

На самом деле очень печально, что в оффициальной документации Zabbix почти ничего не сказано об обеспечении безопасности самого же Zabbix, и PHP от которого собственно и работает frontend и API.

В результате, как я уже говорил раннее, мы имеем вполне легитимный руткит в системе, на который не будет ругаться ни одни антивирус, и который нам предоставит удаленный доступ к системе, тем самым упрастив рутание серверов в локальной сети.

На сегодня это всё, что я хотел рассказать о безопасности Zabbix, но могу отметить, что это лишь верхушка айсберга в плане безопасности данной системы =)
А где же эксплойт?
https://www.exploit-db.com/exploits/39937/

UPDATE!
Нашёл видео, которое записывал для демонстрации, залил на YouTube:

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.