Siren by Open Source Security Foundation (OpenSSF)

Те, кто давно подписан на канал, помнят проект OpenSSF, о котором здесь неоднократно писалось. Наши любимые проекты – это Scorecard и Insights. Недавно они выпустили новый мини-проект Siren, Open Source Threat Intelligence. Это рассылка писем о последних техниках и IOC, связанных с атаками на open-source проекты. Инструмент появился логично спустя месяц после атак на xz-utils.

По словам OpenSSF, эффективность таких TI ресурсов, живущих за счет сообщества, подтверждается проектами oss-security mailing list и (linux)-distros. И понятно почему так происходит - это ключевая фича сообществ и open source, про которую написана замечательная "Социальная Архитектура: Создание онлайн сообществ" П. Хинченса (русский перевод доступен по ссылке: https://irus.github.io/social-architecture-ru/ ).

Интересно, что именно будет попадать в данную рассылку и какая будет частота оповещений? Подписались, посмотрим. Тот же DataLog, например, собрал только датасет из 1500 вредоносных PyPI и NPM пакетов меньше чем за 2 года с помощью своего open-source инструмента GuardGod. Они же недавно писали про вредоносные PyPI пакеты, которые атаковали MacOS машины месяц назад...

#supplychain

Как мы взломали многомиллиардные компании за 30 минут с помощью поддельного расширения VSCode 😇

Тема supply chain не имеет конца и края. Сегодняшний пост мы начнем со статистики о плагинах VS Code:

- 1,283 расширений VS Code содержат известные вредоносные зависимости, с общим числом установок 229 миллионов.
- 87 расширений пытаются прочитать файл /etc/passwd на хост-системе.
- 8,161 расширений общается с жестко закодированным IP-адресом.
- 1,452 расширений запускают неизвестные исполняемые файлы или DLL.
- 145 расширений были отмечены VirusTotal с высокой степенью уверенности.
- 2,304 расширений используют репозиторий другого издателя на GitHub.

Такой статистикой поделились авторы сервиса ExtensionTotal по проверке безопасности плагинов VS Code в своей серии статей (часть 1, часть 2).

А теперь пара слов, почему так происходит:

- Стать "проверенным" издателем на VSCode Marketplace можно, просто подтвердив домен.
- Можно связать любое репо на GitHub с вашей страницей расширения, даже если оно вам не принадлежит.
- Расширения могут выполнять произвольный код, создавать процессы, выполнять системные вызовы, импортировать любые пакеты NodeJS.
- Расширения автоматически обновляются, что позволяет атакующему вставить вредоносный код после роста популярности плагина.

В частности, авторы статей разместили копию популярного плагина Darcula. В результате за сутки плагин вывелся в топы, а авторы получили пинги от крупных компаний, чьи имена не раскрыли. Скорее всего, речь идет о техногигантах вроде Microsoft, Google, Apple, Amazon.

Таким образом, "потоп" продолжается и по мере усложнения экосистем и зависимостей количество "сценариев провала" возрастает. Полностью закрыть возникающие потребности в информационной безопасности не может ни автоматизация, ни искусственный интеллект, ни развитие новых образовательных подходов. Времени, технологий и рук решительно не хватает. Подробнее об этом в нашем материале на соседнем канале:

https://t.iss.one/radcop_online/138

Интересно, когда появятся сервисы по сканированию плагинов для кофеварок и плоек? 😁

#supplychain

The Open Source Problem

Мы в канале любим статистику, особенно если она хорошо раскрывает глобальные проблемы на примере громких инцидентов. Недавно нам попался интересный ресерч: автор которого взял 5000 pip-пакетов и применил к ним "критерии Цзя Тан", того самого китайского контрибьютора бекдора в xz. Набор критериев простой: права на коммит, китайский часовой пояс и email, в котором сочетается имя и номер. В результате получилось 310 pip-пакетов. Даже у контрибьютеров самого pip есть некий [email protected], соответствующий таким критериям. Дополнительно можно почитать здесь и здесь.

А теперь взглянем на статистику Blackberry из их отчета о безопасности цепочки поставок ПО, составленного по результатам опроса 1000 старших руководителей:

- 51% компаний смогли восстановиться после взлома в течение недели, около 40% потребовалось месяц.
- 74% атак исходили от участников цепочки поставок программного обеспечения, о которых компании не знали или не отслеживали до взлома.
- Хотя 78% компаний отслеживают влияние атак на цепочку поставок, только 65% информируют своих клиентов об этих инцидентах.

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

Мы, в свою очередь, подбросим очередную новость о том, как в популярный проект polyfill.js китайцы внедрили вредоносный код на 100k+ сайтов. Здесь, правда, история о том, как развивалась атака, более загадочная, ибо домен и GitHub-репозиторий были переданы китайским мейнтейнерам в феврале этого года одним из разработчиков polyfill, принадлежащей компании Fastly. Поясняем: один из рядовых разработчиков компании, которой принадлежит проект polyfill, просто взял и продал проект новым владельцам (за что, скорее всего, получил хорошие деньги). Есть semgrep правило для поиска и замены вредоносных пакетов. Вот также полезный свежий ресерч.

#supplychain

Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine

Если история с CrowdStrike – это реализовавшаяся катастрофа в цепочке поставок, то команде JFrog удалось предотвратить атаку, которая потенциально могла бы быть еще более ужасающей. В своей статье команда JFrog Security Research рассказывает, как в одном из публичных репозиториев Docker Hub был обнаружен легаси GitHub токен с админ-правами от репозиториев таких проектов, как python, pypa, psf и pypi. Обладатель данного токена теоретически мог бы скрыть вредоносный код в CPython, который является репозиторием некоторых основных библиотек, составляющих ядро языка программирования Python и скомпилированных из кода на C. Из-за популярности Python, вставка вредоносного кода, который в конечном итоге попадет в дистрибутивы Python, могла бы означать распространение бэкдора на десятки миллионов машин по всему миру.

Токен был найден в бинарном файле .pyc. Как это произошло?

1) Автор добавил авторизационный токен в исходный код.

