• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Гостевая статья Почему запуск привилегированного контейнера в Docker - плохая идея

Привилегированные контейнеры в Docker - это, кратко говоря, которые имеют все корневые возможности хост-машины, что дает возможность доступа к ресурсам, которые недоступны в обычных контейнерах. Один из вариантов использования - запуск демона Docker внутри контейнера Docker; В другом случае контейнер требует прямого доступа к оборудованию. Первоначально Docker-in-Docker был представлен для разработки самого Docker. Сегодня существуют различные варианты использования для запуска привилегированных контейнеров, такие как (CI / CD) задачи на сервере автоматизации с открытым исходным кодом Jenkins. Однако запуск привилегированных контейнеров не обязательно безопасен. В этой записи блога мы рассмотрим, как запуск привилегированного, но небезопасного контейнера может позволить киберпреступникам получить черный ход в системе организации.

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

Запуск контейнера с привилегированным флагом позволяет внутренним командам иметь критический доступ к ресурсам хоста, но, злоупотребляя привилегированным контейнером, киберпреступники также могут получить к ним доступ. Когда злоумышленник злоупотребляет привилегированным контейнером для атаки, это не обязательно приводит к удаленному выполнению кода. Но когда они действительно выполняют код, потенциальная поверхность атаки велика. , Поскольку привилегированный контейнер создается из-за необходимости расширенных разрешений, существует большая вероятность, что злоумышленник сможет выполнить код от имени пользователя root. Это означает, что злоумышленник сможет запустить полный корень хоста со всеми доступными возможностями, включая . Следует отметить, что другие методы изоляции, такие как , AppArmor и SECcomp, или отключен.

Для злоумышленников, которые получают доступ к незащищенным привилегированным контейнерам, возможности для злоупотреблений кажутся безграничными. Злоумышленники могут идентифицировать программное обеспечение, работающее на хосте, для поиска и использования уязвимостей. Они также могут использовать уязвимости или неправильные конфигурации программного обеспечения контейнеров, такие как контейнеры со слабыми учетными данными или без аутентификации. Поскольку у злоумышленника есть root-доступ, вредоносный код или майнеры могут быть выполнены и эффективно скрыты.

Хранение контейнеров изолированными
, который содержит основные компоненты приложений ', по существу , изолированной среде. Чтобы иметь возможность изолировать несколько процессов, запущенных на одном хосте, механизм контейнера использует различные функции ядра. Поскольку контейнеры Docker работают поверх среды Linux, функции изоляции ресурсов ядра Linux используются для их независимой работы. Одно из них называется Linux namespaces. Таблица 1 показывает типы пространств имен.

Пространство имениспользование
МНТ (гора)Управляет точками монтирования файловой системы
PID (процесс)Изолирует процессы
NET (сеть)Управляет сетевыми интерфейсами
IPC (межпроцессное взаимодействие)Управляет доступом к ресурсам IPC
UTS (имя хоста)Изолирует ядро и идентификаторы версий
контрольные группыОграничивает, изолирует и измеряет использование ресурсов нескольких процессов
Идентификатор пользователя (Пользователь)Обеспечивает изоляцию привилегий и идентификацию пользователей
Таблица 1. Типы пространств имен Linux

По умолчанию демон Docker, а также контейнерный процесс запускаются с правами root. Создание другого пользователя и снижение разрешений все еще возможно и настоятельно рекомендуется с точки зрения безопасности.

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

возможностьРазрешенная операция
CAP_AUDIT_WRITEЗаписывать записи в журнал аудита ядра
CAP_CHOWN (сменить владельца)Произведите произвольные изменения в файловых UID и GID; изменить владельца и группу файлов, каталогов и ссылок
CAP_DAC_OVERRIDE (Дискреционный контроль доступа)Обойти проверку прав на чтение, запись и выполнение файла
CAP_FOWNERОбход проверок разрешений для операций, которые обычно требуют, чтобы UID файловой системы процесса совпадал с UID файла, за исключением проверок, которые охватываются CAP_DAC_OVERRIDE и CAP_DAC_READ_SEARCH
CAP_FSETIDНе удаляет биты режима set-user-ID и set-group-ID, даже когда файл изменяется
CAP_KILLОбход проверок разрешений для отправки сигналов
CAP_MKNODСоздавать специальные файлы
CAP_NET_BIND_SERVICEПривязать сокет к привилегированным портам интернет-домена (номера портов ниже 1024)
CAP_NET_RAWИспользуйте сокеты RAW и PACKET и привязывайте их к любому адресу для прозрачного прокси
CAP_SETGID

