Arbitrary command execution через… Snyk CLI

Всем привет!

Интересная статья от Imperva, в которой рассказано о том, как команда нашла CVE-2022-40764, эксплуатация которой позволяет реализовать «arbitrary command execution» при использовании Snyk CLI.

Статья читается как небольшой детектив и на одном дыхании! Получился примерно такой путь:
🍭 Monkey patch для Snyk CLI с целью журналирования значимых NodeJS действий (например, доступ к файлам, запуск shell)
🍭 Да, все так, оказалось, что shell запускается! Дальнейшее исследование привело к идентификации причины: файл vendor.json и поле ignore
🍭 Первый payload, подготовленной командой не сработал из-за особенностей «обработки» значения, указанного в поле ignore
🍭 А вот второй… уже позволил запустить калькулятор на рабочей станции пользователя!

Реализацию подобной атаки выполнить сложно. Однако, у Snyk есть VS Code plugin, который использует CLI для автоматического сканирования кода при открытии IDE. Остается только сделать так, чтобы пользователь открыл «интересующий» код в VS Code. PoC-ролик, примеры monkey patch, payload’ов и код обработки поля ignore можно увидеть в статье.

Команда Snyk, в свою очередь, достаточно оперативно устранила дефект и выпустила соответствующий патч 😊

Kubernetes Security Profiles Operator

Привет!

Основная задача Security Profile Operator – сделать использование и управление SELinux, AppArmor и Seccomp профилями более простыми и удобными для пользователей. Предысторию его появления можно узнать в этом RFC.

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

Обладает следующими возможностями:
🍭 Создание профилей через CRD
🍭 Применение профилей для Pod
🍭 Автоматическая генерация профилей (частично, пока только для Seccomp)

Для лучшего ознакомления с Security Profile Operator, вариантами запуска, возможностями и принципами работы рекомендуем ознакомиться со статьей. Roadmap дальнейшего развития проекта представлен в repo в виде диаграммы ☺️

P.S. А В этом repo можно найти очень-очень-очень много AppArmor профилей

Совместное использование Snyk и ArgoCD

Всем привет!

В статье приводится tutorial, который позволит анализировать приложения, контролируемые ArgoCD при помощи Snyk.

Последовательность действий:
🍭 Создание приложения в ArgoCD
🍭 Настройка PreSync Hook в ArgoCD, который будет запускать анализ запускаемых сущностей при помощи Snyk
🍭 Просмотр результатов: в ArgoCD и в консоли Snyk

В целом такой подход можно использовать не только со Snyk а с любым другим инструментом анализа, который Вы используете.

Seccomp в Kubernetes: 7 базовых вещей

Всем привет!

Использование Secure Compute Mode (Seccomp) позволит сократить поверхность атаки за счет возможности ограничения/разрешения syscalls, которые могут быть «запущены». Базовый профиль содержит несколько основных блоков: defaultAction – действие, которое будет применено «по умолчанию», architectures (syscalls могут обладать разными id в зависимости от архитектуры), syscalls – перечень системных вызовов. Но как его правильно «приготовить»?

Частично ответ на это есть в подробной статье от Paulo Gomes, в которой он раскрывает важные аспекты, про которые не стоит забывать, например:
🍭 Устанавливайте allowPrivilegeEscalation в значение false. Да, это влияет на Seccomp. Как именно – описано в статье
🍭 Назначайте Seccomp профиль на уровне Container, а не Pod (статья 2019 года, возможно причина уже не актуальна)
🍭 Используйте default профили только в экстренных случаях. Лучше напишите свои
🍭 Запускайте Seccomp в режиме аудита для «тонкой настройки». Да, так можно
🍭 Whitelisting лучше, чем Blacklisting

Для каждого рассмотренного совета Paolo приводит аргументацию, почему предложенный вариант является оптимальным и несколько примеров. Отличная статья, чтобы начать изучение Seccomp.

P.S. В документации Docker можно ознакомиться с обоснованием того, почему тот или иной syscall «заблокировали» и он не попал в Seccomp профиль.

Seccomp в Kubernetes: создание профиля

Привет!

Вторая часть статьи от Paolo Gomes, посвященная Seccomp! В ней Paolo рассуждает на тему того, как можно создать whitelist-профили и как решить самую значимую задачу – определить, какие именно syscalls используются приложением.

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

Например:
🍭 Использование strace для получения syscalls, используемых командой
🍭 Анализ приложения для сбора всех syscalls. Paolo сделал PoC для программного обеспечения, разрабатываемого на golang
🍭 Запуск Seccomp в режиме «аудита» ("defaultAction": "SCMP_ACT_LOG")
🍭 Brute force! Да, тот самый «подход в лоб»: разрешаем все и удаляем, пока не найдем нужное состояние. Или наоборот – отбираем все и разрешаем по одному, наблюдая изменения в ошибках

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

