- Регистрация
- 03.06.2012
- Сообщения
- 6 166
- Репутация
Приложение ВКонтакте !? Фу, какая гадость !
Понравилась одна статья, но больше вторая часть, чем первая, так-что начнём со второй части !
Итак:
1)Подручные средства:
У нас в распоряжении комп под Linux (Ubuntu 16.04 LTS), два телефона на Android 5.1 (Sony Xperia L) и 6.0.1 (Samsung *какой-то там*). У Sony выпилены Google Play Services. На обоих телефонах последняя версия приложения и стороннее приложение - Kate Mobile (версии 37 и 41 соответственно). Ну, и, естественно, единая локальная сеть, к которой подключен и комп, и два устройства.
2)Подготовка: создание сертификата SSL:
Если просто начать снифинг, то мы получим лишь сырые данные, не поддающиеся обработке, поскольку они передаются по протоколу HTTPS - данные зашифрованы. Для того, чтобы получить данные такие, которые мы можем расшифровать, мы меняем сертификат на тот, который мы же и создали. Таким образом мы можем расшифровать этот трафик.
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
Этой командой создаем сертификат, где key.pem - файл ключа, cert.pem - сертификат.
В phrase key вводим что-то типа пароля. Он нам еще понадобится. Затем его еще раз повторить. Остальные поля можно оставить пустыми/не вводить. По окончанию в текущей директории будет создано два файла.
3)Подготовка: установка нашего сертификата на устройство:
Передаем файл cert.pem на устройство и устанавливаем его в систему. Обращу внимание, что для установки сертификата необходимо, чтобы на телефоне был какая-нибудь защита на экране блокировки (графический ключ, пароль или PIN).
Пошаговая установка сертификата на Android 5.1
Сертификат установлен.
4)Подготовка: переброс портов:
Возвращаемся на Linux, вбиваем в терминал:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -F
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443
iptables -t nat -A PREROUTING -p tcp --dport 587 -j REDIRECT --to-ports 8443
iptables -t nat -A PREROUTING -p tcp --dport 465 -j REDIRECT --to-ports 8443
iptables -t nat -A PREROUTING -p tcp --dport 993 -j REDIRECT --to-ports 8443
iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080
5)Подготовка: Ettercap:
Устанавливаем Ettercap:
sudo apt-get -y install ettercap
После установки его запускаем.
6)Снифинг данных:
Клацаем "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".
7)Конец подготовки: 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 logdir/ 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" - имя Вашего пользователя.
Далее можно просматривать файлы с помощью обычного текстового редактора.
Теперь результаты исследования программы ВКонтакте:
Проснифив только авторизацию, аудиозаписи и вообще первые минуты после авторизации в приложении, уже можно поймать все эти странные запросы. Итак:
Самое странное, что мне показалось - это то, что приложение сливает абсолютно весь список пользовательских приложений, установленных на устройстве. Зачем?! (в центре скрина влепил decoded-строку параметра apps).
Довольно часто промелькивали запросы к некоему сервису vigo.ru. Сервис позиционирует себя как аналитика в передаче, поиска ошибок, проблем и обработке видео. Но странно, ведь я всего лишь авторизовался, перешел в аудио и пролистал свою стену, где не было ни единого видеоролика (которые должны были автоматически проигрываться?), а запросов скопилось около 5-7 штук. Помимо notify еще был network_status.
Вот опять. wallGetWrapNew - по названию понятно, что это запрос на получение чьей-то стены (пользователя или сообщества). Зачем тут передавать информацию о устройстве? Максимум, что приходит на ум - для статистики. Хорошо, а зачем данные о типе сети? Еще, что не относится к сливу информации: довольно раздражает то, что везде пытаются всунуть рекламу - лишь посмотреть на параметр fields.
Приложение отправляет все действия пользователя: перешел через меню в раздел "аудио", "geo_data" - вероятно, отправлял бы примерное (или даже точное) местоположение устройства. Спрашивается, зачем, если пользователь не просит находить что-то по близости? Нет, облегчать пользователю жизнь, подсказывая релевантные данные в поиске, например - в этом ничего плохого нет, но зачем отправлять данные просто так при заходе в аудио? Не понятно.
Приложение делает бенчмарки и зачем-то передает время запроса к API и время загрузки изображений. Видимо, усредненные данные.
Все это - официальное приложение. На момент написания этой статьи (29 июля 2017 года) была версия 4.12.1.
В Kate Mobile таких сливов замечено не было. Единственное, после ввода в эксплуатацию нового алгоритма выдачи аудиозаписей, и Kate, и официальному приложению нужно обращаться к Google Accounts для получения некого receipt-токена. И всё.
О том, как работают приложения на iOS, Windows Phone мне только можно догадываться. Их пакеты не перехватывал, и устройств не имею.
Update 2
Друг-разработчик
Название точки доступа, к которой подключено устройство, а также другие, которые находятся в зоне досигаемости, их сигнал в dB, MAC-адреса.
Плюсом от него же, вот что отправляет официальное приложение для Windows
Только версию системы, версию приложения, метод ввода.
Update 3
А вот, что на самом деле представляет Vigo по описанию Григория:
Отправка местоположения, как оказалось, производится только при просмотре отдельного поста. На аудиозаписи это не влияет, как некоторые стали считать, что в зависимости от региона некоторые треки "скрывается".
Оригинал:
Понравилась одна статья, но больше вторая часть, чем первая, так-что начнём со второй части !
Итак:
1)Подручные средства:
У нас в распоряжении комп под Linux (Ubuntu 16.04 LTS), два телефона на Android 5.1 (Sony Xperia L) и 6.0.1 (Samsung *какой-то там*). У Sony выпилены Google Play Services. На обоих телефонах последняя версия приложения и стороннее приложение - Kate Mobile (версии 37 и 41 соответственно). Ну, и, естественно, единая локальная сеть, к которой подключен и комп, и два устройства.
2)Подготовка: создание сертификата SSL:
Если просто начать снифинг, то мы получим лишь сырые данные, не поддающиеся обработке, поскольку они передаются по протоколу HTTPS - данные зашифрованы. Для того, чтобы получить данные такие, которые мы можем расшифровать, мы меняем сертификат на тот, который мы же и создали. Таким образом мы можем расшифровать этот трафик.
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
Этой командой создаем сертификат, где key.pem - файл ключа, cert.pem - сертификат.
В phrase key вводим что-то типа пароля. Он нам еще понадобится. Затем его еще раз повторить. Остальные поля можно оставить пустыми/не вводить. По окончанию в текущей директории будет создано два файла.
3)Подготовка: установка нашего сертификата на устройство:
Передаем файл cert.pem на устройство и устанавливаем его в систему. Обращу внимание, что для установки сертификата необходимо, чтобы на телефоне был какая-нибудь защита на экране блокировки (графический ключ, пароль или PIN).
Пошаговая установка сертификата на Android 5.1
Сертификат установлен.
4)Подготовка: переброс портов:
Возвращаемся на Linux, вбиваем в терминал:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -F
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443
iptables -t nat -A PREROUTING -p tcp --dport 587 -j REDIRECT --to-ports 8443
iptables -t nat -A PREROUTING -p tcp --dport 465 -j REDIRECT --to-ports 8443
iptables -t nat -A PREROUTING -p tcp --dport 993 -j REDIRECT --to-ports 8443
iptables -t nat -A PREROUTING -p tcp --dport 5222 -j REDIRECT --to-ports 8080
5)Подготовка: Ettercap:
Устанавливаем Ettercap:
sudo apt-get -y install ettercap
После установки его запускаем.
6)Снифинг данных:
Клацаем "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".
7)Конец подготовки: 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 logdir/ 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" - имя Вашего пользователя.
Далее можно просматривать файлы с помощью обычного текстового редактора.
Теперь результаты исследования программы ВКонтакте:
Проснифив только авторизацию, аудиозаписи и вообще первые минуты после авторизации в приложении, уже можно поймать все эти странные запросы. Итак:
Самое странное, что мне показалось - это то, что приложение сливает абсолютно весь список пользовательских приложений, установленных на устройстве. Зачем?! (в центре скрина влепил decoded-строку параметра apps).
Довольно часто промелькивали запросы к некоему сервису vigo.ru. Сервис позиционирует себя как аналитика в передаче, поиска ошибок, проблем и обработке видео. Но странно, ведь я всего лишь авторизовался, перешел в аудио и пролистал свою стену, где не было ни единого видеоролика (которые должны были автоматически проигрываться?), а запросов скопилось около 5-7 штук. Помимо notify еще был network_status.
Вот опять. wallGetWrapNew - по названию понятно, что это запрос на получение чьей-то стены (пользователя или сообщества). Зачем тут передавать информацию о устройстве? Максимум, что приходит на ум - для статистики. Хорошо, а зачем данные о типе сети? Еще, что не относится к сливу информации: довольно раздражает то, что везде пытаются всунуть рекламу - лишь посмотреть на параметр fields.
Приложение отправляет все действия пользователя: перешел через меню в раздел "аудио", "geo_data" - вероятно, отправлял бы примерное (или даже точное) местоположение устройства. Спрашивается, зачем, если пользователь не просит находить что-то по близости? Нет, облегчать пользователю жизнь, подсказывая релевантные данные в поиске, например - в этом ничего плохого нет, но зачем отправлять данные просто так при заходе в аудио? Не понятно.
Приложение делает бенчмарки и зачем-то передает время запроса к API и время загрузки изображений. Видимо, усредненные данные.
Все это - официальное приложение. На момент написания этой статьи (29 июля 2017 года) была версия 4.12.1.
В Kate Mobile таких сливов замечено не было. Единственное, после ввода в эксплуатацию нового алгоритма выдачи аудиозаписей, и Kate, и официальному приложению нужно обращаться к Google Accounts для получения некого receipt-токена. И всё.
О том, как работают приложения на iOS, Windows Phone мне только можно догадываться. Их пакеты не перехватывал, и устройств не имею.
Update 2
Друг-разработчик
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
добавил ещё скринов того, что сливается официальным приложением под Android.
Название точки доступа, к которой подключено устройство, а также другие, которые находятся в зоне досигаемости, их сигнал в dB, MAC-адреса.
Плюсом от него же, вот что отправляет официальное приложение для Windows
Только версию системы, версию приложения, метод ввода.
Update 3
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
, разработчик модификации официального приложения VK Coffee, прокомментировал этот пост так:
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
, бывший разработчик этого самого приложения, как оказывается, был сам против включения сервисов Vigo в приложение:А вот, что на самом деле представляет Vigo по описанию Григория:
Отправка местоположения, как оказалось, производится только при просмотре отдельного поста. На аудиозаписи это не влияет, как некоторые стали считать, что в зависимости от региона некоторые треки "скрывается".
Оригинал:
Вы должны зарегистрироваться, чтобы увидеть внешние ссылки
