В нашей работе мы порой сталкиваемся с весьма экзотическими инфраструктурными решениями. В этой статье рассмотрим не самую популярную, но все еще встречающуюся в инфраструктурах систему оркестрации.
Marathon – продукт с открытым кодом, построенный с использованием Apache Mesos. Вполне неплохая комбинация функциональности платформы и используемой технологии, не так ли? Но дьявол, как и в большинстве случаев, кроется в деталях: гибкость и множество приятных бонусов для платформы оркестрации имеют обратную сторону – сложность, неочевидность, а зачастую и нелогичность настройки веб-части всей платформы.
Например, столь продвинутая система в качестве единственного механизма авторизации использует basic auth. И не просто basic auth, а одну-единственную пару логин/пароль, задаваемую в команде на запуск сервиса. И хотя документация настоятельно рекомендует вместе c авторизацией включать SSL, такой подход выглядит довольно грустно в современных реалиях. Хуже всего то, что по умолчанию административная панель вообще не требует авторизации.
Что же мы можем сделать в случае получения доступа к такой панели? Конечно же, оркестрировать контейнеры! Запуск новых сервисов, их масштабирование, создание новых развертываний – с такими возможностями мы можем использовать Marathon как полноценную площадку для развертывания всего, что нам потребуется для развития атак. Однако захват самого кластера выглядит куда перспективнее. Для этого всего лишь нужно создать контейнер, из которого мы «сбежим».
При изучении документации и местного формата конфигурационных файлов для развертывания сервисов можно понять, что нам ничего не мешает создавать привилегированные контейнеры или монтировать в них файлы непосредственно с сервера.
Рассмотрим вариант с монтированием файлов в контейнер. Пример такой конфигурации:
stages:
{
"id": "/basic-3",
"cmd": "echo \"ssh-rsa YOUR_KEY_HERE\" >> /opt/.ssh/authorized_keys",
"cpus": 1,
"mem": 256,
"disk": 10,
"instances": 1,
"acceptedResourceRoles": ["*"],
"container": {
"type": "DOCKER",
"docker": {
"forcePullImage": false,
"image": "python:3",
"parameters": [],
"privileged": true
},
"volumes": [
{
"containerPath": "/opt/",
"hostPath": "/root/",
"mode": "RW"
}
],
"portMappings": []
},
"networks": [],
"portDefinitions": []
}
В конфигурационном файле выше мы включаем привилегированный режим, монтируем домашнюю директорию пользователя root в каталог «/opt» контейнера и добавляем туда свой SSH-ключ.
Почему же мы выбрали вариант с файлами и ключами SSH? Дело в том, что за подобными системами обычно скрывается не один сервер, а кластер из серверов. Таким образом, мы с помощью настроек масштабирования сможем запустить указанную выше конфигурацию на каждом из них.
В дополнение скажем, что параметр hostPath в Marathon отвечает за путь до локального файла и директории, а не до ресурсов на общем хранилище / файловой системе, подключенных к узлам, что кажется несколько странным решением.
Вывод: обязательно включайте авторизацию и следуйте документации. Даже тот факт, что сервис находится во внутреннем периметре, не является гарантией того, что его не найдет злоумышленник и не будет слушать трафик между вашими сервисами с помощью MitM-соединений (подобная техника все еще жива).
Kubernetes Web View
Приведем еще один пример «экзотики». Kubernetes Web View – продукт, призванный облегчить жизнь DevOps-инженеров и разработчиков, предоставить удобный способ просмотра данных о кластере и его ресурсах. Легко разворачивается, но сложно настраивается – к слову сказать, снова нюансы.
В качестве механизма авторизации сервис предлагает использовать OAuth2 или поставить перед ним веб-прокси с авторизацией – не самые удобные в реализации методы.
Раздел документации о безопасности этой системы содержит подробное описание всех нюансов настройки и информацию о проблемах, связанных с передачей секретов в контейнеры. Но все эти меры – дополнительные шаги, а на практике мы встречаем примеры лени и пренебрежения простым чтением документации, не говоря уже о реализации дополнительных шагов.
Что мы можем сделать, найдя такой сервис? Система не предусматривает выполнения каких-либо действий, изменений конфигурации и чего-то подобного, но, если администратор пренебрег документацией, мы можем посмотреть конфигурационные файлы, переменные окружения и другую информацию о кластере с контейнерами.
Придется читать, в том числе довольно много однообразной информации.
Первыми на очереди будут списки узлов и сервисов. Полученная информация может пригодиться при планировании атаки и работе внутри периметра, а также даст больше понимания о структуре сервисов на внешнем периметре.
Затем можем почитать подробнее про сами сервисы, посмотреть их конфигурации и даже журналы событий (стоит отметить, что по умолчанию их показ отключен).
Как видим, ничего критичного в представленной информации о сервисе нет, поскольку тут секреты передаются правильно, как и рекомендуют разработчики.
Но если администратор решил не включать авторизацию, то, наверное, он и не стал проверять все конфигурационные файлы?
Если кто-то все же решился включить сбор событий запущенных сервисов, невзирая на предупреждения, то можно встретить и такое:
