Алексей Пешик, инженер-эксперт Security Vision

Екатерина Гайнуллина, инженер по информационной безопасности

Цепочка поставок программного обеспечения (Software Supply Chain) — это сложная структура, которая включает в себя разные этапы, начиная с разработки программного кода и заканчивая доставкой готовых продуктов конечным пользователям. Важность цепочки поставок программного обеспечения заключается в том, что она является фундаментом цифровой экономики.

Программное обеспечение играет важную роль в современной жизни, будь то в бизнесе, государственных организациях или в повседневной деятельности частных лиц. Благодаря программному обеспечению мы получаем доступ к информации, ресурсам и услугам, и оно является ключевым фактором в технологическом развитии. Цепочка поставок обеспечивает надежность и доступность программных продуктов для конечных пользователей, что критически важно для бизнес‑процессов, инноваций и развития технологий. Однако, цепочка поставок программного обеспечения также стала объектом увеличивающегося внимания со стороны злоумышленников. Атаки на эту цепочку могут иметь серьезные последствия, включая уязвимости в программных продуктах, подмену компонентов, внедрение вредоносного кода и другие виды кибератак. Поэтому безопасность и надежность цепочки поставок программного обеспечения стали приоритетными вопросами в области кибербезопасности. Управление рисками и безопасностью в цепочке поставок становятся критически важными, и разработчики, поставщики и пользователи должны сотрудничать, чтобы обеспечить её надежную работу.

OSC&R — это открытая структура, предоставляющая комплексный, системный и действенный способ понимания поведения и методов атакующих. Создана при участии таких компаний как как Check Point, Fortinet, GitLab, Google, Microsoft, OWASP.

Так же как и MITRE ATT&CK, OSC&R организована в четком и структурированном виде тактик, техник и процедур (TTP), используемых злоумышленниками. Однако OSC&R является первой и единственной матрицей, которая фокусируется специально на атаках на цепочку поставок программного обеспечения. Она охватывает широкий спектр векторов атак, включая уязвимости в библиотеках и компонентах сторонних разработчиков, атаки на системы сборки и развертывания, а также компрометированные или злонамеренные обновления программного обеспечения. Как пример атаки с вредоносными пакетами, где выстраиваются килчейн из букета тактик — Inititial access, Execution, defence evasion, collection, impact, описывается в одном из отчетов исследователя безопасности из Sonatype — Ax Sharma, где раскрываются обнаруженные вредоносные пакеты в реестре PyPI, в том числе aptx, которые могут устанавливать троян Meterpreter, замаскированный под pip, и раскрывается исследование о новых вредоносных пакетах, обнаруженных в реестре PyPI, включая aptx, который может установить троян Meterpreter, замаскированный под pip, удалить системную утилиту netstat и подделать файл SSH authorized_keys.

Названный в честь популярного аудиокодека, разработанного компанией Qualcomm и используемый во многих Bluetooth‑устройствах (Привет различным беспроводным девайсам для прослушивания музыки), aptx в итоге оказался не единственной новой угрозой, обнаруженной на PyPI.

Среди других вредоносных пакетов — httops и tkint3rs. Их объединяет интересная особенность, направленная на введение людей в заблуждение с помощью специально придуманных имен. Как отмечает Sharma, в реальности же httops и tkint3rs — не что иное как это заведомо неправильное написание https и, соответственно, tkinter Python‑интерфейса.

При ближайшем рассмотрении инженеры Sonatype обнаружили, что в aptx есть закладка setup.py, которая способна создать двоичный файл ELF с именем./pip/pip. Этот двоичный файл содержит троян Meterpreter, сгенерированный с помощью Metasploit, инструмента для тестирования на проникновение, и позволяет злоумышленнику получить shell‑доступ к зараженной машине. Чтобы системному администратору было сложнее отслеживать активные соединения, setup.py также удаляет netstat, хотя на самом деле является большим триггером для аналитиков безопасности, если он есть в инфраструктуре.

