15 мая в 12:00 в рамках активности КОД ИБ под названием БЕЗОПАСНАЯ СРЕДА пройдет вебинар "С чем безопаснику стоит есть Kubernetes и почему это отличается от всего с чем вы работали раньше?".

Наша команда Luntry примет участие вмести с крутыми специалистами и нашими хорошими друзьями из Тинькофф, Wildberries и Okko.

Зарегистрироваться можно тут.

В процессе, подготовки нового исследования, копаясь на сайте проекта gVisor, который является sandbox runtime, была найдена интересная/хайповая формулировка.

В новых реалиях мы будем защищаться не только от не доверенного, стороннего кода, но и от сгенерированного машиной кода с помощью Large Language Model (LLM).

В контейнерных окружениях с этим будет попроще, но вот с чисто Windows и Linux окружениями ....

P.S. Напоминаем, что идет конкурс и есть возможность выиграть билет на БеКон 2024!

26 мая (воскресенье) в 12:00 в зале Фобос в секции в SECURE DEVELOPMENT в рамках Positive Hack Days Fest 2 наша команда представит доклад "Кубик Runtime в конструкторе Kubernetes для безопасности".

Классические контейнеры имеют слабую изоляцию с точки зрения безопасности (по крайней мере, так давно считается). И нам на помощь спешит Kubernetes, который достаточно просто позволяет запускать приложения и под другими типами рантайма с более сильной изоляцией.

Но решит ли это все проблемы и не добавит ли новых?

В рамках доклада рассмотрит такие инструменты/механизмы как Sandbox, microVM, WASM, Sandbox API, Confidential Containers в мире Kubernetes.

netfetch – проект, по заявлению автора, направленный на демистификацию Network Policy в Kubernetes.

Инструмент проходится по всем нейсмпейсам и проверяет есть ли внутри них Network Policy (Native и Cilium), затем проверяет к каким Pods они привязаны. Тем самым вычисляет unprotected workloads – те, которые не находятся под влиянием Network Policy.

Также из интересного, netfetch умеет предлагать (генерацией это назвать сложно) сетевые политики для тех самых unprotected workloads. Для этого тулза анализирует YAML-манифесты Pods и основываясь на этой информации формирует NetworkPolicy. Всё это работает как через CLI так и через веб-дашборду.

На первый взгляд, инструмент кажется довольно интересным. Но когда начинаешь разбираться в правильности предложенной политики, всплывает кучу нюансов – учитываются ли ClusterWide политики? а если приложение общается с БД за пределами кластера? И другие прочие моменты..

В МГТУ им. Н.Э. Баумана по инициативе кафедры ИУ10 «Защита информации» состоится уникальный цикл лекций по фундаментальным информационным технологиям, их развитию в России и в мире "Школа фундаментальных технологий разработки безопасного ПО".

Наша команда Luntry проведет лекцию на тему «Безопасность инфраструктур под управлением оркестратора Kubernetes» состоится 27 мая в 13:30.

В рамках данной лекции мы познакомимся и рассмотрим тему оркестрации контейнеров и оркестратор Kubernetes. Мы посмотрим как устройство данной системы, так и на ее безопасность и безопасность контейнеров под ее управлением.

Обязательно зайдите и ознакомьтесь со всеми лекциями (их всего 12 штук) и они покрывают широкий спектр тем: операционные системы, система управления базами данных, виртуализация и контейнеризация, интерпретаторы, разработка безопасного программного обеспечения, композиционный и компонентный анализ!

Зарегистрироваться и ознакомиться с подробной программой и спикерами можно на сайте и в телеграм-боте.

P.S. Все лекцию должны будут доступны в записи для всех желающих.

Сегодня хочется привлечь ваше внимание к докладу "Латаем огрехи в образах приложений с помощью Kubernetes", который наша команда Luntry готовит к БеКон 2024. Данный доклад явно будет сильно отличаться от всех на конференции (и тех что мы делали до этого), так как мы изначально задумывали его как шуточный, немного юморной, не серьезный что ли.

История начинается с того что к вам/нам попадает готовый образ без каких-либо исходных данных (исходники, dockerfile - забудьте у нас их нет) и при этом он плох настолько на сколько это вообще можно придумать:
1) Много лишнего в базовом слое: Шумные отчеты об уязвимостях в базовом слое, setuid/setgid файлы, большой Attack Surface, возможности для LotL-атак
2) Чувствительная информация в слоях образа
3) Разные не закрытые CVE в самом приложении, рядом лежат майнеры и т.д.
4) Dockerfile противоречит всем лучшим практикам CIS.

В общем выдуманная ситуация (или нет?!) ...

И в таких условиях мы начинаем из этого делать конфетку. И такую, что многие позавидуют даже при наличии всех исходных данных)

Скорее всего это нельзя будет встроить и автоматизировать полностью, но при необходимости заниматься таким ручным кастомом сможет каждый!

Основная идея показать какие возможности и гибкость дают контейнеры и Kubernetes при харденинге и обеспечении ИБ.

