Вступление

TikTok одно из самых популярных приложений для просмотра мобильного видео. В нём зарегистрировано 800 миллионов пользователей. Пользователи создают контент с помощью фильтров, музыки, эффектов. Видео создаются странные, но захватывающие внимание.

Для столь обширной и популярной платформы развлечения есть очень большой пласт минусов, которые постепенно становятся явными для СМИ. Незащищенный HTTP трафик и спуфинг СМС ссылок это конкретные примеры уязвимости, которые были обнаружены в приложении за последние 3 месяца. Несмотря на это, люди продолжают публиковать видео. Показывают, в какие школы они ходят, видео внутри и за пределами своих домов и даже раздают телефонные номера и другую личную информацию. Именно с этой темы стоит и начать нашу статью.

OSINT технологии

Большинство пользователей TikTok молодые подростки, которые не понимают в чем заключается опасность распространения личной информации. TikTok подвергается различным трендам, которые в свою очередь вовлекают в раскрытие персональной информации, включая: паспорта, номера телефонов, email, ссылки на свои социальные сети, информацию кредитных карточек и множество других данных.

Поисковая строка

Одна из самых интересных функций TikTok это поиск видео различного контента, который находится в кнопке Discover. После нажатия на нее экран меняется на ленту из самого популярного контента, но главная часть этой вкладки это поисковая строка вверху экрана. В ней можно вбивать все подряд, начиная от имен пользователей, наименований песен, хештегов и заканчивая ключевыми фразами челленджей. В качестве примера давайте возьмем ключевую фразу: find my number (Примеры других запросов Call me / Phone Me / Угадай мой номер / Позвони мне / Credit Card / Debit Card)


Результаты сами дают знать о себе на главной странице. В качестве более качественного примера поиска информации выбираем из всех вкладок Хештеги и нажимаем на самое первое поле. На различных видео пользователи по частям показывают свои номера. Могут весь полностью, но без последней цифры. Легко найти спрятанные цифры на экране или предугадать последнюю цифру методом перебора.

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


Вот еще несколько примеров, где пользователи размещают адреса электронных почт. Данные видео были обнаружены по запросу в поиске gmail.com, а также по хештегам: email me.

Аудио Дорожка

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


Еще один из примеров представляет собой звуковую дорожку, которая называется Your I.D. will always Humble you. Под ней пользователи записывают видео со своей фотографией из своих документов удостоверения личности. Конечно, многие из них не раскрывают документы в полном объеме. Однако, на большинстве есть личная подпись и дата рождения под своей фотографией. Просмотрев много видео, опубликованных с этой звуковой дорожкой, точно можно найти тех, кто показал полный разворот удостоверения личности.

Получение дальнейшей информации

После того как данная информация стала доступна, последовал логический вопрос: а что еще возможно обнаружить, исходя из номеров телефонов и электронных почт?

Дальнейший поиск данных на основе полученной информации происходит через использование Lampyre. Он позволяет искать идентификаторы и возвращать данные, которые зарегистрированы на введенной электронной почте или номере телефона. Такие запросы обычно выдают точные и достаточно уникальные результаты.

Ниже был совершен поиск по трем телефонным номерам из США. Результаты показали, что двое из номеров вернули связанные аккаунты из Instagram и Twitter вместе с соответствующими ID и ссылками на их профили. Хоть и в этот раз было показано немного информации, можно получить гораздо больше. Это зависит только от поставленной цели и от того, какой номер телефона пользователи используют при регистрации. Для поиска в Instagram воспользуйтесь нашим приложением [Nuga], о котором мы писали недавно. Другой номер выдал больше информации и показал, что он подключен к учетной записи WhatsApp и Skype. Теперь добавляем и проверяем на наличие учетных записей через список контактов.



Ниже приведен пример поиска по электронной почте через Lampyre. Здесь он вернул частичную информацию, такую как номер телефона от LinkedIn и Apple, прямую ссылку на их учетную запись Facebook и подтверждение того, что электронная почта используется в Instagram и TikTok:



Lampyre можно использовать 4 раза бесплатно за одну регистрацию, потом нужна платная подписка или покупка дополнительных токенов. Конечно, можно создавать аккаунты на временные почты и использовать инструмент в ваше удовольствие, искать и анализировать всю информацию предоставленную в результатах Lampyre.

OSINT TOOL

Сбор основной информации пользователя это также еще один из способов получения пассивных данных из TikTok. Конечно, это можно сделать вручную, записав все ключевые метаданные профиля. Однако, есть более автономный и удобный в применении инструмент, предназначенный для сбора подобной информации TikTok OSINT Toolkit.

Он позволяет автономно собрать все публичные данные пользователя TikTok, такие, как:

• Наименование профиля
• Картинка профиля
• Количество подписчиков
• Количество подписок
• Данные профиля
• Подтверждение профиля
• Количество поклонников
• Количество лайков
• Количество видео
• Идентификационный номер профиля

Инструмент написан на Python 3 и использует обширный пакет BeautifulSoup, значительно упрощающий сбор всей информации, которую можно получить из URL пользователя. Инструмент исполняется через команду:

python3 tiktokOSINT.py --username {USERNAME} --downloadProfilePic

