5 инцидентов безопасности Kubernetes и чему мы можем у них научиться

Безопасность по-прежнему остается проблемой №1 для организаций, использующих Kubernetes, и что интересно, она имеет мало общего с присущей самому Kubernetes небезопасностью. Наоборот, это во многом связано с тем, насколько на самом деле сложен Kubernetes, и с тем фактом, что даже опытным облачным разработчикам часто бывает трудно ориентироваться. Согласно недавнему отчету StackRox, в дополнение к крутой кривой обучения и нехватке квалифицированной рабочей силы, незащищенность из-за неправильных конфигураций является основной причиной инцидентов безопасности Kubernetes. Получив информацию от более чем 540 респондентов, мы пришли к выводу, что более 94% сталкивались с инцидентами безопасности за последний год!

Как показывает этот краткий список крупных инцидентов безопасности Kubernetes, они были далеко не одни.

1. Капитал Один

Этот инцидент с безопасностью Kubernetes был крупным, без каламбура, и заставил многих людей проснуться и обратить на это внимание. Произошедший ровно год назад, этот взлом привел к краже 30 ГБ данных о кредитных заявках, затронувших около 106 миллионов человек. То, что на самом деле вызвало нарушение, — это то, что мы довольно часто видим в мире Kubernetes, неправильная конфигурация. В частности, неправильно настроенный брандмауэр, который позволял злоумышленнику запрашивать внутренние метаданные и получать учетные данные роли IAM Amazon Web Services, которая изначально не имела такого «широкого» значения.

Один из важных уроков, который мы извлекли из этого инцидента, заключается в том, что нужно быть более осторожным при назначении ролей IAM. Большинство людей просто торопятся заставить Kubernetes работать и часто обходят стороной важные задачи, такие как управление секретами и службами и назначение ролей IAM для каждого модуля, а не для каждого приложения. Еще одна важная задача — регулярно «прокручивать» учетные данные, желательно с помощью автоматизированной службы, которая устанавливает ограничение на то, как долго необходимо обновлять учетные данные. Это также устанавливает верхний предел того, как долго может продолжаться нарушение.

2. Докер-хаб

С Kubernetes, контейнерами и распределенными средами поверхность атаки становится все больше в геометрической прогрессии, и вы никогда не знаете, откуда придет атака. Одним из примеров является то, как в прошлом году злоумышленникам удалось внедрить вредоносные образы в хаб Docker, в результате чего любой, кто использует эти образы, подвергается «криптоджекингу». Это означает, что пользователи неосознанно развернули майнеры криптовалюты в виде контейнеров Docker, которые затем перенаправили вычислительные ресурсы на добычу криптовалюты для злоумышленника. Это лишь одна из множества подобных атак, которые мы наблюдаем в последнее время.

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

3. Майкрософт Азур

Microsoft — еще одна организация, которая сама столкнулась с множеством проблем с криптоджекингом. После того, как в апреле этого года стало известно о крупномасштабной атаке криптомайнинга на кластер Kubernetes в Azure, в июне была обнаружена аналогичная кампания, нацеленная на неправильно настроенные контейнеры Kubeflow, чтобы превратить их в криптомайнеры. Подобно ситуации со скомпрометированным образом в Docker Hub, Kubeflow использует ряд сервисов, которые, в свою очередь, позволяют пользователям использовать собственные образы, такие как сервер ноутбуков Katib и Jupyter. В случае с Jupyter выбранный образ не обязательно должен быть законным изображением ноутбука, и именно здесь злоумышленники нашли точку входа.

Если мы посмотрим, что вызвало эту неправильную конфигурацию, то это почти то же самое, что вызывает каждую неправильную конфигурацию — нетерпение, лень и отсутствие знаний. Информационная панель пользовательского интерфейса Kubflow по умолчанию доступна только изнутри через входной шлюз Istio. Некоторые пользователи, тем не менее, пошли по короткому пути, чтобы получить доступ к панели управления напрямую, минуя API-сервер Kubernetes, и не осознавали, что, хотя то, что они делали, экономило время, но также открывало ряд лазеек в процессе. В данном случае они открывали входной шлюз Istio в Интернет, позволяя любому получить доступ к панели управления. Мораль этой истории заключается в том, что каждое изменение параметра или конфигурации имеет последствия для безопасности.

