DevSecOps Talks

Использование Repository Webhook для доступа к CI

Всем привет!

Если задуматься, то Repository Webhook – VIP-персоны, ввиду тех задач, для которых они используются. Сделали commit, хочется, чтобы сборка начиналась автоматически? Webhook! А значит, что они проходят «сквозь», например, межсетевые экраны и иные ограничения ИБ.

А можно ли это как-то использовать для получения доступа к CI? Именно на этот вопрос и попытались ответить Авторы статьи. В целом, все достаточно неплохо – GET-запросы к CI не очень-то и поддерживаются, а при POST-запросах отсутствует возможность контроля тела запроса, да еще и CSRF-токен формируется. Но…

Авторы статьи сделали следующее:
🍭 Создали свой repo и «настроили» webhook на CI-жертву - Jenkins
🍭Подобрали пароли для учетной записи Jenkins с использованием POST-запроса на страницу аутентификации и анализом возвращаемого ответа. Кстати, чтобы этот и дальнейшие опыты сработали был использован GitLab, ввиду его особенности (какой именно - описано в статье)
🍭 Получили доступ к job console output
🍭 Создали reverse-shell для Jenkins instance через эксплуатацию уязвимости платформы (в статье есть отдельное видео, где можно посмотреть пример «в деле»)

Да, для реализации примеров необходимы «входные» данные, например, существующие и актуальные учетные записи, но… это все равно достаточно интересное исследование на наш взгляд, реализуемое через очень своеобразный вектор.

Kubernetes CVE feed

Всем привет!

Небольшая, но интересная новость. У Kubernetes, как и у любого другого программного обеспечения есть уязвимости.

Особенность заключалась в том, что трудно было отслеживать (программно) эти уязвимости из-за отсутствия единого источника.

Команда решила это поправить и запустила «Auto-refreshing Official Kubernetes CVE Feed». Feed будет содержать актуальную информацию по уязвимостям, которую можно извлечь в формате JSON для дальнейшей работы.

Например, можно воспользоваться командой:

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json

Больше про feed и то, что сейчас находится внутри можно посмотреть по ссылке. Приятно, что для каждой CVE указывается ссылка на GitHub Issue и можно посмотреть как (не)идут дела.

Визуализация JSON

Всем привет!

JSON – один из самых часто встречаемых машиночитаемых форматов. В таком формате, например, можно получать результаты работы open source инструментов, обеспечивающих анализ программного обеспечения или защиту сред контейнерных испытаний.

Есть множества библиотек для различных языков, которые упрощают его «обход» и помогают забирать нужно или «перекладывать» данные в другую структуру.

Но сперва надо понять, как он «устроен». Это не то, чтобы сложно, но иногда хочется простой визуализации, а не просто «красивой» формы, которые могут давать jq, Notepad++, VSCode и другие системы.

Если Вы согласны, то рекомендуем обратить внимание на проект JSONCrack, которые позволяет построить наглядную диаграмму из JSON-файла. И все это в минималистично-необходимом UI.

JSONCrack доступен как online, так и в качестве контейнеров, которые можно запустить on-premise.

Sidecar(less) mTLS от Cilium

Всем привет!

Многие ИБ-специалисты хотят, думают использовать, используют (?) mTLS для повышения безопасности сред контейнерной оркестрации.

Одним из самых популярных подходов является использование sidecar-паттерна, который реализует необходимый функционал. Однако, такой подход может быть избыточным и ребята из Cilium представили свой подход к mTLS, в котором не требуется дополнительных контейнеров.

В статье этот вопрос рассматривается более детально:
🍭 Общее описание того, что такое mTLS и зачем он нужен
🍭 Разница между session based и network based mutual authentication
🍭 Плюсы и минусы описанных выше подходов

Далее поднимается вопрос о том, можно ли совместить 2 подхода (session/network based) и как этого можно достигнуть при помощи Cilium Service Mesh. И, конечно же, тесты на производительность! Куда же без них! Если верить текущим прогнозам, то функционал mutual authentication будет доступен в Cilium v1.13 (текущая версия – 1.12).

False positive/negative при сканировании образов контейнеров

Всем привет!

Одна из самых частых практик, про которую точно слышали все – сканирование образов контейнеров на наличие уязвимостей. Есть большое количество инструментов (как open source, так и enterprise), которые решают эту задачу. Они развиваются, функционал расширяется, например, создание Software Bill of Materials (SBOM) для образа контейнера. Но все ли они видят? И как обстоят дела с наличием ошибок первого и второго рода?