Главный параметр это имя пользователя, через которое производится HTTP запрос, на HTML страницу профиля. Впоследствии собирается вся информация на странице, происходит поиск по критерию application/json. И выборочно, данные, которые находятся у пользователя, заполняются в массив и сохраняются в одной папке вместе с инструментом. В дополнение программа дублирует текстовую информацию о пользователе в командной строке.

В качестве примера ниже показана командная оболочка Unix, через которую можно получить результаты пользователя juliagodunova:


В качестве небольшого бонуса похожий инструмент также доступен в онлайн, но немного в лимитированной форме. Функциональность инструмента заключена также в посылке запроса HTTP со ссылкой профиля пользователя. Только в этом случае сервер ответит при помощи того же JSON файла и упорядочит всю нужную информацию на странице. В нем заключаются 3 главные функции:

1. Поиск профиля пользователя по его имени
2. Поиск видео с указанным хештегом
3. Метаданные пользователя с помощью его имени

Информационный поиск по URL

Хештеги

В приложении TikTok есть специальная вкладка для поиска видео при помощи хэштегов, которая также находится в поисковой строке. Но есть альтернативный способ поиска. Самый распространенный это ссылка на официальный сайт TikTok. Если вы знаете точный и интересующий вас хэштег, можно перейти к следующему URL адресу, заменив test на интересующую вас категорию.

www.tiktok.com/tag/test

Имена пользователей

TikTok имеет опцию поиска имени пользователя, которая работает точно так же, как и при поиске хэштега. Если вы знаете имя пользователя вашей цели, вы можете перейти непосредственно к профилю с помощью следующего URL адреса. Замените test на имя выбранного вами пользователя.

www.tiktok.com/@test

Комментарии

Подобно любой другой социальной сети пользователи TikTok оставляют комментарии к сообщениям различных пользователей. Их можно просматривать рядом с каждым видео-контентом, но, к сожалению, они не находятся в исходном коде. Для автономного процесса сбора такой информации воспользуйтесь exportcomments.com. Достаточно лишь скопировать URL видео TikTok в поле поиска и дождаться завершения процесса. Ниже приведен отрывок, который включает в себя точные имена пользователей, дату, время, лайки и комментарии к целевой записи.

Видео TikTok

При поиске интересующего видео на TikTok оригинальная ссылка на страницу видео не предлагает функцию загрузки, а щелчок правой кнопкой мыши не предоставляет никаких полезных опций, в том числе, как и исходный код файла. Вместо этого следует полагаться на сторонние сайты, как например Experts PHP.


Служба Experts PHP передает URL адрес выбранного видео на официальный видео сервер TikTok и дает прямую ссылку на просмотр и скачивание видео в 720p. А теперь давайте рассмотрим пример, как с помощью уязвимости серверов TikTok, можно подделать видео для любого пользователя.

Уязвимости, расширяющие возможности OSINT в TikTok

Интеграция собственного видео на заглавном экране

Приложение TikTok использует небезопасный протокол HTTP для загрузки всего своего медиа-контента. Как и многие приложения, предназначенные для социальных сетей или с большой и активной базой пользователей, TikTok использует сети доставки (и дистрибуции) содержимого контента (CDN) для плотного распределения своих массивных данных в рамках всего мира. Выбор в пользу CDN, TikTok объясняет более быстрой передачей видео и других мультимедийных данных по протоколу HTTP. Хоть это и повышает скорость и производительность передачи файлов, использование незащищенного трафика ставит под угрозу личные данные и конфиденциальность пользователей. Анализ HTTP протокола может быть вполне легко отслежен и изменен со стороны посредника.

На момент написания этой статьи, в версиях TikTok для iOS (версия 15.5.6) и для Android (версия 15.7.4) использовался обычный HTTP для подключения к CDN сетям TikTok. После небольшого сеанса перехвата и анализа сетевого трафика из TikTok с помощью Wireshark, можно с легкостью заметить сетевые запросы с пакетами видео и изображений, которые передаются в полностью открытом и незашифрованном виде.

Ниже, в качестве примера показан сетевой трафик, перехваченный Wireshark:


Таким образом, TikTok наследует все известные и хорошо задокументированные уязвимости HTTP. Любой маршрутизатор, установленный между приложением TikTok и его CDN, может очень легко документировать все сетевые пакеты с видео, которые пользователь скачал и просмотрел вместе с историей просмотра. Операторы общественных Wi-Fi точек и интернет-провайдеры могут собирать эти данные без особых усилий.

Вот перечень всех данных которые транспортируются через HTTP канал в TikTok:

• Видео все видео, находящиеся в приложении.
• Фотографии все фотографии, включая фотографии профилей предварительного просмотра.
• Видеоизображения изображение предварительного просмотра видео, отображающееся при загрузке видео.

Все типы контента, перечисленные выше, подвержены отслеживанию. Например, история наблюдения может быть создана путем захвата сетевого трафика, загруженного с http://v34.muscdn.com.

MITM-атака может полностью изменить загруженный контент в вашем телефоне. Однако, значительным ограничением данной атаки служит факт того, что пользователь должен находиться вместе с злоумышленником в одной локальной сети. Только таким образом злоумышленник сможет вклиниться в канал (с использованием атаки ARP Spoofing) и передавать большое количество поддельных фактов в замененном видео, которые могут принадлежать знаменитостям или доверенной учетной записи пользователей.