Произвольные манипуляции с GID процесса и дополнительным списком GID
CAP_SETPCAPЕсли поддерживаются файловые возможности (т. Е. Начиная с Linux 2.6.24): добавьте любую возможность из ограничивающего набора вызывающего потока в его наследуемый набор; отбросить возможности из ограничивающего набора; внести изменения в флаги безопасных битов.


Если файловые возможности не поддерживаются (например, ядра до Linux 2.6.24): предоставьте или удалите любую возможность в разрешенной возможности вызывающей стороны, установленной для любого другого процесса или из него.
разрешения CAP_SETUID

Произведите произвольные манипуляции с UID процесса, подделайте UID при передаче учетных данных сокета через доменные сокеты UNIX и запишите сопоставление идентификатора пользователя в пространстве имен пользователя
CAP_SYS_CHROOTИспользуйте chroot и изменяет пространства имен с помощью setns.
Таблица 2. Возможности контейнера, запускаемого от имени root

Для большей безопасности Docker предоставляет возможность запуска процесса контейнера под пользователем без полномочий root с использованием директивы USER внутри Dockerfile. Следует отметить, что он не использует , которые по умолчанию позволяют разделить корневого пользователя хоста и корневого пользователя контейнера. Пространства имен пользователя могут быть настроены в демоне Docker и могут использоваться во многих ситуациях, когда в противном случае необходим корневой доступ. Смотрите рисунок 1 и запишите числа в квадратных скобках.

Fig1-1024x390.png

Рисунок 1. Снимок экрана, показывающий, что пространства имен пользователя не используются по умолчанию

Следовательно, Docker не использует пространства имен пользователя, пока он не будет явно указан в флаге -userns-remap.

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

Это означает, что даже если процесс выполняется внутри нового пространства имен пользователя с доступным CAP_SYS_ADMIN и для выполняемого действия требуются повышенные привилегии, например, установка модуля ядра, тогда пространство имен родительского пользователя - которое не запускается под пользователем root и не имеет требуемая возможность - также проверяется на наличие требуемой привилегии. Если он не найден, то все действие отклоняется.

Следует отметить, что хотя -userns-remap обеспечивает повышение безопасности, это не то же самое, что , который на момент написания статьи все еще был экспериментальной функцией. Демон Docker, родительский контейнерный процесс, все еще работает под root.

Атаки с использованием привилегированных контейнеров
С помощью привилегированных контейнеров злоумышленники могут порождать их, пытаясь получить root-доступ к среде хоста пользователя.

Недавно мы увидели зловредную активность в одной из наших приманок, в которой злоумышленники пытаются поместить свои собственные открытые ключи SSH в / root / authorized_keys хоста через свой порожденный привилегированный контейнер.

Screen-Shot-2019-11-16-at-9.41.45-AM-1024x221.png

Рисунок 2. Снимок экрана кода порожденного со злым умыслом контейнера

После дальнейшего анализа мы обнаружили, что контейнер, который создали злоумышленники, использовал привязку « / mnt», чтобы попытаться привязать его к корню хоста «/» . После чего мы заметили, что были выполнены следующие команды:

  • «Cmd»: [«sh», «- c», »mkdir -pv / mnt / root /; mkdir -pv /mnt/root/.ssh/; ls -ld /mnt/root/.ssh/; chattr -i -a /mnt/root/.ssh/ /mnt/root/.ssh/authorized_keys ”]
  • Удалите неизменяемые атрибуты и добавьте те, которые находятся в /mnt/root/.ssh и /mnt/root/.ssh/authorized_keys

