Исследователи обнаружили вредоносный модуль Go, маскирующийся под фундаментальную библиотеку криптографии

В центре расследования оказался модуль "github[.]com/xinfeisoft/crypto". Он представляет собой точную копию авторитетного репозитория "golang.org/x/crypto" - одной из основных библиотек криптографии в экосистеме Go, поддерживаемой самим проектом Go и используемой миллионами приложений для работы с алгоритмами вроде bcrypt, argon2, chacha20 и протоколом SSH. Однако в файл "ssh/terminal/terminal.go" был внедрён зловредный код. Выбор этой точки для атаки не случаен: функция "ReadPassword", предназначенная для безопасного чтения паролей из терминала, используется множеством CLI-инструментов для ввода высокочувствительных данных, таких как SSH-пассфразы, ключи API или учётные данные баз данных.

Механизм работы бэкдора хитроумно спроектирован для скрытности. Он активируется только в момент реального интерактивного ввода пароля пользователем, что позволяет ему избегать срабатывания в автоматических тестах и снижает шансы на случайное обнаружение. Получив секрет, код сначала сохраняет его в локальный файл по неочевидному пути "/usr/share/nano/.lock" для обеспечения закрепления в системе (persistence). Далее происходит серия сетевых взаимодействий. Модуль обращается к ресурсу на GitHub Raw, выступающему в роли лёгкого механизма управления команд и контроля (C2). По этому указателю он получает адрес конечной точки, принадлежащей злоумышленникам, куда отправляет похищенный пароль методом HTTP POST. В ответ система управления атакой возвращает скрипт для оболочки, который немедленно исполняется на хосте-жертве, открывая путь для произвольных команд.

Этот скачиваемый скрипт выступает в роли многоступенчатого загрузчика для Linux. Его действия направлены на полное закрепление в системе и подготовку платформы для дальнейших атак. Во-первых, он добавляет SSH-ключ злоумышленника в файл "authorized_keys" пользователя "ubuntu", что обеспечивает устойчивый удалённый доступ даже после смены паролей. Во-вторых, скрипт ослабляет встроенный межсетевой экран, устанавливая политики по умолчанию "ACCEPT" для цепочек "INPUT" и "OUTPUT" в "iptables". Наконец, он загружает с контролируемого злоумышленниками домена "img[.]spoolsv[.]cc" два исполняемых файла, замаскированных под медиафайлы с расширением ".mp5". Анализ этих файлов, "sss.mp5" и "555.mp5", подтвердил, что один из них является бэкдором Rekoobe для Linux. Rekoobe - это известный инструмент, используемый продвинутыми постоянными угрозами (APT, Advanced Persistent Threat), в том числе группировкой APT31 (Zirconium). Он предоставляет злоумышленникам широкие возможности для скрытого управления скомпрометированной системой.

Тактика, применённая в этой атаке, классифицируется как «путаница в пространстве имён» (namespace confusion). Поскольку официальный проект "golang.org/x/crypto" использует GitHub лишь как зеркало, а каноническим источником считается "go.googlesource.com/crypto", злоумышленники воспользовались этой особенностью. Они создали репозиторий на GitHub с именем, очень похожим на зеркало ("xinfeisoft/crypto" вместо "golang/crypto"), рассчитывая, что разработчики или автоматические системы могут ошибиться при указании зависимости. На момент написания материала пакет всё ещё был доступен для просмотра на "pkg.go.dev" - официальном индексе пакетов Go. После оперативного обращения исследователей из Socket команда безопасности Go заблокировала модуль через публичный прокси, и теперь попытка его загрузки возвращает ошибку безопасности 403. Это важная, но не исчерпывающая мера, так как модуль уже мог быть загружен и использован в проектах.

Инфраструктура атаки также заслуживает внимания. Аккаунт "xinfeisoft" на GitHub содержал несколько репозиториев, игравших разные роли в цепочке доставки. Основной модуль размещался в "crypto", в то время как репозиторий "vue-element-admin" использовался для хранения того самого указателя ("update.html") на GitHub Raw, что позволяло операторам угрозы гибко менять адреса серверов управления, не пересобирая и не перепубликуя сам вредоносный модуль. История коммитов показывает, что злоумышленники поддерживали эту инфраструктуру активной в течение нескольких месяцев после публикации модуля, меняя домены, что свидетельствует о продолжении кампании.

С точки зрения защиты, этот инцидент служит серьёзным напоминанием для всех, кто использует открытые зависимости. Во-первых, необходимо относиться к корневым модулям Go как к критически важным границам цепочки поставок. Любые изменения в файлах "go.mod" и "go.sum" должны проходить тщательную проверку. Особую подозрительность должны вызывать добавления сторонних библиотек, предоставляющих возможности сетевого взаимодействия или выполнения команд, таких как "github.com/bitfield/script", которая была использована в данном бэкдоре для упрощения вредоносной логики. Во-вторых, командам безопасности следует внедрять детектирование конкретных поведенческих сигнатур, наблюдаемых в этой атаке: запись в нестандартные файлы вроде "/usr/share/nano/.lock", последовательность «запрос к GitHub Raw -> HTTP POST на внешний ресурс», выполнение конструкций "curl | sh", модификация файла "authorized_keys" и изменения политик "iptables" по умолчанию.

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