РегистрацияПростой способ атаки "в обход" 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
ЫЫЫ, фактически я сделал то, что SATtva сказал изначально, просто облекши в техническую форму :))
Все стадртуют с доверяемого среднего, накладывая ограничения на эволюцию статистики. Время от времени средняя статистика между пользователями синхронизируется (вручную), и обновляется.
А вот тут бага. Дело в том, что для того чтобы гарантировать что у тор-клиента есть все ключи тор-нод, которые подписал DA за сутки, ему надо сутки держать запущенным клиент, как минимум. Иначе DA сможет сказать, что те ноды, ключи которых он подписал, были в точности в то время онлайн, когда все тор-вочеры сидели незаконнекченными к тору. это если тор-вочеры – тор-клиенты (для тор-нод это не так критично, как аргумент). Идея в том что объединение некоторого числа тор-вочеров даст строго обоснованную претензию к DA лишь в случае если те постоянно online.
Как я уже высказался, лучше для начала воздержаться от беспокойства владельцев тор-нод – им итак достаётся проблем.
Кстати, очень действенное сравнение. Поддерживаю написать об этом в письме в качестве красивой аллегории.
комментариев: 9796 документов: 488 редакций: 5664
Только по моему у нас у всех не до конца ясное представление о работе сети.
Всё что подписано DA лежит в /var/lib/tor/cached-status
Каждый список – от своего DA, можно узнать каким DA подписан ключ.
Там есть отпечаток каждого ключа и время. Принуждение DA к аудиту, как заметил SATtva не нужно.
Но это пока в версии 2. В версии 3 не так? И подпись какого-то хэша в начале списка относится
к последующей части файла? Или он не подписан и предъявить его в качестве доказательства нельзя?
Дальше, по этим отпечаткам ключей скачиваются сами ключи по мере возможности и складируются
в /var/lib/tor/cached-routers и /var/lib/tor/cached-routers.new. По методу разностей (диффа), но не побайтово, а по секциям,
как я понимаю.
Выяснить что в списке от DA есть ключ от несуществующего узла нереально: кто-то может включить узел ненадолго и тут же
вырубить. Кстати можно даже вызвать ложное срабатывание, если запускать и отрубать после авторегистрации в DA много tor серверов умышленно.
Единственное, что можно это после срабатывания выделять подозрительные ключи и переписываться с кем-то или связываться по
иному защищённому каналу и выявлять левые ключи.
Сомнение Роджера было не только в том, какие опции нужны для регистрации подозрительного,
но и в том, что делать пользователю, если сработал детектор на скачок статистики, чтобы кто-то параноидальный не
включил этих опций, а потом не морочил всем голову в рассылке, создавая панику,
не выяснив по-возможности предварительно сам в чём дело.
Ну не будет такого никогда. Какие-то шутники собирались ставить серваки с тором незаметно на флэшках в какой-то университетской библиотеке.
Кто-то ещё что-то придумает.
Узлы теперь не регистрируют вручную. Каждый может стать узлом. Через время не больше 3 часов кажется он попадает в статистику DA.
По какой-то причине куча серваков исчезает (сбой), затем снова запускается, некоторые держат серваки на CDR генеря ключ после ребута в памяти.
Т.е. регистрация такого рода атаки очень опциональна, это не автоматическое детектирование, а скорее действительно аудит для особо желающих.
P. S. Кстати, китайцы в рассылке пару раз просили выслать статистику по
почте – у них были заблокированы только DA, но не вся сеть и после
подкладывания чужой статистики они могли работать.
комментариев: 9796 документов: 488 редакций: 5664
Не совсем. Я исхожу из того, что группа скомпрометированных DA не будут настолько наглыми, что подпишут кучу левых ключей для всех.
Левые ключи будут поставляться лишь отдельным изолированным клиентам. А не по всему миру, не во всех странах и не во всей сети.
Кто-то, устроивший сговор с 50% DA не захочет это так публично выставлять, чтобы обнаружить было легче.
Пусть DA в списке подписывает время действия полученных ключей.
Важно, есть ли там сама подпись от DA, или её клиент проверяет и уничтожает?
Были торокопатели класса лыжы_асфальт и soot. Они бы могли точно сказать что к чему.
Видимо, cashed-routers и есть пример собственно файла статистики...
Что касается этой атаки и беспокойства самого Роджера:
- Опция для параноиков. Кто хочет – включает лишь диагностику, никто никого не заставляет включать Actions.
- Если будет предпринята массовая атака по подключению большого числа тор-нод на короткое время, то не вижу ничего неадекватного в том что тор-клиенты на это среагируют и известят пользователя. Далее уже тор-team будет думать что с этим делать, я пока ничего предложить не могу.
На следует исходить из очень простого тезиса: от заметания мусора под ковёр сам мусор никуда не исчезает, так что опциональную (по желанию) диагностику включить надо – она делает лишь лучше. Далее: есть группа параноиков, она хочет хоть какую-то защиту – для них Actions. Атаку с массовым подсоединением новых нод к сети можно провести и сейчас, но это вряд ли кто обнаружит и никто толком ничего не сможет предпринять (банально нет инструментов) – так лучше что ли? Не стоит сразу хвататься за звёзды, давайте для начала протолкнём Diagnostics и Actions для параноиков и для диагностики возможных атак тор. Далее, может быть сам Роджер выскажет идеи что можно сделать против тех ддос атак.Кстати, что приходит в голову против такой атаки: можно установить квоту – число возможных подключений тор-нод к тор сети за единицу времени исходя из реальной статистики (чтобы очередь не накапливалась и атака не проканывала). – почему бы и нет? Сейчас все сайты устанавливают счётчики на скачку файла например – это чем-то напоминает то.
Секцию Diagnostics, возможно, и можно (пока ещё не ясно до конца).
Секцию Actions нельзя написать (скрипт может реагировтаь лишь постфактум, а это может уже оказаться поздно).
Там предлагается скрипт, но он кроме того должн быть ещё и интегрирован в функционал tor'а (tor его должен запускать). Кстати, если узлов – сотни, не факт что это будет делаться достаточно быстро.
Кроме того, действия скрипта в стиле "перехватить статистику, успев создать её бэкап в другом каталоге" я считаю извращением.
Это всё-таки базовые вещи, потмоу сам tor тоже надо допиливать.
Другое дело, что можно самим попатчить тор-клиент, так как протокол совершенно не меняется. НО... я не программист.
комментариев: 9796 документов: 488 редакций: 5664
Да, именно это для меня не ясно.
Именно soot говорил в этом треде, что в v.3 клиент получает уже согласованный между нодами список,
если я правильно понял. У меня клиента с поддержкой v.3 пока нет. Если это так, то это плохо
для аудита. Они там по тихому между собой голосуют, что затрудняет обнаружение
атаки :-)
Смотря что называть статистикой.
Раньше всё было в одном файле, теперь это просто разделили, чтобы разгрузить DA и равномернее
распределить нагрузку между зеркалами.
отпечатки ключей в cached-status, а сами ключи и подробности об узлах в большом файле cached-routers.
Причём файл cached-routers скачивается и обновляется постепенно. Так что анализировать его труднее.
И обмениваться им нежелательно в отличие от cached-status, который у всех примерно одинаковый
(различия по времени некритичны и не указывают ключей каких узлов не хватало клиенту, каких он
не использовал в цепочках на какой-то определённый момент времени).
Если в v.3 действительно клиенту поставляется готовый cached-status с отпечатками, уже подписанный всеми DA,
то это ещё больше разгружает и DA и зеркала на узлах, но для нашего предложения это хуже :-(
Поэтому и хорошо хотя бы раз в сутки с каждого DA требовать подробный отчёт по каждому подписанному ключу
тор-узла с указанием времени появления и исчезновения его из статистики.
В cashed-routers есть для каждого узла opt write-history и opt right history.
Про это и про многое другое хорошо бы почитать в спецификациях, прежде чем нас опять вежливо отправят это делать.
Если будет время, предлагаю примерно в течении следующей недели выучить почти наизусть спецификации
и v.1, и v.2 и v.3, чтобы было можно обсуждать более предметно.
Это они и так мониторят без помощи клиентов, собирая и анализируя статистику с DA.
Им возможно бы интересно только знать что у отдельных клиентов картина tor-сети отличается от общей.
Может это уже есть? DA регистрируют узлы почему то через неодинаковые промежутки времени, может есть и очереди и квоты.
Надо спецификации читать, учитывая ещё что они местами и устаревшие и неполные.
Нужны подробности, в один-два абзаца о том как это всё происходит, протокол обновления статистики. Без этого говорить о конкретике невозможно.
А там вообще есть какие-нить подписи кого-нибудь из DA?
Блин, как всё не просто... А по какому протоколу сейчас работает большинство? Я не уверен что это спецификации, подробные и внятные, на каждый протокол есть (в терминах ИДЕИ а не в терминах программистских выпендрёжов). Мне например пох как называется та или иная функция, я бы хотел видеть, меня интересует сама научная идея организации доставки статистики, и мне кажется что прийдётся изучать всю рутину чтобы это понять, но на рутину у меня к сожалению уже нет времени (pgpru.com съедает много времени, да...).
Можно перевести вопрос в плоскость "есть пример атаки" на то, то и то – сделайте что-нибудь. Мне не нравится сама идея, что они полагаются на то, что ключи DA никем не будут похищены и DA всегда можно доверять. Это сродни доверию что владелец сервиса-анонимайзера не сдаст ваши логи когда его прижмут. В общем, есть вариант объяснить вкратце идею решения в рассылке, а уже как её конкретно согласовать с
протоколомроем протоколов – оставить Роджеру. Сразу честно скажу что спецификации читать не буду, я итак оборзел – нифига не делаю по учёбе. Если кто-то поймёт логику работы со статистикой и кратко, внятно её изложит – можно будет ещё пообсуждать, иначе, видимо, ограничимся "вбиванием кола" что "проблема существует".комментариев: 9796 документов: 488 редакций: 5664
Стабильные на втором. Третий только в альфа-версиях и он в стадии разработки.
Там изложено именно так как вы хотите. На уровне идеи.
Я Вас понимаю. Предлагаю сделать перерыв примерно на неделю, если ничего революционного в голову не прийдёт.
Надеюсь у меня будет свободное время за неделю подробно осмыслить все спецификации. Там совместными усилиями двинемся дальше.
Они думаю лучше нас понимают чего можно придумать, если иметь ключи от DA. Того что было изложено в новогоднем письме было достаточно.
ну мы и так уже много чего придумали.
тезисно кратко пока:
Так или иначе всё что нужно для защиты от атаки это определение того, что клиент видит искажённую картину tor-сети что выявляется или автономно или относительно к другим источникам.
Может разработчики могут предложить совершенно иной способ решения.
комментариев: 9796 документов: 488 редакций: 5664
Статистика состоит как и говорилось выше из двух частей: статуса сети /var/lib/tor/cached-status и дескрипторов узлов (/var/lib/tor/cached-routers и /var/lib/tor/cached-routers.new).
Статус сети – это то что подписывают DA, там в основном отпечатки ключей узлов и очень краткое их обозначение. В версии 2 каждый отдаёт список порознь, пользователь скачивает все списки и сам по ним голосует.
В версии 3 готовый консенсус с подписанным всеми DA статусом голосования (консенсусом). В консенсусе есть подписи всех согласных нод.
V3 не только разгружает сеть, но и даёт всем пользователям одинаковые данные без рассинхронизации между DA (рассинхронизация нежелательна из-за возможных атак разделения). В статусе содержатся только отпечатки и краткое описание узлов.
Дескрипторы – это уже подробное описание узлов, их ключи, политики и т.д.
Они могут скачиваться по частям.
Если что то анализировать, так это файл статуса сети.
Собственно все опции укладываются просто в разность уникальных ключей и их количества в предыдущем и текущем статусе.
Вот что на основе ваших опций, spinore, придумалось:
Если имеется N_k ключей нод и N_k+1 за интервал обновления, можно сравнивать увеличение/уменьшение их количества:
C=N_k+1/(N_k) – изменение общего кол-ва ключей (на самом деле это показывает число нод)
I – число совпадающих ключей между списками N_k+1 и N_k (индекс совпадающих ключей)
Его максимальное значение не может быть больше размера меньшего из списков:
max I = min (N_k+1, N_k)
Чем ближе C к единице, а I к своему максимуму (т.е. меньшему значению между N_k и N_k+1), тем стабильнее tor-сеть.
Пусть D = I/I_max – индекс изменения ключей. Тогда и D будет стремиться к единице при стабильной сети.
D <=1 (всегда); C<1 при уменьшении числа узлов, C>1 при увеличении.
Увеличение числа узлов опаснее. Также как и уменьшение числа совпадающих ключей.
Тогда можно подсчитать стабильность сети в самом примитивном виде как некое S=C/D
Чем больше единицы значение S, тем опаснее. Ну и чтобы D не равно было нулю, а то вообще хана :-)
Только как отслеживать данные между интервалами? Например часть нод пропала из статистики, а затем
появилась снова, но не с новыми ключами, а с теми которые и были? (Некоторые тор-ноды работают по крону:
только по ночам или по выходным).
Другие подозрительные параметры, о которых мы писали в письме не вытащить из статистики: это верная
статистика (статус сети), но неверные ключи, заблокированные ноды и т.д. Само по себе это об атаке
не свидетельствует, но в сочетании с повышением индекса S усиливает подозрение.
Таким статистическим анализом можно выявить подозрительные ключи (чем их больше и чем быстрее они вброшены,
тем это будет эффективнее).
Затем их можно прдъявлять как доказательство, сравнивая с данными по индексу S за определённое время и с ключами у других пользователей.
К индексу S (а также к C, D и всему остальному) можно прикрутить построение графиков, вычисление их собственной статистики "хи-квадрат" и прочее.
Но всё это трудно автоматизировать и похоже требует вынесения в отдельную утилиту.
Возможно это следует внести в проект torflow
Если на нём обкатают, тогда только можно думать о какой-то автоматизации и включение в сам tor. А так маловероятно.