Автор: Elliot Alderson
На дворе 2020 год, и американский президент собирается забанить ТикТок (мобильное приложение социальной сети для публикации видео), поскольку «этот сервис несет риски для национальной безопасности США». В то же время компания Microsoft задумалась о покупке ТикТока. В последнее время эта социальная сеть получила массу внимания со стороны СМИ, но насколько приведенная информация достоверна? На этот вопрос я и попытаюсь ответить в этой серии статей. Каждая заметка будет отвечать на конкретный вопрос. Пришло время выложить факты на всеобщее обозрение.
Предварительные замечания
-
Благодаря миллионам строк кода, в распоряжении пользователей ТикТока есть масса функций. Соответственно, в одной статье нельзя полностью раскрыть такой широкий и расплывчатый вопрос «представляет ли ТикТок угрозу для национальной безопасности США». Поэтому я запланировал написать несколько статей, каждая из которых будет посвящена конкретной теме.
-
Меня зовут Батист Роберт. Я – француз. Работаю в сфере безопасности. Последние годы занимаюсь анализом мобильных приложений. С моими статьями можно ознакомиться по адресу fs0c131y.com/press. Мой Твиттер: twitter.com/fs0c131y.
-
Моя основная задача – быть полностью откровенным с вами. Я поделюсь всем необходимым, чтобы вы смогли проверить написанное в этой статье.
-
Если вы не хотите вдаваться в технические детали, в конце статьи приведены выводы по результатам моих исследований.
Введение
2 августа 2020 года я начал исследовать ТикТок и написал твит по этому поводу.
Рисунок 1: Первоначальный твит, посвященный исследованиям ТикТока
Через несколько минут после публикации твита, я получил комментарий от одного из моих подписчиков.
Рисунок 2: Ответ одного из подписчиков
Мы пообщались в личных сообщениях, и мой собеседник рассказал о проблеме. Во время анализа сетевого трафика, имеющего отношение к ТикТоку, был замечен запрос, отсылаемый каждые две минуты. Однако содержимое запроса было зашифровано, а расшифровать не получилось.
В результаты беседы сформировались вопросы для исследования:
-
Какую информацию ТикТок отсылает на регулярной основе?
-
Когда происходит отсылка?
-
Куда происходит отсылка?
-
Как шифруется содержимое?
Что ТикТок отсылает на регулярной основе?
Во время отладки чего-либо 90% процентов времени уходит на воспроизведение проблемы. Соответственно, первое, что я попытался сделать, - воспроизвести проблему. Что было сделано:
-
Скачана последняя версия мобильного приложения ТикТок из французского PlayStore.
-
Установлен Burp Suite для перехвата сетевых запросов, выполняемых моим телефоном.
-
3. Использован скрипт Frida для обхода SSL pinning (привязки сертификата или публичного ключа сервера к клиенту) в приложении и запустил ТикТок.
Рисунок 3: Запросы, перехваченные приложением Burp Suite
По результатам анализа выяснилось, что ТикТок отсылает сетевые запросы с зашифрованным содержимым каждые 5 минут.
Конечный пункт /service/2/app_log/
Обратим внимание на запросы, отсылаемые по адресу /service/2/app_log/.
Рисунок 4: Содержимое POST-запроса, отсылаемого по адресу /service/2/app_log/
Параметры
Перед изучением зашифрованного содержимого обращаем внимание, что запрос состоит из огромного количества параметров.
Рисунок 5: Параметры отсылаемого запроса
Большинство имен говорит само за себя. Все параметры можно разделить на три категории:
-
Информация об устройстве: device_id, device_type, device_brand, os_api, os_version, …
-
Информация о приложении: app_type, app_language, version_code, version_name, build_number, …
-
Информация о пользователе: current_region, locale, region
На самом деле в вышеуказанной категоризации нет ничего удивительного. Мы имеем дело со стандартной практикой, и вы можете быть уверены, что у большинства используемых вами приложений технология сбора данных примерно одинаковая.
Зашифрованное содержимое
Пришло время взглянуть на зашифрованный контент! Эта часть будет довольно веселой. Я декомпилировал приложение, выполнил поиск по слову «app_log» и тут же нашел метод sendEncryptLog, принадлежащий классу com.ss.android.common.applog.NetUtil.
Рисунок 6: Содержимое метода sendEncryptLog
Плохо разбираетесь в коде? Ничего страшного. Взгляните на сигнатуру метода. На входе 4 параметра: arg4 – URL, arg5 – содержимое запроса (незашифрованное). Остальные два параметра нас пока не интересуют.
Теперь я воспользуюсь скриптом Frida с целью перехвата вызова этого метода и изучения содержимого запроса перед шифрованием.
Рисунок 7: Метод для перехвата содержимого запроса
Я воспользовался методом TTencryptedLog и получил следующие результаты:
Рисунок 8: Содержимое перехваченного запроса перед шифрованием
Файл JSON содержит довольно стандартные данные:
-
Как и прежде, много информации об устройстве.
-
Когда приложение было запущено в последний раз.
-
Регистрация событий. Мне нужно было бы внимательнее взглянуть, что подразумевается под «событиями», но насколько я могу судить, речь идет о довольно стандартной аналитике.
Когда происходит отсылка запроса?
Частота отсылки запроса равна частоте вызова метода sendEncryptLog. Нажав клавишу X в приложении JEB, вы можете легко получить все перекрестные ссылки.
Рисунок 9: Места вызова метода sendEncryptLog
Было найдено 4 метода:
- doUpdateConfig
- sendTimelyEvent
- sendLog
- неизвестный метод из пакета deviceRegister
Метод sendEncryptLog используется для отправки другого типа JSON. Я очистил данные, имеющие отношение к ТикТоку, и начал всё заново. По итогу мне удалось отловить следующие JSON’ы:
Содержимое запроса во время регистрации устройства:
Рисунок 10: JSON-данные во время регистрации устройства
Содержимое запроса, когда ТикТок изменяет настройки логов:
Рисунок 11: JSON-данные во время изменения настройки логов
И снова имена говорят сами за себя. В вышеуказанных JSON’ах я не вижу ничего подозрительного или специфического, касающегося ТикТока.
Куда происходит отсылка?
По предыдущим скриншотам видно, что запросы отсылаются по адресу log16-normal-c-useast1a.tiktokv.com. Забавно наблюдать, что я нахожусь в Европе, а мои логи отсылаются на восток США. ТикТок распространен по всему миру, и, вероятно, используется несколько узлов для хранения логов.
После более подробного изучения кода находим класс URLConfig.
Рисунок 12: Создание нескольких экземпляров класса URLConfig
По рисунку выше видно, что есть 7 конфигураций: China, America, America HTTP, SIG AWS, SIG ALIYUN (Alicloud Singapore), Musically, Musically HTTP.
Кажется довольно странным, что нет конфигурации для Европы, но ладно.
Как шифруется содержимое?
Помните метод sendEncryptLog?
Рисунок 13: Содержимое метода sendEncryptLog
Шифрование происходит в строке v5 = b.a(v5, v5.length);
Рисунок 14: Функция шифрования запроса
Начиная с класса EncryptorUtil начинается самое забавное:
Рисунок 15: Содержимое класса EncryptorUtil
Шифрование выполняется нативной библиотекой. Все нативные библиотеки, используемые ТикТоком, находятся в папке /data/data/com.zhiliaoapp.musically/app_librarian/<version> на вашем телефоне. На этом мои исследования на время приостанавливаются. Освещение темы шифрования данных в ТикТоке заслуживает отдельной статьи. К тому же сейчас 12 ночи, и я довольно голоден.
Заключение
В этой статье я попытался понять, какие данные ТикТок регулярно отсылает на свои сервера. Я расшифровал и проанализировал содержимое запросов. Как мы можем видеть, на данный момент ТикТок не замечен в чем-то подозрительном и в отсылке специфических данных. Получение информации об устройства пользователя вполне стандартная практика для мобильных приложений. Схожие сведения собирает Facebook, Snapchat, Instagram и другие популярные сервисы.
Надеюсь, вам понравилась эта статья. В скором времени появятся остальные части. Не забудьте подписаться на мой Твиттер. Если у вас есть какие-либо вопросы, не стесняйтесь написать мне сообщение в Твиттере или по почте fs0c131y@protonmail.com.
