По мере того, как разработка программного обеспечения продвигается по жизненному циклу цепочки поставок программного обеспечения, этап упаковки становится ключевым моментом, преобразующим исходный код в исполняемые артефакты, подготовленные для распространения. Однако этот критический этап не застрахован от уязвимостей, что делает его основной мишенью для злоумышленников, стремящихся подорвать целостность и безопасность программного обеспечения. В этом сообщении блога рассматриваются распространенные угрозы, которые могут возникнуть на этом этапе, и излагаются эффективные стратегии по их смягчению. Этот контент является продолжением серии наших блогов, посвященных изучению software supply chain security через SDLC.
Этап пакета в жизненном цикле разработки программного обеспечения
Этап упаковки жизненного цикла цепочки поставок программного обеспечения включает в себя процесс упаковки и подготовки программного обеспечения для распространения среди пользователей. Этот этап включает в себя создание установочных пакетов, управление зависимостями и создание метаданных для программного обеспечения.
Угрозы целостности сборки — это уязвимости, которые могут позволить злоумышленникам внести несанкционированные изменения в программное обеспечение во время процесса упаковки. Эти угрозы могут быть внедрены различными методами, такими как компрометация реестра пакетов, использование уязвимостей в инструментах упаковки или манипулирование сторонними зависимостями.
Полная зависимость от компонентов с открытым исходным кодом в современном программном обеспечении сделала этот этап наиболее частымSCA target. Внедрение скрытого вредоносного ПО в популярный компонент с открытым исходным кодом — мечта многих киберпреступников. Вот почему более За 245,000 год было обнаружено 2023 XNUMX вредоносных пакетов..
Примеры Software Supply Chain Security Угрозы на стадии упаковки
Использовать скомпрометированный пакет
Это относится к развертыванию или использованию пакета программного обеспечения, который был подделан или изменен злоумышленником.
Это может произойти после того, как пакет покинул официальный реестр пакетов, либо через прямой доступ к системе пользователя, либо с помощью тактики социальной инженерии, которая обманом заставляет пользователя загрузить или установить вредоносный пакет. Примером этого вектора является Просматривать Typosquatting Атака.
Злоумышленник, стремясь скомпрометировать системы Linux и Mac, проник в процесс разработки популярной библиотеки Node.js под названием Browserify. Злоумышленник внедрил вредоносный код в исходный код проекта, намереваясь распространить его через реестр пакетов NPM. Как только испорченный пакет Browserify был загружен в NPM, ничего не подозревающие разработчики загрузили и установили его, полагая, что это законная версия. Вредоносный код, встроенный в пакет, будет работать бесшумно, ставя под угрозу целостность зараженных им систем. Это может привести к краже данных, нестабильности системы или даже удаленному доступу злоумышленника.
Реестр скомпрометированных пакетов
Скомпрометированный реестр пакетов — это хранилище программного обеспечения, в которое проник злоумышленник, получивший несанкционированный доступ к административному интерфейсу или инфраструктуре реестра.
Это позволяет злоумышленнику модифицировать или заменять законные пакеты программного обеспечения вредоносными, которые затем могут быть распространены среди ничего не подозревающих установленных пользователей. Примером такого типа угроз является Атака на зеркала пакетов: Исследователь с целью продвижения программного обеспечения с открытым исходным кодом взломал несколько популярных реестров пакетов, включая Maven Central, NPM и RubyGems. Получив доступ к этим реестрам, исследователь смог создать зеркала и копии исходных репозиториев, что предоставило разработчикам удобную альтернативу для загрузки пакетов.
Однако эти зеркала преследовали зловещую цель. Скомпрометированные зеркала служили исследователям каналами для распространения вредоносных пакетов. Эти пакеты заменили законные, незамеченные основными реестрами, а ничего не подозревающие разработчики неосознанно загрузили и установили их. После установки эти вредоносные пакеты высвободили свою полезную нагрузку, выполняя произвольный код, похищая конфиденциальные данные или нарушая операции.
Загрузить измененный пакет
Злоумышленник загружает в репозиторий или канал распространения модифицированный пакет, содержащий вредоносный код или полезные данные. Это можно сделать путем изменения исходного кода, упаковки или метаданных пакета.
Одной из наиболее известных угроз такого типа была Атака CodeCov в 2021 году. Злоумышленник, стремящийся скомпрометировать программные проекты, использует CodeCov, популярный метод непрерывной интеграции и непрерывной доставки (CI/CD) использовал украденные учетные данные для получения несанкционированного доступа к хранилищу Google Cloud Storage (GCS) проекта. Получив доступ к хранилищу GCS, злоумышленник загружал вредоносный артефакт, измененную версию пакета CodeCov, которая затем распространялась среди пользователей через службу CodeCov. Ничего не подозревающие разработчики, полагаясь на функцию автоматического обновления, загружали и устанавливали вредоносный пакет, полагая, что он является легитимным. После установки вредоносный код работал бы незаметно, нарушая целостность зараженных им систем. Это могло привести к краже данных, нестабильности системы или даже удаленному доступу для злоумышленника.
Атаки на реестры пакетов настолько распространены, что некоторые шаблоны атак получили названия:
In TyposquattingЗлоумышленник загружает в реестр несколько вредоносных пакетов с небольшими опечатками или именами, похожими на законные и популярные пакеты, в надежде, что разработчики неправильно напишут предполагаемое имя пакета, указав вредоносное. Часто вредоносный пакет маскируется под законный и проходит незамеченным, увеличивая вероятность быть атакованным при наблюдении за звездами.
Путаница зависимостей использует способ, которым некоторые менеджеры пакетов разрешают запрошенные пакеты из нескольких реестров. Когда организация использует внутренние компоненты, опубликованные во внутреннем реестре, злоумышленник, знающий об этом, может опубликовать вредоносный компонент с тем же именем в общедоступном реестре. Если имя, используемое для внутреннего компонента, не ограничено областью действия, некоторые менеджеры пакетов будут получать вредоносный компонент вместо внутреннего.
Благодаря более чем Троянские пакетыКиберпреступник маскирует вредоносное ПО под полезный валидный код. Это может использовать настоящий автор или участник, который предложит себя поддерживать пакет. Это также известно как Взлом пакета. Злоумышленники использовали множество методов для взлома существующего пакета, например Поглощение домена где заброшенный домен с истекшим сроком действия был захвачен злоумышленником, который воссоздал старый адрес электронной почты сопровождающего и выполнил восстановление пароля, чтобы завладеть учетной записью сопровождающего.
Заключительные замечания
Поскольку организации все чаще применяют методологии разработки программного обеспечения, в которых приоритет отдается автоматизации и непрерывной доставке, важность обеспечения безопасности на этапе пакета программного обеспечения никогда не была более важной. Внедряя надежные меры безопасности на этом критическом этапе, организации могут существенно снизить риск стать жертвой злонамеренных атак, которые могут поставить под угрозу целостность и безопасность их программного обеспечения.
Стратегии, описанные в этом посте, вместе с приведенными примерами служат ярким напоминанием о том, что этап упаковки представляет собой уязвимое место в цепочке поставок программного обеспечения. Организации должны учитывать эти угрозы и принимать необходимые меры безопасности для защиты своего программного обеспечения от атак. Поступая таким образом, они могут гарантировать целостность, безопасность и надежность своего программного обеспечения для своих пользователей и клиентов.
Присоединяйтесь к нашему пути к безопасной экосистеме программного обеспечения
Не упустите шанс быть на шаг впереди в сфере software supply chain security. Подпишитесь на наш блог сегодня и будьте в числе первых, кто получит наши последние аналитические данные, гарантируя, что ваша организация останется устойчивой и безопасной среди развивающихся угроз. Вместе мы сможем построить более надежную и безопасную экосистему программного обеспечения для всех.
Помните, что software supply chain security это продолжающееся путешествие, а не пункт назначения. Постоянно оценивая и адаптируя методы обеспечения безопасности для устранения возникающих угроз, организации могут защитить свою цепочку поставок программного обеспечения и предоставлять надежное программное обеспечение своим пользователям.
Посмотрите наше видео-демо
