В сентябре активность сетевого червя P2PInfect возросла в 600 раз

В сентябре активность сетевого червя P2PInfect возросла в 600 раз

В сентябре активность сетевого червя P2PInfect возросла в 600 раз

Объявившийся летом самоходный зловред P2PInfect становится все более агрессивным и продолжает совершенствоваться. К сентябрю число попыток эксплойта на ханипотах Cado Security возросло в три раза, за последнюю неделю — в 600 раз.

Сетевой червь P2PInfect написан на Rust и нацелен на серверы Redis, работающие под управлением Linux или Windows. Для получения первоначального доступа используется эксплойт CVE-2022-0543.

В Cado отслеживают ботнет, построенный на основе P2PInfect, с конца июля. Спустя месяц на ханипотах был зафиксирован рост активности, ассоциируемой с этим вредоносом, в начале сентября число атак стало стремительно увеличиваться. За неделю с 12 сентября по 19-е эксперты насчитали 3619 попыток эксплойта.

 

На настоящий момент выявлены 219 уникальных узлов ботнета (пиров) в разных странах; больше половины из них расположены в Китае. В основном это зараженные серверы Redis и SSH в сетях облачных провайдеров — Alibaba, Tencent, Amazon.

 

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

Так, в дополнение к изначальному сценарию выхода из системы (bash_logout) у зловреда появился полноценный механизм персистентности: он теперь обеспечивает себе постоянное присутствие, создавая cron-задачу на запуск полезной нагрузки каждые 30 минут.

Добавлен также bash-скрипт, который поддерживает основной пейлоад в активном состоянии, используя локальный сокет. Когда основной процесс завершается или удален, охранник получает копию бинарника с какого-нибудь пира, сохраняет ее как /tmp/.raimi и запускает на исполнение.

Свой SSH-ключ P2Pinfect теперь использует для перезаписи файлов .ssh/authorized_keys, чтобы законные пользователи не смогли воспользоваться таким входом. (Ранее ключ SSH вредоноса просто добавлялся в конец файла.) При наличии root-доступа червь меняет также пароли пользователей, автоматически генерируя 10-значную строку, и, таким образом, блокирует их аккаунты.

В отличие от других ботов P2Pinfect не имеет конфигурационного файла. Вирусописатели постарались восполнить этот пробел: вместо файла .conf новейшие семплы используют C-структуру, загружаемую в память и обновляемую динамически.

В качестве финальной полезной нагрузки некоторые образцы пытаются загрузить криптомайнер, однако его запуска на ботнете пока не замечено. Не исключено, что этот компонент пока не завершен. Возможно также, что загрузка майнера используется для демонстрации возможностей — чтобы привлечь подписчиков на услуги.

Критическую уязвимость в ядре Linux x86 не замечали с 2020 года

В ядре Linux обнаружили уязвимость, которая тихо жила в системе несколько лет — и притом в одном из самых чувствительных мест. Речь идёт о механизме обработки page fault на архитектуре x86, то есть о коде, который срабатывает каждый раз, когда процессор фиксирует некорректный доступ к памяти.

Проблема тянулась как минимум с 2020 года и была связана с тем, что в ряде сценариев аппаратные прерывания оказывались включёнными в момент, когда ядро ожидало их отключения.

На практике это означало потенциальную нестабильность в крайне редких, но критически важных ситуациях — там, где от предсказуемости поведения ядра зависит вообще всё.

На уязвимость обратил внимание инженер Intel Седрик Син (Cedric Xing), внимательно изучавший код обработки исключений. Как выяснилось, логика в функции do_page_fault() опиралась на устаревшее и, по сути, ошибочное допущение.

В комментариях прямо говорилось, что отследить состояние прерываний на всех возможных ветках выполнения почти невозможно — и разработчики много лет балансировали между «комбинаторным кошмаром» из патчей и попытками аккуратно чинить отдельные случаи.

Но проблема оказалась глубже. Код смешивал два разных понятия — адрес (пользовательский или ядерный) и контекст выполнения. Обычно они совпадают, но не всегда.

Существуют ситуации, когда обращение идёт к памяти ядра, но в пользовательском контексте. В таких случаях некоторые ветки обработчика могли повторно включить прерывания — и вернуть управление туда, где ядро было уверено, что они всё ещё выключены.

Особенно показательной оказалась ветка __bad_area_nosemaphore(), где предпринимается попытка «восстановить правильное состояние», но на деле это происходило не всегда и не одинаково. В результате возникала асимметрия: в зависимости от пути выполнения система могла оказаться в неожиданном состоянии.

В итоге разработчики пришли к простому, но радикальному выводу: латать отдельные ветки бессмысленно. Вместо этого было принято решение гарантированно и безусловно отключать прерывания в одном конкретном месте — прямо перед возвратом управления в низкоуровневый обработчик page fault. Без условий, без проверок, без попыток «угадать» контекст.

Патчи уже вошли в ветку Linux 6.19, а также планируются к бэкпорту в поддерживаемые стабильные версии. Фактически оно устраняет дефект, появившийся ещё во времена Linux 5.8.

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