Meta и Яндекс деанонимизируют пользователей брузеров Android

Исследователи обнаружили, что код отслеживания, который Meta* и российская компания Яндекс встраивают в миллионы веб-сайтов, деанонимизирует посетителей, злоупотребляя законными интернет-протоколами, в результате чего Chrome и другие браузеры тайно отправляют уникальные веб-идентификаторы приложениям, установленным на устройстве. Google заявляет, что расследует злоупотребление, которое позволяет Meta и Яндекс преобразовывать эфемерные данные в постоянные идентификаторы пользователей мобильных приложений.

Скрытое отслеживание, реализованное в трекерах Meta Pixel и Яндекс.Метрика, позволяет Meta и Яндекс обходить основные меры безопасности и защиты конфиденциальности, предоставляемые как операционной системой Android, так и браузерами, работающими в ней. Например, песочница Android изолирует процессы, чтобы они не могли взаимодействовать с ОС и любыми другими приложениями, установленными на устройстве, перекрывая доступ к конфиденциальным данным или привилегированным системным ресурсам. Такие средства защиты, как разделение состояний и разделение хранилищ, встроенные во все основные браузеры, хранят файлы cookie сайтов и другие данные, связанные с веб-сайтом, в контейнерах, которые являются уникальными для каждого домена, чтобы обеспечить их недоступность для всех других сайтов.

Вопиющее нарушение

«Один из основных принципов безопасности, существующих в Интернете, а также в мобильных системах, называется песочницей», сказал в интервью Нарсео Валлина-Родригес, один из исследователей, стоящих за этим исследованием. «Вы запускаете все в песочнице, и между различными элементами, запущенными в ней, нет взаимодействия. Этот вектор атаки позволяет взломать песочницу, существующую между мобильным и веб-контекстом. Существующий канал позволил системе Android сообщать о том, что происходит в браузере, мобильному приложению».

Обход, который Яндекс начал в 2017 году, а Meta — в сентябре прошлого года, позволяет компаниям передавать файлы cookie или другие идентификаторы из браузеров Firefox и Chromium в нативные приложения Android. Затем компании могут связать эту обширную историю просмотров с владельцем учетной записи, вошедшим в приложение.

Это злоупотребление наблюдалось только в Android, и есть доказательства того, что Meta Pixel и Метрика нацелены только на пользователей Android. Исследователи говорят, что технически возможно нацелиться и на iOS, потому что браузеры на этой платформе позволяют разработчикам программно устанавливать соединения с localhost, которые приложения могут отслеживать.

Однако, по словам исследователей, в отличие от iOS, Android налагает меньше ограничений на локальные хост-коммуникации и фоновое выполнение мобильных приложений, одновременно внедряя более строгий контроль в процессы проверки приложений в магазинах приложений, чтобы ограничить такие злоупотребления. Эта чрезмерно разрешительная конструкция позволяет Meta Pixel и Яндекс.Метрика отправлять веб-запросы с идентификаторами веб-отслеживания на определенные локальные порты, которые постоянно отслеживаются приложениями Facebook, Instagram и Яндекс. Затем эти приложения могут связывать псевдонимные веб-идентификаторы с реальными идентификаторами пользователей, даже в режиме приватного просмотра, эффективно деанонимизируя привычки пользователей при просмотре сайтов, содержащих эти трекеры.

Meta Pixel и ЯндексМетрика — это аналитические скрипты, предназначенные для помощи веб-мастерам и рекламодателям в оценке эффективности их кампаний. По оценкам, Meta Pixel и ЯндексМетрика установлены соответственно на 5,8 миллиона и 3 миллиона сайтов.

Meta и Яндекс обходят ограничения, злоупотребляя базовой функциональностью, встроенной в современные мобильные браузеры, которая позволяет осуществлять связь между браузером и нативным приложением. Эта функциональность позволяет браузерам отправлять веб-запросы на локальные порты Android для установления различных сервисов, включая медиа-соединения через протокол RTC, обмен файлами и отладку для разработчиков.

Несмотря на различия в технической основе, Meta Pixel и Яндекс.Метрика используют «странное неправомерное использование протокола» для получения непроверенного доступа, который Android предоставляет портам localhost. Браузеры получают доступ к этим портам без уведомления пользователя. Нативные приложения Facebook*, Instagram* и Яндекс незаметно прослушивают эти порты, копируют идентификаторы в режиме реального времени и связывают их с пользователем, вошедшим в приложение.

