Barcode Scanner стал зловредом при переходе в другие руки

Barcode Scanner стал зловредом при переходе в другие руки

Barcode Scanner стал зловредом при переходе в другие руки

Через несколько дней после публикации сообщения о внезапной метаморфозе Android-приложения Barcode Scanner компания LavaBird, от имени которой вышел вредоносный апдейт, прислала в Malwarebytes письмо с объяснением ситуации. По словам отправителя, виновником изменения поведения популярного сканера штрихкодов является нынешний владелец проекта, пожелавший протестировать ключ подписи разработчика и пароль перед покупкой.

Напомним, с выходом обновления 1.68 программа Barcode Scanner, на счету которой числилось 10 млн загрузок с Google Play, стала заваливать пользователей непрошеной рекламой. В Malwarebytes новый вариант сканера признали троянским, и Google пришлось изъять его из доступа в магазине.

На тот момент комментариев от LavaBird не последовало, однако позже ситуация прояснилась. В своем письме представители компании утверждают, что осуществляли лишь посреднические функции при перепродаже проекта: купили его 23 ноября прошлого года и договорились о последующей продаже 25 ноября. Покупателем являлась некая группа The space team.

По условиям сделки покупателю был предоставлен доступ к консоли Barcode Scanner — тот пожелал вначале убедиться в работоспособности ключа подписи и пароля, а также добавить свою аналитику. В итоге 27 ноября на Google Play был выложен апдейт 1.67 — видимо, уже с вредоносным кодом, но еще под именем LavaBird. Обновление 1.68 появилось 4 декабря, и тогда же Barcode Scanner начал демонстрировать изменения в поведении.

Седьмого декабря сделка по купле-продаже была завершена. Новый владелец, The space team, выпустил Barcode Scanner 1.69, с той же зловредной функциональностью. К концу декабря злоумышленники начали прятать свой код, применяя обфускацию, и успели выпустить еще несколько обновлений до изгнания с Google Play.

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

Популярную ИИ-библиотеку LiteLLM заразили бэкдором через PyPI

В экосистеме ИИ-разработки всплыла неприятная история: исследователи из Endor Labs обнаружили, что популярная Python-библиотека LiteLLM, у которой больше 95 млн загрузок в месяц, была скомпрометирована в репозитории PyPI. Через заражённые версии злоумышленники распространяли многоступенчатый бэкдор.

Речь идёт о версиях 1.82.7 и 1.82.8. Причём в официальном GitHub-репозитории проекта такого вредоносного кода не было.

Проблема возникла именно в пакетах, опубликованных в PyPI: туда попал файл с закладкой, который декодировал и запускал скрытую нагрузку сразу после импорта библиотеки.

Во второй заражённой версии, 1.82.8, схема стала ещё жёстче. Пакет устанавливал .pth-файл в директорию site-packages, из-за чего вредоносный код мог запускаться вообще при любом старте Python, даже если сам LiteLLM никто не импортировал.

После запуска зловред начинал искать самое ценное: SSH-ключи, токены AWS, GCP и Azure, секреты Kubernetes, криптокошельки и другие конфиденциальные данные. Если заражение происходило в контейнерной или кластерной среде, вредонос пытался двигаться дальше по инфраструктуре, в том числе через развёртывание привилегированных подов на узлах Kubernetes.

Для закрепления на хосте атакующие, как сообщается, ставили systemd-бэкдор sysmon.service, который регулярно связывался с командным сервером и мог получать новые команды или дополнительные вредоносные модули.

Специалисты считают, что за атакой стоит группировка TeamPCP, которая в последнее время явно разошлась: до этого её уже замечали в инцидентах, затронувших GitHub Actions, Docker Hub, npm и OpenVSX.

Украденные данные, по информации исследователей, шифровались и отправлялись на сервер атакующих. Для маскировки использовались домены, внешне похожие на легитимные, например models.litellm[.]cloud и checkmarx[.]zone.

Сейчас разработчикам и DevOps-командам советуют как можно быстрее проверить окружение. Последней известной чистой версией LiteLLM считается 1.82.6. Если в системе использовались 1.82.7 или 1.82.8, нужно проверить наличие файла litellm_init.pth, артефактов вроде ~/.config/sysmon/sysmon.py и сервиса sysmon.service.

RSS: Новости на портале Anti-Malware.ru