Vulnerability subsprition

Возвращаюсь к написанию постов после долгого перерыва. Сегодня я бы хотел поднять тему оперативного информирования о новых уязвимостях в продуктах, которые вы используете (а их, как правило, очень много, особенно в контексте разработки и DevOps).

Вариант #1 - подписаться на CVE

Есть множество сервисов, где это можно сделать. Один из них - opencve.io. Сервис абсолютно бесплатный, можно подписаться на определенного вендора или продукт с отбивками на почту. Достаточно удобно, но наблюдаются задержки в 1-2 дня.

Вариант #2 - узнавать о новых уязвимостях от первоисточника.

Информация о важных обновлениях, решающих вопросы безопасности, может содержаться в еженедельных отчетах вендоров через их официальные страницы (как, например, страница релизов на примере Gitlab). Здесь мы имеем очевидную проблему c отсутствием унификации поступающей информации. В случае, если продукт open source и он находится на Github или Gitlab, то здесь у нас есть возможность отслеживать уязвимости через страницу Issues. Так, например, чтобы узнавать раньше всех о найденных уязвимостей Kubernetes, надежнее всего подписаться на label kind/bug (в сочетании с triage/accepted) через desktop client (как описано в этом топике).

Вариант #3 - воспользоваться агрегатором

Другой вариант - воспользоваться сервисами вроде Vulners. Vulners, помимо возможности отслеживания CVE, предоставляет язык запросов, на результаты которого можно подписываться. Например, запрос affectedSoftware.name:"nginx" OR affectedPackage.packageName:"nginx" OR cpe:nginx order:published выдаст агрегированную информацию обо всех уязвимостях, связанных с nginx.

В заключение хочу поделиться также интересным ресурсом - cvetrends.com, который собирает информацию о "хайповых" CVE из twitter.

#dev #ops

Про безопасность разработки в большой организации

Не так давно ребята из Мимокрокодил позвали меня записать подкаст про современный DevSecOps в крупных организациях. Помимо главной темы, мы подняли концепцию AppSec/DevSecOps-платформ, путь моего развития в индустрии, влияние медийности на карьеру, а также подноготную ведения телеграм-каналов. Получилось весьма интересно:)

Предлагаю послушать:
https://podcast.ru/1505781025

#talks

The Python Vulnerability Landscape

Сегодня у нас пост про Python. Начнем со статьи "The Python Vulnerability Landscape" о развитии уязвимостей в пакетах python'а. В статье приведены данные об изменение числа уязвимостей в пакетах (в т.ч. с разбивкой на CWE и популярные фреймворки вроде django) и степени их критичности. На картинке вы в частности можете видеть наиболее уязвимые пакеты по годам.

А теперь об инструментах. Они не такие популярные как тот же Safety, но безусловно заслуживают внимания.

trailofbits/pip-audit - инструмент для анализа уязвимостей пакетов python от небезызвестных Trail of Bits с базой advisory-db. Скармливаем requirments.txt и получаем результат (можно в json).

ochronasec/ochrona-cli - аналогичный инструмент, использующий базу данных с уязвимостями, которая бралась за основу для формирования статистики выше. В базе используются NIST NVD, Github Advisory Database, PyPA Advisory DB.

#dev #sca

CodeQL for Log4j

“Пятница-пятницей, а Log4j JNDI инъекцию никто не отменял :) все про нее уже в курсе, но если нет, то почитать можно тут или тут, ну или по-русски тут. Для CodeQL соответственно сразу же подъехали экспериментальные запросы: https://github.com/github/codeql/pull/7354/files
Можно уже погонять на своём коде. Сами запросы используют csv-модели, то есть разделенные точкой с запятой однострочные описания неймспейса, типа, подтипа, имени класса и еще нескольких параметров для задания source'a, sink'a и summary. Это укорачивает спецификацию этих элементов, позволяет их писать быстрее, но читать это чуть непривычнее :)”

За текст спасибо @shad0wrunner

Из чата @codeql

#dev #ops #attack #sast

Acra 0.90.0: application-level encryption and searchable encryption for any SQL and NoSQL databases

