О том, как ВКонтакте собирает информацию о нас. Часть 1

[DronVR]

О том, как ВКонтакте собирает информацию о нас, Часть 1.
(C)Владислав Велюга

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

Disclaimer
Сразу хочу отметить, что я снимаю с себя любую ответственность за возможный ущерб, который Вы можете причинить себе/своим устройствам или другим/чужим устройствам, выполняя действия, которые здесь описаны. Также я не призываю заниматься подобной деятельностью на своих сетях. Информация предоставлена исключительно в ознакомительных целях и крайне не рекомендуется к воспроизведению/повтору на личных устройствах, сетях, а также строго не рекомендуются эксплуатации на пользователях, поскольку снифинг чужих данных - дело незаконное, а свое устройство я промониторить в праве.

И да, для любителей найти рекламу там, где её нет: этот пост/статья -- не является рекламой. Упомянутые ниже приложения приводятся в качестве примеров, не более.

Update 6
А еще давайте сразу, вот что ответил (где-то) Андрей Рогозов про данную информацию.

Предисловие
Года два назад я тоже снифил трафик с помощью Shark for Root, отправляемый ВКонтакте с телефона. Ничего странного я тогда не видел. Сейчас же, когда нас окружают "умные" (именно в кавычках, ибо они идиотские) ленты, машинное обучение и прочее, техника стала, мягко говоря, следить. С одной стороны, это хорошо (мы даем пищу для машин, чтобы они обучались), с другой - плохо (данные о нас сохраняются на серверах).

Результаты
Проснифив только авторизацию, аудиозаписи и вообще первые минуты после авторизации в приложении, уже можно поймать все эти странные запросы. Итак:

Самое странное, что мне показалось - это то, что приложение сливает абсолютно весь список пользовательских приложений, установленных на устройстве. Зачем?! (в центре скрина влепил decoded-строку параметра apps)

Довольно часто промелькивали запросы к некоему сервису vigo.ru. Сервис позиционирует себя как аналитика в передаче, поиска ошибок, проблем и обработке видео. Но странно, ведь я всего лишь авторизовался, перешел в аудио и пролистал свою стену, где не было ни единого видеоролика (которые должны были автоматически проигрываться?), а запросов скопилось около 5-7 штук. Помимо notify еще был network_status.

Вот опять. wallGetWrapNew - по названию понятно, что это запрос на получение чьей-то стены (пользователя или сообщества). Зачем тут передавать информацию о устройстве? Максимум, что приходит на ум - для статистики. Хорошо, а зачем данные о типе сети? Еще, что не относится к сливу информации: довольно раздражает то, что везде пытаются всунуть рекламу - лишь посмотреть на параметр fields.

Приложение отправляет все действия пользователя: перешел через меню в раздел "аудио", "geo_data" - вероятно, отправлял бы примерное (или даже точное) местоположение устройства. Спрашивается, зачем, если пользователь не просит находить что-то по близости? Нет, облегчать пользователю жизнь, подсказывая релевантные данные в поиске, например - в этом ничего плохого нет, но зачем отправлять геоданные просто так, при открытии поста? Не понятно.

Приложение делает бенчмарки и зачем-то передает время запроса к API и время загрузки изображений. Видимо, усредненные данные.

Пока не понял когда, при каких условиях и зачем, в приложении подгружается невидимая WebView со страницей m.vk.com/counters.php. Ибо от нее же потом подгружаются две метрики-пикселя (внизу HTML-кода) и favicon. Накрутка статистики? upd: спустя еще пару минут отправился еще один запрос сюда же, уже с другими числами в тегах img - для того, чтобы тот самый пиксель не загрузился из кэша, а запрос к метрике все таки был реальным.

Чуток не негатива: приложение отправляет сообщения об ошибках, если, например, была попытка загрузить изображение (например, оно было прикреплено к посту), но произошла какая-то ошибка. На скрине предоставлен пример, когда изображение просто отсутствовало на сервере (ошибка 404 Not Found). upd: хотя вот попался момент, когда state=success и никаких других "опознавательных знаков" не было.

