Взгляд на безопасность кластера K8S с точки зрения злоумышленников (часть 1)

9 декабря 2022 г.

Как представитель облачных систем управления и оркестрации Kubernetes (сокращенно K8S) привлекает все больше внимания. Отчет [1] показывает, что 96 % организаций используют или оценивают K8S, и его доля рынка в производственных средах очевидна.

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

Основываясь на предыдущем опыте тестирования на проникновение, мы разобрались с возможными проблемами безопасности в архитектуре кластера K8S и отметили потенциальные точки атаки в инфраструктуре кластера K8S

Эта статья состоит из двух частей: первой части и второй части. Эта часть является первой частью. В основном он представляет атаки на компоненты K8S, внешние службы узлов, бизнес-модули и выход из контейнера, что соответствует точкам атаки 1–7 на рисунке 1. Остальные будут представлены в следующей главе.

Точка атаки кластера K8S

Точка атаки: атаковать компоненты K8S

Проблема компонентов K8S в основном связана с небезопасной конфигурацией каждого компонента. Пункты атаки 1–4 перечисляют четыре репрезентативные проблемы компонентов, а именно: несанкционированный доступ к серверу API, несанкционированный доступ etcd, несанкционированный доступ kubelet и небезопасная конфигурация прокси-сервера Kube.

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

В таблице 1 собраны порты по умолчанию со скрытыми опасностями каждого компонента для справки:

| имя компонента | порт по умолчанию | |----|----| | API-сервер | 8080/6443 | | приборная панель | 8001 | | кубелет | 10250/10255 | | и т. д. | 2379 | | быть прокси | 8001 | | докер | 2375 | | куб-планировщик | 10251 | | kube-контроллер-менеджер | 10252 |

Точка атаки: внешняя служба узла атаки

В дополнение к обычному внешнему бизнесу также могут быть некоторые «скрытые» открытые службы, которые не должны быть доступны для внешней сети. Такая ситуация может быть вызвана небрежностью администратора, либо какой-то преднамеренно зарезервированной для удобства управления. Короче говоря, интерфейс также является потенциальной точкой атаки.

Например, я сталкивался с проблемой входа со слабым паролем во внешнюю службу Mysql раньше: один из узлов целевой системы сопоставляет порт службы Mysql извне через NodePort, и после попытки он может войти через слабый пароль . Эта ситуация связана с недостаточной осведомленностью администратора о безопасности.

Говоря об атаках на Mysql, мы обобщили три пути атаки Mysql для справки в предыдущем процессе тестирования на проникновение, как показано на рис. 2:

* Прямой доступ к Mysql через внешние интерфейсы, такие как NodePort, и вход в базу данных через слабый пароль; (соответствует шагу 1 на рисунке 2) * Атакуйте приложение, получите оболочку модуля, найдите внутрисетевой адрес службы Mysql через переменную окружения в модуле, а затем попробуйте войти в систему со слабым паролем; (соответствует шагам 2-1 и 2-2 на рисунке 2) * Атакуйте приложение, получите оболочку модуля и успешно сбегите к узлу. Используйте проверку докеров, чтобы просмотреть или напрямую войти в контейнер Mysql, работающий на текущем узле. Вы можете видеть, что его переменные среды сохраняют имя базы данных, пароль root, адрес входа в базу данных и т. д. Информация (при условии, что контейнер Mysql и контейнер приложения развернуты на одном узле, и будет ли конфиденциальная информация, такая как пароли базы данных, хранится в переменных среды, зависит от конкретной конфигурации контейнера Mysql). (соответствует шагам 3–1, 3–2, 3–3 на рис. 2)

Точка атаки 6: атака сервисных модулей

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

Поскольку веб-безопасность развивалась на протяжении стольких лет, существует множество уязвимостей, которые можно использовать, не говоря уже об уязвимости Log4j2-RCE (CVE-2021-44228), обнаруженной в конце 2021 г., и недавней Уязвимость Spring-RCE (CVE-2022)-22965), ее вред очень велик, а ее эксплуатация также очень проста (например, уязвимость Log4j2, хотя метод эксплуатации отличается в старшей и младшей версии среды JDK , в Интернете уже есть много готовых EXP), после успешного использования он может полностью захватить весь бизнес-модуль.

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

