Простота использования Signal Private Messenger, многоплатформенная поддержка и сквозное шифрование как сообщений, так и вызовов, становятся причиной роста популярности этого приложения. Сегодня им пользуется даже известный американский осведомитель Эдвард Сноуден: «Я использую Signal каждый день».
Я был очень рад увидеть, как быстро в Signal исправили найденную мною в этом месяце уязвимость, при помощи которой было возможно установить примерное местоположения любого пользователя, просто введя его номер в Signal (из - за утечки DNS-сервера - CVE-2020–5753). В случаях, если используется Google Public DNS (8.8.8.8/8.8.4.4) и схожие сервера, эта атака может сузить местоположение до города, в котором проживает искомый пользователь, в связи с использованием клиентской подсети EDNS.
Команда разработчиков Siganl сразу же сообщила всем, о том, что начала работу над обновлениями клиентов под Android и IOS. У этого приложения открытый исходный код, и, в соответствии с политикой раскрытия информации, они сообщают о проблемах, как только любой патч или информация, имеющая отношение к уязвимости, становится общедоступной (как в этом случае). Согласно нашему исследованию, на Android уязвимы версии Signal 4.59.0 и выше, в то время как для iOS уязвимое обновление WebRTC было представлено в версии 3.8.0.34.
Для некоторых пользователей эта уязвимость покажется критичной, в то время, как обычные обыватели ее вряд ли заметят. Стоит также отметить, что проблема возникает не из - за плохого кода сигнала (нет, с ним все в порядке), а из-за того, что DNS-запросы выполняет WebRTC. Другие приложения для обмена сообщениями также могут быть уязвимы. С момента обнаружения бага, Signal уведомил о нем команду Chromium и представил патч.
Сигнальная Сигнализация
Сигнал использует свой собственный форк WebRTC для голосовых / видео звонков на расстоянии. Чтобы WebRTC мог соединиться с удаленным одноранговым узлом, он должен найти валидное соединение для локального и удаленного однорангового узла связи. Он использует для этого технологию под названием «сигнализация», предполагающую использование промежуточного сервера-сигнализации, который обменивается публичными / частными IP-адресами каждого однорангового узла (ICE-кандидаты), чтобы каждый одноранговый узел мог обнаруживать друг друга и в конечном итоге устанавливать оптимальное соединение.
Для обеспечения защиты, Signal не будет отправлять ваши публичные/частные IP-адреса, если вызов осуществляется от кого-то, кого нет в списке контактов. Кроме того, если пользователь сигнала хочет скрыть свои частные/публичные IP-адреса даже от своих контактов, то на этот случай предусмотрена функция «Всегда ретранслировать вызовы» в параметрах конфиденциальности аккаунта, которая никогда не будет включать ваши публичные/частные IP-адреса в ICE-кандидаты. Вместо этого, Signal просто отправит IP-адрес ближайшего Signal TURN-сервера для того, чтобы вызывающий узел мог подключиться и ретранслировать аудио-/видеовызов через него. Еще одна интересная вещь, которую я заметил, заключается в том, что отправка ip-адреса происходит до того, как пользователь сигнала решит, ответить ли ему на вызов или нет. Я подумал, может ли такая реализация привести к интересной атаке, заключающейся в частичной деанонимизации пользователя, у которого может быть даже включен режим «Всегда ретранслировать вызовы».
Получение DNS по номеру телефона
Для того, чтобы понять, как это можно сделать, мне помог открытый исходный код мессенджера. Читая RFC для ICE, я обнаружил, что он поддерживает доменные имена для ICE-кандидатов.
Чтобы реализовать это, я просто изменил одну процедуру в Signal и скомпилировал приложение Signal под свой «атакующий» смартфон. https://github.com/signalapp/Signal...ecuresms/service/WebRtcCallService.java#L1688
В нем я добавил дополнительных ICE-кандидатов в список iceCandidateParcels. Они содержали мой домен (для которого у меня есть авторитетный сервер имен).
Для каждого ICE-кандидата (а также для каждого вызова) я генерирую уникальный поддомен по двум причинам:
Результаты
После многократного тестирования, я обнаружил, что точность определения местоположения DNS обычно была в радиусе ~ 400 миль, в зависимости от конфигурации ISP / DNS, и могла ответить на такие вопросы, вроде, в какой стране, а иногда и в какой части страны, находится человек. Нужно учитывать не только идентификацию местоположения через DNS-сервер, но и определение местоположения через ISP-коммутаторы. Например, я сейчас сижу дома... эксплуатирую себя с помощью телефона с Signal... Запросы идут на DNS-сервер, который мой телефон использует в домашней сети, и вижу, что этот DNS-сервер от интернет-провайдера Cox в Южной Калифорнии... это правильно, так как я живу в Южной Калифорнии и использую Cox ISP.
Теперь я выхожу на улицу и иду к Starbucks, у меня включен 4G, я вновь использую технику таинственного пропущенного звонка, чтобы уличить новый DNS-сервер…
Хорошо ... похоже, это сервер Verizon DNS в Сан-Хосе, что указывает на то, что я, вероятно, удален от любой известной Wi-Fi-сети на мобильном операторе.
Затем я подключаюсь к Starbucks Wi-Fi. Я сделал еще один вызов с утечкой DNS, который выявил IP-адрес сервера OpenDNS в районе Южной Калифорнии.
Получив эту информацию, злоумышленник узнает, что меня сейчас нет дома. Если он пойдет дальше, он может даже создать профиль часто используемых DNS-серверов, которые я использую, чтобы наметить мои обычные местоположения, такие как «на работе», «дома», «в кафе», «в доме друга» и т. д.
Я проверил это в нескольких других местах и сетях. Один человек вызвался для теста. DNS-сервер мне пришел из Пенсильвании, в том же штате, в котором он находился во время моего тестирования.
Иногда мне приходили странные результаты. Например, однажды я находился в Калифорнии, будучи подключенным к одной Wi-Fi-сети в каком-то ресторане, а запросы определялись как из… Майами, Флорида.
В таких случаях повторяющаяся атака в течение недели поможет сузить радиус поисков, поскольку будет больше утечек DNS-серверов. Сопоставив несколько точек, мы сможем более точно определить местоположение.
Более точную информацию можно получить через клиентскую подсеть EDNS
Некоторые DNS-серверы, такие как часто используемый Google Public DNS (8.8.8.8/8.8.4.4), используют клиентскую подсеть EDNS. При ее использовании, часть IP-адреса исходного клиента (первые 3 октета) направляются на сервер имен.
Эта IP-подсеть позволила узнать местоположение пользователя, чуть ли не в плотную (в паре миль от него).
После этого, я затестил этот способ на себе, так как находился в сети, используя Google Public DNS. После того, как я позвонил на свой телефон со своего номера, я задеанонил город, в котором я находился, после просмотра переадресованной клиентской подсети.
Вывод
Одна из самых больших проблем, которую я хотел обозначить в этой статье, заключается в том, что вы не можете запретить неизвестному номеру в Signal звонить на ваш телефон. Помимо этого, масло в огонь подливает клиентская подсеть EDNS, при использовании который, как мы видели, возможно точно определить ваше местоположение в городе. Если вы обеспокоены этим, я рекомендую обновить Signal Android до версии 4.59.11 или Signal iOS до версии 3.8.4. Если вы не можете выполнить обновление до этих версий, я рекомендую использовать VPN для туннелирования DNS-трафика. В ходе тестирования я обнаружил, что приложения Private Internet Access и Psiphon VPN предотвращают возможную утечку.
оригинал этого материала на английском можно здесь.
автор перевода t.me/cybred
Я был очень рад увидеть, как быстро в Signal исправили найденную мною в этом месяце уязвимость, при помощи которой было возможно установить примерное местоположения любого пользователя, просто введя его номер в Signal (из - за утечки DNS-сервера - CVE-2020–5753). В случаях, если используется Google Public DNS (8.8.8.8/8.8.4.4) и схожие сервера, эта атака может сузить местоположение до города, в котором проживает искомый пользователь, в связи с использованием клиентской подсети EDNS.
Команда разработчиков Siganl сразу же сообщила всем, о том, что начала работу над обновлениями клиентов под Android и IOS. У этого приложения открытый исходный код, и, в соответствии с политикой раскрытия информации, они сообщают о проблемах, как только любой патч или информация, имеющая отношение к уязвимости, становится общедоступной (как в этом случае). Согласно нашему исследованию, на Android уязвимы версии Signal 4.59.0 и выше, в то время как для iOS уязвимое обновление WebRTC было представлено в версии 3.8.0.34.
Для некоторых пользователей эта уязвимость покажется критичной, в то время, как обычные обыватели ее вряд ли заметят. Стоит также отметить, что проблема возникает не из - за плохого кода сигнала (нет, с ним все в порядке), а из-за того, что DNS-запросы выполняет WebRTC. Другие приложения для обмена сообщениями также могут быть уязвимы. С момента обнаружения бага, Signal уведомил о нем команду Chromium и представил патч.
Сигнальная Сигнализация
Сигнал использует свой собственный форк WebRTC для голосовых / видео звонков на расстоянии. Чтобы WebRTC мог соединиться с удаленным одноранговым узлом, он должен найти валидное соединение для локального и удаленного однорангового узла связи. Он использует для этого технологию под названием «сигнализация», предполагающую использование промежуточного сервера-сигнализации, который обменивается публичными / частными IP-адресами каждого однорангового узла (ICE-кандидаты), чтобы каждый одноранговый узел мог обнаруживать друг друга и в конечном итоге устанавливать оптимальное соединение.
Для обеспечения защиты, Signal не будет отправлять ваши публичные/частные IP-адреса, если вызов осуществляется от кого-то, кого нет в списке контактов. Кроме того, если пользователь сигнала хочет скрыть свои частные/публичные IP-адреса даже от своих контактов, то на этот случай предусмотрена функция «Всегда ретранслировать вызовы» в параметрах конфиденциальности аккаунта, которая никогда не будет включать ваши публичные/частные IP-адреса в ICE-кандидаты. Вместо этого, Signal просто отправит IP-адрес ближайшего Signal TURN-сервера для того, чтобы вызывающий узел мог подключиться и ретранслировать аудио-/видеовызов через него. Еще одна интересная вещь, которую я заметил, заключается в том, что отправка ip-адреса происходит до того, как пользователь сигнала решит, ответить ли ему на вызов или нет. Я подумал, может ли такая реализация привести к интересной атаке, заключающейся в частичной деанонимизации пользователя, у которого может быть даже включен режим «Всегда ретранслировать вызовы».
Получение DNS по номеру телефона
Для того, чтобы понять, как это можно сделать, мне помог открытый исходный код мессенджера. Читая RFC для ICE, я обнаружил, что он поддерживает доменные имена для ICE-кандидатов.
Еще в 2018 году, в WebRTC была добавлена поддержка этих доменных имен https://webrtc-review.googlesource.com/c/src/+/85540/16. Поскольку под капотом Signal использует WebRTC, я решил, что можно просто указать доменное имя для одного из ICE-кандидатов, чтобы, когда я позвоню по телефону (и инициирую обмен ICE-кандидатами), у вызываемого абонента не было другого выбора, кроме как принять запрос. Если у меня будет авторитетный сервер имен для домена, я смогу зарегистрировать IP-адрес, который попытается запросить мой сервер имен. Этим IP-адресом будет DNS-сервер, используемый удаленным пользователем сигнала, который обычно географически близок к пользователю. И снова вызываемый абонент выполнит этот запрос еще до того, как решит, ответить ли ему на звонок. Фактически, я обнаружил, что могу легко вызвать DNS-запрос до того, как телефон даже «зазвонит», а затем завершить вызов, так что все, что увидит вызывающий абонент, это уведомление о «пропущенном вызове». Между тем, на моей стороне сервера имен мы увидим входящий DNS-запрос от текущего распознавателя DNS удаленного пользователя Signal.
Чтобы реализовать это, я просто изменил одну процедуру в Signal и скомпилировал приложение Signal под свой «атакующий» смартфон. https://github.com/signalapp/Signal...ecuresms/service/WebRtcCallService.java#L1688
В нем я добавил дополнительных ICE-кандидатов в список iceCandidateParcels. Они содержали мой домен (для которого у меня есть авторитетный сервер имен).
Для каждого ICE-кандидата (а также для каждого вызова) я генерирую уникальный поддомен по двум причинам:
- Определить конкретные входящие запросы в моем журнале имен
- Убедиться, что он обойдет любое DNS-кэширование (поэтому я всегда заставляю DNS-сервер вызываемого абонента запрашивать мой сервер имен).
Результаты
После многократного тестирования, я обнаружил, что точность определения местоположения DNS обычно была в радиусе ~ 400 миль, в зависимости от конфигурации ISP / DNS, и могла ответить на такие вопросы, вроде, в какой стране, а иногда и в какой части страны, находится человек. Нужно учитывать не только идентификацию местоположения через DNS-сервер, но и определение местоположения через ISP-коммутаторы. Например, я сейчас сижу дома... эксплуатирую себя с помощью телефона с Signal... Запросы идут на DNS-сервер, который мой телефон использует в домашней сети, и вижу, что этот DNS-сервер от интернет-провайдера Cox в Южной Калифорнии... это правильно, так как я живу в Южной Калифорнии и использую Cox ISP.
Теперь я выхожу на улицу и иду к Starbucks, у меня включен 4G, я вновь использую технику таинственного пропущенного звонка, чтобы уличить новый DNS-сервер…
Хорошо ... похоже, это сервер Verizon DNS в Сан-Хосе, что указывает на то, что я, вероятно, удален от любой известной Wi-Fi-сети на мобильном операторе.
Затем я подключаюсь к Starbucks Wi-Fi. Я сделал еще один вызов с утечкой DNS, который выявил IP-адрес сервера OpenDNS в районе Южной Калифорнии.
Получив эту информацию, злоумышленник узнает, что меня сейчас нет дома. Если он пойдет дальше, он может даже создать профиль часто используемых DNS-серверов, которые я использую, чтобы наметить мои обычные местоположения, такие как «на работе», «дома», «в кафе», «в доме друга» и т. д.
Я проверил это в нескольких других местах и сетях. Один человек вызвался для теста. DNS-сервер мне пришел из Пенсильвании, в том же штате, в котором он находился во время моего тестирования.
Иногда мне приходили странные результаты. Например, однажды я находился в Калифорнии, будучи подключенным к одной Wi-Fi-сети в каком-то ресторане, а запросы определялись как из… Майами, Флорида.
В таких случаях повторяющаяся атака в течение недели поможет сузить радиус поисков, поскольку будет больше утечек DNS-серверов. Сопоставив несколько точек, мы сможем более точно определить местоположение.
Более точную информацию можно получить через клиентскую подсеть EDNS
Некоторые DNS-серверы, такие как часто используемый Google Public DNS (8.8.8.8/8.8.4.4), используют клиентскую подсеть EDNS. При ее использовании, часть IP-адреса исходного клиента (первые 3 октета) направляются на сервер имен.
Давайте посмотрим несколько примеров. В этом случае утек DNS-сервер добровольца на Среднем Западе, который использует клиентскую подсеть EDNS. Нашему серверу имен были переданы первые 3 октета действительного IP-адреса пользователя (последние 2 октета размыты) в поле «Дополнительные записи / клиентская подсеть» запроса.
Эта IP-подсеть позволила узнать местоположение пользователя, чуть ли не в плотную (в паре миль от него).
После этого, я затестил этот способ на себе, так как находился в сети, используя Google Public DNS. После того, как я позвонил на свой телефон со своего номера, я задеанонил город, в котором я находился, после просмотра переадресованной клиентской подсети.
Вывод
Одна из самых больших проблем, которую я хотел обозначить в этой статье, заключается в том, что вы не можете запретить неизвестному номеру в Signal звонить на ваш телефон. Помимо этого, масло в огонь подливает клиентская подсеть EDNS, при использовании который, как мы видели, возможно точно определить ваше местоположение в городе. Если вы обеспокоены этим, я рекомендую обновить Signal Android до версии 4.59.11 или Signal iOS до версии 3.8.4. Если вы не можете выполнить обновление до этих версий, я рекомендую использовать VPN для туннелирования DNS-трафика. В ходе тестирования я обнаружил, что приложения Private Internet Access и Psiphon VPN предотвращают возможную утечку.
оригинал этого материала на английском можно здесь.
автор перевода t.me/cybred