С видеозаписями обстоят дела еще хуже. Здесь передается информация о таких событиях как "volume_on", "volume_off" (видимо, включение/выключение звука, но это неточно), "fullscreen_on", "fullscreen_off" (переход и выход в/из полноэкранного режима), событие "video_play", которое просто отсылает текущую позицию просмотра видео, где-то с периодичностью 10-20 секунд. upd: хотя вот Андрей подсказал идею, для чего это сделано: для того, чтобы запоминалось место, на котором пользователь остановился при просмотре видео, чтобы он мог переключиться с мобильного на ПК и на ПК продолжить смотреть с места, где был в последний раз на мобильном.

При закрытии страницы (активити) с видео, приложение запрашивает метод video.viewSegments, в параметрах которого передаются рейнжы (отрезки) таймкода, которые были просмотрены пользователем.

Все это - официальное приложение. На момент написания этой статьи (29 июля 2017 года) была версия 4.12.1.

В Kate Mobile таких сливов замечено не было. Единственное, после ввода в эксплуатацию нового алгоритма выдачи аудиозаписей, и Kate, и официальному приложению нужно обращаться к Google Accounts для получения некого receipt-токена. И всё.

О том, как работают приложения на iOS, Windows Phone мне только можно догадываться. Их пакеты не перехватывал, и устройств не имею.

Повторюсь, такие данные, как ближайшие точки доступа Wi-Fi, текущее местоположение пользователя, а также все его действия не отправляются сторонними приложениями, такими как Kate Mobile, VK Coffee (модификация официального, с вырезанными метриками и пр.), моим сайтом-клиентом APIdog и пр.

Update 2
Друг-разработчик Андрей добавил ещё скринов того, что сливается официальным приложением под Android.

Название точки доступа, к которой подключено устройство, а также другие, которые находятся в зоне досигаемости, их сигнал в dB, MAC-адреса.

Плюсом от него же, вот что отправляет официальное приложение для Windows

Только версию системы, версию приложения, метод ввода.
Update 3

Эдуард Безменов, разработчик модификации официального приложения VK Coffee, прокомментировал этот пост так:

Григорий Клюшников, бывший разработчик этого самого приложения, как оказывается, был сам против включения сервисов Vigo в приложение:

«Vigo уже очень давно был, внедрял его я. Я был против с самого начала, но на моё мнение всем было известно как. И это вы там ещё до мейловского MyTracker не дошли, там самая мякотка.»
А вот, что на самом деле представляет Vigo по описанию Григория:

«По изначальному замыслу, точнее, как это мне все объясняли — "выбирать качество видео в зависимости от интернета". Естественно, я абсолютно не хотел сливать подобные данные ради этой никому не нужной мелочи. Хотели бы на самом деле сделать удобный просмотр видео с подстройкой качества под интернет — запилили бы DASH/HLS, как у настоящих видеохостингов. ...»
Отправка местоположения, как оказалось, производится только при просмотре отдельного поста. На аудиозаписи это не влияет, как некоторые стали считать, что в зависимости от региона некоторые треки "скрывается".

Update 5: Ответы от ВКонтакте
Мобильная техподдерка
Денис решил всё-таки добиться ответов на наши вопросы и задал их мобильной поддержке ВК (id333)

Оказывается, Ваше местоположение, данные для таргетинговой рекламы, список установленных приложений и сети Wi-Fi жизненно необходимы для приложения и сайта в целом.

В ответ на последний вопрос, поддержка решила отойти от темы.

О том, как это было получено
Подручные средства
У нас в распоряжении комп под Linux (Ubuntu 16.04 LTS), два телефона на Android 5.1 (Sony Xperia L) и 6.0.1 (Samsung *какой-то там*). У Sony выпилены Google Play Services. На обоих телефонах последняя версия приложения и стороннее приложение - Kate Mobile (версии 37 и 41 соответственно). Ну, и, естественно, единая локальная сеть, к которой подключен и комп, и два устройства.

