Я не так давно в ИТ, но в последнее время увлёкся темой кибербезопасности. Особенно интересна профессия пентестера. Во время сёрфинга увидел классную статью «How a badly configured DB allowed us to own an entire cloud of over 25K hosts» от Security Shenanigans. Перевод обеих частей и предлагаю вашему вниманию.
Введение
Из этой статьи вы узнаете, как нам удалось выполнить прямое соединение sqlmap с базой данных с использованием BMC/IPMI для компрометации крупного клиента.
Предыстория
Пару лет назад наша команда получила задание: провести пентест инфраструктуры в сети Openstack. Он состоял из примерно 2000 физических серверов, на которых размещалось более 25 тысяч виртуальных машин. Работу мы начали в небольшой подсети, в которой было ограничение на объём исходящего трафика. После быстрого сканирования Nmap не удалось найти очевидные уязвимости, которыми можно было бы воспользоваться. Поэтому мы начали изучать доступные нам сервисы. Среди них мы обнаружили беззащитный сервер PostgreSQL, размещенный на сервере разработки. После создания настраиваемого списка слов с несколькими производными названия компании нам удалось пробраться в систему, используя относительно простые данные от учётной записи. Имя пользователя было Postgres, а пароль, допустим, «admin».
Далее мы решили задействовать sqlmap. Этот инструмент был создан для использования SQL-инъекций, но он также может предоставить вам несколько вариантов при установке прямого подключения к базе данных (когда у вас есть данные учётки). Один из этих вариантов — запуск командной оболочки для эксплуатируемой базы данных.
После тестирования шелла мы решили собрать нестандартный пэйлоад (полезную нагрузку), чтобы получить обратное подключение. Это позволило бы работать с большим комфортом.
Сборку пэйлоада мы выполняли с помощью msfvenom. Полезной нагрузкой в этом случае был обратный TCP-шелл для машины с Linux x64. На предыдущем изображении видно, что нам нужно было выбрать архитектуру БД.
Собираем полезную нагрузку с помощью msfvenom
Преимущество этого пэйлоада заключается в том, что с его помощью можно получить обратное подключение с помощью простого Netcat. Для большинства других полезных нагрузок требуется что-то вроде Metasploit (выбирать хэндлер exploit/multi/handler) для тех же самых задач.
После запуска полезной нагрузки с оболочкой sqlmap мы получили наше соединение с сервером.
Запуск пэйлоада
Получение обратного подключения и тестирование доступа
Использование BMC-устройств
Всякий раз, когда вы выполняете пентест инфраструктуры и компрометируете машину в новом сегменте сети, вам следует повторно выполнить сканирование, чтобы проверить, не появилось ли чего-нибудь нового. Эта БД позволила нам подключиться к облачной сети компании, включая большинство виртуальных машин и хостов. Мы очень обрадовались результатам нового сканирования, поскольку обнаружили несколько устройств BMC.
Одно из трёх BMC-устройств
BMC (Baseboard Management Controller, сервисный процессор) — это преимущественное встроенное устройство, подключенное к основному серверу, которое обеспечивает внеполосный мониторинг и контроль. Работает независимо от центрального процессора, BIOS и операционной системы. Ошибки, возникающие в любом из этих элементов, не способны повлиять на его работу. Микроконтроллер имеет собственный процессор, память, сетевой интерфейс, поэтому доступен, даже если сам сервер выключен. Все крупные поставщики оборудования имеют специальные BMC для своих продуктов:
- Dell DRAC
- IBM IMM
- HP iLO
- Supermicro IPMI
Еще один термин, с которым вам необходимо ознакомиться, IPMI (Intelligent Platform Management Interface, интерфейс интеллектуального управления платформой), в основном представляет собой протокол, который вы используете для связи с этими устройствами. Его назначение — мониторинг и управление железом сервера, независимо от операционной системы, даже в тех случаях, когда сервер выключен, но подключен к источнику питания.
Скажем так, IPMI на сегодняшний день является одним из самых небезопасных протоколов, которые вы можете найти. Чтобы дать вам представление, IPMI 2.0 разработан таким образом, что вы можете напрямую запрашивать пользовательский хэш с сервера на этапе аутентификации. Существует и другая уязвимость, когда вы запрашиваете авторизацию в режиме «cipher 0», который позволит вам войти в систему с любым паролем.
Архитектура блока IPMI
BMC-устройства, которые вы можете обнаружить, Обычно слабо защищены, так как это тип укстройств, которые настраиваются один раз, на этапе сборки центра обработки данных, а затем используете лишь в тех случаях, когда сервер недоступен обычными средствами.
Мы смогли легко пройти аутентификацию на некоторых устройствах, на которых был включен cipher 0.
Здесь вы можете увидеть, как мы вошли в систему со случайным паролем. Обратите внимание на часть «-C 0».
Успешный вход в устройство со случайным паролем
Информация о сети для устройства
Даже если на некоторых устройствах не включен cipher 0, у вас всё равно остаются другие способы входа в систему. Двумя наиболее известными являются либо использование учетных данных по умолчанию (которые системные администраторы обычно не пытаются изменить), либо использование уязвимости раскрытия хэшей (и последующий взлом хешей). Последнее пришлось сделать для большинства устройств.
Банальные пары логин/пароль по умолчанию для большинства пользователей
Список слов, содержащий хэши пользователей, которые мы запрашиваем у сервера
Раскрытие пользовательских хэшей с помощью metasploit
Сразу получаем данные о типовых хэшах
Перебрав все хеши, мы начали их взламывать.
Взлом первых хешей
Через пару минут мы получили доступ примерно к 600 BMC.
609 хэшей успешно взломаны
Была пара устройств HP ILO, которые мы не смогли взломать. К счастью для нас, в HP iLO 4, начиная с версий 1.00 до 2.50, также есть обход аутентификации. Это позволяет вам создать учетную запись администратора через переполнение буфера в HTTP-заголовке подключения, обрабатываемое веб-сервером. Эксплойт использует это для получения привилегированного доступа к остальному API, который, в свою очередь, даёт вам права на создание учётных записей.
Использование CVE-2017–12542
После этих шагов мы получили полный контроль над 90% BMC-устройств компании. Если вы читали об устройствах BMC, то теперь знаете, что они позволяют:
- Мониторить
- Перезагружать
- Переустанавливать
- KVM (виртуализировать)
подключённые устройства. Это здорово и всё такое, но они только имитируют физический доступ к серверу, вам всё равно нужно попасть внутрь. Да, вы можете похулиганить, выключив устройства, но мы думали, что этого недостаточно, поэтому продолжали копать.
Один из наиболее распространенных способов взлома оборудования, имеющего физический адрес, — это его перезагрузка и управление автозапуском для рут шелла. Вы можете сделать это в Unix, Mac и Windows.
Трудность этого подхода заключается в том, что на каждом сервере обычно размещается около 2000 виртуальных хостов. Итак, нам нужно было найти неиспользуемый сервер. План состоял в том, чтобы выключить его (или только запустить, если он уже был отключен) и отредактировать автозапуск, чтобы предоставить нам root-доступ. После этого мы хотели взглянуть на конфигурацию, чтобы найти какие-либо ошибки/полезные данные, которые позволили бы нам скомпрометировать и другие серверы.
Openstack позволяет запрашивать локальную инфраструктуру и запрашивать определенные параметры. Одним из них является состояние виртуальной машины, которое в случае этой локальной компании было определено как доступность ВМ (белый/чёрный список для приёма трафика) + рабочее состояние (запущена/отключена).
Нам нужно было найти сервер из чёрного списка (рабочее состояние не имело значения), и мы нашли один не работающий из-за проблем с диском. К счастью, нам удалось загрузиться, но некоторые части файловой системы оказались в режиме «только для чтения».
Запрос openstack о подходящем сервере для взлома
Как только мы его нашли, то вошли в систему по найденными ранее учётными данными.
Используем доступы, полученные ранее
Доступ к интерфейсу KVM
Интерфейс KVM имитирует прямое подключение к серверу через BMC. При загрузке вам нужно отредактировать автозагрузку Grub и добавить ro init = / bin / bash в соответствующую строку, чтобы загрузиться в рут-шелл. Обычно используется флаг чтения и записи (rw), но нам пришлось использовать флаг только для чтения (ro), чтобы предотвратить любые проблемы с неисправным диском.
Редактирование меню grub
После входа в систему мы изучили сетевые интерфейсы для проверки возможности подключения к серверу. Как видите, ifconfig показывает более 10 активных интерфейсов.
Потратив некоторое время на то, чтобы проанализировать структуру сети и понять, где мы находимся, мы начали изучать сервер.
Через пару минут мы нашли золотую середину с помощью bash_history (один из лучших источников ценнейшей информации, который вы можете найти на Linux-машине)
Учетные данные novadb в bash_history
Для тех, кто не знаком с архитектурой Openstack, Nova — это управляющая БД, в которой хранится административная информация для всего облака, такая как сертификаты, квоты, имена экземпляров, метаданные и много другой важной информации.
Проверка учетных данных
После входа в систему мы проверили админский доступ, используя grants_MySQL.
Сделав это, мы можем посмотреть внутреннюю структуру NovaDB.
Таблицы в базе данных Novadb
Просматривая информацию о ВМ, мы могли увидеть около 34 тысяч устройств. Однако примерно треть из них была недоступна/не работала. Точное количество можно увидеть в строке запись float_ips.
Позвольте мне объяснить, почему эти данные из базы данных так важны.
Если вы хотите остановить работу всей компании, вы можете выключить каждый виртуальный сервер через интерфейс BMC. Они не будут работать, пока системные администраторы не включат всё обратно.
Вы можете написать собственное вредоносное ПО для заражения всех серверов, но массовое развертывание по каналам BMC непросто (помните, что нам нужно было запустить неиспользуемый сервер, чтобы отредактировать автозапуск Grub, прежде чем получить к нему доступ).
Однако с доступом к NovaDB вы можете просто повредить базу данных, и вся облачная среда перестанет работать. Даже если предположить, что системный администратор был достаточно сообразителен, чтобы немедленно взглянуть на БД, гораздо сложнее устранить неисправность поврежденной базы данных, чем отсутствующей.
А ещё системный администратор может понять, что что-то не так, и просто перезаписать всё с помощью самой последней резервной копии, верно? Мы тоже подумали об этом. Вот почему мы пошли дальше и скомпрометировали резервные копии.
Сначала мы попытались запросить основную базу данных с помощью чего-то вроде
SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; , но компания использовала собственное решение для резервного копирования, которое выполнялось нерегулярно и без использования схемы «ведущий — ведомый» (master/slave). Поэтому мы продолжили сканирование соседних подсетей, просто чтобы найти базы данных резервного копирования, работающие на том же порту, что и главная.
Как нам удалось найти резервные копии
Мы проверили возможность использования имевшихся учётных данных и, конечно же, они подошли.
Проверка доступа к резервной копии
Имея собственные резервные копии, мы смогли доказать полную компрометацию инфраструктуры виртуализации, а также способ окончательного завершения операций за несколько минут.
Я всегда люблю заканчивать рецензию/отчет написанием возможных исправлений найденных проблем. При этом их было много, например:
- Повторное использование учетных данных
- Отсутствует сегментация сети
- Банальнейшие пароли
- Небезопасная структура резервного копирования
- Устаревшая прошивка
Одним из критических моментов, который было нелегко исправить, были недостатки протокола IPMI.
Наиболее удачным решением будет размещение серверов с поддержкой BMC в другом сегменте сети с ограниченным и контролируемым списком IP-адресов. Вот так в итоге и поступила эта компания.
Я надеюсь, что вам понравилось наша история. Так же, как и нам было весело изучать эту тему.
Комментариев нет:
Отправить комментарий