Замена и распространение вводящих в заблуждение фальшивых видео на такой интерактивной платформе как TikTok, представляет огромный риск. В качестве примера, далее будут выявлены риски возможных атак посредника для замены видео и анализа результатов.

Метод применения

Была подготовлена небольшая сборка поддельных видео, размещенных на сервере, который эмулирует сервера TikTok, а именно v34.muscdn.com. Для демонстрационных целей были созданы только сценарий и условия, которые меняют видео. Были сохранены в оригинале фотографии профилей, хотя они могут быть также изменены аналогичным способом. Было эмитировано поведение только одного видеосервера для хорошего сочетания поддельных и реальных видео, чтобы вызывать чувство доверия у пользователей.

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

Вся уловка состоит в том, чтобы перенаправить приложение на созданный сервер. Это можно сделать просто добавив новую ресурсную запись в DNS, которая сопоставит имя домена v34.muscdn.com с IP-адресом поддельного сервера.

Аналогично подобное может быть сделано лицами, которые напрямую имеют доступ к маршрутизаторам пользователей. Сначала необходимо изменить файл hosts на устройстве жертвы, перенаправляющем имя домена v34.muscdn.com на фальшивый сервер. Затем, измененные маршрутизаторы должны быть настроены на использование этого DNS-сервера. Теперь, когда приложение TikTok запрашивает IP-адрес у v34.muscdn.com, DNS возвращает IP адрес поддельного сервера. В дальнейшем все последующие запросы на фальшивый сервер, который выдает себя за v34.muscdn.com от TikTok будут задаваться автоматически.

Такие действия могут быть выполнены следующими лицами:

1. Операторы Wi-Fi: операторы общественных сетей Wi-Fi могут настроить маршрутизатор на использование уязвимого DNS сервера.
2. Провайдеры VPN: провайдер VPN может настроить свой DNS сервер для всех пользователей использующих его сервис.
3. Интернет-провайдеры (ISP): Интернет-провайдеры, предоставляющие доступ к интернету, имеют полный доступ к соединениям своих клиентов. Они могут перенастроить DNS сервер для того, чтобы обмениваться контентом или отслеживать действия пользователей

Если вы не доверяете ни одному из лиц приведенных выше, то есть шанс на то, что контент, который вы смотрите в TikTok, возможно, был уже изменен. Это может также относиться к любому интернет-сервису, который использует HTTP протокол для передачи данных.

Ниже показан сетевой трафик HTTP, направленный на поддельный сервер. Выделенная строка является запросом на видео, отправленное приложением на входящий IP адрес 192.168.13.2, который является адресом поддельного сервера. Затем, этот же сервер выбирает подготовленное видео и возвращает его в приложение, которое в свою очередь, воспроизводит выбранное видео пользователю, как показано в демонстрационном видео. Обратите внимание, что на поддельный сервер направляются только видео запросы, так как запросы на фотографии профиля и пользователей были оставлены без изменений, и они перенаправляются на настоящие сервера.


youtu.be/voTnYPfkqlY

Созданные видеоролики содержат вводящую в заблуждение информацию о COVID-19. Таким образом был показан пример о реальном и потенциальном источнике распространения дезинформации и ложных фактов современной проблемы.

Пользователи, которые были подключены только к локальному маршрутизатору, могут видеть такой вредоносный контент. Однако, если DNS сервер крупного интернет провайдера был взломан для добавления собственной записи DNS, то как это было продемонстрировано ранее, вводящая в заблуждение информация или фальшивые новости будут просматриваться в глобальном масштабе.

SMS Спуфинг

На официальном сайте TikTok есть интересная функция, которая позволяет отправить SMS сообщение для загрузки приложения на указанный мобильный номер пользователя. Уязвимость взлома аккаунта, посредством этого функционала, была обнаружена. И в качестве примера она будет продемонстрирована ее в этой части.

Злоумышленники, желающие отправить SMS-сообщение потенциальной жертве, могут перехватить HTTP-запрос, используя прокси-инструмент (например, Burp Suite). Параметр Mobile содержит номер телефона, на который будет отправлено SMS, а параметр download_url это ссылка, появляющаяся в сообщении SMS:


Пример такого SMS сообщения:


При изменении параметра download_url оригинальная ссылка будет изменена, и она будет содержать другую, которая была выбрана для дальнейшей атаки. На картинке ниже показано сфабрикованное SMS-сообщение, содержащее вредоносную ссылку. Для демонстрации была использована следующая ссылку attacker.com

Фальшивое SMS-сообщение, содержащее ссылку https://attacker.com:


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

Основными связями, через которые приложение принимает запросы, являются https://m.tiktok.com и musical: //:


Злоумышленники, использующие вышеописанную функциональность, могут перехватить запрос и отправить свой собственный, который будет содержать ссылки на вредоносные сервера, упомянутые выше. Так как пользовательская ссылка будет содержать параметр url, мобильное приложение откроет окно веб-просмотра через браузер телефона и перейдет на веб-страницу, записанную в параметре из кода мобильного приложения. Таким образом, любой запрос будет отправлен вместе с cookie пользователя.

Для демонстрации была использована следующая ссылка:


Ниже была продемонстрирована переадресация глубокой ссылки в самом приложении:


Впоследствии мобильное приложение открывает окно веб-просмотра (браузера) и переходит на созданный веб сервер: http://10.10.10.113:8000. С помощью которого в дальнейшем можно будет отправлять запросы от имени пользователя.

