РегистрацияПростой способ атаки "в обход" tor
Простой способ атаки "в обход" против пользователя Tor.
Протокол сети tor (Onion Routing) имеет топологию статической сети с корневым сертификатом (Root CA). Этот сертификат используется для подписи статистики и ключей независимых серверов, подключаемых к сети Tor. Закрытая часть ключа сертификата принадлежит разработчикам программы tor, открытая зашита в саму программу. Поэтому пользователи всегда доверяют этому сертификату так же как и самой запускаемой ими программе, работу которой они могут протестировать и посмотреть исходники.
Могут ли разработчики злоупотребить наличием своего закрытого ключа? На первый взгляд нет. Серверы в сеть подключаются хотя и под контролем разработчиков, но в целом принадлежат множеству разных людей и организаций. Если разработчики начнут делать с помощью своего закрытого ключа фальшивые подписи на корневом сервере статистики или его зеркалах, то владельцы серверов это заметят, поднимут скандал, отключат сервера и подорвут репутацию проекта.
Однако, если использовать Tor в качестве "приманки" против конкретного пользователя, то всё делается достаточно гладко.
Вот как это может происходить:
1) Представитель силового ведомства Мэллори получает ордер на прослушивание интернет-соединения Алисы, которая использует Tor.
При этом он также получает ордер на выдачу закрытого ключа сети Tor у разработчиков (или получает его другим способом – прослушивание, кража, взлом сервера, подписывающего статистику).
2) Мэллори также получает ордер на установку у интернет-провайдера Алисы специального оборудования для прозрачной трансляции сетевых адресов (Network Adress Translation). В отличии от обычного NAT, который используют админы, это оборудование и соотвествующее программное обеспечение должно максимально незаметно подменять адреса из выбранного списка, имитировать соединение с ними, обрабатывать и отправлять траффик дальше.
3) Если Алиса использует обычное, не связанное с Tor, интернет-соединение, Мэллори просто прослушивает траффик сниффером (эту скучную работу он может поручить Еве).
4) Если Алиса посылает запрос статистики на один из серверов Tor, Мэллори осуществляет простейшую атаку человека посредине "man-in-the-middle". Он создает имитацию соединения с этим IP адресом, а на самом деле отправляет Алисе пакеты, подписанные похищенным сертификатом.
5) После того как Мэллори дал Алисе скачать фальшивую статистику, с фальшивыми же ключами серверов, заверенную сертификатом разработчиков Tor, он перехватывает все обращения к IP-серверам Tor, расшифровывает весь траффик Алисы теми ключами, которые он ей же и подсунул.
6) Для предотвращения подозрений со стороны Алисы Мэллори дополнительно фальсифицирует ответ от всех серверов, которые возвращают IP Алисы (http://serifos.eecs.harvard.edu/cgi-bin/ipaddr.pl?tor=1) и другие.
Правда этот метод не сработает, если Алиса зайдёт на SSL-защищённый сайт, от которого нет ключа у Мэллори и увидит там свой IP, не соответствующий сети tor.
В таком случае Мэллори может перенаправлять конечный траффик Алисы на свои подконтрольные сервера, зарегистрированные в сети Tor.
Имеем классическую (хотя слегка модифицированную) атаку "человека посредине" на сеть с корневым сертификатом.
Это гораздо проще, чем статистический анализ, атаки пересечения или глобального наблюдателя. И результат при соблюдении всего двух условий (достать корневой ключ, получить согласие провайдера, или даже взломать его маршрутизатор без его ведома) не так уж сложно.
Спасибо Spinore http://www.pgpru.com/forum/viewtopic.php?p=11332#11332
который предложил множество интересных идей и вдохновил меня на более внимательное изучение анонимных протоколов, в результате чего мне и пришла в голову мысль насчёт возможности атаки на Tor и использования его в качестве средства индивидуального прослушивания траффика, после чего я и написал этот текст.
Spinore, а Вы хотели ключ хранить в анонимной сети! Современной криптографии пока ещё очень далеко до этого.
Особое внимание при написании данного текста я уделил прекрасному обзору Андреаса Хирта http://pages.cpsc.ucalgary.ca/~hirt
всвязи с его тезисами о том, что в течении давдцати лет так и не было разработано удовлетворительно стойкого и практичного анонимного сетевого протокола, надёжных сведений по доказательству стойкости и классификации атак на такие протоколы в открытой литературе крайне мало, а исследователи то и дело с подозрительным постоянством находят неописанные, хотя и очевидные атаки.
Также, советую тем, кто хочет и дальше копать в этом направлении ознакомиться с архивом проекта Gnunet.
http://www.gnunet.org/papers.php3?xlang=English
Это ответ Гостю на
комментариев: 9 документов: 0 редакций: 1
Насколько я понимаю, реальные системы управлением реактора строятся на сравнении измеряемых параметров с проектными. Строить реактор с заранее неизвестными характеристиками — самоубийственно.
Ув. Spinore невольно ввёл меня в заблуждение своим определением "средних". В действительности он не предлагает "скользящее среднее", а просто "скользящую точку отсчёта".
Трудность усреднения понятна. Для того, чтобы использовать статистику и моменты от неё, нужно иметь период, за который можно ручаться, что статистика верна. Поэтому на первом шаге вместо усреднения можно использовать сверенную независимым способом статистику в начальный момент времени, по методу spinore. Когда пройдёт определенный период времени, т.е. размер окна усреднения, можно уже переходить на "скользящее среднее" (и высшие моменты). Далее положение окна будет плавно сдвигаться, по мере обновления данных о серверах tor-сети. Периодически статистика должна кросс-верифицироваться между пользователями.
Преимуществом усреднений будет меньшее количество ложно-положительных срабатываний системы. Недостаток является продолжением достоинства — будет меньшая чувствительность к немонотонным вбросам, впрочем, на монотонные вбросы оно не повлияет. Нельзя забывать и о большей технической сложности критерия с усреднением по сравнению с предложением spinore. Можно поэтому рассмотреть схему с усреднением как следующий этап.
комментариев: 9796 документов: 488 редакций: 5664
Разработчики неоднократно говорили, что собирают статистику сети, они могут наверное сразу сказать насколько реально то или другое.
Я не подразумевал брутального соглашательства... если есть существенные недоработки в схеме, которые стоило бы учесть в первом шаге на пути к истине, то пишите. Может быть я просто не вижу ряд других возможных атак.
Ну чё, мне тогда попытаться доработать итоговое письмо с учётом всех правок?
комментариев: 9796 документов: 488 редакций: 5664
Как бы связность C и D между собой внести?
Можете всё письмо или хотя бы внести абзацы с описанием Вашего метода.
Нам в первом приближении вообще всё равно – скоррелированы C и D или нет. Общие формулы это не отменяет.
Завтра будет. Сегодня уже – баиньки :)
А что под этим будет пониматься:
оппонент оставляет доступ для подключения к ентри-ноде только к подконтрольным нодам, остальное блокирует на стороне провайдера
или
оппонет банально досит (или закрывает ноды использую административный ресурс) неподконтрольные ноды так что цепочки строятся через вражеские ноды.
В первом случае это сразу обнарудится по статусам (для всех ноды работают для вас нет).
Во втором не знаю как грамотно сделать. Допустим ориентироваться на график работы каждой ноды на прошлый период, например если пойдет массовое отключение нод раньше никогда не отключавшихся, но нереагировать на появление/пропадания ноды если это укладывается в ее средний график работы (днем работает ночью выключена или наоборот) + стараться "разумно" использовать в цепочках спонтанно появляющиеся ноды (в масштабе всей сети нода должна наработать себе статистику, неделю-месяц, после чего ей условно можно доверять и использовать в цепочках) – во всякомслучае это избавит от вброса большого колич вражеских нод (например зарядили ботнет).
Вообще, строго говоря это терминология unknown'а – он лучше ответит что подразумевал, но мне казалось что вот это:
хотя, мб вы привели более общий случай.
P. S.: задача пока бьётся на модули и мы разбирамеся с самым первым из них. Далее судя по ответу Роджера будем думать как доработать схему. Не надо сразу за звёзды, надо постепенно, а то замахнувшись на всё, не получим и малого.
Теоретически звучит хорошо, но как это будет выглядеть технически мне совершенно не понятно. Лично изучить несколько сотен нод и их график? А насколько он устойчив/меняется?
А вот эта идея очень интересная.. мне нравится :) Выглядит как тривиальная защита от атаки которую мы рассматриваем (только для начала всё равно прийдётся с нескольких различных площадок набрать статистику тора, чтобы потом было на что ориентироваться). Если бы нод было очень много, то ваш критерий работал бы и был разумен для всех (выкидывание малоизвестных нестабильных нод не повлияло бы на анонимность). Что же касается текущего статуса сети – это может привести к катастрофическому снижению числа нод и, соответственно, падению анонимности (но точно я здесь не скажу, может быть кто из наших торокопателей ответит). Кстати, если стабильных узлов – подавляющее большинство, то как первая контрмера можно внести их список в конфиг (в список узлов, разрешённых для цепочек и запретить все остальные).
Тогда уж вы придумайте как детектировать такую атаку apriori, а не aposteriori.
комментариев: 11558 документов: 1036 редакций: 4118
spinore, разница, как я уже отмечал, в степени привязки к Tor-клиенту. Ваше решение обязано быть реализовано только в коде клиента. Я сомневаюсь, что разработчики за это возьмутся: в лучшем случае скажут "send a patch", в худшем проигнорируют. Другое дело, если сейчас отправить это предложение, самим реализовать утилиту для аудита, как сделал ygrek, собрать статистику при разных вводных величинах (изменения в статистике ведь можно и вручную в офлайне моделировать, вставляя и удаляя собственные записи в status-файле дополнительным скриптом) и затем уже представить её разрабам: хотели доказательства эффективности? вот они. Если подобный аналитический подход (независимо от конкретной модели — Вашей, uknown'а или ygrek'а) реально сможет детектировать аномальные изменения в статусах узлов, разработчики сами закодят его в Tor. А так нам остаётся только бить себя в грудь, мол, прислушайтесь к нам, мы дело говорим.
Всё, что Вы далее описываете, можно (и нужно) реализовать в виде сторонней утилиты. Это называется dry-run, когда программа только имитирует своё реальное поведение: собирает статистику, выводит в собственный лог сигналы об обнаружении аномальных с её точки зрения случаях и т.д. Это именно то, что следует передать разработчикам для анализа. Пока всё, что мы здесь рассматриваем — чистая теория. Будь я на месте Роджера (в разработке я немного понимаю), я бы не включил это даже в нестабильную ветку (тем более, что писать реализацию, будь я на месте Роджера, пришлось бы мне ;-).
Замечу, я не критикую ни одну из предложенных моделей, они на мой взгляд просто разные и предназначены для разных целей; могли бы и дополнять друг друга; возможно, на их основе можно было бы вычислять и некоторую "мета-оценку"... Моя критика направлена только на избранный spinore'ом подход: первостепенную реализацию в Tor-клиенте. Я не вижу это реалистичным.
комментариев: 9796 документов: 488 редакций: 5664
Остаётся: небрутальное соглашательство, брутальное несоглашательство, небрутальное несоглашательство ;-)
причём последний вариант самый бредовый.
Вот тоже четыре варианта. Представим, что C и D – это нечто вроде спроса и предложения на рынке, которые в идеале должны
быть стабильны и сбалансированы и немного плавно расти.
Спрос падает и предложение падает: застой, замораживание.
Спрос растёт и предложение растёт: экономический бум, перегрев.
Спрос растёт, а предложение падает: дефицит, кризис производства (самый худший вариант).
Спрос падает, а предложение растёт: кризис перепроизводства (самый абсурдный вариант).
Имеет ли смысл изучать такие величины отдельно друг от друга?
Мне чего-то тоже кажется, что они там между собой тоже подумали (более вяло чем мы) и решили, что мороки много, толку мало.
Всё равно это полумера или костыль, не устраняющий недостаток самого протокола.
А так, оба варианта в урезанном виде можно смоделировать и вне tor-клиента. Просто не будет готового к применению решения, а только исследование.
К сожалению кроме идеи у меня ничего нет :( Оформить это в формулу (каламбурчик), чтобы набрать начальную статистику для предметного обсуждения я не могу. Но если всем идея покажется не бредовой, можно начать обдумывать реализацию. Вопрос ко всем: стоит этим заниматься или нет?
Проблему начальной статистики присутствует во всех предложенных схемах. Здесь имхо прийдется придумывать мехинизм отденый от тора.
Почему?
Нестабильность я рассматриваю как появление ноды с новым ключем на небольшой промежуток времени – появилась нода, поработала пару дней и пропала. Потом на том же ip может появиться нода с другим ключем.
Если же нода в течении месяца работает по 2-3 часа в вечернее время, то условно такую ноду можно считать стабильной, со своим определенным коэффициентом стабильности во времени.
Если нода в течении месяца работает в хаотическом режиме, то она тоже считается стабильной, со своим коэф стабильности.
Основная идея, это прежде чем использовать ноду присмотреться к ней самостоятельно! А не слепо ориентируясь на информацию с DA.
Это никак не защитит от наличия в цепочке вражеских нод (уж наверно они изыщут возможность поднять стабильные ноды!) Идея – не дать возможность сделать это быстро, только для выделенного человека, и с минимальными затратами.
Связываться с анализом работоспособности ноды во времении я вижу смысл только если есть задача определить целенаправленно выведение из рабочего состояния нод в масштабах всей сети. Иначе перекресной проверки вполне достаточно.
В идеале допустим у нас есть график доступности ноды за весь предыдущий период ее существования. Из этого графика вытягиваем статистику:
1. как часто включатеся/выключается нода
2. среднее и максимальное время недоступности
3. корреляцию времени работы (нода может постоянно работать, нода может работать в строго определенное время, нода может работать хаотически)
Можно обрабатывать изменение режима работы ноды – если нода раньше работала только в опр часы а начала работать постоянно это нужно как-то учесть.
Можно предложить людим поднимающим ноды указавать референсный режим работы и обрабатывать отклонение от этого режима.
Я понимаю, все эти действия могут привести к непредсказуемым результатам, но они не будут сказываться на работе самой сети тор! Это будут действовать только на клиента решившего самостоятельно настроить для себя модель анализа поведения нод.
Я все понимаю но у нас нет другово выхода, мы можем только констатировать что такая то нода стала для нас недоступна. А дальше обработать эту информацию (сравнить со статусами других нод, сравнить со своим "коэф стабильности" для ноды).
А можно так посмотреть на это в клиенте тора уже есть возможность работать как DA, все что нужно для обмена статистикой и статусами есть. Положим врикручивать "эвристический" анализ работы нод во времени это бесперспективно для самих разработчиков пока не будет хотябы работающей можели. НО перекресную проверку нужно сделать ОБЯЗАТЕЛЬНО!
Еще у нас не получится показать работу модели при реальной атаке, тк мы рассматриваем теоретическую атаку какие еще не было, и максимум сможем показать на реальных данных что наши формулы не дают ложных тревог при обычной работе сети. Готовый код для клиента тор думаю никто из нас не напишет.
Можно долго и нудно что-то доказывать человеку, приводить статистику, аналитические выкладки и тд, и все равно не убедить если ему не понравится идея, соотв реализации не будет.
С другой стороны если он проникнится идеей и она покажется ему интересной и нужной, то убеждать не прийдется.
Я не программист, к сожалению, и написать рабочий код не смогу – хотя могу прочесть чужой код и даже написать что-то для обсчета своих данных на уровне институтских знаний :( но показывать другим такое нельзя ;)
PS Прошу прощения за несвящанность мыслей, месагу набирал урывками в течении трех часов :)
комментариев: 11558 документов: 1036 редакций: 4118
Я писал выше, как смоделировать атаку. В конце концов, как Tor-клиент, так и гипотетическая утилита берут входные данные из статус-файла. Целенаправленная модификация этого файла (вручную или автоматически) с петтарнами, примерно соответствующими модели атаки, должна показать эффективность защиты (ну, или неэффективность). А без тест-кейсов даже готовый патч для Tor-клиента не сможет показать свою эффективность.
...+k*(C-D)2 ?