Немного теории
Docker — это платформа для разработки, доставки и запуска контейнерных приложений. Docker позволяет создавать контейнеры, автоматизировать их запуск и развертывание, управляет жизненным циклом. Он позволяет запускать множество контейнеров на одной хост-машине.
Для того, чтобы не было путаницы, уточним несколько определений и различие между ними:
Реестр Docker - все образы docker хранятся в реестре docker. Пользователь
может иметь либо локальный реестр в своей системе, либо общедоступный,
например docker hub.
Docker образ — это шаблон (физически — исполняемый пакет), из которого создаются Docker-контейнеры. Образ хранит в себе всё необходимое для запуска приложения, помещенного в контейнер: код, среду выполнения, библиотеки, переменные окружения и конфигурационные файлы.
Контейнеры — это способ стандартизации развертки приложения и отделения его от общей инфраструктуры. Экземпляр приложения запускается в изолированной среде, не влияющей на основную операционную систему.
Виртуальные машины отлично подходят для полной изоляции процесса для приложения: почти никакие проблемы основной операционной системы не могут повлиять на софт гостевой ОС, и наоборот. Но за такую изоляцию приходится платить. Существует значительная вычислительная нагрузка, необходимая для виртуализации железа гостевой ОС. Контейнеры используют другой подход: они предоставляют схожий с виртуальными машинами уровень изоляции, но благодаря правильному задействованию низкоуровневых механизмов основной операционной системы делают это с в разы меньшей нагрузкой.
Этого достаточно, чтобы у вас не взорвалась голова и вы поняли о чем тут идёт речь.
Практика повышения привилегий
Заходим на заготовленную заранее уязвимую машину по ssh. Представим, что все этапы для получения удалённого доступа к системе мы прошли.
Пользователь вполне обычный. Прав особо у нас нет, но можно обратить своё внимание на группы пользователя test, к которым он принадлежит.
Отталкиваясь от этого попробуем добиться прав root на этой машине.
Если порыться в системе, то можно увидеть один установленный образ docker-контейнера.
Присутствие докера в системе можно было также обнаружить взглянув на процессы атакуемой машины (если контейнер запущен) или забросив туда написанный сценарий Linpeas.
Запустим контейнер и одновременно смонтируем папку системы /etc к docker-контейнеру.
Тут можно уже разгуляться как хочешь, но цель статьи показать как получить права root. Этим и займёмся!
Ага! У нас тут нет nano и vim тоже не завезли. Не беда! Сейчас поставим.
Отредактируем конфиг sudoers:
Теперь пользователь test может выполнять команды, где необходим root!
Развивать атаку дальше можно уже как угодно. Своей цели мы достигли.
Как это работает?
Демон Docker работает таким образом, что к нему разрешен доступ пользователю root или любому другому пользователю в конкретной группе docker. Это говорит о том, что доступ к группе docker аналогичен предоставлению постоянного root-доступа без какого-либо пароля
Админ засунул своего пользователя изначально в группу docker, чтобы запускать необходимые контейнеры и не вводить каждый раз пароль sudo. Это и стало критической уязвимостью в системе.
Смонтировав папку системы к контейнеру - получаем доступ к конфигурационным файлам от имени администратора с синхронизацией к атакуемой системе. Так мы и развили вектор атаки через неправильно настроенный docker-контейнер.
Подведём итоги
Небольшой пример халтуры и лени администратора и то, к чему может привести всё это. Не спорю, что вводить каждый раз пароль при выполнении команды, где нужны права администратора, это большой гемор и надоедает такое очень быстро, но стоит хоть и иногда думать о безопасности своих систем и продуктов.
Мной буде рекомендовано, если же вы допускаете подобные упрощения работы, то не забудьте использовать меры по мониторингу доступа к контейнеру или же внутренние инструменты аудита.
Лучше всего разграничивать доступ пользователей, чтобы не допускать возникновение подобных лазеек.
Могу посоветовать следующую статью по обеспечению безопасности docker-контейнеров: https://habr.com/ru/companies/flant/articles/474012/
