Поиск уязвимостей в Helm Charts

Всем привет!

В предыдущем посте мы писали о том, как можно искать устаревшие версии используемых Helm Chart’ов.

А как быть с уязвимостями в них? По крайней мере в public-версиях chart’ов, которые используются? Например, есть ли там ошибки конфигураций или уязвимости?

Ответ на этот вопрос можно найти в статье от Cloudsmith.

Автор использует open source инструменты, такие как Trivy и OPA для анализа chart’ов до их активного использования в промышленных средах.

Помимо этого, Автор рекомендует всегда проверять репозиторий, в котором хранится chart. Обращать внимание рекомендуется на: поддержку, использование, автора.

В завершении статье можно найти несколько сценариев, описывающих возможные способы эксплуатации уязвимостей в Helm Chart.

Безопасность Golang parsers

Всем привет!

Разбор (parsing) данных, получаемых от непроверенных источников, может привести к разным последствиям.

Например, обходу аутентификации, нарушению авторизации, эксфильтрации чувствительных данных и не только.

В статье Trail of Bits Авторы исследуют насколько хороши различные Golang parsers с точки зрения информационной безопасности: можно ли им доверять по умолчанию, можно ли их делать более безопасными и что (не) следует использовать.

Для анализа используется несколько наиболее популярных библиотек для работы с JSON, XML и YAML.

После небольшой вводной про Marshalling и Unmarshalling Авторы переходят к самому интересному – сценариям атак.

Рассматривается:
🍭 (Un)Marshalling unexpected data
🍭 Parser differentials
🍭 Data format confusion

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

Завершает статью набор общих рекомендаций о том, как минимизировать риски при работе с JSON, XML, YAML.

Множество примеров, кода, пояснений! Рекомендуем к изучению!

EoL или End Of Life

Всем привет!

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

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

Хочется чего-то централизованного, удобного и автоматизируемого. Например, endoflife.date. Это ресурс, на котором собрана информация о различных релизах и их «актуальности» с точки зрения поддержки.

На сайте представлена информация о Ansible, Nginx, Redis, Argo CD, Kubernetes, Kyverno, SonarQube и не только.

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

Автоматизация тоже возможна: есть минималистичный API, через который можно получить всю нужную информацию, доступную на сайте.

Данные о Supply Chain атаках

Всем привет!

Автор репозитория проделал отличную работу и собрал информацию об общеизвестных Supply Chain атаках.

В наборе данных приведена информация о 56 OSS проектах и 59 инцидентах.

Для каждого случая есть своя «карточка» (конечно же в формате *.yaml!):
🍭 Наименование
🍭 Синопсис
🍭 Дата «реализации»
🍭 Ссылки на материалы по теме
🍭 Информация по артефактам и не только

Помимо этого в репозитории содержится аналитическая информация: о распространении, векторе атаки, реализованному воздействию и не только.

Если хочется посмотреть «на все сразу», то в корне проекта есть oss_summary.csv, в котором представлена консолидированная информация.

🚀 Шерлок прокачивает управление ИБ-дефектами!

24 июля в 11:00 мск приглашаем на вебинар по новому релизу «Шерлока» — AppSec-платформы, которая оптимизирует процессы безопасной разработки.

На вебинаре расскажем:
🐾 О возможностях Шерлока для автоматизации
🐾 О новом функционале платформы
🐾 Проведем живое демо и ответим на все ваши вопросы

📌 Успейте зарегистрироваться! 👇
👉 РЕГИСТРАЦИЯ НА ВЕБИНАР

Application Security Introduction

Всем привет!

Начинаем новую рабочую неделю с плавного погружения в Application Security.

В приложении можно найти материал (~ 73 страницы), в котором описаны основы Application Security.

Например:
🍭 Те самые известные атаки (XSS, CSRF, SQLi, DDoS, IDOR и т.д.)
🍭 Secure Software Development Process (SAMM, BSIMM и т.д.)
🍭 Security Requirements Engineering
🍭 Security Design и не только