P.S. Кстати, Paolo один из разработчиков Kubernetes Profile Operator, про который мы писали тут.

P.P.S. Еще один популярный инструмент, который позволяет генерировать Seccomp-профили (и не только) – Docker Slim.

Kubernetes Storage: Basics

Всем привет!!!

Хорошая обзорная статья про то, что такое Storage в Kubernetes, зачем они нужны, какие они бывают и в чем между ними разница.

В статье разбираются следующие моменты:
🍭 hostPath и почему лучше не использовать его, а обратить внимание на NFS
🍭 ConfigMap/Secret as Volume и как с их использованием можно передать данные в Pod
🍭 PersistentVolume (PV) и PersistentVolumeClaim (PVC) – что это, какие VolumeTypes, AccessModes и RetainPolicy бывают
🍭 Dynamic Provisioning, зачем нужен StorageClass и как все это связано с PV и PVC

Примеры, код манифестов, диаграммы для упрощения восприятия, ссылки на полезные материалы – все на месте и хорошо структурировано.

Статья очень базового уровня, и поясняет основные понятия и механизмы проброса persistent storage в кластер Kubenetes.

Из статьи понятно, что хорошо и просто живется лишь тем, кто в облаках ☺️ Для тех, кто "на земле" - рекомендуется посмотреть в сторону NFS. Мы со своей стороны при этом рекомендуем не забывать, что в NFS нет никакого встроенного механизма квотирования ресурсов, и может случиться так, что один контейнер занимает всю шару.

Поэтому соблюдайте осмотрительность, и посмотрите в сторону специализированных CSI от производителей внешних СХД, если вдруг такая задача у вас возникнет.

Chain-bench: GitLab

Всем привет!

Сегодня будет короткая, но весьма приятная новость. На предыдущей неделе в Chain-bench от Aqua Security была добавлена поддержка GitLab (v 0.1.5). Судя по всему, добавлены не все проверки, но движение в этом направлении есть и это уже хорошо.

Chain-bench – open source решение, которое позволяет анализировать настройки окружения (например, систем управления исходным кодом) на соответствие требованиям ИБ.

В качестве «источника данных» используется CIS Software Supply Chain Security Guide. Про Chain-bench и CIS мы писали тут и тут соответственно.

Fine grained personal access token в GitHub

Привет!

До недавнего времени personal access tokens (PAT) GitHub’a предоставляли достаточно широкие полномочия. Например, предоставлялся доступ ко всем repo, к которым был доступ у пользователя, генерирующего PAT. Это не всегда было удобно разработчикам и точно не соответствовало практикам ИБ. Например, такой подход не соответствует need-to-know и least privilege принципам.

18 октября GitHub открыл доступ к fine grained personal access tokens, которые находятся в стадии beta. Их задача – сделать предоставление доступа к repo максимально гибким и удобным.

Например:
🍭 Можно давать доступ ко всем repo или только к тем, которые выберет разработчик
🍭 Доступ только к Issues определенного repo
🍭 Возможность просмотра pull requests и многое другое

Всего добавлено более 50 granular permissions, которые можно устанавливать в значения «no access», «read», «read and write». Еще один приятный бонус – возможность просмотра использования токенов и их отзыв владельцами в случае необходимости.

Подписи и аттестации

Всем привет!

Когда говорят про контроль supply chain зачастую вспоминают про подпись чего-бы-то-ни-было. Все как обычно – есть пара private/public key, используя которые можно гарантировать, что мы получили артефакт именно от его Автора.

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

Как быть в такой ситуации? Ответ отлично разобран в статье "Policy and Attestations", в которой рассматривается термин «Аттестация». Грубо говоря – набор некоторых утверждений, которые характерны для того или иного артефакта, подписанные электронной подписью. Например, те же результаты сканирования образа.

Именно так (анализируя аттестации) Kyverno может проверять когда последний раз образ был просканирован и принять решение – стоит ли его запускать. Об этом use case мы писали тут, там тоже есть немного про аттестацию и то, как она реализуется в Cosign.

Проверка конфигурации GitHub

Всем привет!

Еще одно решение, похожее на Chain-bench – Legitify. Проверяет настройку параметров безопасности GitHub.

В отличие от Chain-bench, Legitify не использует CIS Software Supply Chain Security Guide, а руководствуется тем, что написано в OSSF Scorecards и в Policies.

