17 December 2019

Скрытая активация камеры браузерами: Большой Брат или технологический просчёт?

РосКомСвобода corporate blogFirefoxInformation SecurityGoogle ChromeBrowsers

image


Всем привет!


Меня зовут Вадим, и я один из технических консультантов и, по совместительству, системный администратор "РосКомСвободы".


Но данный пост будет не обо мне. Он будет историей о подозрительной (с точки зрения приватности в контексте мобильных телефонов) ситуации, с которой мы недавно столкнулись.
Он мог бы быть в стиле "А-а-а-а-а-а! Смотрите, Большой брат (Google) следит за нами", но я, всё же, попробую провести какой-никакой анализ и выдвинуть правдоподобные гипотезы о том, почему может происходить то, что произошло.


Заранее прошу прощения, если кому-то не нравится формат а-ля "журнал }{akep в нулевые". Пишите — исправлюсь.


Итак. К нам обратился один из наших читателей, утверждая, что при входе на наш сайт (на котором, весьма иронично, сейчас в топе висит плитка нашей кампании против распознавания лиц — BanCam) у него активируется фронтальная камера.


Дело в том, что он является обладателем телефона из нового поколения телефонов без "чёлок", у которых фронтальная камера вынесена в отдельный "выезжающий" лоток. Который, собственно, и выезжает при обращении к камере.



Как вы, наверное, догадываетесь, моими первыми мыслями были подозрения о том, что нас каким-то чудом, не смотря на все "охранные механизмы", которые я выстраивал, всё-таки взломали и "протроянили".


Однако расследование показало, что с нашим сайтом всё в порядке.


После проведения вышеупомянутого расследования и обсуждения его выводов в техническом чате "РосКомСвободы" я вспомнил о том, что я уже сталкивался на нескольких форумах в интернете с тем, что через баннерные сети (при открытии форума с Android-телефона) "подсовывались" "троянские" apk-пакеты (видимо, в надежде что пользователь установит их, думая, что это официальный клиент данного форума).


Обдумав данную мысль, я предложил попробовать попроверять "трекеры", которые попали в список разрешённых (данный читатель использует Firefox и установленный в нём аддон uBlock).


Пара часов экспериментов показали, что камера перестаёт выезжать если заблокировать обращения к домену google.com. Также, где-то к этому же моменту данный юзер заявил, что на сайте kod.ru тоже воспроизводится данная ситуация (до этого мы работали с версией "только у нас").


Немного углубившись в раскопки, я обнаружил, что запросы к google.com провоцируют не только гугловые трекеры (aka "аналитика"), но даже и обычное "встраивание" видео с ютуба на странице. Воспроизводимость выезда камеры на kod.ru тоже попадала в данную теорию (как выяснилось, на тестируемой странице тоже было видео с ютуба).


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


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


Окей, копаем дальше.


Поковырявшись в браузерных инструментах отладки я нашёл, что с www.google.com (именно с www) грузится странный и до ужаса обфусцированный (да так, что ни один испробованный мной деобфускатор из поисковой выдачи не справился) скрипт, у которого даже имя и то обфусцировано (зная гугл, могу предположить, что через некоторое время этот скрипт пропадёт, а на его место будет поставлен скрипт с другим (но столь же нечитабельным) именем. Так что, вот его код, на всякий случай).


Беглый просмотр скрипта не показывает наличия тут упоминаний камеры, а погружаться в отладку ещё глубже и интерпретировать что он там делает — нет времени и возможности (хотя, если кто-то из вас, читателей, хочет — можете заняться).


Пробуем зайти с другой стороны:
Лично у меня телефон без выездной камеры, поэтому так легко отловить обращение к ней я не могу. Но я могу подключить его по USB и сделать adb logcat | grep -C5 camer (grep — потому что иначе уж слишком много иррелевантного мусора на каждый чих, включая нажатия пальцем на экран или движения телефона в пространстве). Что я, собственно, и делаю...


Итак, попытка номер один: захожу на тестируемые сайты, и… ничего!


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


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


Иду в настройки приложения и вижу что, да, у меня для Firefox не выставлены разрешения на камеру. Включаю, проверяю ещё раз, и вижу простыню на пару "экранов" с подобным:


скриншот


Ага! Обращение к камере, значит, всё же есть!
Более того, сразу после строки с "get device info" идёт явное открытие девайса камеры:


12-12 17:10:14.734   751  6924 I QCamera : <HAL><INFO> int qcamera::QCamera2Factory::cameraDeviceOpen(int, struct hw_device_t **): 405: Open camera id 0 API version 256

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


Значит, получается проблема:
а) не локальная для юзера,
б) не специфичная для браузера.


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


В свете вышеописанного у меня родились две гипотезы:


  1. Либо Big Brother, всё же, is watching you, либо
  2. тот обфусцированный до ужаса скрипт в реальности вызывает какую-то часть Camera API в браузерах для фингерпринтинга юзера, но при этом не обращается к камере напрямую. Поэтому и нет запроса на доступ к ней (впрочем, если присмотреться к видео в начале статьи, то можно увидеть как между открытием и закрытием камеры моргает светодиод, что заставляет задуматься).

Браузеры же исповедуют тут логику: "при инициализации Camera API, если доступа к камере нет, то не делаем ничего (даже не запрашиваем его, пока не возникнет реальная необходимость) а если есть — инициализируем камеры и проверяем что за девайсы там у нас и что они умеют" (для чего, видимо, и происходит "открытие" девайса).


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


Итого, получается, что проблема не так уж и фатальна, как казалась в начале, и, хотелось бы надеяться, снимков никто не делает (хотя это, всё же, до сих пор "не точно", т.к. моей компетенции в познании исходных кодов Android'а недостаточно для того чтобы однозначно гарантировать в каком случае простыня обращений к камере в logcat говорит о сделанном снимке, а в каком — просто о светских беседах приложения с девайсом).


Однако, тем не менее, сам факт того, что открытие любой веб-страницы, на которой будет iframe с встроенным видео с YouTube'а приводит к обращению к камере (и даже каким-то переговорам с девайсом) всё равно довольно печален в контексте приватности и, как мне кажется, всё же стоит обсуждения сообществом.


А как думаете вы?


P.S. На английском данный пост опубликован на Medium.


UPD: спасибо хабравчанам berez и ksil за пакет орфографических правок (а то при вычитке и переписывании разных кусков текста, как это водится, "исправляя одни баги, привнесли пучок других")

Tags:androidprivacyfirefoxchromeтрекерыроскомсвободаyoutubeбраузеры
Hubs: РосКомСвобода corporate blog Firefox Information Security Google Chrome Browsers
+181
79.2k 158
Comments 100