Это третий эпизод в серия статей о наиболее распространенных видах атак на цепочки поставок программного обеспечения: тех, которые злоупотребляют общедоступным реестром открытые источники программные компоненты. После анализа в предыдущем эпизоде «Анатомия вредоносных пакетов: каковы тенденции?«Как злоумышленники внедряют вредоносное поведение в новые или существующие опубликованные компоненты, мы готовы надеть противопожарные куртки и изучить, как мы можем успешно блокировать вредоносное программное обеспечение, доставленное таким образом, или, альтернативно, справиться с потенциально серьезным киберинцидентом, потому что мы приняли неправильный подход.
Большинство профессионалов, знающих о безопасности, имеют идеи о том, как справиться с этой угрозой. Мы слышали, как менеджеры по безопасности говорили без колебаний, что SCA Инструменты уже сообщают вам, когда версия пакета является вредоносным ПО. Или что они зависят от известных, тщательно проверенных программных компонентов, где любое вредоносное ПО будет быстро обнаружено и удалено. Они используют открытые второстепенные версии/версии исправлений для автоматического получения исправлений уязвимостей, и это правильный, рекомендуемый способ снизить риск в зависимости от открытого исходного кода, следуя «исправлять рано, исправлять часто»Принцип.
В этом выпуске мы рассмотрим, почему эти идеи ошибочны и как такие заблуждения способствуют популярности этого механизма атак и огромным рискам, которым подвергаются организации. Мы закончим тем, что работает, и какие усилия и ресурсы затрачены.
Распространенные заблуждения
В ходе нашего исследования безопасности программного обеспечения мы увидели развитие методов атак и широкий спектр идей от людей, заботящихся о безопасности. Организации часто неправильно понимают, что работает против этой угрозы, поэтому сначала мы рассмотрим, что не работает, и кратко изложим их в следующем, не исчерпывающем списке заблуждений.
Заблуждение №1: SCA инструменты уже сообщают о вредоносных компонентах
В самом деле! Но постфактум… Когда, вероятно, уже слишком поздно, если элемент был использован в сборке программного обеспечения, и злоумышленники уже закрепились в разработчике или CI/CD хост. Секреты могли быть украдены, дополнительное вредоносное ПО загружено и установлено, и, возможно, злоумышленник продвинулся вбок и уже получил доступ в другом месте.
Анализ состава программного обеспечения (SCA) инструменты были разработаны для выявления потенциальных известных уязвимостей. Современные инструменты отлично справляются с этой задачей, увеличивая отношение сигнал-шум, определяя, является ли уязвимость действительно достижимой или эксплуатируемой. Но они бесполезны против новых вредоносных программ. Представьте себе вредоносный компонент как уязвимость нулевого дня: только когда обнаруживается его вредоносное поведение, компонент сообщается в реестр, который после проверки группой безопасности подтверждается как вредоносный и удаляется из реестра [1].
В этот момент мир (включая SCAs) знает, что установка или использование компонента (или некоторых версий существующего компонента) не является хорошей вещью. Но это когда компонент недоступен из реестра. Знать, что у меня есть уязвимости в сторонних компонентах или даже компонентах, которые были классифицированы реестром как вредоносные, это хорошо, но, к сожалению, SCA или обычные инструменты аудита не помогают в этом контексте. Если SCA/инструмент аудита действительно может заранее определить, является ли компонент вредоносным, прежде чем он будет использован в вашей организации.
Помните: любое решение против вредоносных компонентов с открытым исходным кодом должно их обнаруживать. на лету, между публикацией компонента в реестре и моментом первого использования компонента (версии) в вашей организации. И это включает в себя переходные компоненты.
Заблуждение №2. Управление сценариями установки во время сборки предотвращает вредоносное поведение компонентов с открытым исходным кодом.
Различные менеджеры пакетов предлагают возможность запуска скриптов (включенных в архив компонентов). [2]), по законным причинам, таким как компиляция необходимых элементов на разных платформах, генерация кода или выполнение тестов, и мы все должны знать, что злоумышленники могут злоупотреблять ими, если в архив включены вредоносные сценарии или если злоумышленник может создать вредоносный файл. сценарий запускается вместо хорошего.
Зная это, мы можем настроить менеджер пакетов на игнорирование сценариев. Например, с помощью NPM –Ignore-scripts флаг (или свойство конфигурации в .npmrc файл) пропускает сценарии во время установки. Это может вызвать некоторые проблемы, поскольку запуск сценариев является обычным явлением во многих экосистемах: некоторые менеджеры пакетов даже не разрешают отключать выполнение сценариев (подсказка: подсказка «Какие менеджеры пакетов не позволяют отключать выполнение скриптов установки?» в вашем любимом ИИ). Но в целом это не защищает (нам нужно обеспечить, чтобы конфигурация отключения пропуска была повсюду).
А когда вредоносное поведение сосредоточено не в сценариях установки, а в программном обеспечении, исполняемом во время выполнения, этот вариант сам по себе нас не защитит.
Заблуждение №3: Закрепление версии предотвращает установку вредоносных компонентов.
Существует компромисс между ранним и частым исправлением открытые версии (позволяя менеджеру пакетов автоматически устанавливать новые обновления, когда они доступны для исправлений безопасности) и закрепление версии (имея все прямые и транзитивные зависимости для программного обеспечения в фиксированной версии). Принципы безопасности упрямы, а иногда и противоречивы, как это происходит с принципом «устанавливайте исправления раньше, обновляйте часто» и «К обновлению нельзя относиться легкомысленно». Некоторые менеджеры пакетов автоматически обновляют диапазоны серверов рекомендуемым способом. Отлично, если вы тоже хотите получать вредоносные обновления! Да, компоненты необходимо обновлять, чтобы как можно скорее получать исправления безопасности, закрывающие уязвимости, но… никогда не позволяйте менеджеру пакетов делать это автоматически.
Заблуждение №4: Использование доверенных компонентов безопасно. Любая вредоносная версия будет незамедлительно найдена, раскрыта и удалена.
Почему компонент заслуживает доверия? Возможно, потому что он очень популярен, с большим количеством глаз, ищущих уязвимости, большим количеством участников для обслуживания, с несколькими основными сопровождающими, которые старательно проверяют все pull requests. Реальность совсем иная. Некоторые важные компоненты поддерживаются одним неоплачиваемым разработчиком. Широко используемые фреймворки несколько постоянных участников, с быстро уменьшающимся количеством commits на одного сопровождающего (популярные проекты имеют длинный хвост участников, которые выполняют некоторые проезжающие мимо commit и никогда не вернусь). А популярных проектов с одним сопровождающим предостаточно.
Представьте, что вы говорите «О, мы используем Spring Boot/Angular/React/PyTorch/официальные базовые образы Docker, поэтому риск, о котором вы говорите, довольно низок». Возможно, это правда, мы, поставщики систем безопасности, постоянно нагнетаем панику и вмешиваемся в работу команд разработчиков, чтобы снизить спорный риск, — это нонсенс. У вас может возникнуть соблазн перейти к параграфу принятия риска (в следующем разделе), и все готово. К сожалению, самые популярные компоненты являются мишенью для злоумышленников, например популярный Библиотека PyTorch подверглась атаке в прошлом.
«Быстро найдено, раскрыто и удалено». Удаление нового вредоносного компонента из общедоступного реестра занимает несколько дней. Реестры осторожно относятся к удалению версии компонента во благо. По нашему опыту, согласно сообщению с нашей стороны, среднее время, необходимое для удаления из реестра затронутой версии, составляет 39 часов, то есть более полутора дней. Существуют вредоносные компоненты, которые находятся в реестре через неделю после нашего первоначального сообщения перед удалением. А в некоторых случаях компонент удаляется только после того, как жертва или компания, занимающаяся реагированием на инциденты, сообщит об инциденте, связанном с компонентом.
Что НЕ работает против вредоносных компонентов
Любой неспецифический подход потерпит неудачу. Это факт, вы не обеспечиваете эффективных мер противодействия риску, связанному с этой угрозой.
Традиционном SCA Инструменты сообщают об известных вредоносных программах, но имеют большое окно экспозиции. Если они не выполняют упреждающее обнаружение вредоносных программ с принудительной блокировкой вредоносных компонентов, они не работают против этой угрозы.
Отключение сценариев установки может помочь, но его необходимо применять везде, где необходимо установить компонент. То же самое и с закреплением версий, поскольку версии не могут быть навсегда закреплены из безопасного начального состояния.
Предполагать, что популярным компонентам уделяется достаточно внимания и их нельзя внедрить в непреднамеренное поведение при атаке на цепочку поставок без почти мгновенного обнаружения для предотвращения любого ущерба, наивно и рискованно. Вы же не хотите жить на грани, не так ли?
Если вы остановитесь на этом этапе, то принятие риска единственное, что вы можете сделать: Это деcision, который необходимо задокументировать в вашей модели угроз/оценке риска, включая обоснование принятия риска и его потенциальных последствий. Повысьте осведомленность, сообщив об этом руководству и другим соответствующим сторонам. Некоторые непредвиденные обстоятельства можно спланировать, когда вредоносный компонент установлен или включен в ваше программное обеспечение, но это сложно, поскольку у злоумышленников есть много путей, по которым они могут пойти. Подробности атаки на цепочку поставок, основанной на использовании вредоносного компонента, радикально изменят публичное раскрытие инцидента, которое, вероятно, является обязательным в соответствии с нормативной базой вашей организации. Вы также можете обратиться компенсирующее управление or трансферный риск например, со страховкой.
Однако существуют средства контроля, которые устраняют угрозу, и их следует учитывать, если вы не удовлетворены принятием риска. Пожалуйста, читайте дальше.
Что работает против атак с использованием вредоносных компонентов
Обработка твердых версий
Закрепление версий с помощью контролируемых и информированных обновлений версий — это способ сбалансировать необходимость удаления уязвимостей без получения вредоносного ПО. Но помните заблуждение №3: одного закрепления версий недостаточно для блокировки вредоносного кода, поступающего из новых версий, поскольку в будущем вам потребуется обновлять версии в любой прямой или косвенной зависимости. В этот момент вам нужны достаточно веские доказательства того, что все модифицированные версии не содержат вредоносного ПО.
Раннее предупреждение
Одним из подходов к проблеме вредоносных компонентов является система раннего предупреждения (называемая здесь Раннее предупреждение о вредоносных программах или MEW), где опубликованные новые версии (для новых или существующих компонентов) анализируются механизмом обнаружения, который при обнаружении достаточного количества доказательств может классифицировать новую версию как потенциально вредоносную.
Здесь важна автоматизация, поскольку невозможно вручную просматривать все новые компоненты при текущей скорости публикации. Таким образом, механизм обнаружения должен сочетать в себе различные методы, возможно, включая статический, динамический анализ и анализ возможностей, репутацию пользователя и данные, полученные из несоответствий между метаданными компонента и содержимым архива или между архивом и исходным репозиторием, в котором предположительно находится компонент. происходит от.
Eсть темная зона между временем публикации и моментом анализа содержимого компонента движком, но не должно превышать нескольких минут. Схему можно изменить, например, дождавшись анализа новых компонентов, прежде чем разрешить их установку и использование в сборке программного обеспечения. pipelines или анализировать их по требованию, когда это необходимо. Компонент данной версии является неизменяемым. [3], поэтому его нужно проанализировать только один раз.
Полная автоматизация невозможна, и необходима проверка безопасности на наличие потенциально вредоносных компонентов. Остерегайтесь сторонников цифровой панацеи: ИИ и машинное обучение недостаточно развиты, чтобы оставить последнее слово, когда дело доходит до подтверждения наличия вредоносного ПО в подозрительном компоненте. Конечно, машинное обучение играет ключевую роль в механизме обнаружения при классификации входного компонента на основе собранных необработанных доказательств, но как только компонент помещается на карантин, последнее слово остается за ручной проверкой командой безопасности, имеющей опыт работы с вредоносными компонентами. Это подтверждает наличие потенциального вредоносного ПО или переклассифицирует его как безопасное. И период времени находится в диапазоне часов.
Реестр сообщает о вредоносной версии/компоненте; затем реестр проводит проверку для подтверждения и приступает к публичному раскрытию и удалению из реестра. Некоторые реестры хранят пакет ценных бумаг. Временной диапазон здесь — дни или недели с момента публикации, то есть «время ожидания' или 'окно экспозиции' для большинства вредоносных компонентов.
Можно ли узнать, является ли версия компонента вредоносной?
Итак, для раннего предупреждения нам необходимо дать удовлетворительный ответ на следующий вопрос: Как я могу узнать, что библиотека или пакет (не) вредоносны? Как собрать достаточно доказательств злонамеренного поведения? Это возможно, но сложно, поскольку злоумышленники прикладывают немало усилий, чтобы избежать обнаружения. Существуют разные подходы, каждый из которых имеет плюсы и минусы.
Статический анализ может проверять все пути выполнения, проверять методы, используемые злоумышленниками, без запуска компонента, а также выполнять задачи предварительной обработки, такие как деобфускация или дешифрование. Поскольку злоумышленники пытаются скрыть свое злодеяние, попытки запутывания действительно являются свидетельством наличия вредоносного ПО (но обратите внимание, что легальные компоненты запутывают код для сохранения интеллектуальной собственности, что противоречит «с открытым исходным кодом»). Только меньшинство очень сложных атак с сильным запутыванием нуждаются в песочнице, но такое сильное запутывание является явным признаком вредоносности. Обратите внимание, что обычные SAST инструменты были разработаны для непреднамеренных уязвимостей, а не для злонамеренных действий, таких как бэкдоры.
Динамический анализ запускает компонент и проверяет ответ, инструментируя среду выполнения, обычно предоставляя изолированную среду. Вредоносное поведение, запускаемое при определенных условиях, может остаться незамеченным: обратите внимание, что вредоносное ПО может использовать такие методы уклонения, как Уклонение от виртуализации/песочницы активироваться только тогда, когда он не находится под пристальным вниманием, а также является явным признаком вредоносной активности для любого механизма статического анализа.
Анализ возможностей учитывает, что делает компонент: где он подключается, к каким файлам обращается, какие команды или программы запускаются, какие операции ввода-вывода выполняются с терминала или устройства или какие системные вызовы вызываются. Эти отпечатки поведения можно сравнить (для существующего компонента) между версиями, поэтому при обнаружении неожиданного поведения эти доказательства могут вызвать подозрения в потенциальной вредоносной активности, внедренной в новую версию. Этот подход соответствует этапам сортировки, которым следуют аналитики безопасности при столкновении с потенциальным вредоносным ПО: проверка с использованием струны или подобные инструменты. Этот подход обнаруживает вредоносное поведение независимо от условий запуска и работает, когда исходный код недоступен.
Анализ контекста собирает информацию о том, как и кем был опубликован компонент. В кампаниях злоумышленников часто используются новые учетные записи пользователей, не подлежащие какой-либо строгой проверке. Отслеживание прошлой активности может дать представление о конкретном пользователе, в основном об аномалиях, которые могут указывать на потенциальную угрозу компрометации. Репутацию так трудно заработать и так легко потерять! Пользователь, не участвовавший в прошлой деятельности, нейтрален, но карма преследует злонамеренных. Хактивистов или обычных пользователей, у которых украли учетные данные публикации, следует тщательно отслеживать.
Другая контекстная информация — это любые несоответствия между исходным репозиторием, предположительно использованным для создания архива компонента, и содержимым самого архива. А также следовать передовым практикам, таким как создание тегов или выпусков в исходном репозитории, соответствующих версиям компонента, опубликованным в общедоступном реестре. Когда исходный репозиторий в определенном commit помечен как выпуск, а затем внезапно одна версия не соответствует ему, это само по себе является убедительным доказательством того, что компонент может быть испорчен: злоумышленник мог скомпрометировать учетную запись, используемую для публикации компонента, но не имеет прав на запись в исходном коде хранилище). Многие атаки обычно обнаруживаются с помощью этих правил: например, Атака на Леджер можно было легко обнаружить по этим направлениям. Таким образом, контекстный анализ выявляет такие аномалии в издательском процессе.
Межсетевой экран зависимостей
Другой подход — иметь полный белый список компонентов для всех графов зависимостей, используемых в вашем программном обеспечении, чтобы в любой сборке pipeline В вашей организации можно устанавливать и использовать только утвержденные версии компонентов. «брандмауэр» обеспечивается с помощью внутреннего реестра, в котором хранятся архивы разрешенных версий компонентов (кэшируются или проксируются). Обратите внимание, что любой белый список не будет работать, если у вас нет технологии, позволяющей классифицировать любую новую версию как достаточно безопасную и добавлять ее в белый список.
Обратите внимание, что раннее предупреждение (быстрое обнаружение как можно скорее после публикации новой версии) необходимо сочетать с каким-то способом превентивного использования этой информации для блокировки компонента, влияющего на сборку. pipelineили машины разработчиков [4]. Мы называем это «брандмауэр зависимостей»: карантинный механизм защиты автоматизированных сборок от вредоносных пакетов. Внутренние пакеты и реестры образов хороши для защиты организаций от внешнего зла, но для того, чтобы карантин стал эффективным, необходимы достаточно веские доказательства.
Песочница во время выполнения
Альтернативный подход к обнаружению во время публикации — анализ поведения во время выполнения. Идея состоит в том, чтобы уловить ожидаемое поведение программного обеспечения и обнаружить (или заблокировать) любые обнаруженные аномалии. Этот образ действий имеет проблему, связанную с необходимостью оснащения среды выполнения для мониторинга или блокировки, и это многообещающая идея, которая будет добавлена в арсенал механизмов защиты от вредоносного компонента-вредителя.
Разработка комплексной стратегии
Рекомендуемая стратегия должна сочетать различные методы в процессе разработки программного обеспечения, контролируя обновления версий для блокировки входящих вредоносных компонентов. Мы должны обеспечить закрепление версий, чтобы избежать автоматического заражения при обновлении версий для получения исправлений важных уязвимостей; быстрая и эффективная оценка прямых и косвенных зависимостей во время обновлений версий, чтобы получить достаточно доказательств того, что они не заражены вредоносным ПО. Сборки программного обеспечения, зависящие от известных вредоносных компонентов, должны быть заблокированы. И все должно быть исполнено.
По возможности используйте привязку версий, поскольку это делает сборки более воспроизводимыми. Закрепление версии с помощью контролируемых, утвержденных вручную обновлений версии. и с помощью вспомогательной технологии, должен оценить, содержит ли обновление вредоносное ПО или нарушает работу программного обеспечения, и согласовать обновление для устранения уязвимостей с предотвращением заражения вредоносным ПО. В этом могут помочь инструменты, которые (1) расставляют приоритеты, какие уязвимости действительно важны (доступны и могут быть использованы, с высоким риском стать целью злоумышленников), (2) выбирают целевые версии, которые совместимы с текущим использованием компонентов и не нарушают программного обеспечения, (3) выбирать целевые версии, которые не содержат вредоносного поведения, и (4) делать обновление версий для прямых и косвенных зависимостей простым делом, предлагая изменения в файлах манифеста, которые можно быстро утвердить. Для шага (3) необходима конкретная информация о вредоносных компонентах как можно ближе ко времени их публикации.
Этот процесс обновления зависимостей должен быть исполнение и проверено во всех местах. Процесс должен быть задокументирован, и все вовлеченные стороны должны быть обучены, так как часто разработка и сборка/развертывание программного обеспечения осуществляется внешними силами. CI/CD pipelines должны быть изменены соответствующим образом, чтобы автоматизация не позволила вредоносной косвенной зависимости проскользнуть в сборку: guardrails рекомендуется блокировать сборку, если имеется достаточно доказательств потенциального вредоносного ПО в зависимости.
Если в вашей организации есть внутренний реестр, действующий как прокси-сервер безопасности для хранения разрешенных версий компонентов, вам необходимо получить информацию о вредоносных компонентах (помимо других критериев) для проверки запрошенного компонента перед добавлением его в список разрешенных.
Безопасное использование программного обеспечения с открытым исходным кодом непросто, и фактор вредоносного ПО необходимо полностью учитывать, приложив аналогичные усилия к устранению уязвимостей.
Последнее замечание: Источник происхождения, в форме аттестаций программного обеспечения, генерируемых во время сборки компонента, является еще одним ключевым моментом в усилиях по отслеживанию артефакта (архива компонента) с исходными кодами и процессом сборки, в результате которого он был создан. Обратите внимание, что эта связь между исходным снимком + средой сборки и соответствующим программным артефактом (подписанным доверенной системой сборки) сама по себе не предотвращает отсутствие вредоносного поведения в компоненте, но усложняет злоумышленникам внедрение вредоносного ПО. . А сделать проверку происхождения общим требованием для использования компонентов с открытым исходным кодом займет много времени, и только недавно добавлен в NPM. Обеспечение защиты от несанкционированного доступа этих надежных систем сборки и развертывания или включение обнаружения любого вмешательства в сборку — это другая история, выходящая за рамки этой статьи.
Далее
Следующий эпизод Вредоносные пакеты с открытым исходным кодом: подход Xygeni представит стратегию, которой мы следуем в Xygeni, для наших Раннее предупреждение о вредоносных программах (MEW) система. Новые версии пакетов в общедоступных реестрах пакетов и образов сканируются, и доказательства получаются с использованием комбинации статического, динамического анализа возможностей и контекстного анализа. Доказательства в сочетании с репутацией пользователей и историей изменений в репозиториях исходного кода позволяют полностью автоматически классифицировать компонент по категориям высокого риска и, возможно, вредоносным. Система учится на прошлых данных, собранных из пакетов, чтобы свести ложные срабатывания к минимуму.
Подписавшиеся организации получают предупреждающее уведомление для компонентов, которые они используют, прямо или косвенно, когда вредоносная версия классифицируется. Затем наши аналитики проводят ручной анализ, который подтверждает или отвергает классификацию. В случае подтвержденного вредоносного ПО уведомляется общедоступный реестр, чтобы он мог выполнить собственный анализ и, как правило, удалить вредоносную версию или предпринять дополнительные действия, такие как блокировка или удаление соответствующей учетной записи пользователя.
Мы объясним, как мы помогаем NPM, PyPI, GitHub и другим ключевым инфраструктурам в экосистеме с открытым исходным кодом сократить время существования нового опубликованного вредоносного компонента, который остается активным до тех пор, пока не будет подтверждено вредоносное ПО и удалено из реестра. И как организации могут извлечь выгоду из системы MEW, чтобы иметь гораздо лучшую защиту от атак в цепочке поставок программного обеспечения с использованием компонентов с открытым исходным кодом.
- [1] В любом случае, пользователям компонента необходимо проверить, кэширован или зарегистрирован ли где-нибудь архив компонента, например, во внутреннем реестре, чтобы устранить болезнь.
- [2] Упакованный компонент включает манифест, в котором объявляется его содержимое и метаданные, исходный или скомпилированный код, сценарии установки и дополнительные элементы, такие как наборы тестов, в соответствии с форматом упаковки и обычно в сжатой форме. Это называется «архив компонента».
- [3] Даже если злоумышленник может изменить опубликованный компонент из-за нарушения в самом реестре, старый добрый криптографический дайджест может обнаружить любые изменения в архиве после завершения анализа.
- [4] Помните, что некоторые вредоносные компоненты запускаются во время установки, поэтому это может повлиять на узлы разработчиков, которые невольно запускают «npm install X» с X — вредоносным компонентом.