Acra - проект с открытым исходным кодом для обеспечения безопасности sensitive-информации, хранящейся в базе данных за счет application-level шифрования. Что из себя представляет проект, из каких компонентов состоит и какими принципами руководствуется можно прочитать в статье. Помимо шифрования данных, есть возможность их маскирования, токенизации и поиска. Более того, есть модуль SQL firewall, который позволяет задавать политики для извлечения данных из БД, и модуль Intrusion Detection, расширяющий ваши данные honey-токенами, извлечение которых свидетельствует об атаке. Все это, ко всему прочему, интегрируется с SIEM.

#ops

Log4j - impacted products

Самое время посмотреть на те продукты, которые попали под impact от log4j:

https://github.com/NCSC-NL/log4shell/tree/main/software

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

Фиксить придется много

#dev #ops #attack

Cloud-Native Observability and Security Analytics with SysFlow and Falco

Всех с возвращением в рабочие будни. На канале мы их, кстати, начнем с материала про Falco (движок, реализующий обнаружение аномалий в Cloud-Native мире на базе самописных сигнатур). За последние 2 года вопросов к нему было достаточно много с точки зрения качества, но чем дальше, тем сложнее отрицать его колосальную популярность, которая в свою очередь повлияла на появление сторонних проектов. Особенно интересно наблюдать на интеграции этих проектов в 2022 году. На сайте Falco появилась статья "Cloud-Native Observability and Security Analytics with SysFlow and Falco", описывающая потенциальные возможности интеграции проекта SysFlow и Falco Sidekick.

SysFlow - свежий проект, созданный для стандартизации событий систем и расширения их дополнительными данными (источник, процесс, образ, таймштамп, состояние и тд.). Для расширенных событий строится граф связей, применяется процессинг на базе Falco правил и происходит преобразование в телеметрию и алерты.

Falco Sidekick - молодой, но уже достаточно популярный проект, предоставляющий веб-интерфейс для работы с алертами Falco из большого количества источников.

Итого в связке из двух проектов мы получаем достаточно красивое решение для визуалиации поведения злоумышленника на базе экосистемы Falco. Все это еще и красиво экспортируется в Jupyter для последующей аналитики.

#ops #k8s #docker

А вот скриншот из этого чуда.

P.S. Я, кстати, не подводил итоги года в отличие от моих коллег, а тем временем в канал пришло 2200+ человек за последний год. Всем спасибо! Не переставайте выполнять цели, поставленные в начале года, и не забывайте вступать в наш чат DevSecOps Chat и сторонние проекты - CloudSec Wine и AppSec and DevSecops Jobs!

#talks

Building Trust in the Software Supply Chain

В канале мы очень много говорили про различные варианты атак на цепочку поставок через CI/CD и варианты ее защиты. Предлагаю посмотреть красивую страницу "Building Trust in the Software Supply Chain" по безопасности цепочки поставок от Google, которая в свою очередь предлагает обеспечить защиту пайплайнов через подход создания свидетельствующих об искажении логов (Tamper-evident logs) и их открытого решения Trillian. В основе лежит концепция Verifiable Data Structures, гарантирующая то, что логи, получившиеся в процессе скачивания сторонних библиотек, сборки и проверки сканерами безопасности, не пострадали. Эти же логи можно проверять на целостность перед тем как задеплоить соответствующий артефакт на целевое устройство.

Помимо защиты цепочки поставок подход предлагается использовать при скачивании обновлений на конечных устройствах или при работе с финансовыми транзакциями. Кстати, фреймворк SLSA от того же Google получил отдельный веб-ресурс для изучения. В нем важность сбора логов и информации о том, что собирается, когда и кем отмечена также в отдельном направлении Provenance.

#ops

10 real-world stories of how we’ve compromised CI/CD pipelines

Обожаю NCC Group за их статьи и "10 real-world stories of how we’ve compromised CI/CD pipelines" не исключение. Разбираем варианты атак, где встречающийся CI/CD на пути злоумышленника становится ключевым звеном для развития вариантов компрометации: 3 примера для Jenkins (в т.ч. дамп кредов, про который я писал ранее) и 5 примеров для Gitlab (в т.ч. атаки с использованием неизолированных привилегированных раннеров). Еще 2 примера повествуют об удивительных находках ресерчеров NCC Group в контексте повышения привилегий в AWS аккаунте при наличии доступа к "ноутбуку разработчика" или посредством эксплуатации особенностей плагина Kube2IAM.