4. Тесла

С ростом стоимости криптовалют и неограниченными вычислительными ресурсами, размещенными в облаке, захват ресурсов стал намного более прибыльным, чем кража информации. Автопроизводитель Tesla был одной из первых жертв криптоджекинга, когда кластер Kubernetes был скомпрометирован из-за того, что административная консоль не была защищена паролем. Обнаружение было сделано RedLock Cloud Security Intelligence и обнародовано в отчете, в котором говорится, что неправильная конфигурация помогла злоумышленникам получить учетные данные корзины Tesla AWS S3. Затем эти учетные данные использовались для запуска скрипта криптомайнинга в модуле.

Что было интересно в этой атаке, так это количество «настоящих» мер предосторожности, предпринятых для того, чтобы избежать обнаружения. Злоумышленники не только воздержались от использования известного пула для майнинга и вместо этого использовали незарегистрированный, но и использовали популярный сервис CDN Cloudflare, чтобы скрыть свой IP. Злоумышленники также позаботились о том, чтобы скрипт майнинга не использовал достаточно ресурсов ЦП, чтобы вызвать тревогу или быть обнаруженным, и прослушивал нестандартный порт, что делало обнаружение на основе трафика порта практически невозможным. Единственный способ обнаружить такое нарушение — активно отслеживать конфигурации, чтобы убедиться, что все политики соблюдаются.

5. Дженкинс

Чтобы оценить стоимость такого хищения ресурсов примерно в то же время, что и инцидент с Tesla, хакерам удалось использовать уязвимость в Jenkins для криптомайнинга на сумму около 3,5 миллионов долларов, или 10 800 Monero за 18 месяцев.. Monero — это та же криптовалюта, связанная с вредоносными образами Docker, о которых мы упоминали ранее. В случае с Docker было обнаружено, что шесть вредоносных образов были совместно извлечены более 2 миллионов раз, то есть 2 миллиона пользователей потенциально добывают Monero для врага, что является настоящим подвигом.

Инцидент безопасности Jenkins Kubernetes, безусловно, является одним из самых смелых обнаруженных нарушений, помимо того, что он использует уязвимые машины Windows и персональные компьютеры, работающие под управлением Jenkins, он также нацелен на серверы Jenkins CI. Это недавнее обновление, так как вредоносное ПО проходит ряд жизненных циклов, в ходе которых оно постоянно обновляется и меняет пулы майнинга, чтобы избежать обнаружения. Тот факт, что теперь он может атаковать серверы, является шагом вперед со стороны злоумышленников китайского происхождения. Если бы они могли получить более 3 миллионов долларов от потрепанных настольных компьютеров, мощные серверы добавят к этой цифре как минимум несколько нулей.

Безопасность Kubernetes: поверхность атаки продолжает расти

Инциденты безопасности Kubernetes растут, потому что поверхность атаки теперь представляет собой бесконечную армию гибридных облаков, локальных центров обработки данных, устройств IoT, персональных компьютеров, периферийных устройств и многого другого. Ограниченная безопасность мертва — прошли те дни, когда вы могли просто сосредоточиться на своем приложении, а все остальное оставить на брандмауэр. Угроза потенциально может исходить от службы, используемой службой, которая затем используется службой, которую вы используете. Кроме того, безопасность теперь является общей обязанностью, и ваш облачный провайдер или менеджер Kubernetes могут внести свой вклад только в том случае, если вы будете выполнять и свой. Криптоджекинг будет становиться все более распространенным по мере того, как все больше хакеров поймут, что его довольно сложно обнаружить, за исключением некоторых заметно высоких счетов за облачные услуги.