D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Источник: https://gist.github.com/hackermondev/45a3cdfa52246f1d1201c1e8cdef6117
Перевёл: BLUA специально для xss.is
Cloudflare
По числам, Cloudflare давно является самой популярной CDN на рынке. Он превосходит таких конкурентов, как Sucuri, Amazon CloudFront, Akamai и Fastly. В 2019 году из-за крупной аварии Cloudflare большинство интернета было недоступно более 30 минут.
Одной из самых используемых функций Cloudflare является кэширование. Кэш Cloudflare хранит копии часто запрашиваемого контента (например, изображений, видео или веб-страниц) в своих дата-центрах, что снижает нагрузку на сервер и улучшает производительность веб-сайта ([https://developers.cloudflare.com/cache/](https://developers.cloudflare.com/cache/)).
Когда ваше устройство отправляет запрос на ресурс, который может быть кэширован, Cloudflare извлекает ресурс из локального хранилища дата-центра, если он доступен. В противном случае он получает ресурс с оригинального сервера, кэширует его локально, а затем возвращает. По умолчанию некоторые расширения файлов автоматически кэшируются, но владельцы сайтов также могут настроить свои правила кэширования.
Cloudflare имеет обширное глобальное присутствие, с сотнями дата-центров в 330 городах более чем 120 странах — это примерно на 273% больше дата-центров, чем у Google. Например, в восточном регионе США ближайший дата-центр ко мне находится менее чем в 100 милях. Если вы живете в развитой стране, есть высокая вероятность, что ближайший дата-центр к вам находится менее чем в 200 милях от вас.
Несколько месяцев назад у меня возникла идея: если Cloudflare хранит кэшированные данные так близко к пользователям, можно ли это использовать для атак деинонимизации на сайтах, которые мы не контролируем?
Вы видите, Cloudflare возвращает информацию о статусе кэша запроса в HTTP-ответе.
Если нам удастся заставить устройство пользователя зайти на сайт, поддерживаемом Cloudflare, и тем самым кэшировать его в их локальном дата-центре, мы затем сможем перечислить все дата-центры Cloudflare, чтобы определить, какой из них кэшировал ресурс. Это даст нам невероятно точную оценку местоположения пользователя.
Перед тем как я протестировал эту теорию, мне нужно было преодолеть одно серьезное препятствие.
Вы не можете отправлять HTTP-запросы нужные вам дата-центры Cloudflare. В «целях безопасности» (предположительно для защиты от DDoS-атак) все IP-диапазоны строго прописаны. Поэтому все TCP-соединения, присоединённые к их сети, всегда обрабатываются ближайшим доступным дата-центром к вам; вы не можете попросить дата-центр в Канаде обработать ваш запрос, если вы живете в США.
Однако после некоторых исследований я нашел пост на форуме (https://community.cloudflare.com/t/how-to-run-workers-on-specific-datacenter-colos/385851) от участника сообщества, который показал мне, как это сделать. Автор поделился ошибкой, которую он обнаружил, позволяющей отправлять запросы в конкретные дата-центры Cloudflare с помощью Cloudflare Workers.
Я все еще не на 100% уверен в деталях этой ошибки, но, используя IP-диапазон, который используется внутри Cloudflare WARP (VPN-клиент Cloudflare), мы могли бы попросить определенные дата-центры обработать HTTP-запросы. Обычно этот IP-диапазон блокирует входящие подключения с внешних IP-адресов, но запросы, отправленные с помощью Workers, могли обойти это, поскольку соединение исходило изнутри сети Cloudflare.
Я провел несколько минут, читая их пост, и быстро создал инструмент для этого: Cloudflare Teleport (https://github.com/hackermondev/cf-teleport). IP-диапазоны соответствовующие разным дата-центрам (https://github.com/hackermondev/cf-teleport/blob/main/scripts/data/colos.json).
Cloudflare Teleport — это прокси, работающий на основе Cloudflare Workers, который перенаправляет HTTP-запросы в конкретные дата-центры. Например, https://cfteleport.xyz/?proxy=https://cloudflare.com/cdn-cgi/trace&colo=SEA будет проксировать HTTP GET запрос к https://cloudflare.com/cdn-cgi/trace специально в дата-центр в Сиэтле (SEA).
Cloudflare в конечном итоге полностью исправил эту ошибку через несколько месяцев, что сделало этот инструмент устаревшим, но об этом позже. В течение большей части моего первоначального исследования я использовал этот инструмент.
Первая атака «дезанонимизации»
Как только инструмент Cloudflare Teleport был завершен, я смог подтвердить свою теорию. Я написал простой скрипт, который отправляет HTTP GET запрос на указанный URL и перечисляет все дата-центры, в которых содержался кэш ресурса, а также его возраст.
Для моего первого теста я использовал фавикон Namecheap (https://www.namecheap.com/favicon.ico). Этот ресурс имеет включенное кэширование Cloudflare, это простое статическое изображение их логотипа. (Это был самый быстрый сайт, который я смог найти и который не имел строгой защиты от ботов):
Бум, это сработало. Namecheap настроил возраст своего кэша крайне низким (5 минут), но я смог увидеть каждый дата-центр, который кэшировал фавикон их сайта за последние 5 минут. Поскольку каждый раз, когда вы загружаете их сайт, ваш браузер автоматически загружает этот фавикон, это означает, что пользователь из каждого из этих мест посетил сайт Namecheap.com в течение последних 5 минут, причем последний визит был из Токио, Япония.
Это был простой тест, и здесь почти не было никакого влияния, но с его помощью я подтвердил свою теорию. Это доказало концепцию использования кэширования Cloudflare для атак дезанонимизации.
Применение в реальном мире: Signal
Signal, открытая зашифрованная мессенджерская служба, широко используется журналистами и активистами благодаря своим функциям конфиденциальности. Внутри приложение использует две CDN для доставки контента:
Путь
Чтобы протестировать это, я быстро модифицировал настольное приложение Signal, чтобы убрать SSL-пининг, и настроил Burp для перехвата и просмотра HTTP-запросов/ответов, отправляемых через приложение.
Шаги
1. Заблокируйте HTTP GET запросы к cdn2.signal.org/attachments/* из Signal с помощью Burp.
Это гарантирует, что приложение не будет загружать вложения, загруженные с нашей стороны (злоумышленника), так как это закэширует их в нашем локальном дата-центре и испортит результаты. Лучший способ, который я нашел для этого с помощью Burp, — настроить правила перехвата для вложений, затем оставить перехват запросов включенным и отклонить все запросы.
2. Отправьте вложение (изображение) цели.
Это должно сработать с любым вложением, но изображения автоматически загружаются, когда пользователь открывает разговор, поэтому они работают лучше всего. Я использовал простое изображение 1x1.png для этого теста. Запрос на загрузку отправляется на CDN Signal, и вы можете увидеть URL вложения в Burp, как только мы отправим вложение в разговоре и Signal его загрузит (например,
После того как цель откроет разговор (проверьте это с помощью уведомлений о прочтении), их устройство должно загрузить вложение, что, в свою очередь, вызывает кэширование файла Cloudflare в локальном дата-центре.
Я провел эту атаку на себе, использовал скрипт, о котором упоминал ранее, с URL вложения и обнаружил локальные дата-центры, кэшировавшие это вложение.
В моем случае я нахожусь в Нью-Йорке, и один из ближайших дата-центров ко мне находится в Норке, Нью-Джерси (EWR), который приблизительно в 150 милях от моих фактических координат.
С помощью вложения, выглядящего безобидно, злоумышленник может дезанонимизировать пользователей и определить их местоположение в пределах приблизительного радиуса.
0-click
Вот где начинает происходить интересное. Хотя метод с одним кликом работает, он требует от пользователя открытия разговора в Signal. Возможно ли провести эту атаку без какого-либо взаимодействия со стороны пользователя? Вводим push-уведомления.
Push-уведомления
У мобильного приложения Signal есть 3 настройки push-уведомлений.
Push-уведомления срабатывают, если пользователь получает сообщение, находясь неактивно в приложении Signal. По умолчанию мобильное приложение включает автора и сообщение, когда отправляет push-уведомление на ваше устройство.
Изображение, показанное справа от уведомления, — это вложение, отправленное с сообщением из Signal.
Если цель имеет включенные push-уведомления (что является настройкой по умолчанию), им даже не нужно открывать разговор в Signal, чтобы их устройство загрузило вложение. Как только push-уведомление отправляется на их устройство, изображение автоматически загружается с CDN Signal, что приводит к кэшированию ответа в локальном дата-центре.
Злоумышленник может провести эту атаку на дезанонимизацию в любое время и получить текущее местоположение пользователя без какого-либо взаимодействия.
Применение в реальном мире: Discord
Во время моего исследования я нашел еще одно приложение, уязвимое к этому типу атаки — Discord. Discord — это бесплатное приложение, которое позволяет пользователям общаться друг с другом через текст, голос и видео. Хотя приложение ориентировано на геймеров, в последнее время Discord становился объектом новостей из-за содействия утечкам информации от правительства, и Discord является площадкой для значительной доли киберпреступлений в интернете.
Аспект с 1-click очень прост и довольно похож на Signal; я бы сказал, что его воздействие даже шире с Discord. Discord позволяет пользователям с подпиской Nitro (их платный сервис за $9.99 в месяц) использовать пользовательские эмодзи в различных местах: сообщениях, статусе пользователей, каналах и т. д. Эти пользовательские эмодзи загружаются с CDN Discord и настроены на кэширование в Cloudflare. Злоумышленник может использовать ту же атаку на дезанонимизацию, что и с Signal, чтобы дезанонимизировать пользователей.
Так что вместо того, чтобы отправлять вложение в канале Discord, злоумышленник может отобразить пользовательский эмодзи в своем статусе и просто дождаться, пока цель откроет их профиль, чтобы провести атаку на дезанонимизацию.
Я раскрыл весь отчет HackerOne, который отправил в Discord, в котором содержатся конкретные детали, но я хочу сосредоточиться на аспекте с нулевым кликом здесь.
В Discord мобильные push-уведомления отправляются для различных событий (не только для полученных сообщений, как в Signal). Например, отправка запроса на добавление в друзья пользователю Discord вызывает push-уведомление на мобильном устройстве пользователя.
Интересно, что даже если пользователь активно находится в Discord, уведомления о запросах на добавление в друзья всегда отправляются на мобильное устройство пользователя.
Как бы атака на дезанонимизацию могла быть использована с уведомлением о запросе на добавление в друзья? Давайте посмотрим на уведомление.
Когда вы получаете запрос на добавление в друзья, и Discord отправляет уведомление на ваше устройство, оно включает URL аватара пользователя, который будет показан с уведомлением. Ваш телефон загружает URL аватара (без какого-либо взаимодействия с пользователем) и отображает его рядом с уведомлением.
В Discord настроено кэширование Cloudflare на пути CDN для URL аватаров, что означает, что мы можем просто повторить ту же атаку на кэширование, упомянутую ранее.
В Discord формат URL аватара, используемый в push-уведомлениях, выглядит следующим образом:
Обе ссылки ведут к одному и тому же изображению, но поскольку изображения, отображаемые в приложении, имеют другой путь, они кэшируются отдельно. Это гарантирует, что наши результаты не загрязнены, и позволяет нам убедиться, что мы находим дата-центр устройства, которое загрузило аватар через push-уведомление, а не просто профиль в приложении Discord.
Вот так у нас есть шаги для версии этой атаки с 0-click для Discord:
Представляю GeoGuesser. Это приватный бот для Discord с функцией, которая принимает имя пользователя, выполняет атаку по ранее упомянутым шагам и возвращает результат через Discord.
Когда команда вызывается, она использует учетные данные моей учетной записи для доступа к Discord User API, изменяет аватар пользователя на случайно сгенерированное изображение (чтобы рандомизировать хэш) и отправляет запрос на добавление в друзья на указанный имя пользователя. Наконец, она использует частный API, основанный на Cloudflare Teleport CLI, для выполнения той же атаки по перечислению кэша и отображает результаты непосредственно в Discord, всё это менее чем за 30 секунд.
Чтобы показать масштабы этой атаки, одним из первых пользователей, на которых я попробовал эту атаку, был Станислав Вишневский, технический директор Discord.
Бот отправляет запрос на добавление в друзья Стэну, затем ждет пару секунд, чтобы убедиться, что он получает push-уведомление.
Он находит 2 локальных дата-центра Cloudflare, которые кэшировали аватар. Это может означать, что у него есть несколько устройств, связанных с его учетной записью Discord, которые получили push-уведомление, или его устройство загрузило аватар дважды, и запросы были распределены между разными дата-центрами.
GeoGuesser, работающий на основе Google Maps API, генерирует вероятное местоположение пользователя. Он находит среднюю точку между 2 дата-центрами и рисует 2 круга, которые обозначают его радиусы.
Штаб-квартира Discord расположена в Сан-Франциско, штат Калифорния (что находится в внешнем круге), поэтому эта карта точна. Скорее всего, Стэн находится где-то на границе внутреннего круга, который составляет около 300 миль.
Весь этот процесс занял менее минуты. Я уверен, что Стэн увидел уведомление на своем телефоне, не задумался и просто проигнорировал его. Это была всего лишь простая атака, но эта атака, если ее откалибровать, может быть использована для отслеживания и мониторинга местоположения Стэна.
Атака подобного рода может быть запущена на любого пользователя Discord, и её почти невозможно обнаружить.
Отчёт о ошибке
Я ответственно сообщил пострадавшим сторонам о своей исследовательской работе, надеясь, что будут предприняты меры для защиты или предупреждения пользователей об этом типе атаки на анонимность, но остался разочарован.
Signal мгновенно отклонил мой отчет, сказав, что это не их ответственность и что пользователям предстоит самим скрывать свою личность: "Signal никогда не пытался полностью воспроизвести набор анонимных функций на сетевом уровне, которые могут предоставить такие проекты, как Wireguard, Tor и другое программное обеспечение с открытым исходным кодом для использования VPN."
Я не согласен с этим. Signal позиционирует себя как коммуникационная платформа, ориентированная на защиту конфиденциальности. Хотя он не утверждает, что предоставляет анонимность на сетевом уровне, как Tor, пользователи доверяют Signal в том, что он минимизирует риски для нарушения конфиденциальности.
Уязвимость демонстрирует, что платформа непреднамеренно раскрывает информацию, которая может сузить местоположение пользователя до нескольких сотен миль. Это утечка противоречит ожиданиям многих пользователей, обеспокоенных конфиденциальностью, которые полагаются на Signal не только для обеспечения сквозного шифрования.
Telegram, другое приложение, ориентированное на конфиденциальность, совершенно устойчиво к этой атаке, поскольку (1) они используют собственный протокол, разработанный внутри компании, который не зависит от HTTP, и (2) не полагаются на облачных провайдеров, таких как Cloudflare, для кэширования.
Cloudflare в конце концов завершил исправление уязвимости, используемой Cloudflare Teleport для обхода дата-центров. Уязвимость была сообщена в их программу HackerOne год назад другим исследователем, но тогда они не предприняли никаких действий, поскольку не видели никакого воздействия от обхода дата-центров до тех пор, пока я не поделился своей исследовательской работой.
Cloudflare повторно открыл старый отчет, изучил его и выплатил вознаграждение в размере 200 долларов за мой отчет и оригинальный.
Хотя это шаг в правильном направлении, это на самом деле не решает основную проблему. Каждая атака, описанная в этом отчете, была повторно использована в последние 24 часа, несмотря на то что Cloudflare исправил эту уязвимость неделю назад. Cloudflare устранил уязвимость внутри своей сети, которая способствовала обходу дата-центров, но это не единственный способ легко обходить дата-центры по всему миру.
Через 24 часа после их исправления я перепрограммировал Cloudflare Teleport для использования VPN. Многие VPN предоставляют несколько локаций, к которым пользователи могут подключаться, что отправляет их трафик через серверы в различных частях мира, и эти серверы соответствуют различным дата-центрам Cloudflare по всему миру.
Я выбрал провайдера VPN с более чем 3000 серверами, расположенными в различных местах в 31 стране по всему миру. Используя этот новый метод, я снова могу охватить около 54% всех дата-центров Cloudflare. Хотя это не выглядит как большое количество, это покрывает большинство мест в мире с значительным населением.
Окончательное заявление Cloudflare по этому поводу гласит, что они не рассматривают атаку на анонимность как уязвимость в своих системах и что на них, как на потребителей, лежит ответственность за отключение кэширования для ресурсов, которые они хотят защитить.
Здесь явно существует проблема, так как Cloudflare заявляет, что потребители несут ответственность за свою защиту от таких атак, в то время как потребители (например, Discord) возлагают вину на Cloudflare.
Как защитить себя
Потенциал для эксплуатации этой атаки на анонимность значителен, особенно для пользователей в уязвимых ситуациях, таких как журналисты, активисты и люди, заботящиеся о конфиденциальности. Атака использует основные проектные решения в системах кэширования и пуш-уведомлений, демонстрируя, как инфраструктура, предназначенная для повышения производительности, может быть злоупотреблена для инвазивного отслеживания.
Хотя Cloudflare исправил уязвимость в Teleport, и некоторые приложения, такие как Discord и Signal, возможно, внедрили меры по смягчению последствий после моего раскрытия информации, основные риски остаются. Любое приложение, использующее CDN для доставки контента и кэширования, по-прежнему может быть уязвимым, если не будут приняты соответствующие меры предосторожности.
Последняя мысль
Эта атака подчеркивает, насколько сложной и взаимосвязанной стала цифровая экосистема. Хотя CDN повышают производительность и масштабируемость, они также непреднамеренно создают риски, которые можно использовать новыми способами. Повышая осведомленность и продвигая лучшие практики, мы можем работать сообща, чтобы свести к минимуму вероятность злоупотреблений.
Для пользователей, выполняющих важные задачи, или для тех, кто беспокоится о своей конфиденциальности, главное — оставаться в курсе событий и быть бдительными. Хотя ни одна система не является полностью надёжной, принятие мер по ограничению вашего доступа может существенно изменить ситуацию.
Перевёл: BLUA специально для xss.is
Cloudflare
По числам, Cloudflare давно является самой популярной CDN на рынке. Он превосходит таких конкурентов, как Sucuri, Amazon CloudFront, Akamai и Fastly. В 2019 году из-за крупной аварии Cloudflare большинство интернета было недоступно более 30 минут.
Одной из самых используемых функций Cloudflare является кэширование. Кэш Cloudflare хранит копии часто запрашиваемого контента (например, изображений, видео или веб-страниц) в своих дата-центрах, что снижает нагрузку на сервер и улучшает производительность веб-сайта ([https://developers.cloudflare.com/cache/](https://developers.cloudflare.com/cache/)).
Когда ваше устройство отправляет запрос на ресурс, который может быть кэширован, Cloudflare извлекает ресурс из локального хранилища дата-центра, если он доступен. В противном случае он получает ресурс с оригинального сервера, кэширует его локально, а затем возвращает. По умолчанию некоторые расширения файлов автоматически кэшируются, но владельцы сайтов также могут настроить свои правила кэширования.
Cloudflare имеет обширное глобальное присутствие, с сотнями дата-центров в 330 городах более чем 120 странах — это примерно на 273% больше дата-центров, чем у Google. Например, в восточном регионе США ближайший дата-центр ко мне находится менее чем в 100 милях. Если вы живете в развитой стране, есть высокая вероятность, что ближайший дата-центр к вам находится менее чем в 200 милях от вас.
Несколько месяцев назад у меня возникла идея: если Cloudflare хранит кэшированные данные так близко к пользователям, можно ли это использовать для атак деинонимизации на сайтах, которые мы не контролируем?
Вы видите, Cloudflare возвращает информацию о статусе кэша запроса в HTTP-ответе.
cf-cache-status может быть HIT/MISS, а cf-ray включает код аэропорта ближайшего аэропорта к дата-центру, который обрабатывает запрос (в моем случае, IAD).Если нам удастся заставить устройство пользователя зайти на сайт, поддерживаемом Cloudflare, и тем самым кэшировать его в их локальном дата-центре, мы затем сможем перечислить все дата-центры Cloudflare, чтобы определить, какой из них кэшировал ресурс. Это даст нам невероятно точную оценку местоположения пользователя.
Cloudflare Teleport
Перед тем как я протестировал эту теорию, мне нужно было преодолеть одно серьезное препятствие.
Вы не можете отправлять HTTP-запросы нужные вам дата-центры Cloudflare. В «целях безопасности» (предположительно для защиты от DDoS-атак) все IP-диапазоны строго прописаны. Поэтому все TCP-соединения, присоединённые к их сети, всегда обрабатываются ближайшим доступным дата-центром к вам; вы не можете попросить дата-центр в Канаде обработать ваш запрос, если вы живете в США.
Однако после некоторых исследований я нашел пост на форуме (https://community.cloudflare.com/t/how-to-run-workers-on-specific-datacenter-colos/385851) от участника сообщества, который показал мне, как это сделать. Автор поделился ошибкой, которую он обнаружил, позволяющей отправлять запросы в конкретные дата-центры Cloudflare с помощью Cloudflare Workers.
Я все еще не на 100% уверен в деталях этой ошибки, но, используя IP-диапазон, который используется внутри Cloudflare WARP (VPN-клиент Cloudflare), мы могли бы попросить определенные дата-центры обработать HTTP-запросы. Обычно этот IP-диапазон блокирует входящие подключения с внешних IP-адресов, но запросы, отправленные с помощью Workers, могли обойти это, поскольку соединение исходило изнутри сети Cloudflare.
Я провел несколько минут, читая их пост, и быстро создал инструмент для этого: Cloudflare Teleport (https://github.com/hackermondev/cf-teleport). IP-диапазоны соответствовующие разным дата-центрам (https://github.com/hackermondev/cf-teleport/blob/main/scripts/data/colos.json).
Cloudflare Teleport — это прокси, работающий на основе Cloudflare Workers, который перенаправляет HTTP-запросы в конкретные дата-центры. Например, https://cfteleport.xyz/?proxy=https://cloudflare.com/cdn-cgi/trace&colo=SEA будет проксировать HTTP GET запрос к https://cloudflare.com/cdn-cgi/trace специально в дата-центр в Сиэтле (SEA).
Cloudflare в конечном итоге полностью исправил эту ошибку через несколько месяцев, что сделало этот инструмент устаревшим, но об этом позже. В течение большей части моего первоначального исследования я использовал этот инструмент.
Первая атака «дезанонимизации»
Как только инструмент Cloudflare Teleport был завершен, я смог подтвердить свою теорию. Я написал простой скрипт, который отправляет HTTP GET запрос на указанный URL и перечисляет все дата-центры, в которых содержался кэш ресурса, а также его возраст.
Для моего первого теста я использовал фавикон Namecheap (https://www.namecheap.com/favicon.ico). Этот ресурс имеет включенное кэширование Cloudflare, это простое статическое изображение их логотипа. (Это был самый быстрый сайт, который я смог найти и который не имел строгой защиты от ботов):
Бум, это сработало. Namecheap настроил возраст своего кэша крайне низким (5 минут), но я смог увидеть каждый дата-центр, который кэшировал фавикон их сайта за последние 5 минут. Поскольку каждый раз, когда вы загружаете их сайт, ваш браузер автоматически загружает этот фавикон, это означает, что пользователь из каждого из этих мест посетил сайт Namecheap.com в течение последних 5 минут, причем последний визит был из Токио, Япония.
Это был простой тест, и здесь почти не было никакого влияния, но с его помощью я подтвердил свою теорию. Это доказало концепцию использования кэширования Cloudflare для атак дезанонимизации.
Применение в реальном мире: Signal
Signal, открытая зашифрованная мессенджерская служба, широко используется журналистами и активистами благодаря своим функциям конфиденциальности. Внутри приложение использует две CDN для доставки контента:
cdn.signal.org (работает на CloudFront) для аватаров профилей и cdn2.signal.org (работает на Cloudflare) для вложений сообщений.1-Click Attack
Когда пользователь отправляет вложение (например, изображение) в Signal, оно загружается наcdn2.signal.org. Как только получатель открывает разговор, его устройство автоматически загружает вложение. Поскольку кэширование Cloudflare включено для этих URL, злоумышленник может использовать метод геолокации кэша, чтобы определить местоположение получателя.Путь
https://cdn2.signal.org/attachments/* настроен для кэширования ответов с помощью Cloudflare. Это означает, что как только устройство пользователя автоматически загружает вложение, злоумышленник может провести атаку геолокации кэша, чтобы выяснить, к какому локальному дата-центру они близки — аналогично тому, как правоохранительные органы отслеживают мобильные устройства через сотовые вышки.Чтобы протестировать это, я быстро модифицировал настольное приложение Signal, чтобы убрать SSL-пининг, и настроил Burp для перехвата и просмотра HTTP-запросов/ответов, отправляемых через приложение.
Шаги
1. Заблокируйте HTTP GET запросы к cdn2.signal.org/attachments/* из Signal с помощью Burp.
Это гарантирует, что приложение не будет загружать вложения, загруженные с нашей стороны (злоумышленника), так как это закэширует их в нашем локальном дата-центре и испортит результаты. Лучший способ, который я нашел для этого с помощью Burp, — настроить правила перехвата для вложений, затем оставить перехват запросов включенным и отклонить все запросы.
2. Отправьте вложение (изображение) цели.
Это должно сработать с любым вложением, но изображения автоматически загружаются, когда пользователь открывает разговор, поэтому они работают лучше всего. Я использовал простое изображение 1x1.png для этого теста. Запрос на загрузку отправляется на CDN Signal, и вы можете увидеть URL вложения в Burp, как только мы отправим вложение в разговоре и Signal его загрузит (например,
https://cdn2.signal.org/attachments/UjLld11tvaL16M8mrd86).3. Attack
После того как цель откроет разговор (проверьте это с помощью уведомлений о прочтении), их устройство должно загрузить вложение, что, в свою очередь, вызывает кэширование файла Cloudflare в локальном дата-центре.
Я провел эту атаку на себе, использовал скрипт, о котором упоминал ранее, с URL вложения и обнаружил локальные дата-центры, кэшировавшие это вложение.
В моем случае я нахожусь в Нью-Йорке, и один из ближайших дата-центров ко мне находится в Норке, Нью-Джерси (EWR), который приблизительно в 150 милях от моих фактических координат.
С помощью вложения, выглядящего безобидно, злоумышленник может дезанонимизировать пользователей и определить их местоположение в пределах приблизительного радиуса.
0-click
Вот где начинает происходить интересное. Хотя метод с одним кликом работает, он требует от пользователя открытия разговора в Signal. Возможно ли провести эту атаку без какого-либо взаимодействия со стороны пользователя? Вводим push-уведомления.
Push-уведомления
У мобильного приложения Signal есть 3 настройки push-уведомлений.
Push-уведомления срабатывают, если пользователь получает сообщение, находясь неактивно в приложении Signal. По умолчанию мобильное приложение включает автора и сообщение, когда отправляет push-уведомление на ваше устройство.
Изображение, показанное справа от уведомления, — это вложение, отправленное с сообщением из Signal.
Если цель имеет включенные push-уведомления (что является настройкой по умолчанию), им даже не нужно открывать разговор в Signal, чтобы их устройство загрузило вложение. Как только push-уведомление отправляется на их устройство, изображение автоматически загружается с CDN Signal, что приводит к кэшированию ответа в локальном дата-центре.
Злоумышленник может провести эту атаку на дезанонимизацию в любое время и получить текущее местоположение пользователя без какого-либо взаимодействия.
Применение в реальном мире: Discord
Во время моего исследования я нашел еще одно приложение, уязвимое к этому типу атаки — Discord. Discord — это бесплатное приложение, которое позволяет пользователям общаться друг с другом через текст, голос и видео. Хотя приложение ориентировано на геймеров, в последнее время Discord становился объектом новостей из-за содействия утечкам информации от правительства, и Discord является площадкой для значительной доли киберпреступлений в интернете.
Аспект с 1-click очень прост и довольно похож на Signal; я бы сказал, что его воздействие даже шире с Discord. Discord позволяет пользователям с подпиской Nitro (их платный сервис за $9.99 в месяц) использовать пользовательские эмодзи в различных местах: сообщениях, статусе пользователей, каналах и т. д. Эти пользовательские эмодзи загружаются с CDN Discord и настроены на кэширование в Cloudflare. Злоумышленник может использовать ту же атаку на дезанонимизацию, что и с Signal, чтобы дезанонимизировать пользователей.
Так что вместо того, чтобы отправлять вложение в канале Discord, злоумышленник может отобразить пользовательский эмодзи в своем статусе и просто дождаться, пока цель откроет их профиль, чтобы провести атаку на дезанонимизацию.
Я раскрыл весь отчет HackerOne, который отправил в Discord, в котором содержатся конкретные детали, но я хочу сосредоточиться на аспекте с нулевым кликом здесь.
В Discord мобильные push-уведомления отправляются для различных событий (не только для полученных сообщений, как в Signal). Например, отправка запроса на добавление в друзья пользователю Discord вызывает push-уведомление на мобильном устройстве пользователя.
Интересно, что даже если пользователь активно находится в Discord, уведомления о запросах на добавление в друзья всегда отправляются на мобильное устройство пользователя.
Как бы атака на дезанонимизацию могла быть использована с уведомлением о запросе на добавление в друзья? Давайте посмотрим на уведомление.
Когда вы получаете запрос на добавление в друзья, и Discord отправляет уведомление на ваше устройство, оно включает URL аватара пользователя, который будет показан с уведомлением. Ваш телефон загружает URL аватара (без какого-либо взаимодействия с пользователем) и отображает его рядом с уведомлением.
В Discord настроено кэширование Cloudflare на пути CDN для URL аватаров, что означает, что мы можем просто повторить ту же атаку на кэширование, упомянутую ранее.
В Discord формат URL аватара, используемый в push-уведомлениях, выглядит следующим образом:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}. Формат URL аватара, используемый на сайте для отображения аватаров пользователей, немного отличается (он всегда содержит расширение изображения): https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}.png.Обе ссылки ведут к одному и тому же изображению, но поскольку изображения, отображаемые в приложении, имеют другой путь, они кэшируются отдельно. Это гарантирует, что наши результаты не загрязнены, и позволяет нам убедиться, что мы находим дата-центр устройства, которое загрузило аватар через push-уведомление, а не просто профиль в приложении Discord.
Вот так у нас есть шаги для версии этой атаки с 0-click для Discord:
- Измените свой аватар. Это случайным образом изменяет ваш хэш аватара и обеспечивает то, что URL вашего аватара еще не был загружен никем, что увеличивает точность атаки.
- Отправьте запрос на добавление в друзья цели. Хотя есть несколько способов вызвать push-уведомления в Discord, я выбираю запросы на добавление в друзья, потому что они всегда отправляются, независимо от того, активен ли пользователь в Discord. Кроме того, для этого не требуется наличие общего сервера с целью, что означает, что вы можете практически сделать это с кем угодно в Discord.
- Используйте инструмент Cloudflare Teleport для URL аватара пользователя и найдите все локальные дата-центры, которые кэшировали аватар.
GeoGuesser
Я хорошо знаком с API Discord и понял, что могу автоматизировать каждый шаг атаки с нулевым кликом в Discord, и так я и сделал.Представляю GeoGuesser. Это приватный бот для Discord с функцией, которая принимает имя пользователя, выполняет атаку по ранее упомянутым шагам и возвращает результат через Discord.
Когда команда вызывается, она использует учетные данные моей учетной записи для доступа к Discord User API, изменяет аватар пользователя на случайно сгенерированное изображение (чтобы рандомизировать хэш) и отправляет запрос на добавление в друзья на указанный имя пользователя. Наконец, она использует частный API, основанный на Cloudflare Teleport CLI, для выполнения той же атаки по перечислению кэша и отображает результаты непосредственно в Discord, всё это менее чем за 30 секунд.
Чтобы показать масштабы этой атаки, одним из первых пользователей, на которых я попробовал эту атаку, был Станислав Вишневский, технический директор Discord.
Бот отправляет запрос на добавление в друзья Стэну, затем ждет пару секунд, чтобы убедиться, что он получает push-уведомление.
Он находит 2 локальных дата-центра Cloudflare, которые кэшировали аватар. Это может означать, что у него есть несколько устройств, связанных с его учетной записью Discord, которые получили push-уведомление, или его устройство загрузило аватар дважды, и запросы были распределены между разными дата-центрами.
GeoGuesser, работающий на основе Google Maps API, генерирует вероятное местоположение пользователя. Он находит среднюю точку между 2 дата-центрами и рисует 2 круга, которые обозначают его радиусы.
Штаб-квартира Discord расположена в Сан-Франциско, штат Калифорния (что находится в внешнем круге), поэтому эта карта точна. Скорее всего, Стэн находится где-то на границе внутреннего круга, который составляет около 300 миль.
Весь этот процесс занял менее минуты. Я уверен, что Стэн увидел уведомление на своем телефоне, не задумался и просто проигнорировал его. Это была всего лишь простая атака, но эта атака, если ее откалибровать, может быть использована для отслеживания и мониторинга местоположения Стэна.
Атака подобного рода может быть запущена на любого пользователя Discord, и её почти невозможно обнаружить.
Отчёт о ошибке
Я ответственно сообщил пострадавшим сторонам о своей исследовательской работе, надеясь, что будут предприняты меры для защиты или предупреждения пользователей об этом типе атаки на анонимность, но остался разочарован.
Signal
Signal мгновенно отклонил мой отчет, сказав, что это не их ответственность и что пользователям предстоит самим скрывать свою личность: "Signal никогда не пытался полностью воспроизвести набор анонимных функций на сетевом уровне, которые могут предоставить такие проекты, как Wireguard, Tor и другое программное обеспечение с открытым исходным кодом для использования VPN."
Я не согласен с этим. Signal позиционирует себя как коммуникационная платформа, ориентированная на защиту конфиденциальности. Хотя он не утверждает, что предоставляет анонимность на сетевом уровне, как Tor, пользователи доверяют Signal в том, что он минимизирует риски для нарушения конфиденциальности.
Уязвимость демонстрирует, что платформа непреднамеренно раскрывает информацию, которая может сузить местоположение пользователя до нескольких сотен миль. Это утечка противоречит ожиданиям многих пользователей, обеспокоенных конфиденциальностью, которые полагаются на Signal не только для обеспечения сквозного шифрования.
Telegram, другое приложение, ориентированное на конфиденциальность, совершенно устойчиво к этой атаке, поскольку (1) они используют собственный протокол, разработанный внутри компании, который не зависит от HTTP, и (2) не полагаются на облачных провайдеров, таких как Cloudflare, для кэширования.
Discord
Сначала команда безопасности Discord пообещала изучить этот вопрос и внести изменения для защиты своих пользователей от этого типа атак, но в конечном итоге они также изменили свою позицию, заявив, что это проблема Cloudflare, которую касается и других потребителей.Cloudflare
Cloudflare в конце концов завершил исправление уязвимости, используемой Cloudflare Teleport для обхода дата-центров. Уязвимость была сообщена в их программу HackerOne год назад другим исследователем, но тогда они не предприняли никаких действий, поскольку не видели никакого воздействия от обхода дата-центров до тех пор, пока я не поделился своей исследовательской работой.
Cloudflare повторно открыл старый отчет, изучил его и выплатил вознаграждение в размере 200 долларов за мой отчет и оригинальный.
Хотя это шаг в правильном направлении, это на самом деле не решает основную проблему. Каждая атака, описанная в этом отчете, была повторно использована в последние 24 часа, несмотря на то что Cloudflare исправил эту уязвимость неделю назад. Cloudflare устранил уязвимость внутри своей сети, которая способствовала обходу дата-центров, но это не единственный способ легко обходить дата-центры по всему миру.
Через 24 часа после их исправления я перепрограммировал Cloudflare Teleport для использования VPN. Многие VPN предоставляют несколько локаций, к которым пользователи могут подключаться, что отправляет их трафик через серверы в различных частях мира, и эти серверы соответствуют различным дата-центрам Cloudflare по всему миру.
Я выбрал провайдера VPN с более чем 3000 серверами, расположенными в различных местах в 31 стране по всему миру. Используя этот новый метод, я снова могу охватить около 54% всех дата-центров Cloudflare. Хотя это не выглядит как большое количество, это покрывает большинство мест в мире с значительным населением.
Окончательное заявление Cloudflare по этому поводу гласит, что они не рассматривают атаку на анонимность как уязвимость в своих системах и что на них, как на потребителей, лежит ответственность за отключение кэширования для ресурсов, которые они хотят защитить.
Здесь явно существует проблема, так как Cloudflare заявляет, что потребители несут ответственность за свою защиту от таких атак, в то время как потребители (например, Discord) возлагают вину на Cloudflare.
Как защитить себя
Потенциал для эксплуатации этой атаки на анонимность значителен, особенно для пользователей в уязвимых ситуациях, таких как журналисты, активисты и люди, заботящиеся о конфиденциальности. Атака использует основные проектные решения в системах кэширования и пуш-уведомлений, демонстрируя, как инфраструктура, предназначенная для повышения производительности, может быть злоупотреблена для инвазивного отслеживания.
Хотя Cloudflare исправил уязвимость в Teleport, и некоторые приложения, такие как Discord и Signal, возможно, внедрили меры по смягчению последствий после моего раскрытия информации, основные риски остаются. Любое приложение, использующее CDN для доставки контента и кэширования, по-прежнему может быть уязвимым, если не будут приняты соответствующие меры предосторожности.
Последняя мысль
Эта атака подчеркивает, насколько сложной и взаимосвязанной стала цифровая экосистема. Хотя CDN повышают производительность и масштабируемость, они также непреднамеренно создают риски, которые можно использовать новыми способами. Повышая осведомленность и продвигая лучшие практики, мы можем работать сообща, чтобы свести к минимуму вероятность злоупотреблений.
Для пользователей, выполняющих важные задачи, или для тех, кто беспокоится о своей конфиденциальности, главное — оставаться в курсе событий и быть бдительными. Хотя ни одна система не является полностью надёжной, принятие мер по ограничению вашего доступа может существенно изменить ситуацию.