Сбор информации

При входе в новый модуль первым делом нужно собрать информацию о текущей среде.

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

* ОС, ядро, основная информация о пользователе * Доступные возможности * Доступные команды Linux * Монтажная ситуация * Ситуация в сети * Информация об API метаданных поставщика облачных услуг

Второй — обнаружение конфиденциальных служб и сканирование конфиденциальной информации. Обнаружение конфиденциальных служб можно выполнить путем сканирования портов указанного сегмента сети в интрасети. В дополнение к портам компонентов K8S существуют следующие общие служебные порты:

* сш：22 * http: 80/8080 * https: 443/8443 * MySQL: 3306 * Советник：4194 * nodeport-service：30000-32767

Конфиденциальная информация включает в себя конфиденциальные файлы, связанные с бизнесом (такие как код, база данных, AK/secret или важные файлы конфигурации, связанные с бизнесом), переменные среды (которые могут раскрывать некоторую конфиденциальную информацию о службе), информацию K8S ServiceAccount (хранится в /run по умолчанию) /secrets/kubernetes.io/serviceaccount/), информацию о процессах (с конфиденциальными службами или без них) и т. д.

Повышение привилегий

В K8S существует два типа повышения привилегий: повышение привилегий внутри модуля и повышение привилегий K8S.

Повышение привилегий в Pod

Повышение привилегий в модуле аналогично традиционному повышению привилегий в Linux, которое заключается в повышении уровня оболочки обычного пользователя в модуле до оболочки с привилегиями root. Вообще говоря, даже если вы получите оболочку пода, вы можете иметь только привилегии обычных пользователей. В настоящее время ваши возможности по-прежнему очень ограничены, поэтому вам нужно использовать уязвимость повышения привилегий, чтобы получить привилегии суперпользователя. Существует множество способов повышения привилегий, например повышение уровня уязвимости ядра, повышение уровня sudo, повышение уровня suid, повышение уровня задания cron и т. д.

Стоит отметить, что некоторые уязвимости ядра также могут быть использованы для выхода из контейнера, такие как знаменитая DirtyCow (CVE-2016-5195), DirtyPipe (CVE-2022-0847) и т. д., о которых будет сказано в Раздел «Побег из контейнера» ниже. приехать.

Повышение привилегий K8S

Существует множество способов и сценариев повышения привилегий K8S, например повышение привилегий RBAC [2], и несколько дней повышения привилегий K8S, например CVE-2018-1002105, CVE-2020-8559 и т. д.

Отказ в обслуживании

Атаки типа "отказ в обслуживании" (DOS) можно рассматривать на трех уровнях: бизнес, модуль и кластер.

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

Атаки DOS на уровне кластера могут в основном использовать программные уязвимости кластеров K8S, такие как CVE-2019-11253, CVE-2019-9512, CVE-2019-9514 и т. д.

Точка атаки 7: побег из контейнера

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

Небезопасная конфигурация контейнера

Небезопасная конфигурация контейнера делится на два случая. В первом случае контейнеру даются опасные разрешения, а во втором случае контейнер монтируется с опасным каталогом. Подробная информация представлена ​​в таблице 2:

| категория | небезопасная конфигурация | |----|----| | Опасные разрешения | Привилегированный контейнер | | н | cap_sys_admin | | н | cap_dac_read_search | | н | cap_sys_module | | н | cap_sys_ptrace && --pid=хост | | Опасная гора | смонтировать docker.sock | | н | смонтировать procfs | | н | Смонтировать / , /root , /etc и другие файловые каталоги | | н | Смонтировать lxcfs в режиме rw | | н | pod монтирует /var/log n |

