Архив метки: SupplyChain

Накину ещё немного по кейсу компрометации DAEMON Tools в ответ на комментарий уважаемого Игнатия Цукергохера

Накину ещё немного по кейсу компрометации DAEMON Tools в ответ на комментарий уважаемого Игнатия Цукергохера

Накину ещё немного по кейсу компрометации DAEMON Tools в ответ на комментарий уважаемого Игнатия Цукергохера.

🔹 "Кто-то ещё пользуется DAEMON Tools?! О_о"

Тут дело-то, конечно, не в DAEMON Tools как таковом, а в культуре потребления программных продуктов в принципе. Существует масса сверхпопулярного софта, разрабатываемого непонятно кем. Вот тот же DAEMON Tools - это поделие то ли латышской, то ли гонконгской компании. Что это вообще за компания, что там за люди работают, насколько они ответственно относятся к безопасности своих продуктов? 🤷‍♂️ Непонятно. А Notepad++? Может, там вообще никакой компании нет, просто какой-то один разработчик с ментальными проблемами, передавший доступ к репозиторию какому-то левому анонимусу (как в инциденте с XZ Utils). И это только софт для конечных пользователей. Если посмотреть на то, кто контролирует зависимости для софта, то там вообще мрак. Неудивительно, что злоумышленники прочухали, что атаковать кустарей и получать доступ к их клиентам - это просто и суперэффективно. Поэтому таких supply chain-атак будет только больше. И это не изменится, пока не изменится неадекватно доверчивое отношение к софту. Пока пользователи не перестанут вестись на модные продукты (а программисты - на модные библиотеки и фреймворки) как Эллочка Людоедка на блестящее ситечко, полностью игнорируя соображения безопасности. Пока же, к сожалению, наблюдаю обратные тенденции.

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

Тут тоже не могу согласиться. Устройства всех пользователей, которые установили себе DAEMON Tools с малварью, были скомпрометированы. То, что не на всех устройствах, по мнению исследователей Kaspersky, злоумышленники устанавливали минималистичный бэкдор и QUIC RAT, - дело десятое. Никто не может гарантировать пользователям, что злоумышленники на системе не закрепились. Единственная рекомендация здесь может быть - вайпать машину и перенакатывать операционку, особенно в случае корпоративной среды.

Kaspersky сообщают о компрометации DAEMON Tools

Kaspersky сообщают о компрометации DAEMON Tools

Kaspersky сообщают о компрометации DAEMON Tools. DAEMON Tools - это программа, которая позволяет "подключать" файлы образов дисков (например, ISO) как будто это вставленный в компьютер CD- или DVD-диск. Программа популярная, развивается с 2000 года. Версия с базовой функциональностью доступна бесплатно. Я её в своё время активно использовал. Так вот, эксперты Kaspersky обнаружили масштабную атаку на цепочку поставок через DAEMON Tools. Вредоносные версии программы распространяются с официального сайта с 8 апреля 2026 года (затронуты версии 12.5.0.2421-12.5.0.2434). На момент написания атака всё ещё продолжается.

Все троянизированные исполняемые файлы были подписаны действительной цифровой подписью AVB Disc Soft - разработчика DAEMON Tools. Заражение установщиков было обнаружено Kaspersky в начале мая. По телеметрии зафиксированы тысячи попыток заражения в более чем 100 странах (большинство жертв находилось в России, Бразилии, Турции, Испании, Германии, Франции, Италии и Китае), но полноценное развитие вредоносной активности наблюдалось лишь на десятке систем государственных, научных, производственных и розничных организаций, расположенных в России, Беларуси и Таиланде. Kaspersky сообщили о проблеме разработчику AVB Disc Soft.

Бинарные файлы DAEMON Tools запускаются при старте компьютера. Каждый раз, когда это происходит, активируется бэкдор. Он встроен в код автозапуска, отвечающий за инициализацию среды CRT (C Runtime). Бэкдор работает в отдельном потоке, который используется для отправки GET-запросов на вредоносный сервер, адрес которого создан при помощи тайпсквоттинга легитимного доменного имени daemon-tools[.]cc (вредоносный домен без дефиса). Согласно WHOIS, доменное имя вредоносного сервера было зарегистрировано 27 марта, примерно за неделю до начала атаки на цепочку поставок.