В конце марта 2024 года была раскрыта CVE-2024-3094, также известная как XZ Utils Backdoor. В результате расследования, исследователям удалось выявить следы крупной атаки на цепочку поставок (Supply Chain attack), в ходе которой скомпрометированная библиотека liblzma была использована в sshd и использовалась для её обхода в процессе аутентификации.

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

Подведем итоги конкурса!

Мы выбрали следующую тройку победителей:
- @tg_1ek
- @panab1ack
- @Toshka_31

В ближайшее время передадим проходки.

Спасибо всем участникам и неравнодушным)

P.S. Спешите урвать билеты - они лимитированы.

Начнем эту неделю с доклада «Управление уязвимостями в микросервисах и контейнерных средах», который наша команда Luntry представляла в секции «PRO управление уязвимостями» на конференции «Территория безопасности 2024: все pro ИБ». Сейчас доступны и слайды, и видео.

В рамках данного доклада мы рассмотрели, какие есть особенность в теме vulnerability management для: микросервисов, контейнеров, окружений под управлением Kubernetes, облачных сред и т.д. И какие это дает возможности с соответствующими преимуществами и недостатками.

С удовольствием в комментариях по отвечаем на вопросы и послушаем ваши мнения и взгляды на этот счет!

Относительно недавно вышла свежая версия Kyverno – 1.12. Изменений там достаточно:

- Reports Server. Добавлена возможность использовать альтернативное хранилище (вместо etcd);

- Global Context Entry. Интересная фича, которая позволяет закэшировать и переиспользовать повторяющиеся данные в политиках, например Kubernetes Resource и вызовы API;

- Kyverno JSON in CLI. Kyverno JSON теперь интегрирован в Kyverno CLI для проверки любой полезной нагрузки в формате JSON.

- Policy Exception Enhancements. PolicyExceptions теперь поддерживают conditions{} и podSecurity{} блоки;

- ValidatingAdmissionPolicy in CLI and Reports. Kyverno CLI поддерживает применение ValidatingAdmissionPolicyBinding вместе с определением политики к ресурсам.

- Большое обновление Policy Reporter UI. Custom Boards, поддержка OpenIDConnect, OAuth2 и прочие обновления.

Вышла новая часть видео рассказа под названием "Kubernetes Security Fundamentals: API Security - Part 2". Полный же цикл данных лекций можно посмотреть тут. Это хороший видеоматериал для новичков с рассказом и демонстрацией в консоли.

Осталось ровно 2 недели до нашей конференции БеКон 2024. При этом учтите текущая цена билетов действительна только на этой неделе! Оставшиеся билеты (а у нас их ограниченное количество) пойдут уже по увеличенной стоимости. Так что успейте взять свой билет и подешевле ;)

В расписании (мы точно еще его скорректируем) вы можете наблюдать еще один пустой слот, но он уже точно занят докладом, который мы пока попридержим анонсировать. Но можем сказать, что мы хотели видеть этого докладчика и доклад еще и на первом БеКон. И вот спустя 2 годя мы все же смогли договориться!

Так доклады готовятся/репетируются - все получается очень интересным и самое важно полезном. Новый эксклюзивный стикер пак также в процессе приготовления =)

P.S. В качестве подсказки об этом докладе оставим одну подсказку - 118.

Тем временем, в ArgoCD нашли критическую уязвимость (9.1 по CVSS) CVE-2024-31989: Use of Risky or Missing Cryptographic Algorithms in Redis Cache, эксплуатация которой не требует особых привилегий и может привести к полному захвату Kubernetes кластера.

Исследователей нашедших уязвимость, заинтересовал Redis, который деплоится в кластер при установке ArgoCD, а точнее возможность подключения к нему (из любого Pod) без необходимости указывать username и password. Там они обнаружили множество ключей, которые содержали данные о развернутых приложениях. Однако ключи были сжаты в формате gzip. В документации говорится, что Redis служит в качестве кэширующего слоя, уменьшая количество запросов, отправляемых к Kube API и Git-провайдеру.

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

Однако, для того чтобы заставить ArgoCD задеплоить манифесты, доставленные через Redis, нужно было также добавить ключ с контрольной суммой. К счастью исследователей, этот хэш генерировался без какой-либо секретной подписи и им с легкостью удалось его воспроизвести (base64 encoded FNV64a). Как итог, добавив пару ключей в Redis им удалось задеплоить BadPods и получить реверс шелл, сбежав на Node.

Уязвимость затронула все версии ArgoCD, необходимые патчи доступны в версиях 2.11.1, 2.10.10, 2.9.15, 2.8.19. В качестве основной меры митигации можно рассмотреть использование NetworkPolicy для ограничения общения с инстансом Redis.

P.S. Более подробно об уязвимости можно почитать в этой статье.

Практически через месяц - 26-27 июня пройдет вторая самостоятельная двухдневная конференция CloudNativeSecurityCon. Сейчас стало доступно ее расписание, с которым рекомендуем ознакомиться - там много всего интересного (чтобы быть в тренде). И что приятного можно найти параллели с докладами с нашим небольшим, ламповым БеКон)