Например, есть проверки того, что:
🍭 Включена защита веток (branch protection)
🍭 Применяется SAST и Fuzzing
🍭 (Не) допустимо использование force push
🍭 У repo большое количество администраторов и другие

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

Ingress в Kubernetes

Всем привет!

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

Одной из первых задач, с которой столкнется пользователя кластера – "как организовать доступ к моим ресурсам со стороны «внешних» ресурсов?". Есть несколько вариантов, но сегодня рассмотрим один – Ingress.

В статье рассматриваются такие вопросы как:
🍭 Что такое Ingress и зачем он нужен?
🍭 Как устроен Ingress, как он работает?
🍭 Что такое Nginx Ingress Controller и какими возможностями он обладает?

Минималистично-понятная статья, в которой нет ничего лишнего. А если Вас в большей степени интересует информационная безопасность, то можно ознакомиться с разделом Security и Hardening Guide из официальной документации на решение.

DevSecOps Playbook

Всем привет!

Еще один взгляд на систематизацию DevSecOps подходов и практик, которые можно реализовывать для повышения защищенности разрабатываемого ПО.

Материал включает в себя рекомендации по блокам:
🍭 Development environment
🍭 Source code management
🍭 CI/CD pipelines and automation
🍭 Deployment
🍭 Organizational techniques

Всего предложено порядка 60 активностей. Для каждой из них, помимо описания, приводится ее приоритет, сложность реализации и ссылки на стандарты для получения дополнительных сведений.

Управление GitOps Repos

Всем привет!

GitOps – подход, который позволяет управлять конфигурацией ИТ-инфраструктуры, используя подходы и практики разработки ПО. Например, есть централизованный repo, в котором хранятся интересующие нас конфигурации и инструмент, который применяет эти конфигурации. У такого подхода много преимуществ – начиная от «прозрачности» и заканчивая минимизацией вероятности возникновения configuration drift.

Но как правильно организовать тот самый repo с конфигурациями? Должен ли это быть 1 repo, в котором содержится все-все-все или это должно быть несколько repo? Например, отдельные для production и development-окружений?

Размышления на эту тему можно найти в статье. Автор рассматривает 4 варианта:
🍭 Один repo для приложения и поддерживающей его ИТ-инфраструктуры
🍭 Отдельный repo для ИТ-инфраструктуры с несколькими «долгоиграющими» ветками (main и development, например)
🍭 Несколько repo – по одному на каждое окружение

Для каждого варианта приведены его плюсы и минусы. Например, наличие (отсутствие) управления доступом на изменения, вероятность «расхождения» конфигураций различных окружений и т.д.

В конце статьи Автор дает ссылки на инструменты Harness (CI, CD, GitOps), в разработке которых участвует. По ссылкам можно больше узнать про решения и их open source версии.

Обход eBPF

Всем привет!

Последнее время все чаще и чаще можно слышать про eBPF, которая привносит много нового и удобного не только для ИТ, но и для ИБ-специалистов.

Появляются средства защиты, которые могут анализировать kernel calls что может быть крайне полезно для идентификации подозрительных событий и инцидентов ИБ. Однако, как и у любой технологии у eBPF есть «ограничения», про которые важно помнить.

В статье Автор на примерах разбирает способы обхода средств защиты, использующих eBPF:
🍭 В качестве подопытного используется Tetragon от Cilium (будет работать и с другими аналогичными решениями)
🍭 Создается «подопытный» Ubuntu-контейнер, в котором запускается cat /etc/host. cat использует write system call, что видно при помощи Tetragon
🍭 Автор немного модифицирует write для того, чтобы Tetragon не смог увидеть произошедшее событие

В статье много пояснений, примеров кода и рассуждений о возможных способах обхода. Это вовсе не означает, что eBPF – «плохой» инструмент, скорее наоборот. Главное помнить, что абсолютов не существует и не стоит «слепо» полагаться на автоматизацию.

Practical Guide to Secure Software Supply Chain with Sigstore

Всем привет!

По ссылке доступно очень-очень-очень-очень-очень много текста, посвященного защите supply chain с использованием механизма подписи и аттестации.

Материал включает в себя следующие разделы:
🍭 Sigstore: введение
🍭 Cosign: средство подписи и верификации
🍭 Fulcio: certification authority, выступающий в роли «доверенного» посредника
🍭 Rekor: хранение информации об мета-данных артефактов
🍭 Sigstore: как использовать рассмотренные выше материалы

Кстати, рассмотренный инструментарий поддерживают и другие проекты. Например, Trivy может генерировать отчет в формате Cosign Vulnerability Scan, а Kyverno может «читать» подписи и аттестации Cosign (функционал пока что в beta). И это не единственные примеры 😊

