Google Chrome сливает данные датчика движения Android всем сайтам

Google Chrome сливает данные датчика движения Android всем сайтам

Google Chrome сливает данные датчика движения Android всем сайтам

Редко кто знает, что датчики движения Android-устройств по умолчанию доступны сайтам, которые пользователи посещают, используя Chrome. Мобильный браузер Google передает такие данные по запросу даже при самых жестких настройках приватности, а также в режиме инкогнито.

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

Встроенная защита Android не распространяется на данные акселерометра и сенсоров ориентации, и приложения могут их считывать даже в фоновом режиме, притом независимо от уровня привилегий. Chrome делает это, даже когда пользователь поставил флаги во всех настройках приватности или запустил браузер в режиме инкогнито.

Доступ к таким данным оправдан, например, при посещении мобильной версии сайта Google Карты или у игровых приложений, которым важно следить за касаниями экрана и нажимом клавиш на виртуальной клавиатуре (телефон при этом немного наклоняется). Однако неограниченное предоставление подобной информации через Chrome по дефолту — слишком уж явное нарушение конфиденциальности, о которой так печется Google, по крайней мере, на словах.

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

 

Не проще ли поставить тотальный блок по умолчанию и предоставить пользователю самому решать, кому предоставить доступ к API, — как это сделала Apple для Safari на iPhone в том же 2019 году. Ее браузер теперь запрашивает разрешение у пользователя при переходе на сайт, пытающийся отследить местоположение визитера.

Более того, мессенджерам и клиентам сервисов звонков на iOS теперь запрещено работать в фоновом режиме, то есть их лишили возможности собирать информацию о пользователях в период бездействия. У Google же, напротив, все функции приватности по умолчанию отключены. Примечательно, что Chrome на iPhone безопаснее, чем на Android, так как Apple заблокировала доступ к API датчиков движения для всех браузеров.

Напомним, в браузере Google недавно появился еще один механизм, позволяющий сайтам собирать пользовательские данные без применения куки, — FLoC. Эта скрытая функциональность, также посягающая на приватность навигации в Сети, вызвала неоднозначную реакцию в ИТ-кругах, и Google через несколько месяцев свернула пробный запуск, пообещав доработать проект.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

В npm нашли пакет, ставивший AdaptixC2 на компьютеры разработчиков

Специалисты «Лаборатории Касперского» в октябре 2025 года обнаружили в популярном репозитории npm злонамеренный пакет под названием https-proxy-utils. Он маскировался под легитимные библиотеки для работы с прокси, но внутри прятал постинсталляционный скрипт, который загружал и запускал AdaptixC2.

AdaptixC2 представляет собой опенсорсный фреймворк командования и управления, похожий на Cobalt Strike и уже используемый в реальных атаках. Пакет уже удалён из npm.

Схема выглядела просто и опасно: название пакета имитировало привычные пакеты с похожими именами, поэтому разработчики могли взять его по невнимательности.

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

Авторы кампании подстраивали способ доставки в зависимости от операционной системы жертвы: на Windows использовались техники, позволяющие запустить вредоносную библиотеку вместе с легитимным приложением (DLL sideloading), а для Linux и macOS применялись свои варианты загрузки и запуска. Именно такая адаптивность делает подобные цепочки особенно коварными.

«Инцидент с AdaptixC2 показывает, что хранилища опенсорс-пакетов всё чаще используют как вектор атак», — отмечает Владимир Гурский из «Лаборатории Касперского. — Злоумышленники применяют более изощрённые приёмы маскировки известных инструментов, а техники вроде sideloading становятся всё более популярны. Без современных средств защиты такие кампании тяжело обнаружить».

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

Во-вторых, автоматические проверки и сканеры зависимостей в CI/CD помогают ловить подозрительные действия. И, конечно, на конечных машинах полезны средства мониторинга и EDR, которые заметят необычную сеть- или процессную активность.

Несколько простых правил, которые помогут снизить риск: использовать lock-файлы и проверенные версии библиотек, ограничивать права среды сборки, включать анализ зависимостей в пайплайны, не запускать установку пакетов под правами админа без необходимости и регулярно сканировать проекты на предмет подозрительных скриптов.

Случай с https-proxy-utils — ещё один напоминание: опенсорс полезен и удобен, но требует осторожности. Проверяйте пакеты и следите за зависимостями — ведь одно случайное «npm install» может дорого обойтись.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

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