CrowdSec

CrowdSec - открытый open-source IPS, написанный на Golang. Правила парсятся из всевозможных логов, а принятие решения о том, что делать с тем или иным аномальным IP-адресом определяется баунсером ("вышибалой"). Есть возможность написать правила на yaml или подтянуть их из базы правил сообщества.

Поддерживается деплой через docker-образ. Можно делиться инфой о вредоносных IP-адресах с другими юзерами через центральный API.

#ops

Better security through code hygiene (react)

Полезные слайды о небезопасном использовании JSX-шаблонов в React с возможностью реализации XSS. В том году я уже выкладывал небольшой даташит для разработчиков и appsec о безопасности react. Из слайдов узнал, что semgrep выпустили встроенный пак для поиска нежелательных конструкций в react'е. Стоит отметить, что речь именно о нежелательных конструкциях, а не об уязвимостях.

#dev

Up to 40 Percent Of GitHub Copilot Generated Code May Be Insecure

Copilot от Github (AI-помощник для разработчика) многие прозвали уже одним из самых инновационных проектов для повышения эффективности разработки в 2021 году. Чтобы ответить на вопрос "а насколько генерируемый код безопасен" было проведено исследование, в рамках которого создано 89 сценариев для Copilot и 1692 программ, 40% из которых оказались уязвимыми. Для формирования критерия качества кода использовался инструмент CodeQL.

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

#dev #sast

Company wide SAST

Ребята из Яндекса выложили последний недостающий доклад с ZN (+слайды), где они рассказали о том, как строили SAST. В первой части речь пойдет про разработанный внутри оркестратор SAST'а и правила для Semgrep. Во второй части будет затронута тема CodeQL: его плюсы/минусы, опыт проведения пилота и написания правил. Есть также ссылка на репозиторий с полезными запросами для улучшения taint-анализа.

#dev #sast

Anatomy of a Cloud Infrastructure Attack via a Pull Request

В продолжение темы с извлечением секретов из сборки [1,2] нашел свежую статью от Teleport (разработчики одноименного решения для контроля привилегированных пользователей) с разбором этой атаки в их инфраструктуре. Они, в частности, используют Drone CI в связке с dind. В статье разбирается специфика этой уязвимости у них и приводится небольшой чек-лист, как они митигируют соответствующие риски.

#ops #attack

How to find client-side prototype pollution at scale

Загрязнение прототипа (prototype pollution) - уязвимость, вызванная особенностями JS, позволяющая реализовать XSS и даже RCE. Подробное описание уязвимости было приведено ребятами из Huawei. Сегодня мне хотелось бы поделиться статьей о том, как эту уязвимость искали - "A tale of making internet pollution free"- Exploiting Client-Side Prototype Pollution in the wild". Благодаря selenuim, собственному расширению для браузера и запросу codeql ресерчеры нашли 18 уязвимых библиотек и зарепортили около 80 багов.

Кстати в стандартном паке codeql также есть кое-какие правила для поиска prototype pollution в собственных исходниках.

#dev #sast

Дыры и заборы: безопасность
в Kubernetes

13 октября в 19:00 Мск знакомые проводят вебинар «Дыры и заборы: безопасность в Kubernetes». Речь пойдет про культуру безопасности в Kubernetes, взломы, которые уже попали в категорию "классика" (Tesla 2018, TeamTNT 2020) и атаки, сопровождающиеся майнингом и отключением кластера.

У вас также есть возможность задать вопросы экспертам и поделиться историями атак на ваши кластеры.

#talks

Kubernetes Security Checklist and Requirements

В канале было много того, что касается безопасности ванильного Kubernetes, но, когда дело доходит до составления перечня требований или чеклиста для аудита, так или иначе приходится тратить время для сведения всего этого воедино. Чтобы упростить эту задачу мы зарелизили собственный чек-лист безопасности k8s: Kubernetes Security Checklist and Requirements 🎉

Здесь важно отметить,что этот чек-лист - это лишь один из путей повышения безопасности кластера. Этот путь самый сложный и во многом самый противоречивый и утрированный. Многое из того, что здесь есть, запросто может не подойти для вашей инфраструктуры в силу культуры или технических ограничений. Все это сделано с той целью, чтобы напомнить вам о тех мерах, про которые вы могли забыть, но для вас они подходят больше всего. PR'ы приветствуются!

Кстати, есть также версия на русском.

#k8s #ops

Implementation of DevSecOps for a Microservices-based Application with Service Mesh - SP 800-204C (Draft)