#ops

Exploiting Url Parsers: The Good, Bad, And Inconsistent

Команда Claroty совместно с Snyk опубликовала ресерч, посвященный уязвимостям в URL-парсерсах (названных URL Confussion), ведущих к SSRF, XSS, Open Redirect, обходам фильтраций и DoS. Всего было проанализирвоано 16 популярных библиотек и утилит на предмет их подверженности 5 категориям атак типа Confussion. В конце приведены также рекомендации, как использовать парсеры, чтобы минимизровать появление уязвимостей в своем вебе.

#dev #attack

What does your code use, and is it vulnerable? It depends!

Когда дело доходит до внедрения практики выявления уязвимостей в сторонних библиотеках, первое, что часто приходит на ум - внедрить инструмент класса SCA, получить уязвимые библиотеки и получить с разработчика обещание все исправить. При таком подходе мы сталкиваемся со встречными вопросами:
- откуда у вас уверенность, что в транзитивных зависимостях есть эксплуатируемые уязвимости,
- как определить версию директивной зависимости, чтобы обновить транзитивную
- можете ли вы полагаться на перечень зависимостей, который для вас определил SCA (например, в том же package.json может быть указано, что пакет lodash имеет версию "*")

На все эти вопросы ответить сразу на первых этапах внедрения практики не всегда удается успешно. Например, в случае, если мы имеем gradle, то build.gradle никак не даст ответов на вопросы выше, а результатом сборки в данном случае будет набор библиотек, лежащих в единой директории. Что из этого директивная зависимость,а что транзитивная по итогу анализа результатов SCA понять редко возможно. Приходится смотреть дерево зависимотей от самого gradle и сопоставлять с результатами SCA, из-за чего TTM сильно возрастает.

Часто компании принимают для себя решение просить исправлять только уязвимые директивные зависимости, а контроль устранения уязвимостей в транзитивных зависимостях отдавать на авторов директивных. Это решает часть проблем с объемом работы, но часть вопросов выше остаются актуальными.

В данном случае нам могут помочь несколько вещей. Один из простых и эффективных способов - получить lockfile! Это формат описания зависимостей с указанием явных хэш-сумм (а именно на хэш-суммы, как правило, смотрят все SCA, что сразу повышает точность сканирования). Что удобно, так это то, что lockfile можно получить нативным образом от всех популярных сборщиков (pipenv, npm, yarn, nuget, gradle, composer).

Второе решение - построить граф зависимостей и явно отсечь зависимости с глубиной выше 1. Здесь может помочь инструмент вроде It-Depends от Trail of Bits. Он построит вам перечень зависимостей с нужной глубиной и отдаст результат в формате SBOM, который можно скормить в SCA. Кроме того, он может выдать некоторые уязвимости на основе OSV vulnerability database, про которую я писал ранее.

#sca #dev

OWASP WrongSecrets

12 тасков на компрометацию секретов. Здесь есть hardcoded passwords, использование секрета в ENV, ConfigMap, AWS Secrets Manager, Vault и инжект во время сборки. Для работы с платформой, соответственно, может понадобится k8s, облако (aws, gzp, azure в experimental), minikube, vault.

#dev #secret

New Argo CD Bug Could Let Hackers Steal Secret Info from Kubernetes Apps

Для тех, кто еще не видел, у ArgoCD вышла CVE-2022-24348 (CVSS score: 7.7), позволяющая дампить секреты из кластера благодаря кастомному helm-чарту. Уязвимость затрагивает все версии и была устранена в 2.3.0, 2.2.4, и 2.1.9.

Reference:
https://apiiro.com/blog/malicious-kubernetes-helm-charts-can-be-used-to-steal-sensitive-information-from-argo-cd-deployments/

#attack #k8s #ops

Improving Web Vulnerability Management through Automation