В статье приводятся примеры как первых, так и вторых – можно либо найти лишнее, либо не найти то, что на самом деле важно.

Почему это так?
🍭 Большинство сканеров работают с базой данных пакетных менеджеров (apt, yum, apk и т.д.) и видят только то, что установлено с их использованием
🍭 У некоторых сканеров (например, Snyk) есть «собственные проприетарные практики» обнаружения, например, Node.js, который обычно ставится «напрямую», а не через пакетный менеджер

Если хочется еще примеров – в статье можно посмотреть на Wordpress, который устанавливается через curl в официальном образе, а потому «пропадает» из поля видимости сканеров.

Что делать? Авторы статьи предлагают перенести созданием SBOM на момент сборки и, по возможности, использовать distroless подход с использованием melange и apko (о которых мы писали тут).

Kubernetes resources under the hood — Part 3

Всем привет!

Третья часть серии начинается достаточно провокационно – Don’t set your CPU limits! Это сильно противоречит большинству рекомендаций по ИБ (и не только) по корректному написанию манифестов (наличие CPU/RAM requests и limits).

Далее начинается нечто! Автор обосновывает свою точку зрения с учетом:
🍭 Информации из предыдущих статей, особенно с использованием CPU Shares
🍭 Чуть больше раскрывается тема throttling, разница поведений контейнеров при использовании single/multi threading
🍭 Математики (да, ее много для статьи не про нее)
🍭 Рассуждений о том, что будет если 1 контейнер будет сильно потреблять ресурсы – пострадает только он или все его «соседи» по node?
🍭 Эксперимент с последовательным запуском двух pods, значения CPU requests/limits которых (не)устанавливаются в разные «положения» и что при этом происходит с учетом тех QoS, которые они получают от Kubernetes.

И все-таки? Нужны ли CPU Limits? Мнение Автора и примеры их (не)использования в реальном мире можно узнать в разделе «When to use CPU Limits» в конце статьи.

Kubernetes resources under the hood — Part 2

Всем привет!

Вторая часть серии посвящена Requests и их роли в жизненном цикле pod, которая заключается не только в scheduling.

Прочитав ее, можно узнать:
🍭 Сколько CPU Shares запрашивает Kubernetes, основываясь на данных, указанных пользователем в Requests
🍭 Completely Fair Scheduler (CFS) Linux – распределение CPU requests между процессами, как он работает и зачем нужен
🍭 Влияние threads и QoS на предоставление ресурсов CPU

Просто, наглядно и с примерами!

Kubernetes resources under the hood — Part 1

Привет!

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

Автор рассматривает такие вопросы, как:
🍭 Linux namespaces, их назначение и как (для чего) они используются контейнерами
🍭 Можно узнать, сколько pod по умолчанию Kubernetes может разместить на одной node. Да, есть и такое
🍭 Что такое Requests и Limits, как они связаны с cgroups, при чем тут «сompressible» и «incompressible», что такое throttling и от чего он возникает
🍭 Какие есть QoS у Kubernetes и от чего они зависят. И тут есть много своих нюансов. Если кому хочется узнать особенности поведения Guaranteed с использованием целого количества ядер, а не millicores, как обычно, то можно прочитать про Topology Manager

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

Risk8s Business: Risk Analysis of Kubernetes Clusters

Всем привет!

По ссылке доступен внушительный guide, посвященный размышлениям на тему безопасности Kubernetes и того, как можно ее улучшить.

Guide состоит из нескольких разделов:
🍭 Introduction. Обзор Kubernetes, рассуждения на тему «что такое безопасный кластер»
🍭 Understanding Your Environment. Как получить необходимую информацию о кластере для последующей «работы» с ним по ИБ
🍭 Understanding Your Risk. Простенький анализ рисков с учетом всей информации, полученной на предыдущих этапах
🍭 Wrapping Up. Заключение, в котором делается обзор всего пути и ключевые выводы

Есть примеры, инструменты, их использование и много всего интересного. Рекомендуем открывать на PC, потому что с телефона отображение информации или навигация могут быть искажены.

Securing the Software Supply Chain: Recommended Practices for Developers

Всем привет!

Недавно вышли новые рекомендации от NSA, посвященные безопасности Software Supply Chain.

В 64-х страничном документе разобраны такие темы, как:
🍭 Develop Secure Code
🍭 Verify Third-Party Components
🍭 Harden the Build Environment
🍭 Deliver Code

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