Screen-Shot-2019-11-25-at-10.55.48-AM.png

Рисунок 3. Снимок экрана, показывающий команды, выполняемые в порожденном привилегированном контейнере

Следует отметить, что хотя код на рисунке 3 показывает «Privileged: false», поскольку новый процесс выполняется в контексте привилегированного контейнера, его возможности совпадают с возможностями ранее порожденного привилегированного контейнера. Согласно нашему анализу, привязка «/», / mnt / root эквивалентна -v /: / mnt / root в интерфейсе командной строки Docker, и файловая система хоста доступна.

Нападавшие также пытались переписать файл в SSH, как мы можем видеть из запроса API , показанный на рисунке 4.

Screen-Shot-2019-11-25-at-11.38.25-AM.png

Рисунок 4. Снимок экрана с попытками перезаписать авторизованные ключи

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

Docker эффективно отключает все функции изоляции. Контейнеры могут иметь разные пространства имен PID и MNT, а также примененные профили cgroups. Но с флагом –privileged, работающим на контейнере Docker, пользователь - и, по неосторожности, злоумышленник - имеет доступ к жестким дискам, подключенным к хосту.

Флаг –privileged вместе с корневым доступом дает злоумышленнику множество вариантов выхода из «заключенной в тюрьму» среды:

  • Монтирование / dev / sda1 или аналогичный, позволяющий получить доступ к главному хранилищу
    • ls –la / dev /
    • mkdir / hdd & mount / dev / sda1 / hdd
  • Использование cgroups notify_on_release и release_agent для порождения оболочки в корне хоста
  • Развертывание собственного модуля ядра с сохранением на хосте (например, обратная оболочка)
Рекомендации по безопасности для привилегированных контейнеров Docker
Интересно, что описал экспериментальный режим который позволяет пользователям запускать демон Docker без необходимости иметь права root. В , даже если киберпреступники могут проникнуть в демон и контейнеры Docker, у них не будет корневого доступа к хосту.

Находясь на начальных этапах, режим без root не поддерживает полный набор функций Docker. В настоящее время :

  • Cgroups (включая docker top, который зависит от cgroups)
  • AppArmor
  • Пропускной пункт
  • Оверлейная сеть
  • Предоставление портов SCTP
Однако режим без root должен быть достаточным для многих случаев использования, которые вряд ли будут использовать эти функции, включая сборки в Jenkins.

Контейнеры полезны для организаций, которые хотят идти в ногу с постоянно растущими организационными требованиями. По мере того, как все больше и больше предприятий начинают использовать контейнеры, все больше и больше киберпреступников делают ставку на пробелы в безопасности в таких полезных инструментах для продвижения своей гнусной программы.

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

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

Вот несколько рекомендаций по безопасности для использования привилегированных контейнеров:

  1. Реализуйте принцип наименьших привилегий. Доступ к важным компонентам, таким как служба демона, которая помогает запускать контейнеры, должен быть ограничен. Сетевые подключения также должны быть зашифрованы.
  2. Контейнеры должны быть настроены так, чтобы доступ предоставлялся только доверенным источникам, включая внутреннюю сеть. Это включает в себя реализацию надлежащих процедур аутентификации для самих контейнеров.
  3. Следуйте рекомендуемым лучшим практикам. Docker предоставляет полный и имеет встроенные функции безопасности , специалисты могут воспользоваться, такими как настройкой хостов Linux работать лучше с Докерами через .
  4. Тщательно оценивайте потребности. Должен ли случай использования работать в Docker? Существуют ли другие механизмы контейнеров, которые не работают с доступом с правами root и могут выполнять работу так же эффективно? Можно ли это сделать по-другому? Принимаете ли вы риски, связанные с этой необходимостью?
  5. Аудит безопасности должен проводиться через регулярные промежутки времени для проверки любых подозрительных контейнеров и изображений.

Источник:
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!