Часть 1

Всем привет, я Сергей Полунин и сегодня расскажу вам одну интересную историю. Мой приятель, не скрывая восторга, сообщил, что они завершили многомесячный проект — наконец упаковали свои бизнес‑приложения в контейнеры, развернули kubernetes кластер в облаке, подключили мониторинг и теперь у них всё как у взрослых. Кластер у них небольшой, так что они в тренде. Вот и последний отчет Kubernetes in the wild report 2023 | Dynatrace news и намекает, что эти облачные кластеры kubernetes не такие уж и крупные обычно. С чего‑то же надо начинать. «Слушай, нам даже выделили денег на пентест новой инфраструктуры, хочешь отчет глянуть?». Я открыл отчет, и эйфория от услышанного начала улетучиваться.

---------------------------

Так называемый отчет оказался просто выгрузкой работы бесплатной утилиты kube‑bench, которая только проверяет настройки kubernetes кластера в соответствии рекомендациями CIS Kubernetes Benchmark. Конечно, всё было красиво оформлено в фирменные цвета интегратора, и стояли подписи инженеров, участвовавших в задаче. Сколько тысяч денег они за это взяли, я спрашивать уже не стал. Эта ситуация и побудила меня написать эту статью. В ней разберемся с чего начать анализ защищенности kubernetes кластера в облаке и как эффективнее обеспечить безопасности kubernetes, прежде чем звать белых хакеров.

С чего начать?

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

Во‑первых OWASP относительно недавно обновила свою версию TOP 10 уязвимостей по аналогии с тем, что они делают для веб и мобильных приложений. На сайте они расписаны очень подробно, можно вникнуть. Конечно любые топы — штука для дискуссии, но это неплохая исходная точка, чтобы начать разбираться в том, что вообще может случиться и от чего нам нужно защищаться.

Во‑вторых, от того же OWASP у нас есть гайд по тестированию — он в разработке, но кое‑что можно оттуда почерпнуть уже сейчас.

План битвы

Кроме занятной документации у нас есть аналогичная матрица для kubernetes от Microsoft (неожиданно, правда?). И к счастью, она не такая неподъемная как матрица, например, для ОС семейства Windows.

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

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

Этап 1. Начальный доступ

Все способы можно разделить на 5 классов и соответствующим образом выстраивать защиту:

1. Использовать учетные данные от облачного сервиса. Это актуально, если ваш kubernetes кластер размещается в облаке. Очевидно, если ваша учетная запись будет скомпрометирована, то хакеры получат доступ и к кластеру. Хотя я не уверен, что это будет самая большая из ваших проблем в этом случае. Учетная запись от облачной среды — это уже само по себе ценность и карта с Граалем.

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

3. Файл kubeconfig, который содержит все данные для подключения к кластеру. Если он попадет в руки хакеру, а никаких других мер защиты не предусмотрено, то доступ будет получен без проблем. Вы, конечно, можете удалить сертификаты из файла и передавать их отдельно, или придумать что‑то еще не менее креативное, но валидный файл kubeconfig — это самый короткий путь в ваш кластер.

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

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

Этап 2. Выполнение команд

Итак, начальный доступ в кластер получен, но проблемы теперь только начинаются. Злоумышленники будут пытаться выполнять свои команды в нашем кластере. Способов 4:

1. Использовать kubectl exec. Это совсем простой способ, позволяющий выполнять команду внутри запущенного пода. Главное, чтобы прав хватило. А их скорее всего хватит, если мы уже в этой ситуации оказались;

2. Запустить новый под со своим контейнером. Это примерно то же самое, что и предыдущий вариант на самом деле. Только на вас может не среагирует ids внутри пода. Да, для подов есть специальные «мини‑ids», которые мониторят активность пода, стараясь особо не ломать производительность;

3. Эксплуатация приложения. Возможно, уязвимое приложение в поде не доступно снаружи, зато очень даже доступно уже внутри кластера.

4. Доступ в контейнер по SSH (Secure SHell). Просто имейте в виду, что запуск команд может быть запрещен, а вот SSH никто не запрещает почти никогда, потому что это штатный способ администрирования в linux, и отключать его никто не станет. Да, правила хорошего тона говорят, что вносить изменения в конфигурацию уже запущенного пода нельзя, но когда исправить что‑то нужно прямо сейчас, то без SSH вы не справитесь.

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

Этап 3. Закрепление в системе

Способов 3:

1. Бэкдор. Злоумышленники создают объект deployment или daemonset, содержащий их зараженный контейнер, чтобы убедиться, что он не исчезнет при обновлении системы. Разницу Вы знаете — в первом случае будет равномерно запущено какое‑то количество подов, во втором — поды будут на каждой ноде. Если дать объекту неброское название, то можно оставаться в системе еще длительное время, но об этом позже.

2. Доступный для записи hostPath. Это история про то, что если у атакующих есть права создавать новые контейнеры, то они могут создать такой контейнер и получить доступ к файловой системе хоста, на котором запущена нода kubernetes. А имея доступ к файловой системе можно оставить необходимые закладки.

3. Cronjob. В kubernetes есть свой планировщик, который отслеживает создание новых подов и поиск для них необходимых нод. Можно добавить в этот планировщик задачу запуска вашего пода, содержащего ваш контейнер с вредоносным кодом на случай, если внимательный админ удалит непонятный под из кластера.

Этап 4. Повышение привилегий

Половина дела сделана. Хакеры получили доступ в вашу систему и теперь думают, как продвигаться дальше. Для этого им нужно как‑то повысить свои привилегии. Да, возможно всё настолько плохо что они придут к вам уже с правами администраторов всего вокруг, но я надеюсь вы позаботились на этапе развёртывания о базовом разделении полномочий. В этом случае хакерам придется выбирать из следующего:

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