Неплохой обзорный материал, в котором собраны основные концепты, методологии, подходы и практики.

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

Уязвимости OAuth и что с ними делать

Всем привет!

Open Authentication (OAuth) повсеместно используемый способ аутентификации, в котором вместо логина и пароля используется токен.

Однако, как и любая технология, OAuth не лишена недостатков и, если реализовать ее некорректно, это может привести к уязвимостям.

Именно им и посвящена статья от Outpost24. В ней автор рассматривает:
🍭 Open redirect and redirect URI manipulation
🍭 Missing or weak CSRF/state protections
🍭 Implicit flow and lack of PKCE (Proof Key for Code Exchange)
🍭 Inadequate scope validation and overly broad permissions
🍭 Token leakage via insecure storage or transport и не только

Для каждого сценария приводится краткое описание недостатка и способы его устранения (корректной реализации).

Кстати, на сайте Outpost24 можно найти еще много чего интересного по тематике Application Security.

Kubetail – logging dashboard для Kubernetes

Всем привет!

Если для анализа логов в моменте нужно что-то легковесное, небольшое, простое в эксплуатации, то можно познакомиться с Kubetail.

Эта утилита позволяет анализировать журналы, генерируемые в кластере Kubernetes, в режиме реального времени.

Состоит Kubetail из CLI-утилиты и интерактивного dashboard, который можно установить как локально, так и в кластере Kubernetes.

Возможности, хоть и не велики, но практичны:
🍭 Агрегация данных по разным типам ресурсов Kubernetes
🍭 Возможность фильтрации событий
🍭 Переключение между несколькими кластерами
🍭 Указание временного диапазона для отображения информации о логах и не только

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

Кстати, если хочется посмотреть, как это выглядит, то у Kubetail есть интерактивная демо-площадка, доступная вот тут.

Библиотека Validating Admission Policies

Всем привет!

В репозитории можно найти набор Validating Admission Policies в формате CEL, подготовленных командой ARMO.

За основу при разработке политик был взят перечень ИБ-контролей, используемый в Kubescape.

Примеры того, что есть в репозитории:
🍭 Forbidden Container Registries
🍭 Automatic mapping of service account
🍭 Writable hostPath mount
🍭 Naked PODs
🍭 Image pull policy on latest tag и другие

На текущий момент доступно 33 политики. Для каждой из них доступен манифест и тестовые данные, которыми можно воспользоваться для проверки работоспособности политик.

Использование Validating Admission Policies может быть целесообразно в том случае, если вы не хотите использовать сторонние решения (Kyverno, Gatekeeper и их аналоги) и полностью использовать функционал, доступный в Kubernetes.

Вредоносный код в `is`

Всем привет!

Еще один пример атаки на цепочку поставок ПО. На этот раз «героем» стала is - достаточно популярная JavaScript библиотека (2.8 млн загрузок в неделю).

В нее было встроено вредоносное ПО, которое собирало различную информацию (имя, ОС, сведения о CU и т.д.) о рабочей станции, на которой оно запускалось, и передавала данные «наружу» через websocket.

Если кратко, то:
🍭 Учетные данные maintainer’a были скомпрометированы с использованием phishing
🍭 Злоумышленники сменили owner’a, что оставалось незамеченным несколько часов
🍭 В is был добавлен вредоносный код

Подмена была обнаружена достаточно оперативно и уже устранена: уязвимая версия – v3.3.1 – уже удалена, после чего уже легитимные авторы разместили обновленный вариант – v3.3.2.

Рекомендации постепенно становятся классикой: понимать из чего именно собирается ПО; контролировать то, что попадает в периметр; не забывать, что весь код (и заимствованные библиотеки тоже) - это всё ваш код, который надо анализировать; делать все это на регулярной основе.

P.S. Больше подробностей об инциденте можно узнать из статьи и ссылок, которые в ней доступны.

OpenCVE: управление информацией об уязвимостях

Всем привет!

