Динамика развития и влияние на пользователей вредоносных релеев сети Tor в 2020 году

Автор: nusenu

Более 23% выходной мощности сети Tor участвовало компрометировании пользователей

Рисунок 1: Динамика изменения подверженной вредоносной выходной мощности сети Tor, измеренной в процентах от всей доступной выходной мощности в 2020 году (для конкретно этого крупного оператора вредоносных релеев). Автор графика: nusenu (источник исходных данных: https://metrics.torproject.org/onionoo.html)

В декабре 2019 года я написал статью The Growing Problem of Malicious Relays on the Tor Network с целью привлечения внимания к проблеме и улучшения ситуации в будущем. К сожалению, вместо улучшения стало еще хуже, особенно, когда речь заходит о вредоносной активности выходных Tor-релеев.

Выходные релеи – последний переход (или хоп) в цепи из 3 релеев и единственный тип релеев, который может видеть соединение с местом назначения, указанное пользователем в браузере Tor. От используемого протокола (например, http или https) зависит, сможет ли вредоносный выходной релей видеть и манипулировать передаваемым содержимым.

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

Масштаб деятельности вредоносного оператора

За время моего мониторинга проблемы в течение последних 5 лет текущий 2020 год пока что является наихудшим в плане вредоносной активности выходных релеев. Насколько мне известно, злоумышленник, использующий более 23% выходной мощности всей сети Tor, был обнаружен впервые. Таким образом, приблизительно одно из четырех подключений, покидающих сеть Tor, проходило через выходные релеи, контролируемые одним оператором вредоносных релеев.

На Рисунке 1 показана доля используемой выходной мощности сети Tor, находящаяся под контролем злоумышленника, и количество подтвержденных одновременно работающих вредоносных релеев (пиковое значение – 380). Также по Рисунку 1 можно понять, что если мы откроем браузер Tor на пике реализации атаки (22 мая 2020 года), то вероятность выбрать выходной релей, контролируемый злоумышленником, составляет 23,95%. Поскольку клиенты Tor обычно используют много выходных релеев, с течением времени шанс попасть на вредоносный релей возрастает.

Временное удаление вредоносных релеев

Линия на Рисунке 1, отражающая количество релеев, показывает, что добавление релеев происходило большими пачками, что дает сервису OrNetRadar (детектор групп релеев) возможность обнаружения этих групп, что и происходило во множестве случаев (см. Приложение в конце статьи). Наиболее примечательный пик наблюдается в марте 2020 года. 16 марта сервис OrNetRadar совместно с проектом по обнаружению атак Сивиллы сообщили о внезапном пике в более чем 150 новых релеев, чего никогда не происходило в столь короткий период времени. В тот момент эти релеи были удалены, но спустя три дня опять появились после того, как злоумышленник связался со списком рассылки плохих релеев и сделал так называемую настройку «MyFamily» для объединения в группу. На данный момент не существует дополнительных требований для запуска столь большой группы релеев в сети Tor.

Скорость восстановления после удаления

Три резких спада на Рисунке 1 (помеченные как 1, 2, 3) отражают события, когда некоторые вредоносные выходные релеи были обнаружены и удалены из сети администраторами каталога Tor. Резкость подъемов после спадов показывает, насколько быстро происходит восстановление популяции вредоносных релеев, и что мы не смогли найти все вредоносные релеи одновременно. После удаления потребовалось менее 30 дней на восстановление, и вероятность попадания на вредоносный релей с 4% вновь восстановилась до 22%. Мы снова убеждаемся, что злоумышленники не отступят от своей затеи после обнаружения и удаления. Скорее всего, есть план на случай детектирования и удаления, и в запасе есть релеи с целью избежать полной остановки всех операций и жизнедеятельности сети.

Множество поддельных независимых групп релеев

Ситуация, связанная с временным удаление релеев, послужила для злоумышленников хорошим уроком, и у всех последующих релеев похоже была идеальная настройка MyFamily с одной важной оговоркой: вместо объединения релеев в одну группу, было создано множество групп, несвязанных друг с другом. Эта стратегия стала использоваться с января 2020 года. На Рисунке 2 показана выходная вероятность в разрезе отдельным группам (составная диаграмма).

Рисунок 2: Динамика развития подтвержденной вредоносной фракции выходных релеев, составленная на основе информации из ContactInfo (все группы управляются из одного центра). Автор графика: nusenu (источник исходных данных: https://metrics.torproject.org/onionoo.html)

На Рисунке 3 показано, как много вредоносных выходных релеев от одного оператора были разделены на отдельные группы на основе информации ContactInfo (составной график).

Рисунок 3: Динамика подтвержденных вредоносных выходных релеев с течение времени на основе информации из ContactInfo. Автор графика: nusenu (источник исходных данных: https://metrics.torproject.org/onionoo.html)

Контактная информация может быть произвольно установлена оператором релея. Соответственно, эти сведения следует принимать во внимание с некоторыми оговорками, однако поскольку множество этих электронных адресов взаимодействовали со списком рассылки плохих релеев, есть некоторая уверенность, что эти адреса существуют и находятся под управлением оператора вредоносных релеев. Были даже адреса, имитирующие принадлежность к ФБР, с именем fbirelays@… (этот адрес никогда не использовался для контактов со списком рассылки плохих релеев, и я не считаю, что ФБР может иметь что-то общее с этими релеями). В целом видно, что злоумышленник предпочитает общеизвестные почтовые сервисы (hotmail, protonmail и gmail).

Рисунок 4: Перечень адресов, используемых в поле ContactInfo вредоносными выходными релеями

Используемая инфраструктура

Один из ключевых вопросов, возникающих каждый раз во время анализа вредоносных релеев, - какие используются сервисы для хостинга. OVH - один из наиболее крупных провайдеров, предоставляющих услуги хостинга для релеев. Другие известные провайдеры, предоставляющие услуги подобного рода, - Frantech, ServerAstra и Trabia Network. Компания «Nice IT Services Group» тожепредставляет определенный интерес, поскольку я никогда не видел релеи в этой малоизвестной сети, пока 16 апреля злоумышленник не добавил несколько релеев.

Рисунок 5: Разбивка релев по используемым провайдерам. Наиболее плотно используются OVH и FranTech Solutions. Автор графика: nusenu (источник исходных данных: https://metrics.torproject.org/onionoo.html)

Как используются вредоносные релеи для атак на пользователей

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

Злоумышленники реализуют атаки по типу «человек-посередине» на пользователей сети Tor посредством манипуляции трафиком, который проходит через выходные релеи. Происходит (выборочное) удаление редиректов HTTP-к-HTTPS с цель получения полного доступа к незашифрованному HTTP-трафику без появления предупреждений, связанных с TLS сертификатами. При использовании браузера TOR очень сложно выявить эту схему, если специально не присматриваться к адресной строке на предмет присутствия префикса «https://». Эта хорошо известная атака носит название «ssl stripping», которая основана на том факте, что пользователь редко набирает полный адрес, начинающийся с «https://».

Для противодействия реализованы контрмеры в виде HSTS Preloading и HTTPS Everywhere, однако на практике многие сайты не используют эти технологии, и пользователи остаются уязвимы к угрозам подобного рода. Этот вид атаки не является специфическим для браузера Tor. Вредоносные релеи используются лишь для получения доступа к пользовательскому трафику. С целью затруднить детектирование атаки осуществляются не на все сайты, а в основном на сервисы криптовалют. Если более конкретно – на биткоин-миксеры. Внутри HTTP-трафика происходит замена биткоин-адреса для перенаправления транзакций на кошельки злоумышленников вместо адреса, указанного пользователем. Атаки, связанные с подменой биткоин-адресов не являются чем-то новым, однако впечатляет масштаб деятельности. Кроме того, невозможно определить, реализуются ли другие типы атак.

Я связался с представителями некоторых биткоин-сервисов, затронутых этой атакой, с целью реализации мер на техническом уровне при помощи HSTS preloading. Где-то были внедрены правила HTTPS-Everywhere для известных доменов (HTTPS Everywhere устанавливается по умолчанию в браузере Tor), подверженных этой угрозе. К сожалению, ни на одном из этих сайтов на тот момент не использовался HSTS preloading. Как минимум на одном биткоин-сайте был реализован HSTS preloading после анализа произошедших событий.

Атака завершена?

Если посмотреть на общую заявленную выходную пропускную способность сети Tor и выделить долю, используемую злоумышленниками, которая была удалена, то можно увидеть значительное увеличение выходной мощности после последнего удаления в районе 21 июня 2020 года. Эта часть кривой схожа с предыдущим месяцем, когда злоумышленники восстановились после первого удаления в районе 22 мая 2020 года. Я добавил на график «ожидаемую» линию, чтобы показать, примерно на каком уровне ожидается общая пропускная способность без непривычного роста (приблизительно рассчитанная путем объединения заявленной пропускной способности, добавленной известными операторами после удаления)

Рисунок 6: Общая заявленная выходная пропускная способность сети Tor с течением времени показывает необычный рост после удаления вредоносных релеев. Автор графика: nusenu (источник исходных данных: https://metrics.torproject.org/onionoo.html)

На Рисунке 7 показано влияние оператора вредоносных релеев на вероятность, с которой пользователи браузера Tor выберут одну из известных организаций, составляющих выходную мощность сети (например, упомянутые в разделе https://torservers.net/partners.html и другие компании, известные в сообществе, посвященному релеям, в течение продолжительного времени). Злоумышленнику удалось снизить вероятность выбора выходного релея с обычной в районе 60% до 50%. Этот график также показывает, что доля известных организаций снижается несмотря на увеличение заявленной выходной мощности.

Рисунок 7: Доля выходных релеев и заявленная выходная полоса известных операторов/организаций. Автор графика: nusenu (источник исходных данных: https://metrics.torproject.org/onionoo.html)

Возникает закономерный вопрос: «Если доля известных операторов сокращается, то чья доля увеличивается?». На Рисунке 8 и 9 показана доля выходной мощности неизвестных операторов в разрезе автономной системы (Рисунок 8) и информации ContactInfo релея (Рисунок 9). Графики показывают сети и ContactInfo со значительной долей (более 0,5% вероятности попадания на выходной релей). Видно, что доля сетей, принадлежащих хостерам OVH (ранее плотно используемым злоумышленником) и Liteserver Holding серьезно выросла после удаления в районе 21 июня 2020 года. Кроме того, появились две новые доли (каждая составляет более 5% общей выходной мощности).

Рисунок 8: Выходная доля неизвестных операторов с момента последнего удаления вредоносных релеев (21 июня 2020 года) в разрезе по автономной системе (показаны номера ASN, превышающие вероятность 0,5% попадания на выходной релей). Две сети значительно выросли: OVH (снова) и Liteserver Holding. Автор графика: nusenu (источник исходных данных: https://metrics.torproject.org/onionoo.html)

Рисунок 9: Выходная доля неизвестных операторов с момента последнего удаления выходных релеев (21 июня 2020 года), сгруппированных по контактной информации выходного релея (составной график). Показаны только ContactInfo с вероятностью попадания на выходной релей более 0,5%. Автор графика: nusenu (источник исходных данных: https://metrics.torproject.org/onionoo.html)

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

Меры противодействия угрозе

Обработка плохих релеев

После публикации статьи, посвященной росту вредоносных релеев, в декабре 2019 года у проекта Tor Project были многообещающие планы на 2020 год с назначением исполнителя, который должен был курировать улучшения в этом направлении, однако из-за пандемии коронавируса этот человек был переориентирован на другую задачу. Кроме того, администраторы каталога Tor, по-видимому, больше не удаляют релеи, начиная с 26 июня 2020 года. Не очень понятно, что послужило причиной изменения в политике работы администрации, но кому-то эта ситуация очень нравится, поскольку добавляются незадекларированные группы релеев (которые раньше удалялись из-за незаполнения ContactInfo и MyFamily). Сей факт означает, что обнаружение злоумышленника, которому принадлежало более 10% мощности узлов guard сети Tor в декабре 2019 года, не повлияло ни на какие улучшения. Поскольку предыдущие отчеты остались без ответа более месяца, я прекратил сообщать о релеях на удаление, однако давайте пока оставим эту тему (которая заслуживает отдельной статьи) и учтем, что проект Tor Project пока не выделил ресурсов для решения этой проблемы (важная информация, когда делается попытка добиться некоторого прогресса)

Улучшенные визуализации долей «известных» и «неизвестных» сетей

«Нам не хватает инструментов для отслеживания и визуализации релеев, которым мы доверяем» - Роджер Дингледин.

Важно отследить, когда доли известных и неизвестных сетей сильно меняются. Я стремлюсь внедрить графики, как на Рисунках 7 и 8, в ежедневно генерируемую статистику OrNetStats. Однако решить эту задачу можно только в случае, если верификацию статического идентификатора оператора можно автоматизировать, поскольку ручная верификация отнимает слишком много времени на длительном периоде. Я работаю над второй версии спецификации ContactInfo Information Sharing Specification с целью предоставления операторам релеев две простых опции для автоматической проверки поля «operatorurl». Проверяемые поля затем могут использоваться в качестве входных данных для ручной оценки (выполняемой однократно) «известной» метки, которая затем используется для графиков. Как только вторая версия спецификации будет выпущена (что должно произойти не позднее конца августа 2020 года) и применена достаточным количеством операторов релеев, подобные графики могут быть добавлены в OrNetStats и другие инструменты. Кроме того, сразу же упростится реализация планов Роджера Дингледина. В общем, одним из решающих факторов будет использование второй версии спецификации операторами релеев.

Краткосрочная перспектива: снижение вреда от угрозы

Как же мы можем затруднить жизнь и увеличить трудозатраты злоумышленников по развертыванию больших сетей релеев в сети Tor на постоянной основе? На данный момент не существует требований для операторов релеев, работающих в больших масштабах. Соответственно, ничто не может остановить злоумышленника от добавления 150 вредоносных релеев, как было продемонстрировано во время атаки в марте 2020 года.

Указанные ниже рекомендации учитывают, что у проекта Tor Project нет ресурсов для решения этой проблемы.

В качестве незамедлительной меры по противодействию этой угрозе проект Tor Project может затребовать проверку физического адреса для всех новых (подключившихся в 2020 году) операторов релеев, занимающих долю более 0,5% от выходной мощности или мощности узлов guard. Откуда взялось 0,5%? Это баланс между риском от мощности вредоносного релея и усилиями, требуемые для верификации. Выше порога 0,5% остается мало операторов для верификации. На 8 августа 2020 года только пять операторов выходных релев и один оператор узлов guard соответствовали этим критериям (новые и крупные). Некоторые из этих операторов имели схожие признаки с ранее удаленными группами вредоносных релеев. Другие уже имеют хорошую репутацию. Таким образом, начальная верификация заключается в отсылке 6 писем по предоставленному физическому адресу (хотя наиболее вероятно по 3 адресам, поскольку по некоторым можно не запрашивать проверку физического адреса).

Эта схема также дает полномочия тем, кто принимает трудные решения при работе с подозрительными релеями.

Долгосрочная перспектива: ограничение злоумышленников посредством выделения минимальной доли сети для известных операторов

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

1. Требуется проверенный адрес электронной почты для получения флага выходного релея или релея узла guard. Верификацию электронной почты можно полностью автоматизировать. Поскольку операторы вредоносных релеев могут легко зарегистрировать новые адреса, переходим ко второму шагу.
2. Требуется проверенный физический адрес для больших операторов (более 0,5% выходной вероятности или вероятности узла guard).

Заключение

• С момента обнаружения крупномасштабных атак на сеть Tor (операторы вредоносных релеев занимали более 10% мощности узлов guard) в декабре 2019 года, никаких улучшения в плане снижения количества вредоносных релеев предпринято не было.
• Оператор вредоносных релеев, упоминаемый в этой статье, контролировал более 23% выходной мощности всей сети Tor (на момент 22 мая 2020 года).
• Оператор вредоносных релеев восстановил мощность после первоначальных попыток удаления администраторами каталога Tor.
• Существует множество индикаторов, свидетельствующих, что злоумышленник до сих пор контролирует более 10% от всей выходной мощности сети Tor (на 8 августа 2020 года).
• Повторяющиеся события, связанные с масштабной активностью вредоносных релеев, свидетельствуют о недостаточности мер, предпринимаемых для детектирования плохих релеев.
• Было предложено множество контрмер для решения текущей проблемы, связанной с мощностью вредоносных релеев.
• Всё зависит от руководителей проекта Tor Project и администраторов каталога в плане предотвращения ущерба для пользователей.

Благодарности

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

Поддержка этого исследования

Я бы хотел в дальнейшем и на постоянной основе продолжать исследования подозрительной активности в сети Tor, которая может нести риски для пользователей. Чтобы я смог глубже проанализировать проблему, мне нужна лицензия для утилиты Maltego Classic, поскольку сейчас есть некоторые ограничения при использовании бесплатной версии Maltego Community edition (утилита с открытым исходным кодом для расследований и анализа графических ссылок). Вы можете помочь в дальнейшем развитии этих исследований, если вдруг работаете в компании Maltego или просто хотите помочь, посредством предоставления лицензии для этой утилиты.

Приложение

Ссылки на известные вредоносные выходные релеи, принадлежащие злоумышленнику, упоминаемому в статье:

https://nusenu.github.io/OrNetRadar/2020/01/29/a5

https://nusenu.github.io/OrNetRadar/2020/02/05/a3

https://nusenu.github.io/OrNetRadar/2020/02/11/a4

https://nusenu.github.io/OrNetRadar/2020/02/16/a2

https://nusenu.github.io/OrNetRadar/2020/02/29/a4

https://nusenu.github.io/OrNetRadar/2020/03/16/a5

https://nusenu.github.io/OrNetRadar/2020/03/30/a6

https://nusenu.github.io/OrNetRadar/2020/03/30/a7

https://nusenu.github.io/OrNetRadar/2020/04/11/a4

https://nusenu.github.io/OrNetRadar/2020/04/13/a8

https://nusenu.github.io/OrNetRadar/2020/04/14/a3

https://nusenu.github.io/OrNetRadar/2020/04/16/a7

https://nusenu.github.io/OrNetRadar/2020/04/21/a4

https://nusenu.github.io/OrNetRadar/2020/05/04/a9

https://nusenu.github.io/OrNetRadar/2020/05/06/a2

https://nusenu.github.io/OrNetRadar/2020/05/09/a2

https://nusenu.github.io/OrNetRadar/2020/05/22/a7

https://nusenu.github.io/OrNetRadar/2020/05/25/a4

https://nusenu.github.io/OrNetRadar/2020/05/28/a1

https://nusenu.github.io/OrNetRadar/2020/06/02/a1

https://nusenu.github.io/OrNetRadar/2020/06/13/a2