2. Cluster‑admin биндинг. В основе разделения полномочий в Kubernetes используется ролевая модель, или RBAC. И хранятся эти объекты RBAC тоже непосредственно в кластере. Роль Cluster‑admin — это встроенная роль админа кластера. Если злоумышленнику хватит прав, то он без проблем сделает себе учетную запись и даст ей необходимую роль.

3. hostPath. Вырваться из контейнера можно и с помощью hostPath, про который писали выше.

4. Доступ к облачным ресурсам. Если ваш кластер запущен в облаке, то есть ненулевая вероятность, что, покинув пределы контейнера одним из доступных способов, злоумышленник найдет непосредственно на сервере ноды кластера что‑то, что позволит двигаться дальше.

Этап 5. Обход защитных механизмов

Как только хакеры начнут повышать привилегии, уже должны начать работать ваши IPS или SIEM, которые у вас, не сомневаюсь, развернуты. Сейчас или никогда. Даже с минимальными настройками эти системы должны реагировать на то, что супер‑пользователь делает какие‑то странные действия. Злоумышленники не отстают и начинают делать следующее:

1. Удалять логи контейнеров. У контейнеров есть свои логи — логи собственно программ, которые в них запущены и ОС. Если вы не собираете логи централизованно, а обращаетесь к ним по мере необходимости, то можно их и не дождаться. А если вы заметили, что их не стало? Ну вы поняли…

2. Удалять события kubernetes. И у kubernetes безусловно есть свои логи. Все эти события о старте и остановке подов, поднятию нод, скачиванию образов и т. п. Если логи внезапно недоступны, то возможно, уже поздно.

3. Создание похожих подов. Поды, которые создаются с помощью объектов deployment или daemonSet имеют случайные суффиксы. Они действительно случайные и могут примелькаться. Поэтому довольно частая тактика — создавать поды с вредоносным содержимым, но с похожими названиями. Или просто прятать их в namespace kube‑system, где хранится начинка kubernetes — всё равно туда никто не заглядывает. Там поды могут жить месяцами.

4. Подключаться через прокси. Редко кто‑то атакует системы с открытых публичных IP. В принципе вы еще на своем межсетевом экране можете заметить, что к кластеру подключились откуда‑то издалека.

Этап 6. Доступ к учетным данным

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

1. Секреты Kubernetes. Собственно, секреты Kubernetes — специальный объект в кластере для хранения всякой ценной информации. Секретов этих встроено несколько разных видов для разных популярных сценариев, но важно помнить, что они не то, чтобы очень защищены по умолчанию, хотя у них есть своя важная функция.

2. Учетные записи в облаке. Уже разбирали выше — получив доступ к ОС ноды кластера, можно начать искать секреты там.

3. Доступ к сервисному аккаунту. По умолчанию в каждый под в кластере монтируется сервисный аккаунт, с помощью которого поды собственно общаются с API‑сервером. Получив доступ к поду, можно добраться до токена этого аккаунта (который лежит где‑то вроде /var/run/secrets/kubernetes.io/serviceaccount/token в зависимости от вашей реализации) и выполнять разные действия. А если у вас еще и RBAC не используется, то это просто неограниченные права.

4. Учетные данные в конфигурационных файлах. Речь идет про всякие секреты, которые разработчики хранят в конфигах — те же переменные окружения. Если нет специализированного решения для их хранения и доставки в поды, то будут проблемы.

Этап 7. Продолжаем разведку

Но ситуация развивается, и наши хакеры решают двигаться дальше. Обычно дальше двигаются не куда‑то конкретно, а туда, до куда получается дотянуться. А для этого как раз и существует фаза поиска:

1. Доступ к kubernetes API. Собственно, все элементы общаются с кластером через API. Но специально обращаясь к API, мы может добыть информацию, которая никак не используется в существующей инфраструктуре, однако полезна для чего‑то другого. Например, обнаружить скрытый namespace, где разработчики забыли какой‑то API‑ключ, который о чудо, оказывается всё еще работает;

2. Доступ к kubelet API. Kubelet — это агент kubernetes, ответственный за корректную работу подов на нодах кластера. У kubelet тоже есть свой API в режиме только для чтения, и через него можно вытащить всю информацию по подам на отдельно взятой ноде;

3. Доступ к дашборду. Тут довольно просто — если он настроен, то никто не будет заморачиваться с вводом команд, а соберет информацию непосредственно из GUI;

4. API‑метаданных. Если ваш кластер запущен на виртуальной машине в облаке, то облачный провайдер скорее всего позволяет собирать метаданные об этой виртуальной машине. Так делают все ваши амазоны и ажуры, и даже ваш провайдер скорее всего не отстаёт. Собранная информация таким образом может помочь найти какие‑то новые дополнительные сведения.

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

Финал

В конце нужно поговорить об ущербе. Тут большого разнообразия нет, и в принципе взлом kubernetes в этом смысле мало отличается от взлома любого другого сервера:

1. Уничтожение и кража данных. Всё просто, украли то, к чему получили доступ;

2. Захват ресурсов. Мощности взломанного сервера можно использовать в своих целях. Например, можно устроить DDoS‑атаку с десятка таких вот захваченный серверов. Или вот популярная история — майнинг. И это уже серьезная финансовая проблема, если это облачный сервер, и вы платите за использованные ресурсы. Облачные провайдеры, кстати, часто идут на встречу, если вы докажете факт компрометации и не станут выставлять вам сумасшедшие счета;

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

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

Материал подготовил руководитель группы защиты инфраструктурных ИТ‑решений компании «Газинформсервис» Сергей Полунин, блог Сергея можно почитать по ссылке.