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

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