Сначала в эту историю влетели NSA и CISA, а теперь время пришло и для NIST. Вышел драфт документа SP 800-204C "Implementation of DevSecOps for a Microservices-based Application with Service Mesh" о внедрении DevSecOps в связке с Kubernetes.

#k8s #ops #dev

Introducing Snowcat: World’s First Dedicated Security Scanner for Istio

Snowcat - инструмент для аудита конфигурации Istio на предмет безопасности. В основу взята официальная страница Istio Security Best Practices. На текущий момент инструмент поддерживает:
- проверку наличия mTLS,
- поиск небезопасных паттернов политики авторизации (доступность эндпоинтов без авторизации),
- проверку контроля сертификата при egress-трафике
- проверку политики JWT-токенов ( first-party-jwt / third-party-jwt) для корректного контроля получателя
- поиск небезопасных версий Istio

Для поиска мисконфигураций инструмент может быть натравлен на yaml-файлы в качестве статического анализатора кода, XDS-порт, kubelet API или Istiod debug API без аутентификации. Подробнее об инструменте можно прочитать в блоге.

#ops #k8s

RBAC Tool For Kubernetes

RBAC-tool - инструмент от Alcide (которую недавно приобрела широкоизвестная Rapid7), позволяющий формировать RBAC-роли в Kubernetes по результатам анализа audit events (в основу был взят движок audit2rbac), строить карту ролей и выявлять небезопасные роли.

#k8s #ops

10 Types of Web Vulnerabilities that are Often Missed, OWASP Top 10 Over Time

Сегодня у нас на очереди снова веб, а именно 10 уязвимостей, которые часто упускают.

Среди них:
- HTTP/2 Smuggling
- XXE via Office Open XML Parsers
- SSRF via XSS in PDF Generators
- XSS via SVG Files
- Blind XSS
- Web Cache Deception
- Web Cache Poisoning
- h2c Smuggling
- Second Order Subdomain Takeovers
- postMessage bugs

А на картинке вы, кстати, видете, как менялся OWASP Top 10 с 2004 по 2021 год.

#dev

Common Threat Matrix for CI/CD Pipeline

В рамках доклада “Attacking and Securing CI/CD Pipeline” на конференции CODE BLUE 2021 Opentalks вышла матрица угроз MITRE ATT&CK для CI/CD: Threat Matrix for CI/CD Pipeline. Частично она переиспользует идеи, предложенные SLSA, расширяя перечень потенциальных угроз и мер безопасности. Про многое я писал в серии постов по моделированию угроз CI/CD [1,2,3] и возможности извлечения секретов из CI.

Очень понравился перечень мер безопасности, который сильно пересекается с тем, что прорабатывал я в рамках аналогичной активности (но не успел пока выложить в открытый доступ). Не стоит забывать, что создание модели угроз и требований ИБ для таких широких процессов, как сборка и деплой - это всегда про кастомизацию. Кому-то будет важно ограничить прямой доступ к CD, отделив процесс отдельной системой (например, AWX, для которого есть свой набор security практик) и закрыв PAM'ом. Для кого-то верификация сигнатур в CI/CD может быть очень дорогим процессом и они ограничиваются проставлением метатэгов на уровне централизованного репозитория артефактов. Сама по себе мера "Hardening CI/CD pipeline servers" может завезти вереницу проверок и возможных "переключателей" (пример вариации настроек).

#ops

Popular NPM package UA-Parser-JS poisoned with cryptomining, password-stealing malware

Несколько дней назад в популярном пакете ua-parser-js был обнаружен криптомайнер и password-stealer. Пакет используется такими компаниями как Google, Amazon, Facebook, IBM и Microsoft. Предполагается, что вредоносное ПО попало в пакет после получения доступа к учетной записи мейнтейнера злоумышленником.

Подверженные версии:
0.7.29, 0.8.0, 1.0.0.
Проблема устранена в:
0.7.30, 0.8.1, 1.0.1.

Сейчас уязвимость уже есть во многих AV-движках (в случае если на вашем слейве есть AV) и закрытых базах платных SCA (например, Sonatype под идентификатором sonatype-2021-1529)

P.S. Зависимость может быть транзитивной, поэтому ее можно ожидать в том же пакете react.

#attack #dev #news

В помойке NPM всё как всегда

> Пакет coa, предоставляющий функции для разбора аргументов командной строки, насчитывает около 9 млн загрузок в неделю и используется в качестве зависимости у 159 других NPM-пакетов, включая react-scripts и vue/cli-service.

> Пользователем следует убедиться, что у них установлена версия coa 2.0.2 и желательно добавить в package.json своих проектов привязку к рабочей версии на случай повторной компрометации.