Snyk Learn: обновление учебных курсов

Snyk продолжает радовать отличными материалами и обучающими курсами в частности. На сайте Snyk Learn можно найти несколько интерактивных курсов, посвященных DevSecOps: Java, JS, Python, Golang, PHP, C#, Kubernetes.

Например:
🍭 Insecure Design
🍭 Directory Traversal
🍭 SQL Injection
🍭 Container does not drop all capabilities

Мы уже писали про этот ресурс в 2021 году. На тот момент курсов было гораздо меньше. Приятно, что ребята не останавливаются и продолжают развивать данное направление.

Удаление «старых» образов/контейнеров в Kubernetes

Всем привет!

Не всегда получается поддерживать актуальность используемых образов/контейнеров в кластерах Kubernetes. Альтернативный сценарий – unused images, которые могут храниться на узлах.

Хорошо, что у Kubernetes есть собственный механизм garbage collection, которому посвящена статья. Если просто – то многое зависит от размера образа и времени его последнего использования. Например, большой образ, который использовался неделю назад будет с большей вероятностью удален, чем небольшой и используемый «вчера».

Однако, это можно настроить через манифесты Kubelet:
🍭 Указать необходимый disk threshold
🍭 Задавать определенное количество dead containers (по умолчанию отсутствует)
🍭 Количество минут, через которое контейнер будет считаться «старым» и станет кандидатом на устранение (по умолчанию отсутствует) и не только

Статья 2021 года, но механизмы актуальны. Есть направления по переходу на механизм eviction, который может заменить garbage collection в будущем.

AdminNetworkPolicy

Всем привет!

У сетевых политик Kubernetes есть известный недостаток – отсутствие cluster wide сущностей. По крайней мере у «Native Network Policy». Некоторые CNI, такие как Cilium и Calico, реализуют требуемый механизм. Именно по этой причине невозможно создать сетевую политику, которая, применится ко всему кластеру.

У Kubernetes есть разные SIG, одной из которых является Network. В рамках одного из enhancements Авторы предлагают нововведение – AdminNetworkPolicy, которая решает указанную проблему. При этом разработчики не смогут на нее влиять, а на «обычную» Network Policy – вполне.

Это достигается за счет нового ресурса – AdminNeworkPolicy, который работает в нескольких «режимах»:
🍭 Deny: запрет всего трафика
🍭 Allow: трафик разрешен
🍭 Pass: самое интересное – «решение» о том, разрешать трафик или нет, передается на уровень обычной NetworkPolicy

Увы, функционал пока не реализован, но сам подход достаточно интересный. Больше про user stories и примеры того, как это можно использовать можно найти в описании enhancement. А если хочется еще больше, то можно посмотреть короткое видео (~ 22 минуты), где Авторы рассказывают про этот механизм.

YaraHunter: идентификация malware

Привет!

YaraHunter – небольшая утилита, которая позволяет идентифицировать вредоносное ПО. С правилами, на основании которых происходит идентификация можно ознакомиться тут.

При помощи утилиты можно:
🍭 Искать вредоносное ПО в образах контейнеров, контейнерах и на файловой системе
🍭 Встраивать в CI/CD pipeline
🍭 Получать результаты в машиночитаемом формате – JSON

Пока что YaraHunter находится на стадии разработки. Одной из интересных функций будет интеграция с ThreatMapper – решением по управлению уязвимостями от того же Deepfence, про который мы писали тут. Увы, roadmap, как и документация на решение, пока что возвращают 404.

GuardDog: идентификация вредоносных python-пакетов

Всем привет!

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

После исследования нескольких пакетов, команда пришла к выводу, что большинство вредоносных пакетов используются для Initial Access (например, typosquatting), Code Execution (eval/exec для получения нужного файла) и Exfiltration (передача данных различными способами).

Для идентификации подобных пакетов ребята разработали GuardDog. Инструмент не анализирует пакеты на наличие CVE, как делает большинство SCA-решений, а использует SAST-практики. Примечательно, что анализу подлежит не только исходный код, но и метаданные пакета.

В качестве основы GuardDog используется Semgrep, с правилами идентификации уязвимостей в коде можно ознакомиться тут. Для анализа метаданных ребята подготовили собственные проверки, которые доступны вот тут.

В итоге получилась достаточно занятная утилита. Настоятельно рекомендуем ознакомиться со статьей – в ней есть примеры запуска, много сведений об анализе python-пакетов и о том, что они могут содержать. Читается легко и непринужденно. Как раз то, что нужно для пятницы!