Ephemeral Containers

Всем привет!

По ссылке доступна ознакомительная статья, которая позволит понять, что такое ephemeral containers и зачем они нужны.

Вкратце, ephemeral container – «рыба-прилипала», которая «присоединяется» к целевому контейнеру и позволяет с ним взаимодействовать. Это может быть нужно, например, для debug.

Представим, что у вас есть distroless образ и вы думаете, что есть проблемы с сетевой связностью. Но как проверить? wget, curl – их не будет в таком образе. Как раз вот тут и пригодятся ephemeral containers и это далеко не единственный случай.

Такое возможно благодаря тому, что ephemeral container «разделяет» namespaces (mnt, utc, ipc, user, net и т.д.) с «целевым». Кстати, с pid все несколько иначе.

Детали, команды и их результаты представлены в статье. А в конце – пример использования mirrord с Job или через ephemeral containers.

Elixir Secure Coding Training

Всем привет!

В repo представлен набор Secure Coding Training, включающий в себя такие разделы как:
🍭 OWASP
🍭 Secure SDLC
🍭 GraphQL, Elixir Security
🍭 Cookie Security
🍭 Security Anti-patterns
🍭 CI/CD Tooling

С описанием того, что внутри можно ознакомиться в соответствующих файлах. А если хочется большей красоты и интерактивности – можно установить Livebook и использовать его в качестве «интерпретатора».

Trivy, Cosign и Kyverno: анализ даты последнего сканирования образа контейнера

Всем привет!

Если соединить Trivy, Cosign и Kyverno, то можно реализовать достаточно интересный сценарий. Его демонстрация с примерами всех настроек приведена в статье. Да, там используется GitHub Actions, но сам подход можно реализовать на любой удобной Вам платформе.

Происходит следующее:
🍭 Образ сканируется при помощи Trivy, в результате получаем отчет по уязвимостям
🍭 Результат сканирования проходит аттестацию при помощи Cosign. Про аттестацию (in-toto attestation) можно прочитать тут и тут. «Спецификация» аттестации, генерируемая Cosign описана тут.
🍭 Создается политика Kyverno, которая может «читать» аттестацию и анализировать ее поля. Например, можно проверить, что со времени последнего сканирования прошло не более X дней.

Таким образом можно контролировать, когда образ последний раз был просканирован на уязвимости и, например, заблокировать его запуск или создать событие аудита в соответствии с принятыми требованиями.

Это только небольшой пример возможностей Kyverno по взаимодействию с Cosign, рекомендуем ознакомиться с документацией, чтобы узнать больше!

Security Small Talk

Всем привет!

Вышел новый выпуск Security Small Talk об управлении секретами.
В нём детально объясняется следующее:
• Что такое секреты и в чем отличие «human-to-machine» и «machine-to-machine» секретов
• Управление секретами на всех этапах жизненного цикла
• Как можно защищать секреты, какие практики и средства автоматизации можно использовать

Контроль доступа к REST-endpoints в k8s

Всем привет!

Допустим, что есть приложение с опубликованным REST-endpoint в Kubernetes. Как предотвратить несанкционированный доступ к такому Endpoint?
У приложения могут быть собственные механизмы аутентификации. А что, если их нет? Или они по какой-то причине недоступны?

В статье Автор разбирает возможные сценарии решения задачи:
🍭 Ingress, поддерживающий аутентификацию. Один из наиболее частых способов, реализуемый, например, с Nginx Ingress Controller
🍭 Reverse-proxy. Использование sidecar-контейнера, например, с Nginx
🍭 Использование RBAC k8s. Да, можно и так!

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

Kubernetes OWASP Top-10: примеры

Привет!

Проект Kubernetes OWASP Top 10 продолжает развиваться. Ранее пустые разделы постепенно наполняются описанием и примерами! Появляются статьи, которые разбирают описанные в нем риски.

Одна из таких статей разбирает первый и самый «популярный» - Insecure Workload Configurations. Автор описывает Security Context и что они могут/для чего они нужны.

Он разбирает не все, лишь самые интересные на его взгляд:
🍭 Privileged
🍭 Действия с Capabilities
🍭 runAsUser/Group
🍭 runAsNonRoot
🍭 readOnlyFileSystem

Приведены примеры, что это и зачем, почему это (не) стоит применять. А если Вы не успели ознакомиться с полной версией Kubernetes OWASP Top 10, то он доступен по ссылке.