Подготовка: создание сертификата SSL
Если просто начать снифинг, то мы получим лишь сырые данные, не поддающиеся обработке, поскольку они передаются по протоколу HTTPS - данные зашифрованы. Для того, чтобы получить данные такие, которые мы можем расшифровать, мы меняем сертификат на тот, который мы же и создали. Таким образом мы можем расшифровать этот трафик.

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365

Этой командой создаем сертификат, где key.pem - файл ключа, cert.pem - сертификат.

В phrase key вводим что-то типа пароля. Он нам еще понадобится. Затем его еще раз повторить. Остальные поля можно оставить пустыми/не вводить. По окончанию в текущей директории будет создано два файла.

Подготовка: установка нашего сертификата на устройство
Передаем файл cert.pem на устройство и устанавливаем его в систему. Обращу внимание, что для установки сертификата необходимо, чтобы на телефоне был какая-нибудь защита на экране блокировки (графический ключ, пароль или PIN).

Пошаговая установка сертификата на Android 5.1

Сертификат установлен.

Подготовка: переброс портов
Возвращаемся на Linux, вбиваем в терминал:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -F
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443
sudo iptables -t nat -A PREROUTING -p tcp --dport 587 -j REDIRECT --to-ports 8443
sudo iptables -t nat -A PREROUTING -p tcp --dport 465 -j REDIRECT --to-ports 8443
sudo iptables -t nat -A PREROUTING -p tcp --dport 993 -j REDIRECT --to-ports 8443
sudo iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080

Подготовка: Ettercap
Устанавливаем Ettercap:

sudo apt-get -y install ettercap

После установки его запускаем.

Снифинг данных
Клацаем "Sniff" -> "Unifed sniffing...". В окне выбора интерфейса обычно выбирается уже нужный (может быть wlan0, wlp1s0, enp5s0), если не тот - выбрать свой. "ОК".

Выбор интерфейса
Далее: "Hosts" -> "Scan for hosts". Ожидаем сканирование хостов.

Сканирование хостов

Далее "Hosts" -> "Hosts list". В списке выбираем IP нашего роутера (у меня 192.168.1.1) и жмем "Add to target 1", затем выбираем IP устройства (у меня 192.168.1.222), затем "Add to target 2".

192.168.1.1 - роутер - target 1; 192.168.1.222 - телефон - target 2

Далее "Mitm" (Man in the Middle) -> "ARP Poisoning" -> ставим флаг "Sniff remote connections" -> "OK".

Далее "Start" -> "Start sniffing".

Конец подготовки: SSLSplit
Далее в терминале ставим sslsplit:

sudo apt-get -y install sslplit

Когда установка завершена, создаем директории:

mkdir logs

И в текущей директории (где лежат файлы cert.pem и key.pem)

cp /dev/null logfile.log

Выходим из аккаунта в приложении на телефоне.

В текущей директории выполняем:

sudo sslsplit -k key.pem -c cert.pem -l logfile.log -j logs -S . https 0.0.0.0 8443 http 0.0.0.0 8080

Вводим phrase key, который указывали при создании сертификата.

В logfile.log будут записываться неполные логи (именно домен, адрес, порт), в директорию logs будут записываться подробные запросы, заголовки и ответы.

Далее авторизуемся в приложении и видим, как в терминале, в logfile.log и в директории logs появляются данные. Для остановки снифинга жмем в терминале Ctrl+C.

Логи в директории logs будут записываться под владельцем и группой root без доступа к чтению и записи от текущего пользователя. Поэтому нужно изменить владельца. В директории с сертификатами вводим

 sudo chown -R vlad805:vlad805 logs

Где вместо "vlad805" - имя Вашего пользователя.

Далее можно просматривать файлы с помощью обычного текстового редактора.

Update
Как позже подсказал Антон, снифинг можно выполнить двумя кликами с помощью приложений для Android, и тогда вот эта длиннющая инструкция не понадобится. Но... кому как удобнее.