В NPM-пакет coa, насчитывающий 9 млн загрузок в неделю, внедрено вредоносное ПО
https://www.opennet.ru/opennews/art.shtml?num=56104

Ученые из Кембриджского университета в Соединенном Королевстве раскрыли обнаруженный еще 25 июля вектор атаки Trojan Source, позволяющий внедрять уязвимости в исходный код программного обеспечения таким образом, чтобы рецензенты не могли их обнаружить, что создает угрозу популярному ПО и цепочкам поставок.

Trojan Source использует простой прием, который не требует модификации компилятора или прочих ухищрений, затрагивая C, C ++, C #, JavaScript, Java, Rust, Go и Python. Вся фишка состоит в использовании управляющих символов Unicode для изменения порядка токенов в исходном коде на уровне кодирования.

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

Реализация Trojan Source происходит по двум сценариям: CVE-2021-42574 (или двунаправленная атака) и CVE-2021-42694 (гомоглифическая атака).

В первом случае применяются элементы управления Unicode для двунаправленного текста, чтобы определять направление, в котором отображается контент. К примеру, LRI и RLI. Двунаправленные (Bidi) элементы управления LRI и RLI являются невидимыми символами, и они не единственные. Вводя эти инструкции, компилятор может скомпилировать код, полностью отличный от того, что видит человек.

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

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

Оказывается также, что символы Bidi сохраняются при копировании/вставке в большинстве браузеров, редакторов и операционных систем. Trojan Source работает практически во редакторах кода и веб-репозиториях (оцените сами ниже в таблице)

За свои изыскания научные деятели получили в среднем 2 246 долларов по bugbounty. На GitHub они предоставили PoC, которые демонстрируют, насколько серьезной угрозой может быть атака: тем более, что Trojan Source затрагивает почти все компьютерные языки, а патчи еще толком не выпущены, оставляя уязвимыми почти два десятка поставщиков программного обеспечения.

Minimum Viable Secure Product

Небольшой чеклист, состоящий из минимальных необходимых мер безопасности продукта. Общий список поделен на следующие категории:
- Business controls
- Application design controls
- Application implementation controls
- Operational controls

Если ваши продукты далеки от MVP, то есть также стриница, посвященная Enterprise Ready системам, где собраны гайдлайны по разным доменам и опросник.

#dev #ops

Практика управления безопасностью ПО в масштабных продуктах

Доклад от CISO Тинькофф об угрозах, присущих платформам разработки (куда также относятся CI/CD системы). В число угроз попали:
- Уже многим известный Dependency Confussion
- Использование одних и тех же ключей для всех сборок и деплоев
- Повышение привилегий через shared раннеры (в т.ч. привилегированный DinD)
- Внесение изменений в код за счет отсутствия правил approve/review
- Использование небезопасных сторонних библиотек
- Публикация внутренних API во внешнюю среду через единый ingress
- Открытие полного доступа в Интернет для закрытых ресурсов

#dev #ops #attack

Подводные камни DevSecOps и "безопасности как сервис".

Отдельное внимание мне хотелось бы уделить фразе "Безопасность как сервис". Дмитрий интерпретирует ее в контексте предоставления шаблонов подключения WAF/SAST/DAST, которые могут быть легко встроены как код разработчиками. По сути - это классическое видение DSO, где каждый разработчик может встроить все проверки отдельными стейджами в свой пайплайн.

Здесь, правда, есть большое количество "но", с которыми часто сталкиваются крупные компании, что зачастую препятствует закреплению DSO в культуре разработки.

Разберем некоторые из них:
- До сих пор в компаниях не везде есть единый согласованный CI, под который нужно писать шаблоны
- До сих пор есть разработчики, которые собирают код руками
- Разработчики могут буквально забить на проверку ИБ и не встроить ее в пайплайн, а у ИБ нет механизмов это своевременно выявить
- Все решения (SAST/SCA/DAST) имеют свой flow по работе с уязвимостями. Где-то нужно проставлять комментарии и статусы, а где-то таких механизмов в принципе нет (не говоря про то, что у многих инструментов нет UI)
- У каждого решения (SAST/SCA/DAST) есть своя консоль и, соответственно, свой набор доступов, который нужно предоставлять для разработчиков для триажа.
- Специалистов со стороны ИБ <5, а разработчиков 500+

Но чем больше мне удается пообщаться со зрелыми командами из компаний с большой разношерстной инфраструктурой разработки, тем больше прихожу к концепции предоставления безопасности не просто в виде шаблонов, а в виде полноценного SaaS-решения (DevSecOps/AppSec-платформа). В следующих частях мы поговорим подробнее об этом явлении, которое активно набирает обороты в large enterprise.

#dev #ops