В продолжении темы контейнеризации приложений и применения этой технологии в Big Data системах, сегодня мы поговорим, действительно она абсолютно безопасна. А также насколько популярнейшая DevOps-технология, Kubernetes, «великий кормчий» среди систем оркестрации контейнеров, соответствует своему визуальному образу «неуязвимого» океанического лайнера. Спойлер: на самом деле нет, K8s, как и любые другие технологии Big Data, подвержен хакерским атакам. Читайте подробности в нашей статье.
Крупнейшие уязвимости Kubernetes в 2018 году
В 2018 году было сразу несколько ярких инцидентов с нарушением информационной безопасности K8s, которые доставили немало волнений DevOps-инженерам и специалистам по cybersecurity Big Data систем. В частности, некорректная конфигурация панели управления Kubernetes и отсутствие на ней пароля для авторизации позволили злоумышленникам получить доступ к одному из pod’ов с учётной записью с возможностью обращения к инфраструктуре Tesla в Amazon Web Services. В результате на облачных ресурсах корпорации Tesla был установлен посторонний софт для майнинга криптовалют [1]. К аналогичным последствиям внедрения произвольных файлов в систему с помощью вредоносных контейнеров приводит уязвимость обхода каталога, CVE-2018-1002100, обнаруженная в 2018 году и устраненная выпуском обновлений.
В декабре 2018 года в каждой версии Kubernetes, начиная с v1.0, была обнаружена критическая уязвимость CVE-2018-1002105, которая допускала повышение привилегий в системе как авторизованных пользователей, так и злоумышленников, не прошедших авторизацию [2]. С помощью особым образом сформированного сетевого запроса атакующий может подключиться к конечному серверу через API. После установки соединения возможна посылка произвольных запросов, аутентифицированных с помощью учетных данных TLS сервера Kubernetes API, непосредственно конечному серверу. Таким образом, при настройках по умолчанию все пользователи (как авторизованные, так и неавторизованные) могут выполнять запросы для повышения своих привилегий до уровня администратора. Это опасно риском запуска несанкционированных приложений или утечки данных. Проблема усложнялась невозможностью проверить факт эксплуатации уязвимости: т.к. неавторизованные запросы отправляются через установленное соединение, то они не отображаются в журнале сервера или журнале аудита. Запросы появятся в kubelet или агрегированных логах сервера API, но внешне они не отличаются от авторизованных и проксированных запросов, отправленных через сервер Kubernetes API. Эта уязвимость повышения привилегий была устранена в релизах 1.10.11, 1.11.5, 1.12.3 или 1.13.0-rc1 [3].
Главные уязвимости K8s в 2019 году
Проблема обхода каталога в уязвимости CVE-2018-1002100 не была устранена полностью и в 2019 году вновь возникла в виде новой уязвимости CVE-2019-1002101, связанной с интерфейсом командной строки kubectl для управления Kubernetes. Во время процесса копирования файлов с помощью команды cp в контейнере создается бинарный файл архива tar, который затем передается по сети и распаковывается kubectl на устройстве пользователя. При наличии вредоносного файла tar в контейнере, злоумышленник может внедрить произвольные файлы в любое место системы, похитить конфиденциальную информацию и запустить произвольное приложение с работающими правами kubectl. В частности, если интерфейс запущен с правами суперпользователя (root), атакующий сможет модифицировать конфигурацию системных файлов, исполняемых при загрузке. Это в очередной раз подтверждает потребность очень аккуратной настройки пользовательских привилегий и того, что не стоит без необходимости запускать контейнеры с правами root. Подробнее о способах обеспечения информационной безопасности в Kubernetes читайте в нашей следующей статье. Уязвимость CVE-2019-1002101 была устранена выпуском версий Kubernetes 1.11.9, 1.12.7, 1.13.5 и 1.14.0 [4].
В феврале 2019 года стало известно об уязвимости CVE-2019-5736, которая относится к средству для запуска контейнеров runC, используемого Docker, CRI-O, containerd и Kubernetes. Эта уязвимость даёт заражённому контейнеру возможность перезаписать исполняемый файл runC на хосте и получить к нему root-доступ. Это позволяет такому контейнеру получить контроль над хостом и даёт атакующему возможность выполнять любые команды. Уязвимость можно заблокировать, используя правильную реализации пользовательских пространств имён, где не осуществляется мэппинг root-пользователя хоста в пользовательское пространство имён контейнера. Проблема, как обычно, устранена выпуском новой версии среды запуска контейнеров runC, входящей в большинство систем оркестрации (Kubernetes, Docker, Apache Mesos и др.) [5].
В марте 2019 года обнаружена подобная предыдущей уязвимость CVE-2019-11246, которая позволяет атакующему доставлять файлы из пода на компьютер оператора или модифицировать их с помощью подмены tar binary, используя обычную внутреннюю команду kubectl cp [6].
В августе 2019 года в библиотеке net/http языка Go, на котором написан K8s, были обнаружены 2 опасные уязвимости, затрагивающие все версии этой системы оркестрации контейнеров: CVE-2019-9512 и CVE-2019-9514. Они позволяли неавторизированному злоумышленнику спровоцировать DoS-атаку на кластер путем отправки постоянных запросов на пир HTTP/2 или неправильных запросов на несколько открытых потоков. Это приводило к увеличению ресурсов, потребляемых поставленными в очередь данными (такты ЦП и объемы памяти), что вызывало отказы в обслуживании системы. Уязвимости устранены выпуском новой версии Kubernetes [7].
Чем обусловлены эти и другие уязвимости Kubernetes, а также каковы основные векторы и типы атак на эту систему оркестрации контейнеров, наиболее часто применяемую в Big Data проектах, читайте в нашей следующей статье. А как защитить свои большие данные в корпоративном хранилище (Data Lake) Hadoop и других кластерных решениях для Big Data, рассматривается в программе DSEC: Безопасность озера данных Hadoop на наших практических курсах обучения и повышения квалификации ИТ-специалистов в лицензированном учебном центре для руководителей, аналитиков, архитекторов, инженеров и исследователей больших данных в Москве.
Источники
- https://habr.com/ru/company/flant/blog/436300/
- https://www.anti-malware.ru/news/2018-12-07-1447/28263
- https://www.securitylab.ru/news/496803.php
- https://www.securitylab.ru/news/498596.php
- https://habr.com/ru/company/ruvds/blog/440096/
- https://tech-geek.ru/kubernetes-security/
- https://www.securitylab.ru/news/500532.php