В своем ежемесячном отчете за январь 2023 года Malware Monthly, а именно исследователи Sonatype раскрывают подробности о десятках других вредоносных пакетов, найденных в PyPI, и сотнях новых вредоносных пакетов в реестре npm.

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

Еще одна новая тактика, применяемая в последнее время, — это «Mutant RAT (remote access trojan)», которые используют многоступенчатую полиморфную полезную нагрузку, меняющуюся при каждом запуске бинарного файла, чтобы избежать обнаружения. В ряде случаев такие RAT‑мутанты объединяли возможности троянов удаленного доступа и похитителей информации для получения доступа к данным буфера обмена или информации о кошельке.

В случае с npm компания Sonatype выявила пакеты, которые, хотя и не представляли непосредственной угрозы, должны были считаться вредоносными. В частности, более 33 тыс. пакетов были опубликованы под именем «infinitebrahmanuniverse» и с использованием префикса «nolb‑» с единственной очевидной целью — создать зависимость от любого другого пакета npm. По мнению Sonatype, это выводит проблему «ада зависимостей» на совершенно другой уровень. Действительно, злоумышленник может создать вредоносный пакет, зависящий от некоторых из этих пакетов nolb‑, для проведения атаки типа «отказ в обслуживании» на канал загрузки компании и потребления избыточных ресурсов.

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

SLSA vs OSC&R

SLSA (Supply‑chain levels for software artifacts) и OSC&R (Open Source Cybersecurity Readiness) — это два различных подхода, но они могут быть взаимосвязаны и использоваться в совокупности для обеспечения безопасности цепочки поставок программного обеспечения.

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

OSC&R — это фреймворк, предоставляющий комплексный и системный способ понимания методов и техник атакующих, направленных на компрометацию цепочки поставок программного обеспечения. OSC&R помогает анализировать и понимать поведение атакующих, оценивать цели атаки и текущую фазу атаки.

В то время как SLSA фокусируется на оценке целостности программных артефактов, OSC&R предоставляет инструменты для анализа методов атак и поведения злоумышленников. Их совместное использование может обеспечить более полное понимание и безопасность цепочки поставок программного обеспечения. OSC&R может помочь идентифицировать угрозы, а SLSA — оценить, насколько надежны программные компоненты, используемые в цепочке поставок.

Основные особенности и преимущества OSC&R:

  1. Охват широкого спектра векторов атак: OSC&R охватывает множество векторов атак, включая уязвимости в сторонних библиотеках, атаки на системы сборки и развертывания, а также компрометированные или злонамеренные обновления программного обеспечения.

  2. Уязвимости в сторонних библиотеках: OSC&R предоставляет понимание и помощь в выявлении уязвимостей в широко используемых сторонних библиотеках, на которые часто направлены атаки.

  3. Атаки на цепочку поставок на этапе сборки и развертывания: Фреймворк помогает организациям понимать и уменьшать риски, связанные с компрометацией систем сборки и развертывания, обеспечивая целостность цепочки поставок программного обеспечения.

  4. Компрометированные или злонамеренные обновления программного обеспечения: OSC&R обнаруживает и предотвращает атаки, исходящие от обновлений программного обеспечения, обеспечивая безопасность цепочки поставок.

  5. Действенные понимания угроз: OSC&R предоставляет ценные и объективные понимания цели атаки и текущей ее фазы. Он категоризирует атаки по степени серьезности, воздействию и вероятности возникновения. Эта информация упрощает коммуникацию в области безопасности между организациями, обеспечивает полную видимость покрытия и дает возможность командам безопасности эффективно определить приоритеты в реагировании.

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

  7. Облегчение реагирования на инциденты и форензику: В случае инцидентов или нарушений, пайплайн‑список материалов (PBOM) служит ценным ресурсом для реагирования на инциденты и проведения форензических исследований. Путем обладания всесторонним представлением о цепочке поставок программного обеспечения и связанных с ней компонентах, организации могут быстро выявить источник атаки, проследить ее воздействие и предпринять соответствующие меры.

  8. Содействие непрерывному улучшению: PBOM способствует культуре непрерывного улучшения. Путем регулярного анализа и обновления пайплайн‑списка материалов, PBOM устанавливает новый стандарт для безопасности цепочки поставок программного обеспечения, обеспечивая разработчикам большую видимость в атаки на цепочку поставок программного обеспечения.

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

