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

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

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

Февральский набор обновлений для Android устранил в общей сложности 48 брешей, включая уязвимость нулевого дня (0-day) в ядре ОС. Злоумышленники уже используют соответствующий эксплойт в кибератаках.

0-day отслеживается под идентификатором CVE-2024-53104 и приводит к повышению прав в системе.

Проблема затрагивает драйвер уровня ядра — USB Video Class. С помощью эксплойта киберпреступники повышают привилегии, причём атака в этом случае не представляет никакой сложности.

Корень бреши кроется в некорректном парсинге драйвером фреймов UVC_VS_UNDEFINED в функции uvc_parse_format. В результате неверно подсчитывается размер буфера, что приводит к записи за пределами границ.

Помимо 0-day, февральские обновления устраняю критическую брешь в компоненте Qualcomm WLAN. Она получила идентификатор CVE-2024-45569 и связана с неправильной проверкой индекса массива.

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

MAX Desktop проверили на слежку за VPN, сенсация не состоялась

Пользователь Хабра Slava_B протестировал поведение десктопного клиента MAX в Windows и не обнаружил признаков того, что мессенджер распознаёт VPN при маршрутизации трафика через роутер. Зато приложение читает ряд системных параметров и идентификаторов компьютера.

Эксперимент провели 8 сентября 2026 года. Windows-компьютер подключили к роутеру Keenetic, который самостоятельно распределял трафик: российские ресурсы открывались напрямую, а часть остальных соединений уходила через OpenConnect-туннель на европейский VPS.

В самой Windows не было ни VPN-клиента, ни виртуального адаптера, ни соответствующих маршрутов.

За клиентом MAX следили с помощью Process Monitor, Wireshark и TCPView, а трафик на удалённом сервере записывали через tcpdump. Исследователь выяснил, что приложение запускает процессы MAX.exe и MAX-service.exe, связывающиеся между собой через локальный порт. Клиент подключался к инфраструктуре MAX/ONEME, сервису AppTracer и системам для звонков.


MAX и его служебный процесс многократно читали MachineGuid — стабильный идентификатор установки Windows. Программа также получала имя компьютера, настройки proxy/PAC, собственные device ID и сведения о микрофонах и камере. Впрочем, подобные данные могут использоваться для диагностики, антифрода, подключения через корпоративный прокси и работы звонков.


Главный результат успокаивает: соединения MAX не появились на VPN-интерфейсе VPS, а обращений к сервисам определения внешнего IP, Telegram, WhatsApp (принадлежит корпорации Meta, признанной экстремисткой и запрещённой в России) или другим ресурсам для проверки маршрута исследователь не выявил. Браузеры клиент тоже не запускал.

При этом автор подчёркивает: содержимое TLS-трафика не расшифровывалось, поэтому доказательств передачи MachineGuid или других идентификаторов на сервер нет. Результат относится только к конкретной конфигурации и не показывает, как MAX поведёт себя с VPN-клиентом непосредственно в Windows.

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