OpenCVE – проект, который позволяет управлять данными о CVE, получаемыми из различных источников (NVD, RedHat, MITRE, Vulnrichment и т.д.)

Из ключевых функций можно выделить:
🍭 Наличие интерактивного графического web-интерфейса
🍭 Возможность «подписки» на определенные CVE с последующим получением уведомлений об изменениях
🍭 Получение комплексной информации об уязвимостях
🍭 Отслеживание истории изменения CVE
🍭 Создание собственных дашбордов
🍭 Интеграция с используемыми сервисами через API/Webhook и не только

Решение платное, но есть бесплатный вариант с некоторым (не критическим) ограничением по функционалу.

Установка возможна как в облаке, так и on-premise.

Больше информации об OpenCVE можно найти в GitHub-репозитории проекта и в документации.

Zeropod: оптимизация потребления ресурсов в Kubernetes

Всем привет!

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

При этом они потребляют ресурсы, которые могут быть нужнее «соседу». Как быть? Например, делать scale down до 0. И именно это и делает Zeropod.

Если просто, то по истечении некоторого времени от последнего TCP-соединения, он делает checkpoint (используя CRIU) и scale down до 0.

После, если TCP-соединения появляется вновь, pod восстанавливается и продолжает работу. Для пользователя это происходит «бесшовно». При этом реализуется оптимизация использования вычислительных ресурсов кластера Kubernetes.

Более детально процесс и логика работы Zeropod описаны в GitHub-репозитории проекта. Помимо этого, в repo можно найти информацию по установке, настройке и возможностях утилиты.

Важно: концепт, возможно, и интересный, но использовать такое "у себя" лучше после плотного тестирования ☺️

А как вы думаете, есть ли в этом смысл или "нет, очень опасно и зачем оно вообще нужно"?

Open Source Project Security Baseline

Всем привет!

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

Материал содержит практики 3-х уровней: общие рекомендации (для всех) и отдельно для проектов, у которых (не) очень много пользователей.

Всего порядка 50 рекомендаций. Например:
🍭 Когда был выпущен релиз, то должна обновиться и документация
🍭 Должна вестись запись всех изменений (само изменение, Автор, дата)
🍭 Для каждого проекта должен быть указать контакт по вопросам ИБ
🍭 Перед тем, как принять изменение, необходимо убедиться, что тесты пройдены и функционал соответствует ожиданиям
🍭 Все релизные объекты должны быть однозначно «связаны» с релизом и многое другое

Указанные практики можно использовать, например, при оценке надежности open-source проекта или использовать у себя (да, применимы далеко не все, но можно найти вполне интересные).

Помимо этого, для каждой практики кратко описано зачем она нужна (какой риск она сокращает), приведен небольшой набор рекомендаций и соотношение с иными стандартами и фреймворками (SSDF, PCI DSS, SAMM и т.д.)

Gitxray: анализ GitHub репозиториев

Всем привет!

Продолжаем тему анализа безопасности open source проектов перед их использованием. Еще одним инструментом, который может помочь, является Gitxray.

Он позволяет собрать множество информации о репозитории для последующего анализа.

Например:
🍭 Искать чувствительную информацию в профилях contributors
🍭 Идентифицировать не настоящие (fake) или зараженные (infected) репозитории
🍭 Анализ времени commit’ов для идентификации аномалий
🍭 Предоставлять сведения об артефактах релизов, которые были изменены уже после релиза
🍭 И многое другое

Устанавливается и запускается крайне просто. Результаты работы утилиты предоставляются в виде наглядного html-отчета.

Больше информации об Gitxray можно найти в репозитории или в документации.

Как «безопасный» кластер Kubernetes был взломан за 17 минут

Всем привет!

Небольшая, но достаточно поучительная история о том, что даже «казалось бы защищенный кластер» можно сломать.

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

Однако, это не помогло.

Случилось примерно следующее:
🍭 Злоумышленник просканировал публично доступные endpoints (забыли про kubelet read-only port)
🍭 Быстро нашел уязвимый контейнер (почему он таким стал – лучше прочтите сами)
🍭 При помощи него развернул майнер криптовалюты
🍭 Узлы кластера начали «разваливаться»