Перенаправление пользователя

В ходе исследований было обнаружено, что потенциальная жертва, нажав на отправленную ссылку, будет перенаправлена на вредоносный веб-сайт. Само перенаправление дает возможность выполнения таких атак: атаки межсайтовых сценариев (XSS), подделки межсайтовых запросов (CSRF) и раскрытия конфиденциальных данных пользователя.

Перенаправление происходит когда злоумышленник, отправляет оригинальную ссылку для входа, полученную из официального домена Tiktok: login.tiktok.com.

Было обнаружено, что запрос на логин в систему может содержать HTTP GET redirect_url. Поэтому пример запроса на аутентификацию, который в итоге будет перенаправлять пользователя на другой сайт после успешного входа, выглядит вот так:

login.tiktok.com/?redirect_url=www.tiktok.com

Измененное значение внутри redirect_url будет перенаправлять потенциальную жертву на веб-страницу домена tiktok в соответствии со следующим Regex выражением (выполняется только на клиентской стороне):


Regex выражение не проверяет значение параметра redirect_url должным образом. Скорее оно проверяет значение параметра, содержащее текст tiktok.com. Что дает возможность сделать перенаправление на другое доменное имя, которое содержит tiktok.com.

В демонстрационных целях злоумышленник может перенаправить пользователей на веб-сайт www.attacker-tiktok.com и выполнить дополнительные атаки, направленные на кражу личной информации.

Межсайтовый скриптинг (XSS)

В ходе исследования было обнаружено, что поддомен Tiktok https://ads.tiktok.com уязвим для атак XSS, при которых вредоносные скрипты внедряются в другие безопасные и надежные веб-сайты. Справочный центр, доступный по адресу https://ads.tiktok.com/help/, содержит информацию о том, как создавать и публиковать объявления в Tiktok. Здесь также была обнаружена точка внедрения XSS-атаки в функцию поиска. Когда злоумышленник пытается выполнить поиск, на сервер веб-сайта выполняется запрос HTTP GET с параметром q и искомой строкой в качестве значения для поиска.

На следующей картинке показан обычный запрос на поиск, выполненный злоумышленником при поиске слова pwned:

ads.tiktok.com/help/search?q=pwned


А вот здесь злоумышленник может попытаться внедрить код JavaScript в параметр q (введенное значение имеет кодировку URL). Для демонстрации был создан запрос: открыть окно в браузере с предупреждением xss:

ads.tiktok.com/help/search?q=%22%3Cscript%20src%20%3Djavascript%3Aalert%28%29%3E

Управление аккаунтом пользователя TikTok

Межсайтовая подделка запросов (CSRF)

После завершения предыдущих тестов и анализа всей информации можно использовать код JavaScript двумя способами: в виде XSS атак или перенаправления пользователя на вредоносный веб-сайт, который отправит все запросы на Tiktok при помощи файлов cookie пользователя.

Из-за отсутствия механизма предотвращения подделки анти-межсайтовых запросов можно будет легко запускать предоставленный JavaScript код и выполнять действия от имени пользователя без его согласия.

Удалить видео

Удалить видео можно выполнить при помощи HTTP GET-запроса по ссылке написанной ниже, заменяя ID видео:

api-t.tiktok.com/aweme/v1/aweme/delete/?aweme_id=video_id.

Используя запрос JavaScript, отправляется HTTP GET запрос на удаление видео, указав его идентификатор. На следующей картинке показан сам запрос на удаление видео с идентификационным номером 6755373615039991045:


Подтверждение от сервера, что видео было успешно удалено:

Создать видео

Чтобы создать видео на профиле пользователя, для начала следует отправить запрос на создание видео в своей ленте. Запросы на создание видео будут генерировать новый видео идентификатор. Дальше, копируем сгенерированную ссылку на создание видео и отправляем HTTP POST запрос от имени другого пользователя.

Ниже показан запрос на создание видео в ленте потенциальной жертвы:


В параллели получаем вот такой положительный ответ от сервера:

Подписка на выбранного пользователя

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

Запрос на утверждение отправляется через HTTP POST через следующую ссылку:

api-m.tiktok.com/aweme/v1/commit/follow/request/approve

Внутри самого запроса POST есть параметр from_user_id, содержащий идентификатор пользователя, который хочет быть подписчиком пользователя.

Изменяем значение параметра from_user_id на свой собственный и отправляем запрос на сервер TikTok:


На этом этапе злоумышленник становится подписчиком потенциальной жертвы:

Изменить настройки общедоступности видео

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

После того как злоумышленник сможет получить идентификатор видео частного доступа, возможно изменить настройки конфиденциальности видео, отправив запрос HTTP GET от имени пользователя:

api-m.tiktok.com/aweme/v1/aweme/modify/visibility/?aweme_id=video_id&type=1&aid=1233&mcc_mnc=42503

Самые главные параметры этой ссылке это type и video_id. Video_id это ID видео, доступ которого нужно изменить. А type это режим доступности видео. При type = 1 запрашиваемое видео будет изменено на общедоступный режим, а type = 2 приведет к тому, что видео станет частным.

Ниже показан HTTP GET запрос для изменения идентификатора видео 6755813399445261573 из частного режима в публичный:


Ответ сервера показывает, что видео стало публичным и доступным для всех:

Разоблачение конфиденциальной информации

Исследование показало, что можно выполнять код JavaScript, используя XSS или другие методы для получения конфиденциальной информации. Было обнаружено несколько вызовов API в поддоменах https://api-t.tiktok.com и https://api-m.tiktok.com. Запросы к таким API-интерфейсам помогут раскрыть конфиденциальную информацию о пользователе, включая адрес электронной почты, информацию об оплате, дату рождения и многое другое.

При попытке использовать описанные выше уязвимости через JavaScript, была обнаружена проблема, в виде защитного механизма от перекрестного общего доступа к ресурсам (CORS) и ограничениями безопасности в Same Origin Policy (SOP).

Поддомены приведенных API позволяют сделать запрос только на определенные источники (например, www.tiktok.com). В качестве примера ниже продемонстрирован запрос API, который был сделан с https://cpr.checkpoint.com:


В итоге ответ с сервера был заблокирован из-за установки ограничений безопасности:


Таким образом нужно было найти лазейку для обхода механизмов безопасности CORS и SOP, чтобы извлечь всю приватную информацию, которая там хранится.

В процессе последующего анализа было обнаружено, что сервера TikTok реализовали нетрадиционный вызов JSONP, с помощью которого был получен доступ к данным пользователя через API, обходя ограничения по безопасности CORS и SOP. Этот метод позволит позаимствовать всю конфиденциальную информацию пользователя через данные JSON, с помощью AJAX запроса.

На следующем примере показан AJAX-запрос на получение всей конфиденциальной информации, связанной с кошельком пользователя. Запрос содержит параметр обратного вызова, а его значение это функция JavaScript, которая будет выполняться (myCallBackMethod):


В примере показаны данные, содержащие всю конфиденциальную информацию, полученную из API. Конфиденциальные данные были получены и могут быть отправлены на сервер злоумышленников:

Вывод

Самостоятельно собрать все необходимые метаданные с любого пользователя вручную не составляет особого труда и без особых знаний доступно каждому. Более удобную и простую замену мануальных действий дают автономные инструменты и автоматические запросы на профили.

После проведения анализа стало понятно, что далеко не все приложения являются безопасными для хранения личной информации. Использование таких уязвимостей, как СМС спуфинг и анализ сетевого протокола HTTP, позволяют расширить обычные возможности использования OSINT технологий в анализе данных пользователей. Использование обычного протокола HTTP вместо HTTPS дает возможность не только просматривать входящий и исходящий трафик, но и получать запросы и информацию пользователя TikTok: видео, активность юзера, его видеоизображения и фотографии. А неправильно настроенные каналы для обработки и передачи информации, которые впоследствии способствуют спуфингу или возможного DDOS, помогают перехватывать точные номера телефонов для дальнейшего обратного поиска всех связующих социальных аккаунтов пользователя.

Так как же все-таки правильно обеспечить конфиденциальную защиту своей информации в TikTok? Если говорить о сборе публичной информации, то один из способов это включение настроек приватного аккаунта, который позволяет скрыть всю информацию от публичного доступа. В случае с продемонстрированными атаками ответ остается одним и тем же: Если хочешь пользоваться, то ответственность лежит только на тебе.

Анализ всех демонстрационных атак показал риски, связанные с одним из самых популярных и широко используемых социальных приложений в мире. Проведенные атаки усиливают насущную потребность в конфиденциальности и безопасности данных в виртуальном мире интернета. Наши данные хранятся в большом количестве сетей и в них хранится самая ценная информация.

Электронная коммерция одна из самых больших и быстро растущих областей, в связи с чем она привлекает внимание как исследователей информационной безопасности, так и злоумышленников. Поэтому хотелось бы разобраться в некоторых аспектах механизмов безопасности, применяемых при проведении онлайн-платежей.

Один из протоколов, используемых для увеличения безопасности онлайн-платежей 3D Secure. Это протокол, который был разработан на основе XML в качестве дополнительного уровня безопасности платежей, проводящихся без физического участия карты (card not present payment). VISA создала первую версию этого протокола, но вскоре его начали использовать и другие компании (Master Card, JCB International, AmEx, Мир), впоследствии объединившиеся с VISA в содружество EMV. EMV занимается поддержкой и развитием протокола 3DS.

Почему протокол 3D Secure называется именно так?

Полное название этого протокола Three Domain Secure.
Первый домен домен эмитента это банк, выпустивший используемую карту.
Второй домен домен эквайера это банк и продавец, которому выплачиваются деньги.
Третий домен домен совместимости (interoperability domain) инфраструктура, используемая при оплате картой (кредитной, дебетовой, предоплаченной или другими типами платежных карт) для поддержки протокола 3D Secure. Он включает в себя Интернет, подключаемый модуль продавца (merchant plug-in), сервер контроля доступа (access control server) и других поставщиков программного обеспечения.

Зачем это нужно?

3D Secure обеспечивает новый уровень безопасности путем предоставления дополнительной информации.
Еще одним важным моментом является перенос ответственности. Это означает, что в случае мошенничества вся ответственность ложится на банк-эмитент. Этот момент является очень важным для продавца (мерчанта), т.к. до появления 3D Secure урегулированием спорных вопросов приходилось заниматься мерчанту.

