Вредоносный клон aiohttp: httpserver-cache, извлечение ключа по имени файла

Технический анализ выявил вредоносный клон библиотеки aiohttp, распространяемый под вариантом httpserver-cache. Особое внимание привлек файл connector.py, в котором обнаружены заметные отклонения от оригинальной реализации и реализован необычный механизм обработки ключей шифрования в функции mar.

Краткие выводы

• Вредоносный модуль извлекает ключ шифрования не из кода, а из имени файла одного из установленных модулей: вместо прямой инжекции ключа он сохраняет хэш и перебирает доступные модули для поиска соответствия.
• Такой подход делает ключ легко воспроизводимым при анализе локальной установки (в т.ч. при изучении модулей стандартной библиотеки Python), что упрощает смягчение последствий.
• Несмотря на успешную загрузку вредоносного ПО и расшифровку полезной нагрузки, при тестировании в изолированных средах Linux и Windows не было зафиксировано заметного вредоносного поведения.
• Модуль загружался, но не экспортировал функций — это указывает на возможную нефункциональность полезной нагрузки, её состояние «спящей» или на попытку избежать немедленного обнаружения.
• Кампания использовала тактику typosquatting: обнаружено пять пакетов с незначительными вариациями в названиях. Все идентифицированные пакеты были удалены или помещены в карантин из репозиториев.
• Ситуация подчёркивает сохраняющуюся уязвимость цепочек поставок ПО и необходимость повышенной бдительности.

Технические детали: как реализован механизм ключа

Вместо того чтобы хранить или генерировать ключ шифрования внутри кода, вредоносный вариант реализует следующую схему:

• В коде сохраняется хэш ожидаемого ключа.
• Далее выполняется итерация по именам установленных модулей в окружении — сравниваются хэши имён файлов модулей с сохранённым хэшем.
• При совпадении имя файла выступает источником реального ключа.

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

Поведение полезной нагрузки в тестах

Анализ расшифрованной полезной нагрузки показал отсутствие observable effects в тестовых средах на Linux и Windows. Вредоносный код загружался в память, однако не экспортировал функций и не проявлял активной вредоносной деятельности.

Возможные объяснения:

• полезная нагрузка намеренно бездействует до получения внешнего сигнала (C2) или определённых условий среды;
• релиз кода был неполнофункционален или ошибочен;
• механизмы эваздисации/антианализ включают детектирование песочницы и отключение действий.

Кампания и тактика распространения

Атака сопровождалась классической тактикой typosquatting: в репозитории было размещено пять пакетов с названиями, имитирующими легитимные. Малейшие отличия в написании заставляли пользователей устанавливать подделку вместо официальной библиотеки.

На момент анализа все обнаруженные пакеты были удалены или отправлены в карантин, что предотвратило дальнейшее распространение.

Рекомендации по защите

• Тщательно проверяйте имена пакетов при установке: обращайте внимание на орфографию и подозрительные вариации.
• Используйте фиксированные зависимости (pinning) и lock-файлы для воспроизводимости окружения.
• Ограничьте установку пакетов в production-окружение и применяйте allowlist/denylist для внешних репозиториев.
• Проводите регулярный аудит установленных пакетов и их файловых имён в виртуальных окружениях.
• Применяйте инструменты для сканирования зависимостей и уязвимостей (например, pip-audit, Dependabot) и анализируйте подозрительные пакеты в изолированных sandboxes.
• Мониторьте поведение пакетов в рантайме — особенно импорт модулей с необычными именами и динамическую загрузку кода.
• При возможности используйте проверку подписей пакетов и источников поставки (supply chain provenance).

Заключение

Обнаруженная кампания демонстрирует, что злоумышленники по-прежнему активно эксплуатируют уязвимости цепочек поставок: от typosquatting до хитроумных, но в итоге уязвимых схем получения ключей. Даже если конкретная полезная нагрузка в данном случае не проявила себя в тестах, инцидент напоминает о необходимости комплексной практики безопасности при управлении зависимостями — от контроля источников до постоянного мониторинга и анализа установленных пакетов.

Цитата из анализа:

«ключ извлекается из имени файла одного из установленных модулей»

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.