В глаза бросаются темы про runtime security, безопасность на базе service mesh и внимание к Linux user namespace.

AWRBACS – очередной инструмент для анализа RBAC в Kubernetes.

Со слов автора, AWRBACS создан не для того, чтобы заменить rakkes, kubectl-who-can или другие инструменты и плагины для анализа RBAC в Kubernetes, а, скорее, для их дополнения.

Инструмент позволяет смотреть права для конкретного пользователя в кластере, указать Service Account или запустить автоматическую проверку по всем субъектам в кластере. Также автор реализовал проверку прав у пользователей, добавленных через кастомные вебхуки для авторизации (Keycloak, LDAP, IAM). Если такой механизм будет действовать в кластере, то встроенные механизмы k8s, на примере, kubectl auth can-i могут работать некорректно (про это можно почитать в одном из наших предыдущих постов).

Более подробно о самом инструменте можно почтитать в заметке автора.

В этом году наша команда Luntry на мероприятии PHDays Fest 2 представила исследование «Кубик Runtime в конструкторе Kubernetes для безопасности». В рамках доклада были рассмотрены такие инструменты/механизмы как Sandbox/AppKernel, microVM, WASM, Sandbox API, Confidential Containers.

Сейчас уже доступны и слайды и видео.

В комментариях будем рады ответить на любые вопросы по данной теме.

Осталось 1 неделя до БеКон 2024. И у нас сформировался новый стикер пак! Он будет роздан всем участникам!

Последние билеты можно взять тут.

P.S. Увидимся уже совсем скоро ;)

Сегодня хотим поделиться инструментом k8spider, который был вдохновлен dnscan, используемый в заданиях на Kubernetes LAN Party.

Тулза будет полезна при разведке, когда находясь внутри скомпрометированного Pod, нужно понять какие сервисы есть еще в Kubernetes кластере. Есть поддержка Service ip-port BruteForcing / AXFR Domain Transfer Dump / Coredns WildCard Dump.

#tools

root@pod:/var/www/html/tools# env |grep KUBERNETES
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT_443_TCP=tcp://10.43.0.1:443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_PORT_443_TCP_ADDR=10.43.0.1
KUBERNETES_SERVICE_HOST=10.43.0.1
KUBERNETES_PORT=tcp://10.43.0.1:443
KUBERNETES_PORT_443_TCP_PORT=443
root@pod:/var/www/html/tools# ./k8spider all -c 10.43.43.1/24
INFO[0000] PTRrecord 10.43.43.87 --> kube-state-metrics.lens-metrics.svc.cluster.local. 
INFO[0000] PTRrecord 10.43.43.93 --> metrics-server.kube-system.svc.cluster.local. 
INFO[0000] SRVRecord: kube-state-metrics.lens-metrics.svc.cluster.local. --> kube-state-metrics.lens-metrics.svc.cluster.local.:8080 
INFO[0000] SRVRecord: metrics-server.kube-system.svc.cluster.local. --> metrics-server.kube-system.svc.cluster.local.:443 
INFO[0000] {"Ip":"10.43.43.87","SvcDomain":"kube-state-metrics.lens-metrics.svc.cluster.local.","SrvRecords":[{"Cname":"kube-state-metrics.lens-metrics.svc.cluster.local.","Srv":[{"Target":"kube-state-metrics.lens-metrics.svc.cluster.local.","Port":8080,"Priority":0,"Weight":100}]}]}

После поста про сетевые атаки, должен быть пост про сетевую защиту)

Недавно вышел хороший лонгрид "Cilium: Network Policies". Достаточно простым языком рассказывается как устроены сетевые политики, какие они бывают и как с ними работать. Все, конечно, на примере кастомных политик Cilium. Очень наглядно продемонстрирована такая важная сущность в Cilium как Security Identities, вокруг которой крутиться вся работа NetworkPolicy (а про его проблемы мы писали тут и тут). Также, интересно показан и раскрыт момент с DNS Traffic Visibility. Все остальное достаточное простое и очевидное, но хорошо проиллюстрировано. Так что все новичкам этот материал строго рекомендуется.

Сегодня мы рады анонсировать последний доклад в нашей программе БеКон 2024.

Это будет доклад "Вопросы сертификации системного программного обеспечения" от начальника 2 управления ФСТЭК России Дмитрия Шевцова про сертификацию операционных систем, средств контейнеризации, средств виртуализации и систем управления базами данных. Поговорим про историю, развитие и будущее данного момента. Конечно, будет затронут 118 приказ про "Требования по безопасности информации к средствам контейнеризации".

Так что вопрос безопасности контейнерных сред мы на конференции рассмотрим со всех сторон: разработчиков, внутренних команд безопасности, команд эксплуатации, исследователей и регуляторов.

Финальное расписание можно посмотреть на сайте. Билеты еще можно взять, на входе они продаваться не будут!

Увидимся уже совсем скоро =)