Compromised LiteLLM 1.107.0 on PyPI Installs a Credential Stealer and Backdoor 🔥 Горячее 💬 Длинная дискуссия
Вредоносная версия библиотеки LiteLLM 1.107.0, опубликованная на PyPI, содержала похититель учётных данных и бэкдор удалённого выполнения кода. Все семь колёс (для Linux, macOS и Windows) устанавливали три файла в site-packages, причём два из них загружались при запуске любого процесса Python — даже если он никогда не импортировал litellm. Исходники на GitHub этих файлов не содержат, а PyPI уже удалил релиз. Чистыми остаются версии 1.106.2, 1.107.0rc1 и 1.107.0rc2, а также зависимые пакеты litellm-proxy-extras==0.4.110 и litellm-enterprise==0.1.78.
Файл cook.pth импортировал cook.py — похититель, собиравший SSH-ключи, облачные учётные данные, секреты CI/CD, токены ИИ-инструментов, пароли браузеров и ключи провайдеров LLM из базы прокси LiteLLM; данные шифровались и отправлялись на www.litellm[.]dev. Второй файл, sitecustomize.py, запускал фоновый демон, который ежечасно читал адрес сервера из файла на GitHub, повторно запускал похититель и скачивал чужой код. Имплант попал в релиз через лишнюю строку data = "cook" в секции maturin файла pyproject.toml: она копировала папку cook/ в колесо, но сама папка в sdist отсутствовала — это единственное видимое изменение. Тег v1.107.0 указывал на коммит с версией 1.108.0, а sdist совпадал с более поздним коммитом main плюс пять отредактированных файлов. Колёса собрал обычный конвейер BerriAI (maturin 1.9.4, корректные записи в RECORD), но ни один публичный запуск GitHub Actions релиз не собирал и не публиковал.
Комментарии (173)
Повторная компрометация LiteLLM (версия 1.107.0) из-за кражи трех GitHub-аккаунтов разработчиков указывает на системную уязвимость цепочки поставок в экосистеме Python. Злоумышленники внедрили файл cook.pth, который автоматически загружается при старте любого Python-процесса. Рекомендации: — зафиксировать версию ≤ 1.106.2, использовать приватные реестры и проверять артефакты сборки (включая .pth-записи); — использовать канарейковые токены (canarytokens.org) для раннего обнаружения атак; — рассмотреть альтернативы, например GoModel на Go. Для защиты экосистемы предлагается внедрить в менеджерах пакетов (uv, npm, pip) задержку установки новых версий на 24–48 часов, а в операционных системах — изолированные программные пространства или легкие VM, чтобы избежать безусловного принятия вредоносных пакетов.
Going Dark, and the era of law enforcement hacking 🔥 Горячее 💬 Длинная дискуссия
AI может сделать системы слишком надёжными, что угрожает национальной безопасности. Раньше спецслужбы полагались на уязвимости в ПО, но теперь шифрование (iPhone, WhatsApp) закрывает эти «низко висящие плоды». В 2016 году FBI потребовал у Apple доступа к зашифрованному телефону, но отступил после обвинений в риске злоупотребления бэкдоров. Теперь, когда у злоумышленников остаются лишь редкие уязвимости, агентствам придётся требовать искусственных способов доступа — «исключительного доступа». Это может привести к тому, что США ослабят собственные системы, а иностранные государства получат новые возможности для атак. В итоге мы рискуем ускорить «самосоветскую» уязвимость, когда уже почти справились с защитой инфраструктуры. Нам остаётся лишь надеяться, что решения будут приняты правильно, даже если без чёткого плана.
Комментарии (174)
Тред обсуждает влияние ИИ на безопасность ПО и последствия для правоохранительных органов и национальной безопасности. @mbroshi отмечает, что компании добавляют больше уязвимых функций, чем раньше; ИИ может выявлять существующие проблемы, но не обеспечивает полной безопасности. @tptacek и @thinkthatover спорят, насколько низкоуровневый код платформ менее уязвим, чем код приложений, и изменится ли это в будущем. @Carrok предлагает само-хостинг и контроль над ПО как меру против уязвимостей. @Grombobulous утверждает, что правоохранительным органам не нужен массовый доступ к коммуникациям — исторически это не было необходимо. @ayaros считает, что доступ государства к частным коммуникациям нарушает право на неприкосновенность частной жизни.
The UK is still trying to backdoor encryption for Apple users 🔥 Горячее
Великобритания продолжает попытки внедрить бэкдоры в шифрование для пользователей Apple, несмотря на глобальную критику. Власти настаивают, что доступ к зашифрованным данным необходим для борьбы с преступностью, но эксперты предупреждают, что это ослабит безопасность всех пользователей.
Такие меры могут подорвать доверие к технологическим компаниям и создать уязвимости, которыми воспользуются злоумышленники. Apple и правозащитные организации активно сопротивляются, подчёркивая, что бэкдоры не могут быть ограничены только «законным» доступом.
Комментарии (103)
- Участники обсуждают требования правительства Великобритании к Apple о предоставлении доступа к зашифрованным данным пользователей (iCloud), включая отключение функции Advanced Data Protection.
- Высказывается обеспокоенность по поводу расширения государственного надзора и ущемления приватности, проводятся параллели с ситуацией в Китае и другими законами (PATRIOT Act, FISA).
- Обсуждается юридическая сторона: какие пользователи попадают под юрисдикцию UK, возможность Apple противостоять требованиям и роль правительства США в предыдущих спорах.
- Поднимается вопрос о доверии к производителям устройств и облачным сервисам, уязвимости перед принудительными OTA-обновлениями и необходимости независимого аудита безопасности.
- Некоторые пользователи связывают эти события с общим упадком и ужесточением законодательства в Великобритании, включая ограничение свободы слова и иммиграционную политику.