2) Запустил исходный код (Python-скрипт), который был скомпилирован в бинарный файл .pyc с авторизационным токеном.

3) Удалил авторизационный токен из исходного кода, но не очистил .pyc.

4) Загрузил как очищенный исходный код, так и неочищенный бинарный файл .pyc в Docker-образ.

Какие выводы делают авторы статьи?

- В бинарных файлах тоже могут быть секреты, которые надо искать (отсылка на решение от JFrog).
- Убедитесь, что вы не используете старые GitHub токены (которые были заменены на новые, более безопасные, в 2021 году).
- Предоставляйте доступ к токенам с наименьшими правами.

Отчет об инциденте от самих PyPi можно найти здесь.

#secrets #supplychain

3.7 Million Fake GitHub Stars

«Чем больше количественный социальный индикатор используется для принятия решений, тем сильнее он подвержен коррупционному давлению и тем выше вероятность, что он исказит и разрушит социальные процессы, которые должен отслеживать» (Закон Кэмпбелла).

О том, что на GitHub существуют фейковые звезды, известно давно. Однако насколько часто можно объективно оценить безопасность репозитория, исходя лишь из его популярности? Насколько эта проблема актуальна сегодня и какие последствия она влечет за собой? Ведь часто на аудитах коллеги пытаются аргументировать отсутствие собственного контроля безопасности supply chain тем, что "используют массово популярные компоненты", которые "наверняка безопасны, а если что-то вредоносное случится, то это сразу станет заметно и изменения отзовут/заблокируют ответственные ребята".

Рассмотрим ключевые моменты статьи компании Socket, специализирующейся на безопасности цепочки поставок:

1) Звезду можно купить всего за $0.10;

2) Накрутку часто используют в репозиториях, содержащих бэкдоры и вредоносные программы, включая те, которые крадут криптовалюту;

3) Поддельные звезды вводят в заблуждение венчурных инвесторов, побуждая их инвестировать в компании с низкокачественными продуктами и слабой активностью;

4) Несмотря на активную борьбу GitHub с накруткой, 89% подозрительных репозиториев с фейковыми звездами были удалены, однако 11% остаются доступными для пользователей (1 136 репозиториев), причем 28 из них отмечены на Virus Total;

5) Репозитории с накруткой существуют в среднем около одного месяца, что представляет ощутимую угрозу для пользователей, скачивающих такие проекты;

6) Лишь 18% аккаунтов, использованных для накрутки, удаляются с платформы.

В качестве решения данной проблемы сотрудник компании Socket предложил разработать детектор для выявления поддельных звезд на GitHub. Он основывается на данных из GHArchive, ежедневно обновляемого зеркала активности на GitHub, и двух ключевых эвристических методах:

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

Эвристика кластеризации: Определяет группы пользователей, которые отмечают большое количество репозиториев звездами в короткий промежуток времени, что свидетельствует о массовой покупке фейковых звезд.

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

В результате данный детектор был добавлен в GitHub App компании. На их сайте также доступен список подозрительных репозиториев и другие полезные списки. Например, список репозиториев с подтвержденным вредоносным ПО, репозитории используемые с typosquat атаках и т.д.

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

