Часть 2
В прошлой статье мы вместе расстроились из-за отчета, который мой приятель получил от интегратора, проводившего пентест его kubernetes кластера. Горевали мы недолго, потому что сначала стали обсуждать возможные угрозы, а потом перешли к насущному вопросу – а как вообще проводить тестирование kubernetes кластера на проникновение? Для него есть какой-то специальный модуль в MetaSploit? Или целая специальная сборка Kali linux? Всё немного тоньше. Разберемся в материале.
Модуль возможно есть или скоро появится, но только для конкретной уязвимости. А мне бы хотелось иметь на руках чек-лист или даже готовый сценарий того, что нужно проверить и как это сделать, чтобы убедиться в правильной настройке. Но это все мечты, готового сценария не будет, поэтому я решил сформулировать несколько пунктов, без которых отчет о тестировании принимать не стоит.
Кстати, если вы сами решили разобраться, как тестировать на проникновение kubernetes, то предлагаю сразу после прочтения документации и этой статьи, начать с проекта kube-goat - это kubernetes кластер, в котором намеренно оставили всевозможные уязвимости для вашей пользы и удовольствия. Вы точно никому не помешаете, не нарушите законов, зато получите ценный опыт.
Инструменты тестирования
Теперь давайте пройдемся по инструментарию. Инструментов для тестирования довольно много, но зачастую они охватывают какой-то отдельный аспект безопасности. Нам интересно то, что сразу нарисует как можно более полную картину.
- Kube-bench
Во-первых, у нас есть kube-bench от Aqua Security. Этот инструмент проверит ваш кластер по рекомендациям CIS Security. Причем это будет довольно подробный отчет, разделенный на области – безопасность мастера, безопасность базы, политики и т.п. Это простой и эффективный инструмент начальной оценки, который почти наверняка ничего не сломает, и это большой плюс.
Даже только установленный kubernetes кластер имеет проблемы, что уже говорить о таких, где проводились настройки несколькими поколениями девопсов.
- Kube-hunter
Во-вторых, у нас есть злой брат-близнец предыдущей утилиты – kube-hunter, которая предназначена для оценки безопасности уже с точки зрения атакующего. Ее можно установить самостоятельно или воспользоваться готовым контейнером, который для нас любезно собирает и поддерживает в актуальном состоянии всё та же Aqua Security. Использовать ее довольно просто, указываем режим сканирования и вперед. Дополнительно, есть функция активного сканирования, когда при обнаружении уязвимостей она будет пытаться вносить какие-то изменения в кластер. Использовать нужно с осторожностью и только там, где вы подробно обсудили и договорились с заказчиком, как именно будет происходить пентест.
Только-только ведь развернул кластер, а уже есть что показать
- Kubescape
Далее у нас идёт kubescape – это инструмент скорее для поиска ошибок в конфигурации, но и проверять на соответствие лучшим практикам она тоже умеет. При этом использует понятные фреймворки вроде той же Mitre Att&ck и CIS Benchmark, к которым уже мы успели привыкнуть.
У kubescape к нам уже тоже масса вопросов
В принципе для начала этого достаточно. Конечно, есть специализированные утилиты, например, для ситуации, когда вы уже оказались в поде, вроде BOtB и kdigger, но их нужно подключать по ситуации. Да и в сам под вы попадаете скорее всего, найдя уязвимости в веб приложении, а для этого свои инструменты и техники, рассказывать про которые не хватит никакой статьи.
Отчет
Теперь про сам отчет, который вы получите после проведения работы. В принципе, никакого стандарта не существует, однако, я бы очень расстроился, если бы в отчете не было нескольких ключевых моментов.
- обследование кластера
Для начала в отчете должен быть раздел про обследование кластера. Да, в этом месте могут быть выгрузки из различных утилит, однако все находки должны быть подробно прокомментированы. Даже если вас исследовали просто с помощью какого-нибудь shodan.io, всё равно важно помнить – kubernetes сложная программа, с большим количеством сервисов, портов взаимодействия и нюансов настройки. Даже открытие доступа к ресурсам kubernetes в вашем ЦОД – уже нетривиальная задача с многими развилками. Мне доводилось видеть, как наружу публиковали Kubernetes API server на 443 порту, а пентестеры игнорировали его, мол, наверное, какой-то ваш сайт опубликован, всё хорошо, идем дальше.
Очень здорово, если на этом отчет закончится и пентестеры попробовали всё, что умеют, но ни до чего не добрались. Однако, если это не так, то идем дальше.
- разбор доступа в под
В отчете должен быть подробный разбор того, как белые хакеры оказались внутри одного из подов. Скорее всего это будет рассказ про ошибку в вашем приложении, которая тоже должна обязательно найти отражение в отчете. На этом этапе, кстати должны бы уже сработать различные решения по предотвращению вторжений в kubernetes. Даже простейшие сигнатурные средства должны насторожиться, когда пентестеры начнут разглядывать переменные окружения, пытаясь понять, где же они оказались. Затем они будут выяснять какие права им доступны и сети и не оказались ли они в одном из таких подов, откуда можно легко выбраться. Это кстати, следующая часть, которая должна быть в отчете – как именно мы выбрались из контейнера.
- разбор выхода из контейнера
Способов, кстати, не так много - уязвимости рантайма, ядра или даже самого кубера. Или, как я уже говорил, если повезло попасть в плохой под, в котором и так прав больше чем следовало.
Финал
Выбравшись из контейнера, ситуация сводится к пентесту обычной линкус машины, с поиском информации, попыток поднятия привилегий, а также развитием атаки. Об этом написано тысячи статей, останавливаться на этом не будем.
В принципе этого достаточно, чтобы принять отчет и начать прорабатывать изменения в конфигурации кластера. Самостоятельно, а еще лучше с привлечением опытных специалистов. В следующем материале мы посмотрим, с чего начать защиту своего кластера – возможно, что-то окажется неочевидным.
Материал подготовил руководитель группы защиты инфраструктурных ИТ‑решений компании «Газинформсервис» Сергей Полунин, блог Сергея можно почитать по ссылке.
