Атаки на цепочку поставок программного обеспечения остаются одним из наиболее разрушительных векторов угроз, и недавний инцидент с библиотекой "bittensor-wallet" - яркое тому подтверждение. Компрометация официального Python-пакета для управления криптографическими ключами в экосистеме децентрализованной сети искусственного интеллекта Bittensor демонстрирует, насколько изощрёнными и многоуровневыми стали атаки злоумышленников. В течение примерно 48 часов, с 15 по 17 марта 2026 года, вредоносная версия 4.0.2 находилась в репозитории PyPI, прежде чем была отозвана. Эта уязвимость предоставляла прямой доступ к приватным ключам пользователей, что в контексте криптовалютной сети равносильно прямому хищению средств.
Описание
Расследование, проведённое экспертами StepSecurity, вскрыло техническую сложность этой атаки. Вредоносный код был не просто добавлен в Python-скрипты, а скомпилирован непосредственно в нативное Rust-расширение библиотеки, что серьёзно затрудняло его статическое обнаружение. Злоумышленники также удалили этап генерации криптографических аттестаций (provenance attestation) в конфигурации CI/CD, что лишило пользователей возможности проверить подлинность сборки. Основной целью бэкдора была кража зашифрованных файлов ключей (keyfiles) при их расшифровке для выполнения любой операции - проверки баланса, стейкинга или перевода средств.
Механизм работы вредоносной функциональности был выстроен с расчётом на обход современных систем защиты. Перед любой активностью код выполнял серию проверок на анализ. Он вычислял время работы системы (uptime), и если оно составляло менее 20 минут, что характерно для песочниц и виртуальных машин, выполнение прерывалось. Аналогично, проверялось наличие отладчика через поле "TracerPid" в "/proc/self/status" и сканировались запущенные процессы на предмет инструментов вроде "strace", "gdb" или "wireshark". Это делало обнаружение бэкдора в лабораторных условиях крайне сложной задачей. Само ядро атаки, функция "collect_format_metrics", было внедрено в три критических места модуля "src/keyfile.rs", отвечающих за расшифровку ключей.
Особую опасность представляла многоуровневая система эксфильтрации данных, которая гарантировала доставку украденных ключей даже в неблагоприятных сетевых условиях. Специалисты StepSecurity в ходе экспериментального запуска зафиксировали работу всех трёх независимых каналов. Первый метод (Method A) использовал обычные HTTPS-запросы через стандартную библиотеку Python "urllib" к доменам, замаскированным под легитимную инфраструктуру Bittensor, например, "finney.opentensor-metrics.com". Второй метод (Method B) был более скрытным: при неудаче HTTPS код напрямую, через динамическую загрузку библиотек ("dlopen"), обращался к "libssl" для установки сырого TLS-соединения, обходя любые Python-прокси и мониторинг на этом уровне. Третий, резервный метод (Method C), представлял собой полноценный DNS-туннель: зашифрованный полезная нагрузка разбивалась на 28 шестнадцатеричных блоков и отправлялась в виде DNS A-запросов к поддомену "t.opentensor-cdn.com".
Для обеспечения устойчивости атаки была реализована трёхуровневая система управления (C2, Command and Control). Помимо статически заданных доменов, бэкдор использовал алгоритм генерации доменных имён (DGA, Domain Generation Algorithm), создавая три новых псевдослучайных поддомена в день. Это означало, что блокировка сегодняшних доменов не останавливала атаку завтра. Кроме того, код выполнял DNS TXT-запрос к "_dmarc.opentensor-cdn.com", маскируясь под легитимный запрос политики электронной почты DMARC, чтобы получить свежий список резервных серверов. Для предотвращения дублирования украденных данных использовался механизм дедупликации на основе хэшей SHA256, а фоновый поток с безобидным именем "cache-gc" периодически пытался отправить данные из очереди при первоначальном сбое. После успешной отправки буфер с ключом в памяти затирался с помощью операций "volatile write".
Для специалистов по информационной безопасности этот инцидент служит суровым напоминанием о критической важности контроля исходящего сетевого трафика в средах CI/CD и рабочих станциях разработчиков. Как показал эксперимент, использование решений вроде Harden Runner в режиме блокировки с белым списком разрешённых исходящих подключений (например, только к "pypi.org" и "files.pythonhosted.org") полностью пресекает все три метода эксфильтрации. Прозрачное сравнение исходного кода из публичного репозитория GitHub и артефактов, опубликованных в PyPI, также могло бы выявить расхождения. Пользователям, которые устанавливали версию 4.0.2 в период её активности, необходимо в срочном порядке считать все ключи, которые подвергались расшифровке в этот период, скомпрометированными, немедленно сгенерировать новые и перевести средства. Дополнительно требуется заблокировать на сетевом уровне домены "*.opentensor-metrics.com", "*.metagraph-stats.com", "*.subtensor-telemetry.com" и "*.opentensor-cdn.com", а также провести аудит логов на предмет соответствующих DNS- и HTTPS-запросов.
Индикаторы компрометации
PyPI package
- bittensor-wallet==4.0.2
Source tarball SHA256
6a416b72ff24804abc12484a3b41413a8580acedd8a5f8c84224fcf0732c2f8e
C2 domain
- finney.opentensor-metrics.com
- finney.metagraph-stats.com
- finney.subtensor-telemetry.com
DGA domain pattern
- *.opentensor-cdn.com
DNS exfil subdomain
- *.t.opentensor-cdn.com
DNS C2 lookup
- _dmarc.opentensor-cdn.com (TXT record)
Thread name
- cache-gc
Network User-Agent
- Python/3
Malicious file
- src/keyfile.rs
Attacker NaCl pubkey (hex)
- daeb c8f3 3fd7 9a8e d65b d438 3280 cab1 3f00 f2a0 3ff5 13ca 7c50 aa85 7ecd d46f
