ШТУРВАЛЬЧИК?

Ребятам из «Лаборатории Числитель», видимо, было мало шуток про Штурвал, теперь они выпустили Штурвальчик.

Многие говорили, что он слишком много жрёт. Теперь минимальный конфиг — это:
▪️один хост с 6 CPU
▪️8 ГБ RAM
▪️80 ГБ хранилища

В целом на мощном ноуте можно раскатать парочку кластеров куба — этого хватит на управляющий и несколько клиентских.

Вопросы можно в Kubernetes-чате «Штурвала» задать.

HackList: рекомендация по обучениям!

Всем привет!

Не знаете, что изучить на выходных? Не хочется самостоятельно искать материалы по интересующим вас темам?

Возможно, что HackList сможет вам помочь. Он представляет из себя небольшое web-приложение, которое ищет материалы по интересующим вас темам.

Внутри:
🍭 Рекомендации, сформированные с использованием AI на основе ваших интересов
🍭 Поиск по разным источникам: GitHub, OWASP, блоги, обучающие платформы
🍭 «Встроенный dataset» для быстрого получения информации
🍭 Категорирование проектов по разным ИБ-темам
🍭 Дедупликация результатов и приятный UI

Работает очень просто: вы описываете то, что вам интересно. HackList ищет разные проекты и статьи по теме. Читаете описание и начинаете обучение ☺️

Поддерживается около 15 различных ИБ-доменов, в том числе API Security, Mobile Security, DevSecOps и не только.

Nova: поиск устаревших Helm Charts

Всем привет!

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

Да, есть специализированные решения, которые могут помочь управлять версиями. Например, тот же Helm. Однако, даже с ним, не всегда получается за всем уследить.

Именно эту проблему и решает Nova – open source проект от команды Fairwinds.

Работает максимально просто:
🍭 Устанавливаем
🍭 Запускаем nova find
🍭 Анализируем результаты

В качестве выходных данных Nova предоставляет информацию об установленной версии chart’a и его latest-версии.

Кроме того, можно посмотреть устаревшие версии образов контейнеров, которые используются в chart’e.

Больше информации об утилите и ее возможностях можно узнать в документации.

Поиск уязвимостей в 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 усиливает идею – «относитесь к конвейеру сборки так, будто это промышленное окружение».

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