#supplychain #securitycontrol

Revival Hijack and Fake recruiter coding tests

В различных телеграм-каналах можно встретить множество упоминаний о новой атаке на цепочку поставок PyPI, известной как Revival Hijack, выявленной исследователями из JFrog. Суть атаки заключается в загрузке вредоносного пакета с тем же именем, что и у популярного пакета, который был удален. Это возможно благодаря тому, что PyPI позволяет использовать имя пакета практически сразу после его освобождения. Уже опубликовано немало постов с подробным разбором этой уязвимости на русском языке, поэтому не видим большой необходимости углубляться в детали. Для нас примечательнее скорее то, что эта атака не является совершенно новой: о ней сообщали исследователи из ReversingLabs еще в апреле 2023 года, однако тогда она не вызвала большого резонанса как сейчас 😅. Более того, ReversingLabs также предоставили инструмент для онлайн-идентификации подобных вредоносных пакетов.

В преддверии возможных аналогичных громких заголовков расскажем о еще одном сценарии атаки, который недавно, около недели назад, описали те же исследователи из ReversingLabs. Речь идет о целенаправленной атаке на разработчиков через вредоносный код, замаскированный под тестовое задание от фейкового HR в рамках python проекта. Атака осуществляется следующим образом: фейковый HR связывается с разработчиком через LinkedIn, предлагая решить тестовое задание, которое предполагает нахождение и исправление бага в проекте. Для этого требуется, соответственно, необходимо выполнить сборку, во время которой запускается исполняемый python-файл. В результате жертва подключается к C2 серверу. Помимо известных примеров подобных вредоносных заданий, в сети также были обнаружены реальные жертвы среди разработчиков. На данный момент известно, что за этой вредоносной кампанией, получившей название VMConnect, скорее всего стоит северокорейская APT-группа, действующая в интересах правительства.

P.S. Но самое забавное во всех этих атаках то, что за поверхностным разнообразием инструментов и сценариев скрываются универсальные принципы и базовые архитектурно-процессные изъяны, хорошо известные специалистам с 80-х годов, а то и раньше. Ведя книжный клуб в Кибердоме ваш покорный слуга открыл для себя Клиффорда Столла и «Яйцо кукушки: история разоблачения легендарного хакера». Эта любопытная, но нудноватая книга, на материале 1986 года наглядно показано как "уникальная специфика мира КИИ, цепочек поставок и кибервойн" на деле является давно известной и хорошо изученной территорией, но как обычно "скорость прогресса", пресловутый TTM и плохое понимание и игнорирование универсальных принципов PDCA приводят к тому, к чему приводят и даруют работу десяткам тысяч безопасников по всему миру, создавая ещё один дефицит на рынке труда....

#supplychain #attack

Non-Actionable Findings в 3rd-party Security Scanners...и как их распознать

Инженер Google написал блог-пост о том, как обрабатывать результаты CVE от сканеров безопасности и как распознать те, которые можно спокойно убрать из списка задач на фиксы.

Краткий конспект от нашей команды:

Rejected уязвимости: Самый простой вариант — исключить уязвимости с пометкой rejected в NVD (например, CVE-2023-4881). Это имеет смысл, когда сканер тащит весь NVD без минимальной фильтрации. Такой случай не особо интересен, двигаемся дальше.

Переоценка от мейнтейнеров: Бывает, что NVD отмечает уязвимость как high, а мейнтейнеры ОС считают, что у неё минимальный импакт и не выпускают патчи для своих дистрибутивов Linux. В таких случаях мнение мейнтейнеров может быть более релевантным, и уязвимость можно классифицировать как false positive.
Пример — CVE-2018-20657:

10-byte memleak, not considered important to be fixed by upstream, so no patch is available as of 2023-06-02

Отсутствие импакта на используемую ОС: NVD может показывать широкий диапазон уязвимых версий пакета, но не учитывать влияние на конкретную версию ОС. Если сканер использует только данные NVD и игнорирует статусы not affected от ОС, то он может ложно сработать на уязвимость, которой на самом деле нет (пример CVE-2023-52426)

Кастомные патчи от ОС: Иногда сканеры не учитывают кастомные патчи, которые ОС выпускает для фиксов. Например, сканер видит версию Python 3.6.10 как уязвимую, но Ubuntu выпустила патч с версией 3.6.9-1~18.04ubuntu1.1. Внешние сканеры, использующие NVD вместо базы уязвимостей от Ubuntu, могут ложно считать патченную версию Python уязвимой.

