id: Гость   вход   регистрация
текущее время 12:02 29/03/2024
Автор темы: unknown, тема открыта 31/07/2006 23:00 Печать
https://www.pgpru.com/Форум/АнонимностьВИнтернет/ПростойСпособАтакивОбходTor
создать
просмотр
ссылки

Простой способ атаки "в обход" 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


 
На страницу: 1, ... , 3, 4, 5, 6, 7, ... , 19 След.
Комментарии
— Гость (27/12/2007 16:01)   <#>
owners of these servers really protects their server keys

protect так как множественное число

he still can makes a MITM-based virtual network simulation

can make так как после can идёт инфинитив

may implement an analysis for suspicious activity

can implement, ибо tor-client... да ещё и may... не... слишком большая честь. Я вам уже написал выше: на данном уровне познания английского в научно-технических текстах, включая компьютерную тематику, забудьте про may. Если вам нужно подчеркнуть смысл "делать с позволения" то пишите allowed. Ну в конце концов... есть понятие стиля речи. (Пример: в официальном стиле речи пишут "здесь", а ещё лучше "в расссматриваемом случае" вместо "тут", так же и здесь...).

How MANY keys have to be

Я написал большими буквами чтоб вы запомнили а не для официального текста!
s/MANY/many/

P. S. Вашей шифровальщице, spinore, тоже мой горячий привет.

an opponent controlling more than half of DAs' keys are able

an opponent is able
И вашей шифровальщице тоже низкий поклон! "1:1"

Впрочем и "открыть" ему глаза на подделку данных с большинства других DA, тоже не сможет. Менее половины списочного состава DA могут вообще "Войну и мир" в документы со статусами записывать, и при правильных диалогах персонажей, клиент не обратит на это своего внимания :)

Это нормально?! Имхо, это более чем вопиющая борзость! ... и подлежит немедленному исправлению.
— SATtva (27/12/2007 16:09)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
И вашей шифровальщице тоже низкий поклон! "1:1"

Обменялись любезностями. :-)
— soot (27/12/2007 17:03)   <#>

Это нормально?! Имхо, это более чем вопиющая борзость! ... и подлежит немедленному исправлению.


Что не нормального, если по форме документа со статусами будет всё верно (про диалоги это преувеличение конечно). Допустим можно встроить функцию в клиента, сообщающую что DA создал (v2) документ содержащий какойто процент статусов совершенно неизвестных ранее узлов (вопрос как это отличить от факта более свежего документа с этого DA и ввода в строй кем-либо множества узлов разом, и какой должен быть порог), или исказил статусы большего чем нужно процента узлов (и опять вопрос в большей свежести документа и порога). Мэллори зная это, просто не будет отдавать документы данного DA, опять информировать клиента? А если DA реально не работает? Даже при редких действительных неисправностях и такой функции оповещения, рассылка и разработчики будут засыпаны почтой.

В текущий момент v3 (в альфа версиях) вообще отбирает право у клиентов выбирать статусы для узлов опираясь на документы составленные DA. Вместо этого создается документ-консенсус под которым подписывается каждый DA и который единственный, выкачивает клиент. С одной стороны теперь клиенту проще бы проверить подписал или не подписал, но в спецификации и коде не заложено отказа DA подписывать консенсус (он полагается на правдивость большинства). Проще говоря все те статусы что рассчитывал каждый клиент локально, теперь рассчитывают только DA. Но даже если бы DA перестал подписывать консенсусы (у Мэллори бы не было его закрытого ключа) по соображениям не согласия, отсутствие подписи можно было бы представить его неисправностью.
— SATtva (27/12/2007 17:31)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Допустим можно встроить функцию в клиента, сообщающую что DA создал (v2) документ содержащий какойто процент статусов совершенно неизвестных ранее узлов (вопрос как это отличить от факта более свежего документа с этого DA и ввода в строй кем-либо множества узлов разом, и какой должен быть порог), или исказил статусы большего чем нужно процента узлов (и опять вопрос в большей свежести документа и порога). Мэллори зная это, просто не будет отдавать документы данного DA, опять информировать клиента?

Думаю, в таком случае Мэллори просто будет отравлять не все дескрипторы одним махом, а станет делать это постепенно, стараясь не превысить пороговое тревожное значение большинства пользователей (итоговую картину можно будет списать на регулярную замену ключей узлов). Т.е. атака растянется по времени, но будет иметь тот же самый эффект, оставаясь необнаруженной. Адекватна ли в таком случае предложенная схема защиты?
— soot (27/12/2007 18:37)   <#>

