Привилегированные контейнеры в Docker - это, кратко говоря,
Проблемы с привилегированными контейнерами
Обычно
Запуск контейнера с привилегированным флагом позволяет внутренним командам иметь критический доступ к ресурсам хоста, но, злоупотребляя привилегированным контейнером, киберпреступники также могут получить к ним доступ. Когда злоумышленник злоупотребляет привилегированным контейнером для атаки, это не обязательно приводит к удаленному выполнению кода. Но когда они действительно выполняют код, потенциальная поверхность атаки велика. , Поскольку привилегированный контейнер создается из-за необходимости расширенных разрешений, существует большая вероятность, что злоумышленник сможет выполнить код от имени пользователя root. Это означает, что злоумышленник сможет запустить полный корень хоста со всеми доступными возможностями, включая
Для злоумышленников, которые получают доступ к незащищенным привилегированным контейнерам, возможности для злоупотреблений кажутся безграничными. Злоумышленники могут идентифицировать программное обеспечение, работающее на хосте, для поиска и использования уязвимостей. Они также могут использовать уязвимости или неправильные конфигурации программного обеспечения контейнеров, такие как контейнеры со слабыми учетными данными или без аутентификации. Поскольку у злоумышленника есть root-доступ, вредоносный код или майнеры могут быть выполнены и эффективно скрыты.
Хранение контейнеров изолированными
Таблица 1. Типы пространств имен Linux
По умолчанию демон Docker, а также контейнерный процесс запускаются с правами root. Создание другого пользователя и снижение разрешений все еще возможно и настоятельно рекомендуется с точки зрения безопасности.
В случае привилегированных контейнеров наличие корневого доступа внутри контейнера также означает наличие корневого доступа на хосте. Однако следует отметить, что контейнерный процесс по умолчанию имеет ограниченный набор
Таблица 2. Возможности контейнера, запускаемого от имени root
Для большей безопасности Docker предоставляет возможность запуска процесса контейнера под пользователем без полномочий root с использованием директивы USER внутри Dockerfile. Следует отметить, что он не использует
Рисунок 1. Снимок экрана, показывающий, что пространства имен пользователя не используются по умолчанию
Следовательно, Docker не использует пространства имен пользователя, пока он не будет явно указан в флаге -userns-remap.
Внутри пространства имен пользователя процессу могут быть предоставлены полные привилегии операций, но вне пространства имен пользователя процессу нет. Это означает, что вне пространства имен пользователя процесс может иметь непривилегированный идентификатор пользователя, а внутри него он может иметь идентификатор пользователя 0.
Это означает, что даже если процесс выполняется внутри нового пространства имен пользователя с доступным CAP_SYS_ADMIN и для выполняемого действия требуются повышенные привилегии, например, установка модуля ядра, тогда пространство имен родительского пользователя - которое не запускается под пользователем root и не имеет требуемая возможность - также проверяется на наличие требуемой привилегии. Если он не найден, то все действие отклоняется.
Следует отметить, что хотя -userns-remap обеспечивает повышение безопасности, это не то же самое, что
Атаки с использованием привилегированных контейнеров
С помощью привилегированных контейнеров злоумышленники могут порождать их, пытаясь получить root-доступ к среде хоста пользователя.
Недавно мы увидели зловредную активность в одной из наших приманок, в которой злоумышленники пытаются поместить свои собственные открытые ключи SSH в / root / authorized_keys хоста через свой порожденный привилегированный контейнер.
Рисунок 2. Снимок экрана кода порожденного со злым умыслом контейнера
После дальнейшего анализа мы обнаружили, что контейнер, который создали злоумышленники, использовал привязку « / mnt», чтобы попытаться привязать его к корню хоста «/» . После чего мы заметили, что были выполнены следующие команды:
Рисунок 3. Снимок экрана, показывающий команды, выполняемые в порожденном привилегированном контейнере
Следует отметить, что хотя код на рисунке 3 показывает «Privileged: false», поскольку новый процесс выполняется в контексте привилегированного контейнера, его возможности совпадают с возможностями ранее порожденного привилегированного контейнера. Согласно нашему анализу, привязка «/», / mnt / root эквивалентна -v /: / mnt / root в интерфейсе командной строки Docker, и файловая система хоста доступна.
Нападавшие также пытались переписать
Рисунок 4. Снимок экрана с попытками перезаписать авторизованные ключи
Из этих примеров становится очевидным, что, несмотря на врожденную изоляцию, существуют ситуации, когда киберпреступники могут покинуть изолированные контейнеры и получить доступ к ресурсам хост-машины и сделать инфраструктуру пользователя открытой для атак.
Флаг –privileged вместе с корневым доступом дает злоумышленнику множество вариантов выхода из «заключенной в тюрьму» среды:
Интересно, что
Находясь на начальных этапах, режим без root не поддерживает полный набор функций 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 (имя хоста) | Изолирует ядро и идентификаторы версий |
| контрольные группы | Ограничивает, изолирует и измеряет использование ресурсов нескольких процессов |
| Идентификатор пользователя (Пользователь) | Обеспечивает изоляцию привилегий и идентификацию пользователей |
По умолчанию демон 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. |
Для большей безопасности Docker предоставляет возможность запуска процесса контейнера под пользователем без полномочий root с использованием директивы USER внутри Dockerfile. Следует отметить, что он не использует
Ссылка скрыта от гостей
, которые по умолчанию позволяют разделить корневого пользователя хоста и корневого пользователя контейнера. Пространства имен пользователя могут быть настроены в демоне Docker и могут использоваться во многих ситуациях, когда в противном случае необходим корневой доступ. Смотрите рисунок 1 и запишите числа в квадратных скобках.
Рисунок 1. Снимок экрана, показывающий, что пространства имен пользователя не используются по умолчанию
Следовательно, Docker не использует пространства имен пользователя, пока он не будет явно указан в флаге -userns-remap.
Внутри пространства имен пользователя процессу могут быть предоставлены полные привилегии операций, но вне пространства имен пользователя процессу нет. Это означает, что вне пространства имен пользователя процесс может иметь непривилегированный идентификатор пользователя, а внутри него он может иметь идентификатор пользователя 0.
Это означает, что даже если процесс выполняется внутри нового пространства имен пользователя с доступным CAP_SYS_ADMIN и для выполняемого действия требуются повышенные привилегии, например, установка модуля ядра, тогда пространство имен родительского пользователя - которое не запускается под пользователем root и не имеет требуемая возможность - также проверяется на наличие требуемой привилегии. Если он не найден, то все действие отклоняется.
Следует отметить, что хотя -userns-remap обеспечивает повышение безопасности, это не то же самое, что
Ссылка скрыта от гостей
, который на момент написания статьи все еще был экспериментальной функцией. Демон Docker, родительский контейнерный процесс, все еще работает под root.Атаки с использованием привилегированных контейнеров
С помощью привилегированных контейнеров злоумышленники могут порождать их, пытаясь получить root-доступ к среде хоста пользователя.
Недавно мы увидели зловредную активность в одной из наших приманок, в которой злоумышленники пытаются поместить свои собственные открытые ключи SSH в / root / authorized_keys хоста через свой порожденный привилегированный контейнер.
Рисунок 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
Рисунок 3. Снимок экрана, показывающий команды, выполняемые в порожденном привилегированном контейнере
Следует отметить, что хотя код на рисунке 3 показывает «Privileged: false», поскольку новый процесс выполняется в контексте привилегированного контейнера, его возможности совпадают с возможностями ранее порожденного привилегированного контейнера. Согласно нашему анализу, привязка «/», / mnt / root эквивалентна -v /: / mnt / root в интерфейсе командной строки Docker, и файловая система хоста доступна.
Нападавшие также пытались переписать
Ссылка скрыта от гостей
файл в SSH, как мы можем видеть из запроса API , показанный на рисунке 4.
Рисунок 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 без необходимости иметь права root. В
Ссылка скрыта от гостей
, даже если киберпреступники могут проникнуть в демон и контейнеры Docker, у них не будет корневого доступа к хосту.Находясь на начальных этапах, режим без root не поддерживает полный набор функций Docker. В настоящее время
Ссылка скрыта от гостей
:- Cgroups (включая docker top, который зависит от cgroups)
- AppArmor
- Пропускной пункт
- Оверлейная сеть
- Предоставление портов SCTP
Контейнеры полезны для организаций, которые хотят идти в ногу с постоянно растущими организационными требованиями. По мере того, как все больше и больше предприятий начинают использовать контейнеры, все больше и больше киберпреступников делают ставку на пробелы в безопасности в таких полезных инструментах для продвижения своей гнусной программы.
Хотя для привилегированных контейнеров действительно есть законное использование, разработчики должны проявлять осторожность и сдержанность при их использовании. В конце концов, привилегированные контейнеры могут использоваться в качестве точек входа для атак и для распространения вредоносного кода или вредоносных программ на скомпрометированные хосты.
Однако это не означает, что привилегированные контейнеры абсолютно не должны использоваться. Организациям просто нужно убедиться, что меры безопасности установлены при запуске таких контейнеров в их средах.
Вот несколько рекомендаций по безопасности для использования привилегированных контейнеров:
- Реализуйте принцип наименьших привилегий. Доступ к важным компонентам, таким как служба демона, которая помогает запускать контейнеры, должен быть ограничен. Сетевые подключения также должны быть зашифрованы.
- Контейнеры должны быть настроены так, чтобы доступ предоставлялся только доверенным источникам, включая внутреннюю сеть. Это включает в себя реализацию надлежащих процедур аутентификации для самих контейнеров.
- Следуйте рекомендуемым лучшим практикам. Docker предоставляет полный
Ссылка скрыта от гостейи имеет встроенные функции безопасности , специалисты могут воспользоваться, такими как настройкой хостов Linux работать лучше с Докерами черезСсылка скрыта от гостей.
- Тщательно оценивайте потребности. Должен ли случай использования работать в Docker? Существуют ли другие механизмы контейнеров, которые не работают с доступом с правами root и могут выполнять работу так же эффективно? Можно ли это сделать по-другому? Принимаете ли вы риски, связанные с этой необходимостью?
- Аудит безопасности должен проводиться через регулярные промежутки времени для проверки любых подозрительных контейнеров и изображений.
Источник:
Ссылка скрыта от гостей