Опыт Lyft по периодическому авто-сканированию внутренних веб-приложений с помощью Burp. В принципе, все отражено на схеме. В статье вы можете познакомиться с некоторыми деталями реализации. Со слов автора, благодаря данному подходу им удалось выиграть 3 дополнительных месяца инженера, но, как правильно было отмечено, так как вся информация хранится в Jira, то имеются проблемы с ограничением объема запросов и отслеживанием версий уязвимостей.

#dev #dast

How Flipkart Reacts to Security Vulnerabilities

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

Команда Flipkart рассказывает, как устроены их AppSec-процессы по обработке уязвимостей: источники уязвимости, как они выглядят в Jira, какие есть роли в процессе по устранению уязвимостей, атрибуты, что такое "иммунизация", из чего состоит их обучение разработчиков.

https://blog.flipkart.tech/how-flipkart-reacts-to-security-vulnerabilities-17dae9b0661e

Данные проблемы можно решать не только через Jira, приводя за собой ее проблемы. Мы, например, в Альфа-Банке пошли по пути реализации собственного инструмента оркестрации AppSec (через "платформизацию"), который выполняет задачи, связанные с запуском необходимых сканеров (вроде, nuclei) и обработкой полученных результатов, решая часть упомянутых проблем.

#dev

Code Review Hotspots with Semgrep

Автор сегодняшней статьи предлагает поделить сработки на две группы - security и hotspots. Сработки группы security имеют низкий уровень ложных срабатываний и предназначаются для разработчиков, в то время как сработки группы hotspots только свидетельствуют о подрзрении на уязвимость и попадают под ответственность security-инженеров. Вся статья дальше вращается вокруг хотспотов и способов их поиска через инструмент semgrep. К хотспотам относят hardoced secrets, небезопасную криптографию, мисконфиги, переполнения буфера и тд.

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

В теории можно обратиться к последнему отчету Veracode - State of Software Security v12. В отчете приводится разного рода интересная статистика в контексте сканеров класса SAST/DAST/SCA. В частности, здесь есть перечень CWE, которые лучше всего находятся для того или иного класса сканера (картинка приложена к посту выше). Любопытно, что Cryptographic Issues и Credentials Management относятся к категории уязвимостей, которые гораздо чаще находятся именно SAST'ами, в то время как в вышеупомянутой статье они относятся к хотспотам. Что же делать?

Здесь позволю себе высказать собственное мнение, как мы делим сработки на security и hotspots в Альфе. Для многих оно покажется очевидным. Чем больше уязвимость поддается паттернам, а не механизмам data flow, тем лучше она будет находиться через SAST и тем более уверены вы в ней будете. Сюда относятся hardocded credentials, небезопасный CORS, мисконфиги (в т.ч. Docker / Kubernetes) и другие уязвимости, которые можно допустить, указав в коде непрерывный набор строк кода. SQL-инъекции, XSS, SSRF и прочие уязвимости, подразумевающие прием данных от пользователя через request-объекты имеют свойства приобретать сложную логику развития, а значит и более высокую степень FP/FN. Нередко, влияние на правила нахождения таких уязвимостей в контексте data flow стоит вам от 3 непрерывных месяцев работы в codeql/checkmarx в соусе из перегоревших appsec'ов. В это же время паттерновые уязвимости довольно легко корректируются с помощью того же semgrep.

#dev #sast

Securing Developer Tools: Package Managers

Случались ли у вас ситуации, когда антивирусный агент начинает генерировать алерты о вредоносной активности будучи установленным на сборщике? Вероятно, вы столкнулись с вредоносами, описанными в этой статьей - "Securing Developer Tools: Package Managers". Речь пойдет о вредоносных пакетах, запускаемых с помощью Composer, Bundler, Bower, Yarn и других пакетных менеджерах. Приведены также разные меры по митигации.

В Golang, кстати, часть проблем supply chain попытались решить архитектурно. Начиная c того, что сборщики не могут ничего поставить за пределами зафиксированных хэшей в go.sum и заканчивая невозможностью запускать код во время сборки. Об этой подробнее в статье "How Go Mitigates Supply Chain Attacks".

#dev