Первая вредоносная нагрузка, которую развертывают злоумышленники, - это сборщик информации (Information collector). Данные, собираемые вредоносной нагрузкой, включают MAC-адрес (первый ненулевой), имя хоста, доменное имя DNS, список запущенных процессов (разделённый точкой с запятой), список установленного программного обеспечения (разделённый точкой с запятой) и язык системы. Развертывание сборщика информации наблюдалось на большом количестве заражённых машин. На небольшой части систем (около десятка) злоумышленники пытались доставить дополнительную вредоносную нагрузку. На основании этого исследователи Kaspersky делают вывод, что сборщик информации используется для профилирования заражённых систем, а полученные данные применяются для последующего целенаправленного развертывания дополнительного вредоносного ПО.

Одной из дополнительных вредоносных нагрузок, обнаруженных исследователями Kaspersky, является минималистичный бэкдор (шеллкод). Его функциональность включает возможность загрузки файлов, выполнения shell-команд и запуска шеллкод-модулей в памяти. Минималистичный бэкдор применялся для развертывания более сложного импланта, который назвали QUIC RAT. Этот бэкдор поддерживает множество протоколов коммуникации с C2, включая HTTP, UDP, TCP, WSS, QUIC, DNS и HTTP/3. Хотя его анализ всё ещё продолжается, исследователи Kaspersky установили, что QUIC RAT способен внедрять вредоносные нагрузки в процессы notepad.exe и conhost.exe.

Время обнаружения этой атаки (около одного месяца) сопоставимо с расследованием атаки на цепочку поставок 3CX в 2023 году. Учитывая сложность инцидента, организациям рекомендуется тщательно проверить системы, на которых был установлен DAEMON Tools, на предмет аномальной активности начиная с 8 апреля и позже.

С начала 2026 года прошло всего четыре месяца, однако за этот период зафиксирован рост числа атак на цепочки поставок, что ранее наблюдалось значительно реже. В январе расследовался инцидент с eScan, в феврале - с Notepad++, в апреле - с CPU-Z, и в мае - с DAEMON Tools.

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

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security. А там мощный движ! 🔥🙂 Вообще у меня всегда было весьма скептическое отношение к Trivy. В первую очередь из-за качества детектирования уязвимостей. Каждый раз, когда я пытался использовать его для анализа докер-образов, я наталкивался на какие-то жуткие фолз-позитивы. Причём логику детектирования уязвимостей было отследить весьма непросто. Поэтому я Trivy использовал только в крайних случаях. Если образ можно было просканировать, детектируя чётко по бюллетеням безопасности через Vulners API, - делал так. Если нельзя из-за того, что образ был на основе какого-то дистрибутива, который Vulners на тот момент не поддерживал (например Alpine), то вынужденно использовал Trivy. Лучше, чем ничего. И тем более Trivy же БЕСПЛАТНЫЙ! 🙂 И если не задумываться о качестве детектирования, то бесплатный сканер - это ведь очевидный и лучший выбор, так ведь? 😅 Правда, я Trivy не пользовался уже года 3-4. Возможно, что с детектированием уязвимостей ситуация у них стала получше. Но вот с собственной безопасностью похоже стало хуже. Иначе как объяснить, что вместо бесплатного сканера с официального репозитория Trivy на GitHub распространяется малварь (и это уже во второй раз за два месяца!). 😱

В конце прошлой недели, 20 марта, исследователь безопасности Paul McCarty сообщил о крупной атаке на цепочку поставок, нацеленной на Trivy.