Под опасными разрешениями понимаются привилегированные разрешения (привилегированные контейнеры) и разрешения опасных возможностей (например, cap_sys_admin, cap_sys_module, cap_sys_dac_search и т. д.), которые можно задать с помощью параметров запуска при запуске контейнера. Как упоминалось выше, контейнер — это, по сути, ограниченный процесс. В дополнение к ограничению пространств имен и ресурсов через Namespace и Cgroup существуют также механизмы безопасности, такие как Capabilities, Apparmor и Seccomp, которые ограничивают разрешения процессов в контейнере. С указанными выше опасными разрешениями нарушается механизм безопасности, ограничивающий контейнер, что открывает двери для злоумышленников.

Монтирование опасного каталога контейнером может привести к нарушению изоляции файловой системы контейнера и, таким образом, к получению привилегий. Например, если смонтирован /var/run/docker.sock, то внутри контейнера возможна связь с демоном docker, и злоумышленник может создать привилегированный контейнер и сбежать.

Здесь упоминаются некоторые из наиболее распространенных небезопасных конфигураций в методах атаки с выходом из контейнера. Кроме того, CIS Docker Benchmark[3] предлагает сотни эталонных тестов конфигурации безопасности для контейнеров Docker. Для защиты от уязвимостей проблемы с конфигурацией безопасности часто проще игнорировать. Злоумышленникам часто легче обнаружить и использовать небезопасную конфигурацию контейнеров, чем связанные с ней программные уязвимости и уязвимости ядра, упомянутые ниже.

Уязвимости связанных компонентов

Среда кластера контейнеров содержит множество программ-компонентов, которые взаимодействуют друг с другом, образуя огромную экосистему службы контейнеров. Эти компоненты включают, помимо прочего, runc, containerd, docker, kubelet и т. д. Любая программа будет иметь уязвимости, и программы, связанные с контейнерами, не являются исключением. Однако по сравнению с небезопасными конфигурациями контейнеров большинство этих уязвимостей сложнее использовать. Например, CVE-2019-5736 требует взаимодействия между хостом и контейнером для срабатывания. , а эта уязвимость является "одноразовой", и ее легко выявить, поскольку она нарушает работу runc.

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

| компоненты | Уязвимость | |----|----| | бежать | CVE-2019-5736 | | н | CVE-2019-16884 | | н | CVE-2021-30465 | | контейнер | CVE-2020-15257 | | н | CVE-2022-23648 | | ПЛАКАТЬ | CVE-2022-0811 | | докер | CVE-2018-15664 | | н | CVE-2019-14271 | | кубектл | CVE-2018-1002100 | | н | CVE-2019-1002101 | | н | CVE-2019-11246 | | н | CVE-2019-11249 | | н | CVE-2019-11251 | | кубелет | CVE-2017-1002101 | | н | CVE-2021-25741 |

Уязвимость ядра

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

* CVE-2016-5195 * CVE-2017-1000112 * CVE-2017-7308 * CVE-2020-14386 * CVE-2021-22555 * CVE-2022-0185 * CVE-2022-0492 * CVE-2022-0847

Точно так же использование EXP уязвимостей ядра также сопряжено с риском и может даже привести к сбою целевой системы при слепой попытке (особенно если это внутренний тест на проникновение или проверка безопасности системы).

Обобщить

В этой статье обобщаются и делятся методами и опытом атак на компоненты K8S, внешние сервисы узлов, бизнес-модули и побег контейнеров в кластере K8S, а именно точки атаки 1-7 на рис. 1. В следующей части мы продолжайте говорить о точках атаки 8–12 на рис. 1, включая боковые атаки, а также атаки на платформу управления K8S, библиотеку образов и сторонние компоненты.

Ссылка

* https://www.cncf.io/wp-content /uploads/2022/02/CNCF-Annual-Survey-2021.pdf * https://published -prd.lanyonevents.com/published/rsaus20/sessionsFiles/18100/2020_USA20_DSO-W01_01_Компрометация кластера Kubernetes путем использования разрешений RBAC.pdf * https://github.com/dev-sec/cis-docker-benchmark * https://github.com/cdk-team/CDK

:::информация Также опубликовано здесь.

:::

---

Оригинал