CyberCamp 2022!!!

Всем привет!

Материал не совсем по тематике канала (хотя, spoiler: в программе есть отличный доклад Сергея Канибора из Luntry!), но не поделиться им мы не можем!!!

Встречайте, CyberCamp 2022 !!!

Присоединяйтесь 14-16 сентября к онлайн-конференции! Практики по кибербезопасности расскажут, как обнаруживать, расследовать и отражать кибератаки.

Что будет?
🔹20 докладов и мастер-классов от пентестеров, специалистов по мониторингу и расследованию инцидентов из Group-IB, «Лаборатории Касперского», «Инфосистемы Джет», Positive Technologies, Luntry, Синклит и Yandex Cloud
🔹Задания для отработки практических навыков в формате игрового обучения

Забронируйте три дня на полезный контент:
🔹Поиск низко висящих фруктов в ИТ-инфраструктуре
🔹Раскладываем атаки по MITRE
🔹Эффективный харденинг ИТ-инфраструктуры
🔹Типовые сценарии Windows Persistence и их обнаружение
🔹Инструменты пентестеров для BlueTeam
🔹Автоматизация работы с инцидентами
🔹Форензика и криминалистические артефакты
🔹Безопасность АСУ ТП: угрозы, подходы, практики
🔹Обогащение в SIEM: как забирать данные из AD, GeoIP, TI

Регистрация на сайте CyberCamp 2022!

Устройство сети Kubernetes

Всем привет!

По ссылкам можно ознакомиться с циклом статей, посвященному устройству сети Kubernetes. Цикл разбит на три части, в каждой из которых уровень «погружения» увеличивается.

🍭 Первая статья рассказывает про namespaces (pid, mnt, utc, ipc, user, net). Что это такое, зачем оно нужно и какое отношение имеет к контейнерной сети.
🍭 Вторая раскрывает тему Pause Container. Если вы не знаете, что это такое и в чем суть его существования – очень рекомендуем прочесть, ответ достаточно интересный. Простой контейнер с одним бинарным файлом.
🍭 Третья уже вплотную подбирается к Kubernetes. Описывается как взаимодействуют компоненты между собой (на одной node, на разных node), что такое cbr0, примеры маршрутизации трафика.

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

Импорт результатов Trivy в PolicyReporter

Всем привет!

Frank Jogeleit подготовил интересный проект. Он взял результаты работы Trivy (Vulnerability Assessment, RBAC Analysis и не только) и «переложил» их в структуру v1alpha2.PolicyReportResult и v1alpha2.ClusterPolicyReportResult.

Указанные структуры представляют из себя CRD, прорабатываются Kubernetes Policy Working Group и набирают все большую популярность.

Именно в таком формате, например, предоставляет результаты и другой инструмент – Kyverno! А для визуализации подобных отчетов есть отдельное решение – PolicyReporter. Суть простая: данные из polr (PolicyReports) и cpolr (ClusterPolicyReports) отображаются в виде графиков, что упрощает дальнейший анализ.

Если объединить первое со вторым, то получится «единое» окно, в котором содержится графическое представление результатов работы сразу нескольких инструментов: Kyverno, KubeBench, Trivy. При желании можно дописать свой mapper или доработать существующие. Например, если вы не согласны с той логикой, что определил Автор.

Дополнительно настраивать ничего не надо. Данные по отчетам Trivy появятся в блоках PolicyReports и ClusterPolicyReports за счет того, что PolicyReporter «подписан» на соответствующие изменения.

Обзор Kubernetes Services, LoadBalancers и Ingress

Привет!

Еще одна обзорная статья, посвященная базовым аспектам устройствам сети в Kubernetes, но при этом покрывающая очень важные аспекты.

Как организовать сетевое взаимодействие между pod внутри кластера? А как с «внешним миром»? Почему IP-адреса вроде, как и есть, а вроде как их нет? Ответы на эти вопросы и не только можно найти в статье.

Авторы рассматривают такие сущности как:
🍭 Services (ClusterIP, NodePort, LoadBalancer)
🍭 Ingress

Отдельно в статье упоминаются FAQ. Например: можно ли создать несколько Services с одинаковым именем? Можно ли «пинговать» Services? Можно ли взаимодействовать с pods из другого namespace? Что такое Headless Service и т.д.

Есть примеры, ссылки на материалы по теме. А в конце статьи приведена общая табличка с типами сетевых сущностей и разницей между ними, включая уровни модели ISO/OSI, на которых они работают.