"Внимание! Trivy версии 0.69.4 скомпрометирована ⚠️ Контейнерные образы и GitHub-релизы версии 0.69.4 являются вредоносными, поэтому если вы используете Trivy в CI, стоит срочно обратить на это внимание. К счастью, версия через Homebrew не была скомпрометирована, как я сообщал ранее. Вредоносная нагрузка представляет собой бинарный файл, и мы пока не провели его анализ, но обновим информацию, как только узнаем больше. Огромное спасибо команде, которая оперативно отреагировала сегодня - вы спасли ОЧЕНЬ много людей от крайне неприятного дня."

Подробности по малвари на opensourcemalware.

Разработчики часто встраивают Trivy в свои CI/CD-пайплайны - и это делает его особенно привлекательным для злоумышленников, поскольку позволяет им похищать API-ключи, учетные данные облаков и баз данных, токены GitHub, а также множество других секретов и чувствительной информации.

За атакой стоит группа TeamPCP. Им удалось это сделать, потому что ещё в феврале та же группа воспользовалась ошибкой конфигурации в GitHub Action Trivy и похитила токен с привилегированным доступом. Эта проблема безопасности так и не была полностью устранена, и позже, в марте, злоумышленники использовали этот токен для создания поддельных коммитов в Trivy.

Исследователи из Socket и Wiz в выходные установили подробности атаки. Атака затронула несколько компонентов проекта Trivy: основной сканер, GitHub Action trivy-action и GitHub Action setup-trivy. Злоумышленники принудительно обновили 75 из 76 тегов trivy-action до вредоносных версий, что означает: любой, кто использовал Trivy в своем пайплайне разработки, запускал инфостилер-вредонос при обращении к сканеру.

Исследователи также обнаружили, что TeamPCP расширила свои операции, начав заражать экосистему npm с помощью ранее неизвестного червя под названием CanisterWorm, используя похищенные publish-токены из первоначального взлома Trivy.

В воскресенье Socket зафиксировали дополнительные вредоносные образы, опубликованные в Docker Hub, а Paul McCarty отметил высокий импакт атаки: "44 внутренних репозитория были взломаны, переименованы и сделаны публичными - включая исходный код Tracee, внутренние форки Trivy, CI/CD-пайплайны, Kubernetes-операторы и базы знаний команд (team knowledge bases)". Socket отмечают, что, хотя полный масштаб доступа остаётся неясным, наличие этих репозиториев указывает на более глубокий уровень контроля во время компрометации.

Charles Carmakal, директор Mandiant Consulting, на мероприятии Google заявил:

"Нам известно о более чем 1 000 затронутых SaaS-средах, которые прямо сейчас активно сталкиваются с этим конкретным злоумышленником. Количество этих жертв, вероятно, вырастет ещё на 500, ещё на 1 000, возможно, ещё на 10 000. И мы знаем, что эти акторы сейчас сотрудничают с рядом других групп".

В общем, излишнее доверие к сторонним бесплатным компонентам и излишняя автоматизация вышли компаниям боком. Снова. 😏🍿

Разработчики популярного текстового редактора Notepad++ написали сегодня, что их серверная инфраструктура была скомпрометирована с июня по декабрь 2025 года и злоумышленники устанавливали малвари на хосты с Notepad++ под видом обновлений

Разработчики популярного текстового редактора Notepad++ написали сегодня, что их серверная инфраструктура была скомпрометирована с июня по декабрь 2025 года и злоумышленники устанавливали малвари на хосты с Notepad++ под видом обновлений

Разработчики популярного текстового редактора Notepad++ написали сегодня, что их серверная инфраструктура была скомпрометирована с июня по декабрь 2025 года и злоумышленники устанавливали малвари на хосты с Notepad++ под видом обновлений. 🤷‍♂️

"Согласно анализу, предоставленному экспертами по безопасности, атака включала компрометацию на уровне инфраструктуры, что позволило злоумышленникам перехватывать и перенаправлять трафик обновлений, предназначенный для notepad-plus-plus[.]org. […] Трафик от некоторых целевых пользователей выборочно перенаправлялся на серверы, контролируемые атакующими, которые отдавали вредоносные манифесты обновлений." 🙄

