🏆 Управление Findings: реальность метрик
Когда toolchain начинает лить сотни срабатываний — команда быстро перестаёт им доверять и ценность AppSec резко падает. Думаю, что все таки стоит разобраться с тем, как это полечить, поэтому возьмем кейсы на базе моей практики.
На конфе я рассказал кулуарно как это считается, почему именно такой подход выбрал и что же важно для него. Давай смотреть на метрики:
• False Positive Rate = (закрыто как FP / всего срабатываний) × 100% - на ruleset пороги инструмента (SQL Injection, XSS, SSRF и т.д.)
• FPR по CWE: FPR(CWE XXX) = FP / все сработки × 100% - отдельные критичные моменты, которые подходят чисто под вашу специфику и стек. Если FPR по CWE > 30%, то добавляйте sink/ source whitelist, context-aware фильтры, исключения по аннотациям для правила сработки.
• Risk-based приоритизация срабатываний: Priority Score = CVSS × EPSS × Reachability × Business Impact
• Где нет CVSS/ EPSS, то используем: AppSec Priority = Severity × Confidence (подтверждение сработки по уровню) × Reachability × Business Impact
Итого: минимальный процесс внедрения будет следующий
#appsec #reco #devsecops #specialty #paper #research #toolchain
Когда toolchain начинает лить сотни срабатываний — команда быстро перестаёт им доверять и ценность AppSec резко падает. Думаю, что все таки стоит разобраться с тем, как это полечить, поэтому возьмем кейсы на базе моей практики.
На конфе я рассказал кулуарно как это считается, почему именно такой подход выбрал и что же важно для него. Давай смотреть на метрики:
• False Positive Rate = (закрыто как FP / всего срабатываний) × 100% - на ruleset пороги инструмента (SQL Injection, XSS, SSRF и т.д.)
Реко:
— ≤ 15% — инструмент адекватно считает (если вы делали качественно и не все в исключение отправляли)
— 15–30% — жёлтая зона, нужна донастройка правил
— > 30% — красная зона, следовательно немедленный аудит правил инструмента
— < 5% — проверьте False Negative или что-то повалилось
• FPR по CWE: FPR(CWE XXX) = FP / все сработки × 100% - отдельные критичные моменты, которые подходят чисто под вашу специфику и стек. Если FPR по CWE > 30%, то добавляйте sink/ source whitelist, context-aware фильтры, исключения по аннотациям для правила сработки.
Пример:
— CWE-89 (SQL Injection) — низкий FPR при правильном парсинге AST, но высокий при regex
— CWE-79 (XSS) — FPR зависит от контекста вывода HTML/ JS/ attr
— CWE-22 (Path Traversal) — высокий FPR из-за ложных taint-цепочек в ORM
— CWE-611 (XXE) — низкий FPR и частый FN из-за кастомных XML
— CWE-502 (Insecure Deserialization) — один из самых назойливых FPR
• Risk-based приоритизация срабатываний: Priority Score = CVSS × EPSS × Reachability × Business Impact
Коэффициенты:
— EPSS — вероятность эксплуатации в 30 дней (0.0–1.0)
— Reachability: 1.0 — endpoint достижим снаружи/ из смежного контура; 0.2 — изолирован, нет маршрута
— Business Impact: 2.0 — external API, user data; 1.0 — internal сервис; 0.5 — dev/ test среда
Пример:
— Score = 7.5 × 0.65 × 1.0 × 2.0 = 9.75 → CRITICAL и акцент на приоритете, который эксплуатируем
• Где нет CVSS/ EPSS, то используем: AppSec Priority = Severity × Confidence (подтверждение сработки по уровню) × Reachability × Business Impact
Итого: минимальный процесс внедрения будет следующий
• Считать FPR отдельно по каждому критическому CWE — раз в спринт, общий раз в крватал или H (полугодие)
• CWE с FPR > 30% на аудит правила, не отключение
• Для каждого срабатывания считать AppSec Priority Score
• Порог для сути, где берём в работу немедленно: Priority Score > 10
• Пересматривать Confidence-коэффициенты под свой инструмент по типу 1.0 — High, 0.5 — Medium, 0.1 — Low
#appsec #reco #devsecops #specialty #paper #research #toolchain
🔥6
Forwarded from Партизанский Маркетинг
Увольнения из-за ИИ дошли до того, что разработчики уже готовятся к худшему заранее.
Айтишник сделал кнопку «I GOT FIRED» — после её нажатия система автоматически публикует код компании, сливает все ключи и пароли, удаляет тестовую базу и отправляет уведомление юристу. Сам разработчик уверяет, что нажимать её не планирует, а собрал её чисто на всякий случай.
Пока одни обновляют резюме, другие готовят кнопку на чёрный день.
Айтишник сделал кнопку «I GOT FIRED» — после её нажатия система автоматически публикует код компании, сливает все ключи и пароли, удаляет тестовую базу и отправляет уведомление юристу. Сам разработчик уверяет, что нажимать её не планирует, а собрал её чисто на всякий случай.
Пока одни обновляют резюме, другие готовят кнопку на чёрный день.
😱5
🤔 Метрики оценки: тащим STLC в AppSec правильно
Салют.
Часто показываю слайд с восемью метриками оценки из STLC — это классика QA-мира. На конфе, которая была, словил инсайд: необходимость доносить годность для AppSec, когда мы приравниваем баги к уязвимостям кодовой базы. Поэтому поделюсь с тобой своими мыслями. В целом эти метрики и нужны, но не прямо в лоб, потому что скопировать их нельзя, нужно переопределять.
А теперь чекай слайд:
• «Убойность» правил = подтверждённые уязвимости (TP) / число активных правил ruleset
• Доля покрытия классов угроз (широта) = CWE-классы и контроли, реально проверяемые toolchain / все релевантные для стека × 100%
• Доля отклонённых срабатываний = (FP + accepted / risk accept) / все срабатывания × 100%
• Плотность покрытия (глубина) = число правил / число контролей (CWE / ASVS)
• Плотность уязвимостей = подтверждённые уязвимости (TP) / покрытие кодовой базы (кандидаты на Secure Code Review)
• Доля регрессий уязвимостей (reopen rate) = уязвимости, вернувшиеся после «устранения» / все устранённые × 100%
• Эффективность AppSec = уязвимости, взвешенные по критичности / трудозатраты AppSec (часы скан + триаж). Веса обычно: Critical 10, High 5, Medium 2, Low 0.5, а лучше перевернуть в «стоимость одной Critical-находки» = часы / число Critical.
• Плотность уязвимостей после поставки = уязвимости, найденные в PROD / обьем кодовой базы (про результат). Если плотностьне падает от релиза к релизу, лезем в проектное управление команды и собираем evidence к ним. Считай Defect Removal Efficiency для ИБ = найдено до релиза / (до релиза + после) × 100%.
Итого:
#appsec #devsecops #reco #toolchain #paper #specialty
Салют.
Часто показываю слайд с восемью метриками оценки из STLC — это классика QA-мира. На конфе, которая была, словил инсайд: необходимость доносить годность для AppSec, когда мы приравниваем баги к уязвимостям кодовой базы. Поэтому поделюсь с тобой своими мыслями. В целом эти метрики и нужны, но не прямо в лоб, потому что скопировать их нельзя, нужно переопределять.
Сначала договоримся с тобой так — тут зарыта главная подмена, где в STLC дефект — это баг, тест — тест-кейс, требование — функциональное требование. А теперь прикол в том, что:
• Дефект - это подтверждённая уязвимость True Positive
• Тест - правило/ политика анализатора ruleset
• Требование - класс угроз CWE, контроль ASVS, пункт безопасной разработки ГОСТ 56939-2024
А теперь чекай слайд:
• «Убойность» правил = подтверждённые уязвимости (TP) / число активных правил ruleset
— Низкая по ruleset, где правила сбоят или мертвы
— Аномально высокая на одном правиле, тут либо системный дефект кода, либо правило сбоит
• Доля покрытия классов угроз (широта) = CWE-классы и контроли, реально проверяемые toolchain / все релевантные для стека × 100%
— < 60% — токсично
— 60–85% — рабочая зона
— > 85% — зрелое покрытие
• Доля отклонённых срабатываний = (FP + accepted / risk accept) / все срабатывания × 100%
— высокая из-за FP, то инструмент сбоит, следовательно делаем аудит правил
— высокая из-за accepted risk, то есть то, что валит процесс, делай эскалацию
• Плотность покрытия (глубина) = число правил / число контролей (CWE / ASVS)
— < 1, показывает, что контроль покрыт формально
— несколько правил с разной логикой (AST + taint analys+ semantic ruleset)
• Плотность уязвимостей = подтверждённые уязвимости (TP) / покрытие кодовой базы (кандидаты на Secure Code Review)
• Доля регрессий уязвимостей (reopen rate) = уязвимости, вернувшиеся после «устранения» / все устранённые × 100%
— > 15% — фиксят не то и не там
— на каждую устранённую Critical/ High следует правило в Quality Gate
• Эффективность AppSec = уязвимости, взвешенные по критичности / трудозатраты AppSec (часы скан + триаж). Веса обычно: Critical 10, High 5, Medium 2, Low 0.5, а лучше перевернуть в «стоимость одной Critical-находки» = часы / число Critical.
• Плотность уязвимостей после поставки = уязвимости, найденные в PROD / обьем кодовой базы (про результат). Если плотностьне падает от релиза к релизу, лезем в проектное управление команды и собираем evidence к ним. Считай Defect Removal Efficiency для ИБ = найдено до релиза / (до релиза + после) × 100%.
Итого:
• Широту покрытия и глубину (плотность правил) считать в паре — раз в спринт детально по критичным CWE, общий срез раз в квартал или H
• Долю отклонённых всегда расщеплять на FP и accepted risk
• Плотность уязвимостей и долю регрессий смотреть каждый релиз
• Эффективность считать через стоимость Critical-находки
• Главный KPI зрелости — Defect Removal Efficiency для ИБ > 90%
#appsec #devsecops #reco #toolchain #paper #specialty
🔥6
Forwarded from Alexander Popov
Всем привет!
Open source по выходным: я выпустил новый релиз моей карты средств защиты ядра Linux.
Теперь она соответствует относительно свежему ядру v6.17.
Я добавил в нее новые средства защиты, устранил несколько ошибок и сделал связи еще более красивыми 🖼
Радуюсь, что все-таки находятся силы развивать этот проект!
https://github.com/a13xp0p0v/linux-kernel-defence-map
Open source по выходным: я выпустил новый релиз моей карты средств защиты ядра Linux.
Теперь она соответствует относительно свежему ядру v6.17.
Я добавил в нее новые средства защиты, устранил несколько ошибок и сделал связи еще более красивыми 🖼
Радуюсь, что все-таки находятся силы развивать этот проект!
https://github.com/a13xp0p0v/linux-kernel-defence-map
GitHub
GitHub - a13xp0p0v/linux-kernel-defence-map: Linux Kernel Defence Map shows the relationships between vulnerability classes, exploitation…
Linux Kernel Defence Map shows the relationships between vulnerability classes, exploitation techniques, bug detection mechanisms, and defence technologies - a13xp0p0v/linux-kernel-defence-map
🔥7
Forwarded from The Hacker News
⚡AI is making DDoS attacks faster and smarter — helping attackers find weak spots, create new attack vectors, and scale attacks more efficiently.
Watch this WEBINAR to see how it works → https://thehackernews.com/2026/05/new-ai-ddos-attacks-are-smarter-learn.html
What you’ll get:
• Real examples of today’s AI-enhanced attacks
• How to find & fix hidden weaknesses fast
• Practical defenses you can apply immediately
Watch this WEBINAR to see how it works → https://thehackernews.com/2026/05/new-ai-ddos-attacks-are-smarter-learn.html
What you’ll get:
• Real examples of today’s AI-enhanced attacks
• How to find & fix hidden weaknesses fast
• Practical defenses you can apply immediately
🔥5
🤔 S.T.R.I.D.E. как рабочее решение моделирования и контроля угроз ИБ
Салюты,
Давай сегодня посмотрим на шесть классов угроз описанных в S.T.R.I.D.E. По сути это можно было увидеть во многих выступлениях, но лучше обьяснить смысл и принцип, так как без обвязки он не работает и чтобы превратить её в инструмент нужно DFD и привязка к контролям митигации.
Мы же не живем в идеально иллюзорном мире и всегда приходится что-то куда то "натягивать".
Фундаментом является Data Flow Diagram, как threat modeling с потоками данных, границами доверия. ПО факту это будут у тебя: external entity, процессы, flow, data store, trust boundaries. После только этого ты сможешь перейти к самому S.T.R.I.D.E. Концептуально это все аналитика по принципу:
• Какое свойство Паркеровской гексады нарушается?
• Типовые векторы
• Контроли
• Митигации и оценка рисков ИБ
S.T.R.I.D.E.
• S — Spoofing: подмена, где нарушается подлинность субъекта
• T — Tampering: фальсификация, где нарушается целостность (data flow (in transit), data store (at rest), процесс (целостность кода и конфигов))
• R — Repudiation (отказ от действий), где нарушается неотказуемость и подотчётность
• I — Information Disclosure (раскрытие информации), где нарушается: конфиденциальность
• D — Denial of Service (отказ в обслуживании), где нарушается доступность
• E — Elevation of Privilege, где нарушается: авторизация
#appsec #devsecops #reco #paper #specialty #riskanalysis
Салюты,
Давай сегодня посмотрим на шесть классов угроз описанных в S.T.R.I.D.E. По сути это можно было увидеть во многих выступлениях, но лучше обьяснить смысл и принцип, так как без обвязки он не работает и чтобы превратить её в инструмент нужно DFD и привязка к контролям митигации.
Мы же не живем в идеально иллюзорном мире и всегда приходится что-то куда то "натягивать".
Фундаментом является Data Flow Diagram, как threat modeling с потоками данных, границами доверия. ПО факту это будут у тебя: external entity, процессы, flow, data store, trust boundaries. После только этого ты сможешь перейти к самому S.T.R.I.D.E. Концептуально это все аналитика по принципу:
• Какое свойство Паркеровской гексады нарушается?
• Типовые векторы
• Контроли
• Митигации и оценка рисков ИБ
S.T.R.I.D.E.
• S — Spoofing: подмена, где нарушается подлинность субъекта
Вектора:
• подмена пользователя, session fixation, replay токена
• подмена сервиса, как MITM, фальшивый endpoint, DNS-hijack, отсутствие mTLS между микросервисами
• подмена identity в логах через X-Forwarded-User без проверки
Контроли: MFA, mTLS с проверкой сертификатов, OAuth2/ OIDC с PKCE, привязка токенов, типа DPoP, mTLS-bound, WebAuthn/ FIDO2, anti-replay (nonce, timestamps, jti)
• T — Tampering: фальсификация, где нарушается целостность (data flow (in transit), data store (at rest), процесс (целостность кода и конфигов))
Вектора:
• модификация трафика
• подмена параметров запроса (IDOR через hidden fields, JWT с alg=none, манипуляции client-side state)
• модификация хранимых данных в обход приложения
• supply chain: подмена артефактов сборки, образов, зависимостей
Контроли: TLS актуальных версий, цифровые подписи и HMAC, контроль целостности (checksums, FIM), append-only / WORM журналы, signed commits, signed images, SBOM, контроль конфигураций)
• R — Repudiation (отказ от действий), где нарушается неотказуемость и подотчётность
Вектора:
• пользователь отрицает действие, а доказать нечем
• shared/ служебные аккаунты без идентификации
• админ модифицирует журналы постфактум
• разработчик коммитит без подписи в общую ветку
Контроли: централизованное журналирование с защитой целостности (append-only, WORM), синхронизация времени NTP, корреляция в SIEM, цифровая подпись чувствительных операций, signed commits, запрет shared accounts
• I — Information Disclosure (раскрытие информации), где нарушается: конфиденциальность
Вектора:
• нешифрованная передача
• stack trace и подробные ошибки в ответе пользователю
• BOLA / IDOR — обращение к чужим объектам по перебору ID
• PII (персонификация) и секреты в логах
• side-channel: тайминг, размер ответа, кэш-различия
Контроли: TLS, шифрование at-rest (envelope / KMS / HSM), generic-ответы об ошибках без деталей, output filtering и явные DTO, маскирование PII в логах, минимизация данных, secret management
• D — Denial of Service (отказ в обслуживании), где нарушается доступность
Вектора:
• объёмные DDoS уровней L3/ L4
• application-layer DoS: медленные запросы (slowloris), catastrophic regex backtracking, zip/XML-бомбы, billion laughs
• исчерпание ресурсов: утечки памяти, connection pool, unbounded queues
Контроли: rate limiting и throttling, WAF / DDoS-защита, ограничения размера, времени и глубины, circuit breakers, авто-масштабирование, бэкапы и DR, capacity planning
• E — Elevation of Privilege, где нарушается: авторизация
Вектора:
• BOLA / BFLA: нет проверки прав на объект или функцию
• вертикальная эскалация
• горизонтальная эскалация
• sandbox escape
• JWT-tampering
• RCE через десериализацию
Контроли: RBAC / ABAC с deny-by-default, проверка авторизации на каждом запросе (а не один раз на входе в API-gateway), Segregation of Duties, least privilege, изоляция контейнеров (rootless, seccomp, AppArmor / SELinux), валидация входа, role-claims с клиента
#appsec #devsecops #reco #paper #specialty #riskanalysis
🔥5
Forwarded from The Hacker News
⚠️ WARNING - A malicious npm package was caught stealing files from Claude AI users’ /mnt/user-data directories and uploading them to attacker-controlled GitHub repositories.
Check your installed packages: https://thehackernews.com/2026/05/malicious-npm-package-stole-files-from.html
The package, “mouse5212-super-formatter,” used npm postinstall scripts, hard-coded GitHub tokens, and fake network logs to hide the theft.
Downloaded 676 times so far.
Check your installed packages: https://thehackernews.com/2026/05/malicious-npm-package-stole-files-from.html
The package, “mouse5212-super-formatter,” used npm postinstall scripts, hard-coded GitHub tokens, and fake network logs to hide the theft.
Downloaded 676 times so far.
🔥4
Ух, меня тут позвали на съемку 15 выпуска новостного подкаста по безопасной разработке, вот посмотри как это выглядит тут.
Будет классно выглядить, я уверен, что сделаем пушку в очередной раз 🙏
#appsec #devsecops #specialty #paper
Будет классно выглядить, я уверен, что сделаем пушку в очередной раз 🙏
#appsec #devsecops #specialty #paper
Telegram
AKTIV.CONSULTING
🔥Вышел 🔠🔠 выпуск подкаста «Безопасный выход. Новости»: ПДн в Интернете, доктрина по ИБ и регулирование ИИ
🎙Ведущие — эксперты AKTIV.CONSULTING:
🟠Владислав Крылов, консультант по информационной безопасности
🟠Артём Денисов, консультант по информационной безопасности…
🎙Ведущие — эксперты AKTIV.CONSULTING:
🟠Владислав Крылов, консультант по информационной безопасности
🟠Артём Денисов, консультант по информационной безопасности…
🔥6
🤔 Риск- и бизнес-ориентированная модель в ИБ
В ГОСТ Р ИСО/ МЭК 15408 и в материалах по управлению рисками всегда описывается одна и таже схема, которая вроде бы выглядит понятно, но все же по ней возникают работы, а обычно мало кто обьяснет принцип ее действия.
Начиная работать по ней в проекте появляется «реестр рисков» без владельцев, без сроков и без связи с реальными активами, что обычная практика на сегодняшний день для многих.
Опишем детально
Типовые ошибки
Итого
#appsec #devsecops #term #tiskanalysis #pmi #reco #specialty #paper
В ГОСТ Р ИСО/ МЭК 15408 и в материалах по управлению рисками всегда описывается одна и таже схема, которая вроде бы выглядит понятно, но все же по ней возникают работы, а обычно мало кто обьяснет принцип ее действия.
Начиная работать по ней в проекте появляется «реестр рисков» без владельцев, без сроков и без связи с реальными активами, что обычная практика на сегодняшний день для многих.
Приведенные элементы описывают, как организация защищает то, что ценно, а именно активы, от того, кто хочет причинить ущерб, используя уязвимости, и как этому противостоит, - контрмеры. В следствии половина людей называет угрозой то, что на самом деле является уязвимостью.
Опишем детально
• Активы: данные, сервисы, бизнес-процессы, репутация. Если не можешь оценить ущерб от потери — у тебя не актив, а просто пассив. Пример:
— возможность обрабатывать платежи, база клиентов — активы
— сервера, ВМ, контейнера — носители, не активы
• Владелец: лицо или роль, отвечающее за актив и принимающее решения о его защите, то есть не ИБ и не администратор. Владелец фиксируется вместе с активом и принимает решение принять / минимизировать / делегировать / избежать. Без владельца модель не работает — некому говорить «да, готов жить с этим риском»
• Угроза: потенциальное событие, способное нанести ущерб активу — сценарий, как пример кража токена, вывод средств через скомпрометированную сессию. Угроза — что может случиться; уязвимость — слабость, через которую это происходит. Угроза без актива — абстракция, а без уязвимости — пока не реализуется
• Злоумышленник: субъект угрозы — кто способен и мотивирован причинить ущерб: инсайдер, APT и т.д. Модель нарушителя: категория, мотивация (финансы, разведка, идеология), ресурсы, доступ, потенциал. Без модели нарушителя контрмеры подбираются вслепую — нельзя одинаково защищаться от скриптов и от группировки
• Вектора атак: путь и способ реализации угрозы через уязвимости, такие как - фишинговое письмо, далее макрос, нагрузка и утечка C2
• Уязвимости: слабость, которую может использовать угроза, как пример CVE, процессная (нет триажа), недостаток архитектуры. Уязвимость без угрозы - это гипотеза, а без контрмеры - открытый риск
• Меры минимизации: снижают уязвимости, вероятность реализации угроз или ущерб активу и работает только при правильной настройке, контроле эффективности. Принципы: defense-in-depth и соразмерность. Каждой мере минимизации нужны владелец и метрика, иначе она деградирует
• Риски: возможность реализации угрозы через уязвимость с ущербом для актива. Уязвимость и угроза вместе — потенциал, а риск — его оценка в деньгах, времени, последствиях. Принятый риск без срока и условий пересмотра — это не принятие, а забвение всем нам
Типовые ошибки
• Приравнивание угрозы и уязвимости, в следствии реестр рисков превращается в перечень CVE без сценариев
• Называют активом сервер, а не данные и процессы на нём
• Нет владельца актива и некому принимать решения по риску
• Контрмеры подбирают по аналогии без привязки к конкретной уязвимости или угрозе
• Оценка риска без модели нарушителя, где все угрозы выглядят одинаково вероятными
• Принимаем риск без срока и условий пересмотра
• Контрмеры считают по факту установки, а не по факту работоспособности
Итого
• Следует инвентаризовать активы, назначить владельцев
• Построить модель нарушителя: категория, мотивация, ресурсы, доступ, потенциал (желательно под кейсы, а именно сценарно и не по ФСТЭК России, иначе закопаешься)
• Идентифицировать угрозы по каталогам и привязать к активам
• Выявить уязвимости и связать с активами и угрозами
• Оценить риски по матрице вероятность на ущерб с учётом модели нарушителя и достижимости
• Подобрать контрмеры под уязвимости, зафиксировать ответственных и метрики эффективности
• Согласовать решение по каждому риску с владельцем
• Принятые риски вести со сроком пересмотра
• Пересматривать модель при изменениях
#appsec #devsecops #term #tiskanalysis #pmi #reco #specialty #paper
🔥7
Салют, пока предлагаю изучить тебе эту тему, очень интересно то, что сейчас происходит вокруг RedHat и этого стоит опасаться, на самом деле.
А пока я бегаю тут, готовлю для тебя материалы - это поможет быть нам вместе ближе
А пока я бегаю тут, готовлю для тебя материалы - это поможет быть нам вместе ближе
🔥4
Forwarded from SecAtor
В результате атаки на цепочку поставок скомпрометированы npm-пакеты в экосистеме Red Hat, распространивших новый вариант вредоносного ПО Shai-Hulud, получившего название Miasma.
Инцидент был обнаружен Aikido и OX Security (1 и 2), которые выявили десятки версий пакетов, содержащих бэкдоры с вредоносным ПО, предназначенным для кражи учетных данных разработчиков, секретов из облачных сервисов, ключей SSH, токенов CI/CD и другой конфиденциальной информации.
По данным Aikido, взломанные пакеты скачиваются примерно 117 000 раз в неделю. Как отметили в Red Hat, затронутые пакеты были удалены после того, как ей стало известно об инциденте.
Скомпрометированные пакеты предназначены исключительно для внутренней разработки, вредоносный код не получил распространения среди клиентов через систему console.redhat.com.
Расследование инцидента продолжается, но, предварительно, влияния на среды клиентов или партнеров, а также на производственные системы Red Hat выявлено не было.
По данным Aikido, злоумышленники, по всей видимости, взломали учетную запись GitHub сотрудника Red Hat и использовали ее для прямой отправки вредоносных коммитов в несколько репозиториев.
Инициированные изменения добавили рабочий процесс GitHub Actions и скрипт, который использовал механизм публикации npm для выпуска пакетов с бэкдорами.
Когда запускался рабочий процесс, он устанавливал Bun и выполнял команду _index.js, передавая ей список целевых пакетов через переменную среды OIDC_PACKAGES.
Скрипт использует id-token: разрешение на запись для запроса кратковременного токена OIDC от GitHub, затем использует этот токен для прямой аутентификации с доверенной конечной точкой публикации npm и публикации версий каждого пакета из списка с бэкдорами.
Скомпрометированные пакеты содержали вредоносный скрипт предварительной установки, который автоматически запускал сильно обфусцированный вредоносный файл index.js при установке пакетов разработчиками.
Размер полезной нагрузки в файле index.js составлял приблизительно 4,2 МБ и использовался для кражи секретов GitHub Actions, учетных данных AWS, учетных данных Google Cloud и Docker, субъекта службы Azure, токенов HashiCorp Vault, записи службы Kubernetes, публикации npm и PyPI, ключей SSH и GPG и файлов .env.
Исследователи утверждают, что вредоносная ПО, использованная при взломе Red Hat, имеет много общего с Mini Shai-Hulud, но теперь использует строку «Miasma: The Spreading Blight» в качестве комментариев во взломанных репозиториях GitHub.
Вредоносная ПО хоть и напоминает Mini Shai-Hulud от TeamPCP, но неясно, проводилась ли кампания именно этим злоумышленником либо другим, который модифицировал исходный код просочившейся вредоносной ПО.
OX Security полагает, что вредоносная ПО сохраняет ту же функциональность по краже учетных данных, что и Mini Shai-Hulud, но добавляет дополнительные уровни обфускации, многоступенчатые механизмы доставки полезной нагрузки, а также расширенные функции кражи данных и сбора учетных данных.
На текущий момент вредоносной ПО Miasma были скомпрометированы 309 репозиториев GitHub. Установившим затронутые версии вредоносного ПО рекомендуется немедленно обновить все учетные данные, секреты и токены.
Инцидент был обнаружен Aikido и OX Security (1 и 2), которые выявили десятки версий пакетов, содержащих бэкдоры с вредоносным ПО, предназначенным для кражи учетных данных разработчиков, секретов из облачных сервисов, ключей SSH, токенов CI/CD и другой конфиденциальной информации.
По данным Aikido, взломанные пакеты скачиваются примерно 117 000 раз в неделю. Как отметили в Red Hat, затронутые пакеты были удалены после того, как ей стало известно об инциденте.
Скомпрометированные пакеты предназначены исключительно для внутренней разработки, вредоносный код не получил распространения среди клиентов через систему console.redhat.com.
Расследование инцидента продолжается, но, предварительно, влияния на среды клиентов или партнеров, а также на производственные системы Red Hat выявлено не было.
По данным Aikido, злоумышленники, по всей видимости, взломали учетную запись GitHub сотрудника Red Hat и использовали ее для прямой отправки вредоносных коммитов в несколько репозиториев.
Инициированные изменения добавили рабочий процесс GitHub Actions и скрипт, который использовал механизм публикации npm для выпуска пакетов с бэкдорами.
Когда запускался рабочий процесс, он устанавливал Bun и выполнял команду _index.js, передавая ей список целевых пакетов через переменную среды OIDC_PACKAGES.
Скрипт использует id-token: разрешение на запись для запроса кратковременного токена OIDC от GitHub, затем использует этот токен для прямой аутентификации с доверенной конечной точкой публикации npm и публикации версий каждого пакета из списка с бэкдорами.
Скомпрометированные пакеты содержали вредоносный скрипт предварительной установки, который автоматически запускал сильно обфусцированный вредоносный файл index.js при установке пакетов разработчиками.
Размер полезной нагрузки в файле index.js составлял приблизительно 4,2 МБ и использовался для кражи секретов GitHub Actions, учетных данных AWS, учетных данных Google Cloud и Docker, субъекта службы Azure, токенов HashiCorp Vault, записи службы Kubernetes, публикации npm и PyPI, ключей SSH и GPG и файлов .env.
Исследователи утверждают, что вредоносная ПО, использованная при взломе Red Hat, имеет много общего с Mini Shai-Hulud, но теперь использует строку «Miasma: The Spreading Blight» в качестве комментариев во взломанных репозиториях GitHub.
Вредоносная ПО хоть и напоминает Mini Shai-Hulud от TeamPCP, но неясно, проводилась ли кампания именно этим злоумышленником либо другим, который модифицировал исходный код просочившейся вредоносной ПО.
OX Security полагает, что вредоносная ПО сохраняет ту же функциональность по краже учетных данных, что и Mini Shai-Hulud, но добавляет дополнительные уровни обфускации, многоступенчатые механизмы доставки полезной нагрузки, а также расширенные функции кражи данных и сбора учетных данных.
На текущий момент вредоносной ПО Miasma были скомпрометированы 309 репозиториев GitHub. Установившим затронутые версии вредоносного ПО рекомендуется немедленно обновить все учетные данные, секреты и токены.
www.aikido.dev
Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm
Multiple official @redhat-cloud-services npm packages were compromised with a credential-stealing worm derived from the open-sourced Mini Shai-Hulud malware, targeting cloud credentials, and developer tooling across CI/CD pipelines.
🔥4