В репозитории pub.dev обнаружен вредоносный пакет с червём XCSSET

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

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

XCSSET уже несколько лет известен как опасный червь для macOS. Впервые о нём заговорили в 2020 году, когда вредонос находили в проектах Xcode. Нынешний случай показывает, что червь продолжает развиваться и адаптировался к современным экосистемам разработки. Вместе с тем, в отличие от недавних инцидентов в реестре npm, когда злоумышленники намеренно публиковали вредоносный код, здесь ситуация иная: заражение произошло из-за недостаточной защиты рабочей станции автора. Это типичный сценарий атаки на цепочку поставок, при котором жертвой становится не потребитель, а сам разработчик инструмента.

Механизм распространения у червя многоступенчатый. Сначала он ищет на диске Android-проекты, использующие систему сборки Gradle. В конфигурацию сборки добавляется скрытая команда, которая выполняется каждый раз, когда разработчик собирает проект. Затем червь заражает git-репозитории, изменяя служебный сценарий, запускаемый перед фиксацией изменений. Кроме того, он добавляет вредоносный этап в проекты Xcode. Любой разработчик, который открывает и собирает заражённый проект, автоматически заражает собственный компьютер. Каждый этап реализуется отдельным модулем, что позволяет червю быстро обновлять свои функции и добавлять новые способы заражения. Более того, команда для связи с сервером в каждом заражённом проекте выглядит по-разному, что мешает антивирусным программам распознавать угрозу по сигнатурам.

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

Далее XCSSET приступает к сбору конфиденциальной информации. Вредонос включает модули кражи данных из браузеров: например, из Chrome он похищает сохранённые пароли, cookie-файлы и данные сессий, перехватывая ключ шифрования, который браузер генерирует заново. Отдельные модули отвечают за Safari, Firefox, а также за приложения "Заметки", "Напоминания" и "Календарь". Опасный модуль, нацеленный на Telegram, останавливает мессенджер, подменяет его исполняемые файлы и забирает файлы сессий. Для получения прав администратора червь выводит поддельное окно системных настроек и запрашивает ввод пароля.

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

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

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

Domain

• 5yotmxcc54l9xda.ru
• ejntin6hkjt7gj2.ru
• qdgs232i-q.ru