id: Гость   вход   регистрация
текущее время 10:12 15/11/2019
Владелец: unknown (создано 30/07/2014 20:57), редакция от 31/07/2014 10:27 (автор: SATtva) Печать
Категории: криптография, софт, анонимность, приватность, анализ трафика, протоколы, прослушивание коммуникаций, tor, уязвимости, атаки
http://www.pgpru.com/Новости/2014/УведомлениеОДеанонимизацииОператоровИПользователейСкрытыхСервисовTor
создать
просмотр
редакции
ссылки

30.07 // Уведомление о деанонимизации операторов и пользователей скрытых сервисов Tor

Общие сведения


4 июля 2014 нами была обнаружена группа узлов, которые, как мы предполагаем, пытались деанонимизировать пользователей. Они пытались выделить людей, которые заходили на скрытые сервисы Tor или управляли ими. Атака включала в себя модификацию заголовков протокола Tor для реализации варианта атаки подтверждения.


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


К сожалению, до сих пор неясно, в чём заключается эта «угроза». Мы знаем, что атака основывалась на поиске пользователей, скачивающих дескрипторы скрытых сервисов, но скорее всего атакующие не могли видеть никакого трафика уровня приложений (например, какие страницы скачивались или даже какие пользователи посещали находящийся под прицелом скрытый сервис). Атака вероятно также пыталась выявить тех, кто публиковал дескрипторы скрытых сервисов, что позволило бы атакующему определить местоположение этих скрытых сервисов. В теории эта атака могла бы также быть использована и для вычисления местоположения пользователей обычных цепочек Tor, но мы не нашли доказательств того, что злоумышленники оперировали хотя бы на каких-то исходящих узлах, что делает такой вариант атаки маловероятным. Наконец, мы не знаем сколько данных собрали атакующие и судя по способу её выполнения (см. детали далее), их метод модификации заголовков протокола мог помогать деанонимизировать пользователей и другим атакующим.


Узлы должны обновиться до текущей версии Tor (0.2.4.23 или 0.2.5.6-альфа) для закрытия специфической уязвимости протокола, использованной атакующими — но стоит помнить, что предотвращение атак подтверждения трафика в общем случае остаётся открытой проблемой для исследования. Клиенты должны обновиться по мере выхода новых версий Tor-браузера, чтобы продвинуться в сторону уменьшения количества сторожевых узлов, способных просматривать их трафик, чтобы снизить вероятность подобного рода атак в будущем. Операторы скрытых сервисов должны предусмотреть сценарий смены местоположения своих скрытых сервисов.

Технические детали


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


Атака подтверждения трафика возможна в случае, если атакующий контролирует или наблюдает узлы на обеих концах Tor-цепочки и сравнивает время, объём и другие характеристики, по которым можно сделать вывод о том, что два узла находятся в однй цепочке. Если первый узел цепочки (называемый «сторожевым») знает IP-адрес пользователя, то последний узел в этой цепочке знает ресурс или местоположение, которое запрашивает пользователь, вместе эти сведения позволяют деанонимизировать пользователя. Больше об атаке подтверждения трафика, включая указания на множество исследовательских работ можно прочитать в блог-посте от 2009 года.


Особенностью происходившей атаки подтверждения является использование внесения активных меток в сигнал на стороне одного узла и считывании этих меток на другом узле. Такие атакующие узлы должны быть достаточно стабильными, чтобы получить флаг HSDir («подходящий для использования в качестве директории скрытых сервисов») и Guard («подходящий на роль сторожевого входящего узла»). Затем они вносят сигнал, когда они выступают в роли директории скрытых сервисов и высматривает сигнал, когда используются в качестве входящего узла.


Данные внедрялись в сигнал посылкой последовательностей "relay" или "relay early" — управляющих команд цепочки, что позволяло кодировать желаемое для отправки сообщение. При этом Tor имеет два типа ячеек: ячейки связи, которые предназначены для соседнего узла в цепочке и ячейки узла, которые доходят до конца всей цепочки. В 2008 году был введён новый тип узловой ячейки — "relay early", которая предназначена для предотвращения умышленного создания пользователями слишком длинных путей в Tor-сети: слишком длинные пути приводят к заторам и снижению анонимности. Но исправление путей бесконечной длины привело к проблемам с доступом к скрытым сервисам, и одним из побочных эффектов стало то, что ограничивая исходящие от клиента в цепочку ячейки "relay early", мы не ограничивали количество входящих от узла к клиенту ячеек "relay early".


В итоге, когда клиенты Tor контактировали с атакующими узлами в их роли директорий скрытых сервисов для публикации или получения дескрипторов скрытых сервисов (второй и третий шаги на диаграмме протокола скрытых сервисов), то узел мог отсылать имя скрытого сервиса (закодированного в чередовании ячеек "relay" и "relay early") обратно по цепочке. Другие атакующие узлы, когда они оказывались выбранными в качестве первых узлов в цепочке, смотрели наличие входящих ячеек "relay early" (поскольку никто другой их не мог послать) и таким образом узнавали, какую информацию клиент запрашивал о скрытых сервисах.


Есть три важных соображения по поводу этой атаки:


A) Атакующий кодирует имя скрытого сервиса во вброшенном сигнале (вместо того, чтобы, например, посылать случайное число и сохранять локальный список соответствий случайных чисел и скрытых сервисов). Кодированный сигнал шифруется, так как он посылается по TLS-каналу между узлами. Однако, такой сигнал легко может увидеть и разобрать каждый, кто запускает свой узел и принимает кодированный трафик. И мы также беспокоимся о глобальном наблюдателе (например, большом разведывательном агентстве), который записывает трафик на входящих узлах и затем пытается взломать шифрование Tor-соединений. Таким образом эта атака ослабляет анонимность Tor против всех возможных атакующих, даже от тех кто сохранил логи трафика Tor, чтобы анализировать их в будущем. Так что даже если эта атака является исследовательским проектом (т.е. не преследует злонамеренных целей), она проведена безответственным способом, поскольку подставляет пользователей под риск в неопределённом будущем.


(Это же соображение относится к общим проблемам законности исследований, которые атакуют реальных пользователей, модифицируя их трафик на одной стороне и прослушивая его на другой. Такие средства как Shadow замечательны для исследования идей в отношении Tor в лаборатории).


B) Данная атака модифицирования заголовка протокола довольно изящна с точки зрения перспективности исследований в том, что она отличается от предыдущих атак внедрения меток, которые действовали на уровне трафика приложений. Предыдущие тэггинг-атаки модифицировали завёрнутый трафик, проходящий входящий узел, чтобы затем отслеживать этот модифицированный завёрнутый трафик на исходящем узле (который мог видеть его в расшифрованном виде). Такие атаки не работали в обратном направлении (от исходящего узла обратно к клиенту), потому что завёрнутый трафик оставался шифрованным на входящем узле. Но поскольку этот новый подход модифицирует «тэг» клиентских заголовков, а не завёрнутый трафик, то любой узел в пути способен видеть этот тэг.


C) Следует напомнить читателям, что поскольку данный частный вариант атаки подтверждения трафика позволяет эффективно создавать корреляции с высокой достоверностью, то более общий класс пассивных (статистических) атак подтверждения трафика остаётся неисправленным мерами защиты и будет также хорошо работать в этой схеме. Хорошая новость в том, что атаки подтверждения трафика не являются новыми и неожиданными, а плохая новость в том, что они продолжают работать. См. обсуждение здесь.


Второй класс атак, который был осуществлён совместно с атаками подтверждения трафика — это стандартные сивилловые атаки — они заключаются в запуске быстрых неисходящих узлов, все в IP-диапазонах 50.7.0.0/16 и 204.45.0.0/16. Вместе эти узлы собрали на себя примерно 6.4% пропускной способности входящих узлов Tor-сети. Затем, частично по причине нашей текущей политики ротации сторожевых узлов, они успели оказаться в использовании у значительной части пользователей Tor в течении 5 месяцев проведения операции.


Мы сразу обратили внимание на эти узлы в момент их присоединения к сети по отчётам сканера DocTor. Мы определили множество новых узлов в промежуток времени, но решили, что их не столько много, чтобы повлиять на большую часть сети. Понятно, что следует учитывать пространство возможностей роста Tor-сети при одновременном учёте социальных контактов с владельцам очень больших наборов узлов. (В целом, возможность распределённости по местоположению и операторам без возможности включения плохих узлов, выглядит сложной проблемой; с другой стороны наши скрипты уведомляют об этом, так что следует надеяться на появление улучшенного решения).


В качестве ответа мы принимает ряд краткосрочных шагов:


1) Удаляем атакующие узлы из сети.


2) Вносим обновление в программу для предотвращения использования ячеек "relay early" данным способом.


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


4) Клиенты смогут определять, получают ли они "relay" или "relay-early" ячейки. Для пользователей-экспертов появится возможность просматривать соответствующее предупреждение в логах: "Received an inbound RELAY_EARLY cell".


Долговременные вопросы, требующие исследования, включают:


5) Дальнейший рост разнообразия операторов и размера Tor-сети, уменьшающий ущерб от появления противников определённого уровня.


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


7) Дальнейшее уменьшение раскрытия сторожевых узлов путём уменьшения периода их ротации.


8) Улучшение понимания атак статистической корреляции трафика и выяснение вопроса, поможет ли дополнение трафика и другие методы противостоять им.


9) Улучшение дизайна скрытых сервисов, в том числе создание затруднений узлам, поддерживающим HS-директорию, для выявления скрытых сервисов, дескрипторы которых хранятся на данных узлах.

Открытые вопросы


Q1) Это то, из-за чего было отозвано недавнее выступление на Black Hat 2014?
Q2) Сможем ли мы найти все злонамеренные узлы?
Q3) Могут ли злонамеренные узлы внедрять сигнал куда-либо ещё, помимо HSDir?
Q4) Сколько данных смогли собрать атакующие, собираются ли они уничтожить эти данные? Защищали ли они как-то эти данные при хранении?


Мы потратили несколько месяцев, пытаясь получить информацию от исследователей, пытавшихся выступить на Black Hat, и с их подсказок догадались, что ячейки "relay early" могут быть использованы для атак подтверждения трафика, после чего мы стали искать эти атаки в реальном мире. Они нам не ответили, так что мы считаем, что ответ на вопрос Q1 — «да». Фактически, мы надеемся, что это именно они проводили атаку, иначе это делал кто-то ещё. Ответов на вопросы Q2, Q3 и Q4 мы пока не знаем.


Источник: The TorProject Blog


 
Много комментариев (41) [показать комментарии/форму]
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3