Адекватна ли в таком случае предложенная схема защиты?


Вот поэтому, по моему, единственного DA или меньшую половину списочного состава — проще игнорировать, чтобы они не документировали (даже если они единственные содержат настоящую информацию).

Для сравнения информации от большинства DA (или сравнения консенсусов, во времени), вопросы уже заданы.

Some questions remains: How many keys have to be affected by this attack to rise a suspicion? What the minimum time period threshold should be?


Вот и надо выяснять, можно при особом желании и изменения за месяц (полгода, но кроме ключей надо учитывать процессы ухода старых и появление совершенно новых узлов) сравнивать. Поздно будет, но единственная цель сравнений это выявление катастрофы (если Мэллори разрешит Алисе это рассказать кому-то).
— soot (27/12/2007 19:01)   <#>

итоговую картину можно будет списать на регулярную замену ключей узлов


Узлы периодично (раз в неделю) меняют только onion-key, но signing-key по которым их идентифицируют менять не принято (операторы меняют их только при подозрениях в утрате).
— unknown (27/12/2007 21:39)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Думаю, в таком случае Мэллори просто будет отравлять не все дескрипторы одним махом, а станет делать это постепенно, стараясь не превысить пороговое тревожное значение большинства пользователей (итоговую картину можно будет списать на регулярную замену ключей узлов).

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

Короче про "замедленный вариант атаки" типа "delayed partial cache poisoning" разработчикам лучше пока вообще голову не морочить.
Может он неработоспособен. Спросим, если хоть как-то на простой вариант отреагируют.

В новой спецификации (v.3, а она в черновике и неполная) разработчики озаботились о том, что раз ключи DA имеют такую большую ценность,
то, как я понял, они решили, что хранить их на сервере опасно из-за возможности взлома.

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

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

Ну и что мы им в итоге хотим предложить? Ограниченное решение, которое пытается бороться со следствием, но не с причиной и ещё не известно
насколько успешно. Они могут проигнорировать всё это, поскольку в первую очередь надо подумать об улучшении расширяемости протокола,
чтобы не быть каким-то образом
привязанным к ограниченному числу корневых нод. Может у них какое-то мнение отложится и что нибудь сделают в далёкой версии абсолютно нового протокола.

Технологии типа peer-2-peer они конечно прикручивать не будут, хотя кто знает. И правильно p2p – это популизм,
на самом деле это только кажется, что это лёгкий способ увеличить
анонимность, а как выбрать правильный баланс между распределённостью и централизованностью неясно.

Главное, убедить, что проблему решать нужно и поставить все вопросы и сомнения, а они чтобы озадачились и что-то вероятно более грамотное, чем мы, придумали.

Слово "may" считаю уместным, поскольку это предложение к развитию и обсуждению идеи в весьма свободной форме, а не готовая инструкция
к действию и не приказ.

А у шифровальщиц мы похоже все чему-то не тому учились ;-)
— unknown (27/12/2007 21:59)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
V 0.03

Если не остановимся, то мы тут скоро весь протокол заново пересмотрим :-)

Multiple Directory Authorities' keys compromise: a partial solution for Tor clients protection

The core problem with Tor is the lack of directory authorities which one need to unconditionally trust. Despite the mechanisms of DAs consensus voting and client comparing signed data downloaded from different DAs, an opponent controlling more than half of DAs' keys is able to conduct a multitude of attacks.

Unfortunately, we have a really small set of semi-trusted authorities and more than a half of them are in the single jurisdiction (US), so we are forced to believe that owners of these servers really protect their servers' keys from compromise, and operators themselves are free from any third-party malicious influence ;-)

Main security and trust problems were improved in v3 directory authority protocol, but not resolved completely.

If the third-party agent Mallory possesses more than 50% of semi-trusted DA keys and has an ISP-level access to user traffic, he still can make an MITM-based virtual network simulation for that user, like this:

Normal client activity:

Alice -> encrypted traffic -> [real Tor cloud] -> decrypted traffic from exitnode -> Bob

Intercepted client activity:

Alice -> encrypted traffic -> [Mellory's virtual Tor network simulation] -> decrypted traffic for Mellory ->
-> [Mellory's Tor client using Alice's circuits] -> [real Tor cloud] -> decrypted traffic from exitnode -> Bob

###

We propose a partial (very limited, but adequate) solution: Tor client with active connection and relatively "fresh" stats cache can resort to "heuristic" analysis for suspicious stats changes.

At most two criteria can be analyzed:

1) An attempt to download stats from all of the mirrors is blocked or gives the stats with invalid signatures. As a result, it could be downloaded only from semi-trusted DAs. (Possibility of a legitimate DA's IP substituted with a malicious one, and data authenticated with compromised keys).

2) Tor-nodes' keys signed by a DA are changed significantly (for example, >90% of all keys) during a very short period of time. (This case rises a suspicion about fake stats injection for user cache.)