Также не стоит забывать о двух важных психологических аспектах: повышении доверия к онлайн-платежам и увеличении конверсии.
Конверсия может быть увеличена за счет обновлений протокола 3DS, направленных на сокращение взаимодействия с пользователем.

Версии протокола 3D Secure

v1.0 - 2001 г -v2.0 - 2014 г - Устарелоv2.1 - 2017 гv2.2 - 2018 г

В настоящее время большинство платежных сервисов используют версию 1.0.2 при проведении онлайн CNP-платежей, запрашивающих OTP-код.
Версия 1.0.2 была создана в 2001 году и в ней есть некоторые проблемы.

На данный момент актуальной версией является v2.2, и EMV планирует, что к концу 2020-го года она будет использоваться везде.

Как это устроено?

Это основная схема, необходимая для понимания всего процесса платежа с использованием механизма 3DS.

На этом рисунке мы видим все три домена, используемые в протоколе, а также последовательность сообщений между всеми участниками платежной операции.

Как это работает?

Главное, что необходимо понять, это то, что при использовании своей карты (виртуальной или реальной) для онлайн-оплаты, вы сталкиваетесь именно с протоколом 3DS. Поэтому сейчас мы проиллюстрируем все этапы совершения онлайн-платежа.

1 Покупатель уже добавил все необходимые ему товары в корзину и нажал кнопку "Оплатить". В этот момент он попадает на страницу MPI-сервиса, где вводит данные своей карты.

После нажатия кнопки оплаты продавец (MPI) инициализирует старт платежного потока и, согласно протоколу, отправляет CRReq-запрос (Card Range Request). Данный запрос необходим, чтобы найти банк-эмитент вашей карты и получить CRR из домена взаимодействия. Этот запрос нас мало интересует.

После этого MPI отправляет VeReq (Verification Request). Этот запрос отправляется банку-эмитенту для проверки того, что 3DS для данной карты включен и карту можно использовать для оплаты.

VeRes (Verification Response) содержит дополнительную информацию для следующего этапа платежа.

Клиенты не могут видеть эти два типа сообщений.

2 MPI создает PaReq (Payment Request) запрос на оплату. Этот запрос отправляется через редирект в браузере клиента.

Итогом отправки PaReq становится отображение запроса на ввод OTP-кода.

3 Клиент вводит OTP-код и возвращается на сайт продавца. Опять же в процессе этого через редирект от банка-эмитента к MPI передается PaRes (Payment Response), который содержит информацию о статусе проверки.

А поподробнее?

CRReq/CRRes для нас не очень важны. А вот VeReq/VeRes рассмотреть нужно.

