Это четвёртый эпизод в серия сообщений о вредоносных компонентах, где мы представляем Ксигени подход к борьбе с этой угрозой в рамках нашего покрытия Open Source Security.
Мы увидели, что избыток доверия к компонентам с открытым исходным кодом с неопределенным исходным кодом используется злоумышленниками всех видов для создания неожиданного поведения, которое может быть запущено на машинах разработчиков, CI/CD системы или встроены в программное обеспечение организации-жертвы, поэтому они передаются клиентам организации. Мы рассмотрели в эпизод №2 атаки с использованием публичных реестров для доставки вредоносного ПО и то, что мы узнали, наблюдая за тем, как действуют злоумышленники, и в предыдущих эпизод №3 были изучены меры контроля, которые работают (и те, которые не работают) против этой угрозы.
Теперь пришло время взглянуть на наш подход к проблеме. В этом выпуске мы представляем, какой стратегии мы придерживаемся в Xygeni для нашей Раннее предупреждение о вредоносных программах (MEW) система. Как эта многоэтапная система работает в режиме реального времени при выпуске новой версии пакета, как собираются доказательства из разных источников, как осуществляется сортировка, каким критериям классификации мы следуем и почему все еще необходим ручной анализ для подтверждения характера кандидата вредоносного пакета. Мы также объясним, как мы помогаем NPM, GitHub, PyPI и другим ключевым инфраструктурам в экосистемах с открытым исходным кодом сократить время пребывания вредоносных программ.
pipeline
Xygeni Malware Early Warning (MEW) непрерывно обрабатывает компоненты, будь то пакетные tar-архивы для библиотек и фреймворков для поддерживаемых экосистем программирования, таких как JavaScript/Node или Python, образы контейнеров Docker/OCI или расширения и плагины для таких инструментов, как IDE или CI/CD системы. Такие компоненты публикуются в публичных реестрах с различными уровнями проверки пользователей.
Ниже схематично показано, как работает система:
исследователь процесс получает поток событий публикации. Событие публикации — это создание новой версии нового или существующего компонента. Поскольку популярные реестры не предоставляют механизм публикации-подписки для заинтересованных потребителей, это часто делается путем опроса реестра на предмет недавних событий. Отличный проект от OSSF, пакеты-каналыПоддержка популярные реестры, такие как PyPI или Maven Central, и предоставляют унифицированный интерфейс на основе каналов. В MEW мы добавили несколько конкретных реализаций, которые сокращают время ожидания, например, с помощью реплики базы данных CouchDB, используемой NPM, которая синхронизируется с базой данных общедоступного реестра.
В Xygeni у нас есть инвентарь[1] всех компонентов (прямо или косвенно), используемых программным обеспечением наших клиентов. Координаты компонентов клиентов регулярно передаются в MEW для определения приоритетности анализа: компоненты, используемые нашими клиентами, обрабатываются раньше. Приоритет также зависит от репутации издателя и критичности компонента, поэтому компоненты, поступающие от издателей с низкой репутацией, также имеют приоритет.
анализаторы затем используйте ожидающие компоненты в приоритетной очереди. Когда версия компонента выбрана для анализа, ее архив загружается из реестра. Обратите внимание, что анализируется упакованный двоичный компонент: большинство компонентов с открытым исходным кодом обычно поступают из репозитория с открытым исходным кодом, часто на github.com, который используется только для контекста, а вредоносное ПО всегда ищется в архиве компонента, поскольку злоумышленники систематически лгут об источниках, которые, по их утверждениям, использовались для создания архива компонентов, который они выпускают.
С точки зрения пользователя
Я слышу, как вы думаете: какую пользу я могу получить, узнав о вредоносной версии пакета заранее? В эпизоде «Анатомия вредоносных пакетов: каковы тенденции?» мы увидели, что общее время задержки находится в диапазоне дней, тогда как первое уведомление от MEW клиентам, использующим затронутый компонент, находится в диапазоне минут. С простым ограждением[2] вы можете заблокировать сборку (существует два уровня оповещения: один полностью автоматический, когда движок приходит к выводу о наличии потенциального вредоносного ПО, и более позднее уведомление, когда наша группа безопасности вручную подтверждает наличие вредоносного ПО). Ждать, пока реестр подтвердит наличие вредоносного ПО и удалит его из реестра, обычно бывает слишком поздно из-за длительного окна воздействия.
Организация может использовать ограждение, которое проверяет наличие компонента с потенциальным вредоносным ПО (на любом из двух уровней оповещения) или через API быстро узнавать, использует ли какая-либо из прямых или косвенных зависимостей в программном проекте вредоносный компонент.
Как работает MEW: подробности изнутри
Ядро: механизм обнаружения вредоносных программ
Анализатор использует различные детекторы для сбора доказательств правонарушений. Детекторы сочетают статический анализ, анализ возможностей и контекстный анализ.[3], как описано в предыдущем посте этой серии.
В Xygeni есть команда инженеров с многолетним опытом статического анализа, и в этом главное отличие от других решений для защиты от вредоносного ПО. Обратите внимание, что для некоторых экосистем упакованный архив содержит либо исходный код (например, код JavaScript или TypeScript для пакетов NPM, исходные коды Python для пакетов PyPI), либо скомпилированный код, достаточно близкий к исходному коду для статического анализа (например, байт-код в файлах JAR для Maven). . Для других, таких как образы контейнеров, обычно используются двоичные исполняемые файлы, поэтому используется метод определения возможностей наряду с обычным обнаружением вредоносного ПО на основе правил YARA и сигнатур вредоносного ПО.
Обратите внимание, что простые технологии, такие как регулярные выражения или подписи, не подходят для обнаружения вредоносного поведения. Представьте себе обнаружение дроппера или загрузчика: какой-то код или двоичный файл находится в пакете или загружен из внешнего домена, не связанного с компонентом (это может быть код из большой список доменов, приобретенных злоумышленником[4]Или законный домен, чтобы избежать обнаружения). Затем этот код выполняется с использованием одной из функций. Код можно преобразовать, чтобы скрыть URL-адрес загрузки или функцию, используемую для запуска загруженного кода. Для его обнаружения необходим полный анализ потока данных с использованием всего механизма статического анализа, или выполнение в изолированной программной среде (если условия для запуска вредоносного поведения действительно соблюдены) может обнаружить это в общем случае.
Злоумышленники используют те же методы, и детекторы для них были разработаны и внедрены. Существуют также некоторые этапы предварительной обработки, например, для устранения обфускации, которые часто необходимы для выявления скрытого поведения.
Добавление контекста
Некоторые детекторы используют контекстную информацию. Например, несоответствие между версией в реестре компонентов и тегом/выпуском в соответствующем репозитории GitHub является убедительным доказательством того, что, возможно, злоумышленник получил учетные данные публикации для реестра, но не для репозитория GitHub. Атаки, подобные той, которая затронула поставщика криптокошельков Ledger можно легко обнаружить по этому несоответствию.
A оценка вредоносности (MS) рассчитывается на основе результатов работы детекторов на основе убедительности собранных доказательств. Не все выводы одинаковы, и порядок выполнения имеет значение.
Репутация пользователей и компонентов
Не все разработчики с открытым исходным кодом одинаковы!
Учетная запись NPM известного разработчика может быть взломана (это случается даже с людьми, заботящимися о безопасности), и с использованием этой учетной записи будет опубликовано вредоносное ПО. Очевидно, что репутация должна резко упасть и вернуться к былой славе только тогда, когда взломанная учетная запись будет восстановлена и разработчик исправит условия, которые привели к захвату учетной записи. Репутацию трудно заработать, но ее можно потерять в мгновение ока.
В MEW мы внедрили комплексную систему управления репутацией, позволяющую поощрять позитивное поведение и наказывать за подозрительные действия. Эта система начинается с нейтральной позиции новых пользователей и корректирует их репутацию в зависимости от их текущей деятельности.
Репутация пользователя улучшается благодаря положительным действиям, таким как поддержание активных учетных записей в социальных сетях, включение многофакторной аутентификации, регулярное участие в проектах и подписание commits с проверяемыми ключами. И наоборот, репутация ухудшается из-за враждебных действий, таких как публикация вредоносного ПО, использование одноразовых адресов электронной почты, отказ от подписи commitили демонстрируют необычные закономерности в вкладах.
Основная цель нашей системы — обеспечить безопасную и надежную среду. Это достигается за счет динамической корректировки репутации пользователей на основе различных факторов, а также соблюдения требований конфиденциальности и ограничений различных реестров.
Для пользователя вычисляется внутренняя оценка репутации (по возможности присоединяется к реестру и учетной записи github), а также оценка вредоносности, используемая во время классификации анализируемого компонента, а также для более точного определения того, кто находится под публикацией компонента.
Были обнаружены доказательства злонамеренного поведения. Ну и что? Процесс ручной проверки
Текущий классификатор относит анализируемую версию компонента к одной из категорий «подтвержденная вредоносная», «вероятно вредоносная», «высокая степень риска», «низкая степень риска» или «невредоносная» на основе пороговых значений оценок, объединяющих результаты и репутацию пользователя/компонента. Классификация по категориям «высокого риска» или «вероятно вредоносного» приводит к ручной проверке и первому уведомлению. Категория «подтвержденная вредоносность» устанавливается после проверки вручную или когда доказательства совпадают с теми же доказательствами для предыдущей версии, которая была признана вредоносной.
Когда существует достаточно доказательств потенциального злонамеренного поведения, затронутым организациям выдается первое предупреждение (карантинное оповещение). Как упоминалось ранее, это может заблокировать установку или сборку программного обеспечения, которое зависит от помещенного в карантин компонента.
Это создает проблему во внутренней системе MEW. dashboard поэтому аналитики безопасности могут начать процесс ручной проверки компонента. У команды есть специализированные инструменты (песочница, деобфускаторы, дистрибутив для исследования вредоносного ПО, инструменты отчетности о вредоносном ПО) для быстрой оценки характера исследуемой версии компонента. Большая часть вредоносного ПО («анчоусы» или простые вредоносные компоненты) проверяется
Результат обзора заключается либо в безопасности , поэтому механизм автоматического анализа обнаружил ложное срабатывание, которое используется в качестве обратной связи с классификатором машинного обучения для изучения шаблона; или подтвержденный вредоносный, поэтому компонент ответственно раскрывается как вредоносный в публичном реестре после процедуры сообщения. Второе уведомление направляется затронутым организациям, которые, в свою очередь, могут вывести компонент из карантина или полностью заблокировать его в процессе обновления версии или в брандмауэре компонента, используемом во внутреннем реестре.
Этот параметр позволяет нам ежедневно анализировать десятки тысяч новых версий и выявлять десятки, которые, вероятно, являются вредоносными, а затем проверять их вручную. Помните из предыдущего эпизода, что один из десяти тысяч — это количество вредоносных компонентов, которые мы сейчас видим в дикой природе.
Отчетность в реестре
Мы обнаружили, что большинство общедоступных реестров, являющихся одной из опор инфраструктуры с открытым исходным кодом, предоставляют довольно ограниченные механизмы для сообщения о проблемах безопасности, в частности о вредоносных компонентах. Мы изо всех сил пытаемся улучшить базовую организацию процесса отчетности. Обычно мы получаем максимум электронное письмо от группы безопасности реестра, подтверждающее, что компонент был удален из реестра.
Иногда реестр подвергается злоупотреблениям, нарушающим условия его использования, но не вызывающим вредоносного поведения поставляемого программного обеспечения. Об этом также сообщается в реестр, но не доводится до сведения организаций с целью ограничения шума.
Будущая работа
Многие улучшения в настоящее время находятся в планах. Прежде всего, а общедоступный портал о состоянии компонентов ОС, особенно в отношении обнаруженных доказательств потенциальной вредоносности, в настоящее время находится в стадии разработки. Это задумано как скромный вклад в сообщество открытого исходного кода. Следите за обновлениями.
Еще одной продолжающейся разработкой является улучшение классификатор машинного обучения. MEW будет учиться на прошлых классификациях. Вектор результатов от детекторов двигателя, а также полученная оценка вредоносности и оценка репутации как для компонента, так и для издателя («найденные доказательства») используются в качестве входных данных для системы машинного обучения, которая обновляет модель классификатора. Выходная переменная — это просто подтверждение реестра о вредоносности компонента. Это кодовое название «Оракул» и поможет с более предварительнымcisКвалификатор e, разработанный так, чтобы быть надежным (высокая полнота, т.е. не пропускать вредоносные компоненты), но с меньшим количеством ложных срабатываний (не сообщать о безопасных компонентах как о вредоносных).
A показатель критичности будут добавлены критерии приоритетности, помимо принадлежности к множеству зависимостей клиентов и низкой репутации издателя. Понятно, что проекты с большим влиянием и значимостью следует рассматривать для анализа раньше. Мы не будем здесь изобретать велосипед и последуем Оценка критичности проекта с открытым исходным кодом.
Поддержка дополнительных экосистем находится в стадии разработки. В планах — широко распространенные технологии и инструменты, такие как PHP или плагины Jenkins.
Мы также изучаем, можно ли помочь процессу ручной проверки с помощью искусственного интеллекта, чтобы упростить анализ нескольких более сложных вредоносных компонентов.
В следующей и последней части этой серии: «Использование открытого исходного кода: чего ожидать от плохих парней», мы сосредоточимся на новейших способах, которые используют злоумышленники, чтобы сделать атаки более скрытными, трудными для обнаружения, более нацеленными на конкретные отрасли и более прибыльными. Будут ли с помощью этого транспортного средства осуществляться атаки с использованием программ-вымогателей? Как злоумышленники используют инструменты искусственного интеллекта для создания более сложных вредоносных программ? Подвержены ли риску самые популярные проекты? Это сделано для того, чтобы дать читателям представление об этой гонке вооружений и о том, чего ожидать в краткосрочной (вторая половина 2024 года) и среднесрочной перспективе (2025 год).
В заключение мы выскажем некоторые мысли о том, какие первые шаги сообщество могло бы предпринять, не слишком сильно меняя открытость мира с открытым исходным кодом. Например, более эффективный механизм сообщения о вредоносном ПО в публичные реестры и обмена свидетельствами о потенциально вредоносных компонентах с реестрами и сообществом стал бы небольшим шагом в правильном направлении к цели закрытия дверей для злоумышленников.
Вредоносное ПО в компонентах с открытым исходным кодом не должно нарушать огромные преимущества, которые сообщество открытого исходного кода принесло нашему обществу.
- [1] Наш сканер обнаруживает компоненты с открытым исходным кодом, на которые ссылаются анализируемые программные проекты, поэтому известен полный актуальный график зависимостей, по крайней мере, для проектов, которые сканируются регулярно. Xygeni OSS предоставляет API, который клиенты также могут использовать при внесении в белый список интересующего компонента, включая информацию об уязвимостях и вредоносных доказательствах.
- [2] Ограждение может нарушить сборку, если обнаружено условие, соответствующее проблемам безопасности. Результаты безопасности, такие как критическая и достижимая уязвимость или использование помещенного в карантин компонента, могут считаться достаточно серьезными, чтобы нарушить сборку уязвимого программного обеспечения.
- [3]При необходимости наши аналитики безопасности запускают компонент или сценарии его установки в изолированной среде. Однако MEW не выполняет динамический анализ, в первую очередь потому, что вредоносное поведение не всегда реализуется при целенаправленных атаках, а также из-за логики уклонения, которую злоумышленники используют для уклонения от динамического анализа.
- [4] Этому методу было присвоено название «Алгоритмы генерации зарегистрированных доменов» или RDGA, а также появились новые субъекты угроз, такие как так называемые Револьвер Кролик инвестировал около 1 миллиона долларов в 500 тысяч доменов, показав, насколько прибыльна индустрия киберпреступности.