При обнаружении уязвимости в каком‑либо компоненте гораздо проще обновить зависимости и создать новую сборку приложения, поскольку процесс сборки автоматизирован. Например, можно выполнить поиск в документах, созданных при сборке, и выяснить, где применяется log4j или какие‑то другие интересные закладки как в кодеках, а также какие его версии используются. Затем можно обновить версии зависимостей в затронутых приложениях и запустить сборку снова. Таким образом, проблемы могут быть устранены в течение нескольких минут после первого уведомления.

Если использовать более улучшенные версии фреймворка SLSA, то они добавляют дополнительные гарантии и точки контроля для обеспечения более централизованного надзора и воспроизводимости. Это означает, что предыдущие релизы могут быть обновлены и пересобраны, если клиент по каким‑либо причинам не может перейти/обновиться на последний релиз.

Что такое PBOM?

PBOM (Pipeline Bill of Materials) — это подход, охватывающий весь цикл разработки программного обеспечения, начиная с дизайна и заканчивая производством. Он выходит за рамки списка компонентов, предоставленных SBOM (Software Bill of Materials), и оценивает этапы, на которых могут возникнуть атаки. Этот комплексный подход помогает организациям выявлять потенциальные уязвимости и проактивно предотвращать атаки на протяжении всего процесса разработки программного обеспечения.

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

Преимущества PBOM по сравнению с SBOM:

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

  2. Проактивное управление рисками: Анализ всей цепочки поставок через PBOM позволяет командам безопасности выявлять потенциальные уязвимости на ранних этапах процесса разработки и внедрять соответствующие меры безопасности. Этот проактивный подход снижает риск введения уязвимостей в цепочку поставок программного обеспечения.

  3. Интеграция с процессами безопасности: PBOM может легко интегрироваться с существующими процессами безопасности, такими как моделирование угроз, управление уязвимостями и реагирование на инциденты. Путем включения PBOM в эти процессы организации улучшают свою способность обнаруживать и реагировать на атаки на цепочку поставок, обеспечивая надежную стратегию безопасности.

Примеры использования PBOM:

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

  2. Выявление компрометированных систем сборки и развертывания: пайплайн‑список материалов позволяет организациям выявлять и предотвращать атаки на системы сборки и развертывания. Анализируя всю цепочку, организации могут выявлять аномалии, попытки несанкционированного доступа или подозрительное поведение, которое может указывать на компрометацию.

  3. Обеспечение безопасности обновлений программного обеспечения: PBOM предоставляет видимость в процесс обновления программного обеспечения, что позволяет организациям проверять целостность обновлений и выявлять потенциальные риски. Путем проверки каждого этапа процесса обновления организации могут предотвращать распространение компрометированных или злонамеренных обновлений.

Длительное использование SBOM в программной индустрии приводит к тому, что большая часть атак на цепочки поставок программного обеспечения переходит на второй план. Теперь PBOM предлагает новый стандарт безопасности цепочки поставок ПО. Он обеспечивает командам DevOps полную видимость атак на цепочки поставок ПО. Сюда входят исходный код, конвейер, артефакты, образы контейнеров, активы времени выполнения и приложения. Кроме того, ведется непрерывный мониторинг изменений безопасности в среде. Это гарантирует, что цепочка поставок ПО не отклонится от своего первоначального безопасного состояния. Более того, PBOM предоставляет четкие и действенные стратегии исправления ситуации. Они включают в себя список приоритетных рисков и рекомендации, основанные на контексте и бизнес-целях компании. В экосистеме разработки, требующей одновременно скорости и безопасности, PBOM минимизирует поверхность атаки, не препятствуя гибкости разработчиков. Это позволяет предотвратить атаки на цепочку поставок ПО, не замедляя при этом разработку.