Инсталлеру на такую подмену было пофиг:

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

В коллекцию кейсов ASUS Live Update, CCleaner, eScan и прочих.

Аксиома обновления до последней версии ПО

Аксиома обновления до последней версии ПО

Аксиома обновления до последней версии ПО. В комментариях к посту про Vulnerability Management как порождение хаоса в IT (пользуясь случаем, всех приглашаю комментировать мои посты в VK и добавляться в друзья 😉) Михаил Богаченко подсветил интересную тему. Мы действительно зачастую берём некоторые аспекты Vulnerability Management-а как аксиомы, которые не требуют доказательств.

В случае, если нужно закрыть уязвимость мы зачастую можем рекомендовать "обновиться до последней версии ПО". Хотя эта последняя версия ПО может, например, содержать бэкдор. Как было в случае с XZ Utils, 3CX Desktop App и Free Download Manager. Так что рекомендация может привести к инциденту. 🤷‍♂️ И кто будет в этом случае отвечать? 😏

Причём ладно ещё, если это рекомендации для устранения какой-то конкретной критичной уязвимости. Но мы ведь можем (и, имхо, должны) рекомендовать устанавливать обновления безопасности регулярно и безусловно. Чтобы большая часть уязвимостей исправлялась в этом регулярном процессе, без участия Vulnerability Management специалистов.

И что же делать? Я думаю следующее:

🔸 Риски привнести НДВ с обновлениями всегда есть и будут. Поэтому и существует методика тестирования безопасности обновлений. 😉 Которая должна применяться, как минимум, для зарубежного и опенсурсного ПО. Насколько она реально применяется - пусть будет на совести каждого. 🙂

🔸 Выбор новой версии ПО для исправления конкретной критичной уязвимости лучше оставить на усмотрение IT. Хотят ставить минорную версию, которая исправляет только одну уязвимость, но с меньшей вероятностью влияет на основную функциональность ПО - их право. 🤷‍♂️ Уязвимость исправлена и ладушки.

🔸 Безусловные регулярные обновления ПО до последней версии всё равно считаю правильной и прогрессивной мерой. Риски, что вендора подломят и проведут Supply Chain Attack или вендор сойдёт с ума и сам внесёт зловредную функциональность, всё-таки гораздо ниже, чем риски эксплуатации известных уязвимостей. Чтобы риски были ещё ниже стоит внимательнее подходить к подбору вендоров и мониторить новости об инцидентах с ними, чтобы в случае, если (когда) они будут скомпрометированы, отработать оперативно.

Послушал доклад Татьяны Куцовол (ГК «Солар») про безопасность Supply Chain на SafeCode и сделал небольшой конспект

Послушал доклад Татьяны Куцовол (ГК «Солар») про безопасность Supply Chain на SafeCode и сделал небольшой конспект

Послушал доклад Татьяны Куцовол (ГК «Солар») про безопасность Supply Chain на SafeCode и сделал небольшой конспект.

❓SCA и Supply Chain - в чём разница?

🔹 Software Composition Analysis (SCA) - выявление и исправление известных уязвимостей (CVE)
🔹 Supply Chain - текущих проблем нет, но в будущем с кодом могут быть проблемы

📔 Стандарты

🔸 SLSA (Supply-chain Levels for Software Artifacts). 4 уровня. В основном про билды. 🫤
🔸 OWASP SCVS (Software Component Verification Standard). 6 кратких контролей. 😒
🔸 CIS SSCSG (Software Supply Chain Security Guide). 100 рекомендаций в 5 категориях. 👍

😡 Техники злодеев

🔻 Хактивизм и создание токсичных репозиториев
🔻 Starjacking
🔻 Typosquatting
🔻 Dependency Confusion
🔻 Become Maintainer

📊 Метрики для оценки опенсурсных проектов

➕ Популярность
➕ Авторский состав
➕ Активность сообщества
➕ Заинтересованность в безопасности (есть )
➖ Библиотека создана недавно
➖ Первая версия подозрительно высокая