Представитель Google заявил, что такое поведение нарушает условия обслуживания в его магазине Play и ожидания пользователей Android в отношении конфиденциальности.

«Разработчики, упомянутые в этом отчете, используют возможности, присутствующие во многих браузерах на iOS и Android, не по назначению, что явно нарушает наши принципы безопасности и конфиденциальности», — сказал представитель компании, имея в виду людей, которые пишут JavaScript для Meta Pixel и Яндекс.Метрика. «Мы уже внесли изменения, чтобы смягчить эти инвазивные методы, начали собственное расследование и напрямую связываемся со сторонами».

Meta не ответила на вопросы, но предоставила следующее заявление: «Мы ведем переговоры с Google, чтобы устранить потенциальное недопонимание в отношении их политик. Узнав об этих опасениях, мы решили приостановить работу этой функции, пока мы работаем с Google над решением этой проблемы».

В электронном письме Яндекс сообщил, что прекращает эту практику и также находится в контакте с Google.

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

Как Meta и Яндекс деанонимизируют пользователей Android

Разработчики Meta Pixel злоупотребляли различными протоколами для реализации скрытого прослушивания с момента начала этой практики в сентябре прошлого года. Они начали с того, что заставили приложения отправлять HTTP-запросы на порт 12387. Через месяц Meta Pixel перестала отправлять эти данные, хотя приложения Facebook и Instagram продолжали отслеживать порт.

В ноябре Meta Pixel перешла на веб-сокеты, протокол для двусторонней связи, через порт 12387.

В том же месяце Meta Pixel также внедрила новый метод, использующий WebRTC, протокол одноранговой связи в реальном времени, который обычно используется для аудио- или видеозвонков в браузере. Этот метод использовал сложный процесс, известный как SDP munging — технику, позволяющую коду JavaScript изменять данные протокола описания сеанса (Session Description Protocol) перед их отправкой. SDP munging от Meta Pixel, который используется и по сей день, вставляет ключевой контент куки _fbp в поля, предназначенные для информации о подключении. Это заставляет браузер отправлять эти данные как часть запроса STUN на локальный хост Android, где приложение Facebook или Instagram может их прочитать и связать с пользователем.

В мае в бета-версии Chrome была введена мера по снижению риска, которая блокировала SDP munging, используемый Meta Pixel. В течение нескольких дней Meta Pixel обошла эту меру, добавив новый метод, который заменял запросы STUN на запросы TURN.

В своем посте исследователи предоставили подробное описание перехода файла куки _fbp с веб-сайта в нативное приложение, а оттуда — на сервер Meta:

1. Пользователь открывает нативное приложение Facebook или Instagram, которое в конечном итоге отправляется в фоновый режим и создает фоновый сервис для прослушивания входящего трафика на TCP-порту (12387 или 12388) и UDP-порту (первый незанятый порт в диапазоне 12580–12585). Пользователи должны войти в приложения с помощью своих учетных данных.
2.  Пользователь открывает браузер и посещает веб-сайт, на котором интегрирован Meta Pixel.
3. На этом этапе некоторые веб-сайты ждут согласия пользователей перед встраиванием Meta Pixel. При оценке 100,000 самых популярных  веб-сайтов мы обнаружили, что веб-сайты, требующие согласия, составляют меньшинство (более 75% затронутых сайтов не требуют согласия пользователей)…
4. Скрипт Meta Pixel загружается, и файл куки _fbp отправляется в нативное приложение Instagram или Facebook через WebRTC (STUN) SDP Munging.
5. Скрипт Meta Pixel также отправляет значение _fbp в запросе на https://www.facebook.com/tr вместе с другими параметрами, такими как URL-адрес страницы (dl), метаданные веб-сайта и браузера, а также тип события (ev) (например, PageView, AddToCart, Donate, Purchase).
6. Приложения Facebook или Instagram получают файл куки _fbp от Meta через JavaScript, работающих в браузере, и передают его в конечную точку GraphQL (https://graph[.]facebook[.]com/graphql) вместе с другими постоянными идентификаторами пользователей, связывая fbp ID (посещение веб-сайта) пользователей с их учетной записью Facebook или Instagram.

Первый известный случай, когда Яндекс.Метрика связывала веб-сайты, посещенные в браузерах Android, с идентификаторами приложений, был зафиксирован в мае 2017 года, когда трекер начал отправлять HTTP-запросы на локальные порты 29009 и 30102. В мае 2018 года Метрика также начала отправлять данные через HTTPS на порты 29010 и 30103. Оба метода оставались в силе на момент публикации.

Некоторые браузеры для Android заблокировали вредоносный JavaScript в трекерах. Например, DuckDuckGo уже блокировал домены и IP-адреса, связанные с трекерами, не позволяя браузеру отправлять какие-либо идентификаторы в Meta. Браузер также заблокировал большинство доменов, связанных с Яндекс.Метрика. После того, как исследователи уведомили DuckDuckGo о неполном черном списке, разработчики добавили недостающие адреса.

Между тем, браузер Brave также блокировал обмен идентификаторами благодаря своим обширным спискам блокировки и существующим мерам по блокировке запросов к localhost без явного согласия пользователя. Vivaldi, другой браузер на основе Chromium, пересылает идентификаторы на локальные порты Android, когда установлены настройки конфиденциальности по умолчанию. Изменение настроек для блокировки трекеров, по словам исследователей, позволяет предотвратить утечку истории просмотров.

Должен быть лучший способ

Различные меры, принятые DuckDuckGo, Brave, Vivaldi и Chrome, работают как положено, но исследователи предупреждают, что они могут в любой момент стать неэффективными.

«Любой браузер, использующий списки блокировки, скорее всего, вступит в постоянную гонку вооружений, и это лишь частичное решение», — сказал Валлина-Родригес о текущих мерах по смягчению последствий. «Создание эффективных списков блокировки — сложная задача, и разработчикам браузеров придется постоянно отслеживать использование этой функции, чтобы обнаруживать другие хост-имена, которые могут злоупотреблять каналами localhost, и соответствующим образом обновлять свои списки блокировки».

Он продолжил:

«Хотя это решение работает, если вы знаете хост-имена, которые это делают, это не правильный способ решения этой проблемы, поскольку трекеры могут найти способы получить доступ к этой функции (например, через более эфемерные хост-имена). Долгосрочное решение должно проходить через проектирование и разработку средств контроля конфиденциальности и безопасности для каналов localhost, чтобы пользователи могли быть в курсе этого типа связи и потенциально применять некоторые меры контроля или ограничивать это использование (например, разрешение или некоторые аналогичные уведомления пользователей)».

Chrome и большинство других браузеров на основе Chromium выполняли JavaScript так, как того хотели Meta и Яндекс. Firefox также выполнил код, хотя по непонятным причинам браузер не смог успешно выполнить SDP munging, указанный в более поздних версиях кода. После блокировки варианта STUN SDP munging в бета-версии, выпущенной в начале мая, производственная версия Chrome, выпущенная две недели назад, начала блокировать как вариант STUN, так и вариант TURN. Другие браузеры на базе Chromium, вероятно, реализуют это в ближайшие недели. Представитель Mozilla, разработчика Firefox, заявил, что организация уделяет приоритетное внимание конфиденциальности пользователей и серьезно относится к этому сообщению.

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

Исследователи предупреждают, что текущие исправления настолько специфичны для кода трекеров Meta и Яндекс, что их легко обойти с помощью простого обновления.

«Они знают, что если кто-то другой зайдет и попробует другой номер порта, он может обойти эту защиту», — сказал Гунес Акар, исследователь, стоящий за первоначальным открытием, имея в виду команду разработчиков Chrome в Google. «Но, насколько мы понимаем, они хотят послать сигнал, что не будут терпеть такую форму злоупотребления».

Коллега-исследователь Валлина-Родригес сказал, что более комплексный способ предотвращения злоупотребления — это пересмотр в Android способа обработки доступа к локальным портам.

«Основная проблема заключается в том, что доступ к сокетам локального хоста на Android совершенно не контролируется», — пояснил он. «У пользователей нет возможности предотвратить такого рода коммуникацию на своих устройствах. Из-за динамического характера кода JavaScript и сложности поддержания актуальности списков блокировки, правильным способом постоянной блокировки является ограничение этого типа доступа на уровне мобильной платформы и браузера, включая более строгие политики платформы для ограничения злоупотреблений».

Пока же компания Google не предоставила никаких указаний на то, что планирует перепроектировать способ, которым Android обрабатывает доступ к локальным портам. На данный момент наиболее надежной защитой от отслеживания Meta Pixel и Яндекс.Метрика является отказ от установки приложений Facebook, Instagram или Яндекс на устройства Android.