Вывод достаточно банальный классический: защита информации – процесс постоянный.

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

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

«Внутри» Chainguard Factory

Всем привет!

Команда Chainguard известна тем, что создает и поддерживает образы с минимальным количеством уязвимостей. Их SLA: 7 дней для «Критичных», 14 для «Высоких», «Средних» и «Низких».

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

«Мы делаем это не потому, что это просто, а потому, что думали, будто это будет просто». Если вам интересно узнать о том, как это устроено «внутри», то предлагаем прочесть статью с говорящим названием «This Shit is Hard».

В ней Автор разбирает следующие области:
🍭 Сборочная линия. От GitHub Actions до собственных наработок
🍭 Команда. Да-да, всегда самое важное и ценное
🍭 Роботизация. Автоматизация рутинных задач, чтобы команда хоть иногда отдыхала
🍭 Использование ИИ. Куда без него 😅
🍭Тестирование. «Нельзя просто так взять и собрать»
🍭 Доставка. Как сделать так, чтобы наработки забрали быстро и безопасно

В статье нет деталей, тем не менее читается она на одном дыхании.

Есть такой тезис, что «весь код – ваш код». Команда Chainguard усиливает идею – «относитесь к конвейеру сборки так, будто это промышленное окружение».

Рекомендуем к прочтению!

Predictive Vulnerability Database

Всем привет!

Сегодня хотим поделиться с вами ресурсом от Miggo – Predictive Vulnerability Database. Да, еще один агрегатор информации о «CVE». Но не совсем!

Помимо стандартной информации:
🍭 Оценка уровня критичности (CVSS v3.1)
🍭 EPSS
🍭 Даты публикации, обновления
🍭 Наличия исправления

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

Это может быть полезно как для разметки, так и для анализа достижимости с использованием средств автоматизации.

Из нюансов – информация о методах есть только для уязвимостей, которым менее 60 дней и автоматизировать обращение к базе через API (по крайней мере бесплатно) – не получится.

В остальном – она открыта для использования ☺️

Что такое анализ достижимости?

Всем привет!

Этот термин (хоть он далеко и не новый) появляется все чаще и чаще. Но что он означает? Как обычно, разные специалисты/компании интерпретируют его по-своему.

В статье Автор пытается разобраться в вопросе и формирует свой ответ на то, что же это такое.

Начинается все со сравнения – каким был процесс управления уязвимостями раньше и каким он стал сейчас. Да, когда-то было достаточно просто обновить версию ПО. Однако, сканеры развиваются, начинают лучше понимать ПО и могут анализировать ОС, пакеты, зависимости, ПО и т.д.

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

Например, понимание того:
🍭 Загружена ли библиотека
🍭 Используется ли метод
🍭 Доступно ли ПО извне
🍭 Есть ли какие-то меры по ИБ

может сильно помочь. И да, CVE может и присутствовать, но эксплуатировать ее нельзя. Тогда это false positive?

Поэтому, по мнению Автора, анализ достижимости это не только про комбинирование практик SAST и SCA, но и про понимание контекста – инфраструктуры, средств защиты.

Таким образом получается, что цель не в снижении false positive, а в поиске true positive.

А что вы думаете по этому поводу и реализуете ли вы такой анализ у себя?

Что такое анализ достижимости? Часть 2!

Всем привет!

Продолжение вчерашнего поста. Автор определился с тем, что такое анализ достижимости и пошел дальше.

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

Он выделяет 2 основных типа:
🍭 Статический анализ достижимости. Исследование исходного кода, библиотек, их использования и поиск уязвимых функций
🍭 Динамический анализ достижимости. Пакеты ОС, их использование, поиск уязвимых функций, идентификация вредоносного ПО

Далее Автор разбирает каждый из типов более детально и с примерами. Например, в чем разница между Package Level Reachability и Function Level Reachability, если говорить про статический анализ достижимости.

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