<?xml version="1.0" encoding="UTF-8"?><ThreeDSecure>  <Message id="999">    <VEReq>      <version>1.0.2</version>      <pan>4444333322221111</pan>      <Merchant>        <acqBIN>411111</acqBIN>        <merID>99000001</merID>        <password>99000001</password>      </Merchant>      <Browser>        <deviceCategory>0</deviceCategory>        <accept>*/*</accept>        <userAgent>curl/7.27.0</userAgent>      </Browser>    </VEReq>  </Message></ThreeDSecure>

В VeReq самым важным параметром является идентификатор сообщения, информация о продавце и PAN карты.

<?xml version="1.0" encoding="UTF-8"?><ThreeDSecure>  <Message id="999">    <VERes>      <version>1.0.2</version>      <CH>        <enrolled>Y</enrolled>        <acctID>A0fTY+pKUTu/6hcZWZJiAA==</acctID>      </CH>      <url>https://dropit.3dsecure.net:9443/PIT/ACS</url>      <protocol>ThreeDSecure</protocol>    </VERes>  </Message></ThreeDSecure>

VeRes возвращает message id, который необходим, чтобы сопоставить запрос с этим ответом. А status enrolled показывает, что карта поддерживается.
Однако наиболее важным параметром в данном сообщении является URL-адрес. Этот параметр указывает, где находится ACS сервер эквайера и куда нужно отправить PaReq.

Pareq

Браузер клиента, совершающего оплату, может произвести достаточно много редиректов по различным компонентам, участвующим в совершении платежа. Так, в России есть некоторое количество запросов, обрабатывающихся на стороне Национальной Системы Платежных Карт. Но сегодня нас интересует только традиционный этап, описанный в спецификации протокола. А именно этап передачи PaReq.

URL: https://site.ru/acs/pareqMD=5ebde4d3-3796-7a4d-5ebd-e4d300003dd0&PaReq=eJxVUstywjAM%2FBUm98QPDDiMcIc2dMoh0AedKb2ljiDpNAFMUgJfXzuFPnzSrjQraWW4aoqPzieafb4pRx4LqNfBUm%2FSvFyPvOfFrS%2B9KwWLzCBGT6hrgwpi3O%2BTNXbydOS96VDocEX9FePaF1IIPwlF6qeoV7Inqeyh9hTcjx9xp%2BDcSNk%2BAQdygVbR6CwpKwWJ3l1PZ0rwQZ9SIGcIBZpppAaSuse7POwC%2BeagTApUy%2FEsmrwE8Xw2WQJpKdCbuqzMUfWFLb4AqM2HyqpqOyTkcDgExabEY3BMyhSbwNRAXB7I70D3tYv2Vq%2FJUzU7Teg8ejjE7xMWn9Z8Hk35fKEtNx4BcRWQJhUqTplklIoOC4c9NuwOgLQ8JIUbRDHK2vW%2BEWxdk%2FG%2F1F8KrO%2FGnuWyywUBNls7v62wZv7EQH5nvrlzlurKGsUGNOwy0ZfhXf5udlkmV7ey98rfmnjpjG6LnGJubeKUslbSASBOhpxvSM7nt9G%2Fb%2FEFnkK9RA%3D%3D&TermUrl=https%3A%2F%shop.ru%2Fgates%2F3ds

Платежный запрос, содержащий PaReq (метод POST), имеет три параметра:
1) MD данные продавца. Он нужен MPI, чтобы сопоставить PaReq и PaRes одной транзакции;
2) PaReq параметр этого платежного запрос. Он содержит всю важную информацию о платеже;
3) TermUrl URL-адрес, на который клиент будет возвращен в конце процесса аутентификации 3D Secure.

Параметры TermURL и MD всегда отражаются в ответе на данный запрос. Поэтому могут встречаться имплементации ACS, уязвимые к атакам типа reflected XSS. В процессе аудита различных систем такие сервера были найдены.

Важный момент 1: ACS сервера обрабатывают все входящие PaReq!

Что входит в параметр PaReq?
Вы можете получить его значение, раскодировав PaReq. Это сделать достаточно легко, потому что PaReq это Xml-> zlib-> base64-> urlencode. Для упрощения работы с этими запросами был написан плагин для burp.

Теперь мы видим, что из себя на самом деле представляет PaReq, а именно сообщение формата xml. Это сообщение содержит информацию о сумме платежа (purchAmount, amount и currency), некоторую информацию о продавце и MessageId (из VeReq).

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

Первая мысль, которая может прийти в голову веб-исследователю, который видит XML-запрос это попробовать выполнить XXE. И это правильный путь!

Но для начала посмотрим на то, что случится, если отправить некорректно сформированный PaReq. Мы получим ошибку! Вот несколько примеров таких ошибок:

<ThreeDSecure><Message id="poEpShmja0A36YWe0JOyr4Zt"><Error><version>1.0.2</version><errorCode>99</errorCode><errorMessage>Permanent system failure.</errorMessage><errorDetail>Failed to build error message.</errorDetail></Error></Message></ThreeDSecure><errorCode>5</errorCode><errorMessage>Format of one or more elements is invalid according to the specification.</errorMessage><errorCode>98</errorCode><errorMessage>Transient system failure</errorMessage><errorCode>4</errorCode><errorMessage>Critical element not recognized</errorMessage>

Ошибка может помочь получить дополнительную информацию о версии ACS. Некоторые из них могут также оказаться полезными для получения данных из XXE.

Раскрутим XXE

Рассмотрим следующий пример:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE ThreeDSecure [<!ENTITY ac SYSTEM "file:///proc/sys/kernel/hostname">]><ThreeDSecure><Message id=123-123-123-123-123-123"><PAReq><version>1.0.2</version><Merchant><acqBIN>510069</acqBIN><merID>&ac;</merID><name>MerchantName</name><country>643</country><url>http://asdas.as</url></Merchant><Purchase><xid>U3Vic2NyaWJlX0B3ZWJyMGNr</xid><date>20181004 21:34:21</date><amount>202000</amount><purchAmount>202000</purchAmount><currency>643</currency><exponent>2</exponent><desc>AcquirerName</desc></Purchase><CH><acctID>DYasdVQAOX6as3dfcxccwzPCR6Q74eS5</acctID><expiry>2209</expiry></CH></PAReq></Message></ThreeDSecure>

acqBIN, merID, xid, date, purchAmount и currency отражаются в PaRes. Однако во всех реализациях ACS, которые мы нашли, удалось использовать только merID. Остальные параметры проверяются на соответствие типам данных.

Еще один интересный параметр (и наиболее полезный для атаки) это URL. Этот параметр не отражается, но и не проверяется. Поэтому его можно использовать для эксплуатации XXE.

Вернемся к нашему примеру. В одной из реализаций ACS мы обнаружили, что можем читать короткие файлы, а также получать ответ в PaRes error через параметр merID. Таким образом, используя PaReq из примера выше, мы получали следующий ответ:

<ThreeDSecure><Message id=" 123-123-123-123-123-123 "><PARes id=" 123-123-123-123-123-123 "><version>1.0.2</version><Merchant><acqBIN>510069</acqBIN><merID>ACS server name</merID></Merchant><Purchase><xid>U3Vic2NyaWJlX0B3ZWJyMGNr</xid><date>20181004 21:34:21</date><purchAmount>202000</purchAmount><currency>643</currency><exponent>2</exponent></Purchase><pan>000000000000000</pan><TX><time>20181004 21:34:21</time><status>U</status></TX><IReq><iReqCode>55</iReqCode><iReqDetail>PAReq.CH.acctID</iReqDetail></IReq></PARes></Message></ThreeDSecure>

Тем не менее в большинстве случаев оставалось только использовать параметр URL для получения DNS или HTTP-запроса к нашему сервису. Другой вектор это выполнить DOS через XXE-атаку "billion laughs" (проверялось на тестовом сервере).

Где это можно найти?

В ходе нашего исследования мы обнаружили несколько распространенных URL-адресов:

/acs/pareq/___uid___/acspage/cap?RID=14&VAA=B/way4acs/pa?id=____id____/PaReqVISA.jsp/PaReqMC.jsp/mdpayacs/pareq/acs/auth/start.do

И распространенные имена поддоменов:

acs3ds3dssecurecappaymentsecm3dsauthtestacscard

Впрочем, иногда вы можете найти и другие интересные пути.
Если вы хотите найти что-то новое, используйте proxy interceptor и записывайте процесс совершения платежей для интересующей вас платежной системы.

3D Secure v 2. *

Как мы писали ранее, в 3DS v1.0 есть некоторые проблемы.

Основная проблема в том, что покупатель может использовать множество разных типов устройств. Планшет, мобильный телефон, умные часы, умный чайник и т.д. Но сайт ACS не всегда разработан для взаимодействия со всеми типами устройств.

Для этого в 3DS 2.0 предусмотрели 3DS SDK.

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

Следующий важный момент заключается в том, что технологии аутентификации развиваются. Соответственно, 3DS могла бы использовать не только OTP. Поэтому v2 задумывалась с возможностью расширения поддержки различных механизмов аутентификации.

Интересный факт про v1.0. Люди некоторых стран не доверяли этому протоколу, потому что видели редирект и думали, что это мошенничество!

Этот психологический момент послужил причиной изменения спецификации второй версии протокола для сокрытия момента перенаправления.

Как работает 3D Secure v2?

Начало потока платежей аналогично предыдущей версии. Клиент должен указать данные своей карты.

Первый и самый важный момент это Risk Engine. В версии 1.0.2 клиенты всегда должны вводить второй фактор, например OTP. Однако в версии 2. * клиент может никогда не увидеть этот дополнительный защищенный запрос.

Особенности работы v2

Если вы посмотрите на схему потока платежей, вы увидите, что она похожа на предыдущую, но во 2-й версии больше этапов. Это происходит за счет добавления дополнительных аутентификационных запросов и механизма Risck Engine, который может совершать как один дополнительный запрос (при платеже через браузер), так и множество (используется 3DS SDK).

Условно, 2-ю версию можно разделить на два блока. Красный, где пользователь непосредственно влияет на передаваемую информацию, и желтый, где система сама собирает и передает информацию о пользователе.

А поподробнее?

AReq (base64url) расскажет все о вас и об устройстве, с которого совершена покупка.
Если вы задумаетесь о том, какой информацией о вас располагают рекламные агентства, то данные AReq вас не удивят. Но если вам кажется, что это плохо, рассмотрите следующий момент: банки знают все о ваших покупках и о вас. С этой точки зрения, некоторая дополнительная информация не так уж и плоха)

Это сообщение необходимо для работы системы управления рисками и упрощения покупок.
Если этой информации оказалось недостаточно, Risk Engine сперва попытается получить дополнительную информацию, и именно в этот момент клиент может получить OTP-запрос.

Что контролирует пользователь?

CReq (base64url json) challenge request сообщение, отправляемое браузером пользователя, в случае если ARes вернет сообщение о необходимости провести Challenge Flow.

{"ThreeDSServerTransID": "8a880dc0-d2d2-4067-bcb1-b08d1690b26e","AcsTransID": "d7c1ee99-9478-44a6-b1f2-391e29c6b340","MessageType": "CReq","MessageVersion": "2.1.0","SdkTransID": "b2385523-a66c-4907-ac3c-91848e8c0067","SdkCounterStoA": "001"}

Если платежный процесс использует 3D Secure SDK, это сообщение будет зашифровано (JWE).

В CReq вы можете увидеть следующие поля:

К сожалению, нам пока не удалось провести достаточно подробное исследование 2-й версии протокола 3DS, поэтому сложно сказать, какие уязвимости встречаются чаще. Вы можете стать первым, кто опубликует исследование на данную тему.

Подведем итоги

Проблемы (найденные и возможные)

На что смотреть в v1

• XXE в параметре Pareq:
  
  • DOS
  • чтение файла
  • ssrf
• XSS в параметрах TermUrl
• Blind XSS все параметры и заголовки попадают в систему мониторинга
• Pareq не подписан, но в нем есть цена! Отсюда может последовать атака уже на магазин, т.к. если на стороне магазина не будет проверки суммы подтвержденной операции, то вы сможете совершить покупку вещи стоимостью в 100р за 1р.

На что смотреть в v2

• Blind XSS все параметры и заголовки попадают в систему мониторинга
• Challenge flow, главное его поймать

Тем, кто подумывает обратить свой взгляд на платежные системы, я бы посоветовал остановиться еще и на сервисах, предоставляющих 3DS как SaaS. Там может оказаться еще достаточно много вещей, которые помогут вам понять, как устроен мир онлайн-платежей.

Полезные ссылки

https://github.com/w3c/webpayments/wiki
https://www.EMV.com/emv-technologies/3d-secure/
https://3dsserver.netcetera.com/3dsserver-saas/doc/current/schema/3ds-api.html
https://github.com/webr0ck/3D-Secure-audit-cheatsheet

P.S. Возможно, вам пришел в голову вопрос: "Я пользовался AliExpress, Amazon, другое, и мне не приходил OTP код. Здесь использовался 3DS?" Нет, не использовался. Это как раз примеры тех случаев, когда магазин берет на себя ответственность за мошеннические операции.