Some questions remains: How many keys have to be affected by this attack to rise a suspicion? What the minimum time period threshold should be?

...) What's about other criteria of suspicious activity or formal model of other possible attacks detection for Tor clients?

We propose next log messages for the Tor client as an indication of probable attack-in-progress:

-> Warning! Warning: a lot of tor-nodes' keys were changed during a short period of time!
-> If more than a half of Directory Authorities' keys are compromised, stats could be poisoned with a fake data.

As a paranoid option listed in config file (client-only section) one may use:

StopTorIfTooManyKeysChanged 0|1

Another open questions: Suppose user has this option enabled. Is it then sufficient to stop Tor-client when before-mentioned log event comes up or should also be done some other things too? What are the right things to do for users who got that log event? What's the right procedure to run Tor-client for users who have an outdated cache to be safe from this attack?

There is a long discussion on this problem on our site where we continue to propose a lot of ideas related to the topic.

"OpenPGP-in-Russia Team"
— Гость (27/12/2007 22:32)   <#>
т.е. атака растянется по времени, но будет иметь тот же самый эффект, оставаясь необнаруженной. Адекватна ли в таком случае предложенная схема защиты?

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

Ну и что мы им в итоге хотим предложить? Ограниченное решение, которое пытается бороться со следствием, но не с причиной

Ну почему. Прочитайте топик: я предложил несколько другой протокол, если стремиться к идеалу. Различных DA должно быть много, они должны синхронизированно иметь одну и ту же статистику, а клиенты – доверять некоторым из этих DA либо скачивать статистику со всех из них и потом оценивать вероятность подмены. Аналогия:
  • tor-клиент<=>браузер
  • DA<=>CA

Если не остановимся, то мы тут скоро весь протокол заново пересмотрим :-)

Моё глубокое имхо состоит в том, что протоколу тор ещё очень и очень далеко до совершенства, так что пересмотр протокола – дело обыденное.

V 0.03

Я прочитал. Условимся считать, что возражений не имею (разрешаю отсылку). Видно, ваш текст прочитала какая-то шифровальщица, и внесла свои правки, судя по тексту (которые явно не сводятся к моим и SATtva'овским) :)
— SATtva (27/12/2007 23:19)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А у шифровальщиц мы похоже все чему-то не тому учились ;-)

Или просто пишем в спешке, оставляя глупые ошибки... К тексту замечаний не имею.
— Гость (28/12/2007 00:05)   <#>
"delayed partial cache poisoning"
Напомнило "молекулярную агрессию в культурное ядро" Антонио Грамши.
— Гость (28/12/2007 13:33)   <#>
Another open questions:

Other open questions, поскольку Another – еще один

to rise a suspicion

to raise a suspicion
— unknown (28/12/2007 14:17)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ладно, всем спасибо, думаю какие-то оставшиеся мелкие ошибки всё-равно неизбежны.

Поскольку принципиальных возражений нет, последний вариант уже отправлен:

http://archives.seul.org/or/dev/Dec-2007/msg00029.html

К сожалению, строки не отформатились по длине :-(, надеюсь они все письма из рассылки всё равно читают через mail-client, а не через браузер.
— Гость (31/12/2007 20:52)   <#>
Чё-то ничего не пойму.
Никого не заинтересовало что ли?
Новых сообщений вроде БЫ нет в той ветке.
— unknown (01/01/2008 17:26)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Вполне возможно, что не заинтересует.

Или не поняли и решили, что это повторение старого и известного.

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

Или может просто в новой спецификации протокола черкнут пару строчек на эту тему.

А может, к концу года они решили отдохнуть. Вариантов масса.


Новых сообщений вроде БЫ нет в [WWW] той ветке.


Зато в пользовательской ветке, начиная с 30 декабря появились сообщения от пользователей
с массой странных ошибок в логах тор-клиента вида:



Утверждают, что этих ошибок раньше ни у кого не было (какое удивительное совпадение), а убедительного ответа
тоже нет. Хотя скорее всего это связано с ошибкой при введении третьей версии протокола и неправильно
обновлённым конфигом.
На страницу: 1, ... , 3, 4, 5, 6, 7, ... , 19 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3