Где все нарушения контейнеров?

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

Вместо этого у меня есть много разных идей, ни одну из которых я не могу назвать правильной. Частично эта нерешительность связана с тем, что я потратил все время на изучение безопасности в «унаследованном» мире. Контейнерам действительно нет аналога. Конечно, виртуальные машины (ВМ) часто путают с контейнерами, но они никогда не могли масштабироваться как контейнеры. Они также используются для совершенно других целей, чем контейнеры. Мне потребовалось некоторое время, чтобы скорректировать свое мышление и понять, где контейнеры действительно вписываются в поверхность атаки.

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

По старому

Уязвимости удаленного выполнения кода (RCE) долгое время были основной проблемой компьютерной безопасности. Они по-прежнему существуют, но как этот образ мышления применим к контейнерам? Легко сразу перейти к RCE как к основной угрозе, но, похоже, это неправильный подход к контейнерам. Во-первых, контейнеры зачастую очень недолговечны – 44% контейнеров живут менее пяти минут – так что злоумышленник должен быть быстрым.

Этот подход также предполагает, что контейнер доступен в Интернете. Конечно, некоторые контейнеры настроены таким образом, но зачастую они очень просты и используют хорошо проверенные технологии, такие как NGINX. Для этих приложений могут существовать нулевые дни, но они будут чрезвычайно ценными, и их будет трудно найти. Мой опыт показал, что многие контейнеры используются внутри компании и не подключаются напрямую к Интернету. В этом случае сценарий RCE становится намного сложнее. Я должен упомянуть Лог4дж, хотя такого рода уязвимости могут быть использованы удаленно, даже если уязвимая система не находится на грани.

Новый Путь

Если RCE не является самой большой угрозой для контейнеров, то что? Находятся ли контейнеры в поле зрения злоумышленников? Да, контейнеры и поддерживающая их инфраструктура слишком важны, чтобы их игнорировать. Программное обеспечение для оркестровки контейнеров позволило масштабировать контейнерные рабочие нагрузки до невообразимых размеров. Тенденция использования также растет, поэтому вы можете быть уверены, что они станут целью. Их просто нельзя рассматривать как серверы, к которым вы можете получить доступ через уязвимости RCE.

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

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

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

Путь вперед

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