Неполная информация об уязвимости пакета: Некоторые фиды, как Debian, репортят уязвимости только для исходных пакетов. Сканеры часто ошибаются, считая уязвимыми все связанные бинарные пакеты, даже если они не содержат уязвимых библиотек. Например для уязвимости CVE-2024-6387 затрагивается только OpenSSH-серверы, но Debian отмечает уязвимым исходный пакет "openssh". В итоге даже системы с установленным только "openssh-client" будут ошибочно помечены как уязвимые, хотя уязвимых библиотек там нет.

Нерелевантные к безопасности срабатывания: Некоторые сканеры репортят пакеты, не связанные с безопасностью. Например, Trivy репортит файндинги из Debian LTS (DLA) о таких вещах, как обновления часовых поясов или новые GPG-ключи, которые не влияют на безопасность. Отсутствие этих обновлений не создает рисков для безопасности.

А какие классификации используете вы? Может быть расширим и углубим список "гугла"?

#sca #supplychain

GitHub Users Targeted by New Wave of Spambots

Ищите чтиво на выходные? Если вдруг вы увидели спам в комментариях своего репозитория на GitHub на этой неделе, вы не одиноки. Недавно мы писали об атаках на разработчиков, но на этот раз методы напоминают устаревшие практики. Боты оставляют комментарии, предлагая загрузить файлы с платформы MediaFire, содержащие вредоносное ПО. Цель злоумышленников — убедить разработчиков загрузить эти файлы, что в итоге приводит к компрометации системы и аккаунта GitHub.

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

"Это не должно быть задачей мейнтейнеров open-source — предотвращать спам с вредоносным ПО, но пока GitHub не решит эту проблему, я создал небольшой автоматизированный action, которая удаляет подозрительные ссылки из комментариев в задачах."

В целом подобного рода атаки на open-source не первые и не последние. В феврале этого года волна спама обрушилась на проект Express.js в следствие того как популярный youtube блогер с почти 5 млн подписчиками продемонстрировал пример как делать PR на нетестовом Github репозитории (вот здесь можно увидить результат). Несмотря на то, что это может показаться безобидным, но дело дошло даже до того один из мейнтейнеров Express.js заявил, что люди начали отправлять электронные письма с угрозами и преследовать участников репозитория за открытие спам-запросов на слияние (PR).

#supplychain #malware

SLSA provenance и кое-что еще

Так как канал исторически носит название "DevSecOps", самое время вспомнить то, что было активно обсуждаемым в 2021 году — SLSA. Недавно мы наткнулись на репозиторий s3cme — тестовое приложение на Go, в котором реализованы следующие лучшие практики:

- Сканирование с помощью Trivy
- Сканирование с помощью CodeQL
- Сборка и публикация образа с использованием ko (включает генерацию SBOM)
- Сканирование уязвимостей образа с использованием trivy с параметром проверки максимальной серьезности
- Подпись образа и аттестация с использованием cosign
- Генерация происхождения (provenance) SLSA с помощью slsa-framework/slsa-github-generator
- Проверка происхождения SLSA с использованием slsa-framework/slsa-verifier и CUE политики через cosign.

Напомним, что такое provenance. Всякий раз, когда образ публикуется в реестр, к этому образу прикрепляется аттестация в виде файла SLSA provenance (v0.2). Это позволяет отследить этот образ вплоть до его исходного кода в репозитории (включая GitHub Actions, которые использовались для его создания). Способность обеспечивать такую проверяемую прослеживаемость называется как раз происхождением (provenance). Делать это наибходимо с той целью, чтобы убедиться, что конечный доставляемый артефакт нигде не изменился по пути прохождения цепочки поставок, включая CI/CD. Отследить это можно либо вручную с помощью cosign, либо сразу в кластере с помощью sigstore admission controller.

Вот ссылка на наш старый пост с описанием фреймворка SLSA с действующими ссылками. Сейчас, спустя три года, можно с уверенностью сказать, что сообщество обогатилось конкретной реализацией некогда абстрактной теории, предложенной Google (к вопросу вечного холивара теоретиков и практиков - по-настоящему хорошо работает только синтез 😊 ).

А вот, например, автор из GitHub рассказывают про фичу GitHub по аттестации артефактов, которая упрощает подписание кода для программного обеспечения, созданного в GitHub Actions, и помогает достичь соответствия уровню 2 SLSA. Provenance включает информацию о происхождении, такую как данные о репозитории, инструкции по сборке и SHA исходного кода, делая процесс "голеньким и прозрачненьким".

А как вы решаете эти задачи, и дошли ли до их решения в своих пайпах?

#slsa #supplychain #devsecops