РегистрацияПростой способ атаки "в обход" 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
Ну, а в остальном-то да:
Для студенческой работы достаточно эмулировать на своей машине свою собственную тор-сеть со своими ключами и моделировать атаку на неё с помощью другой машины, на а уж бб может поиграться по-настоящему :)
комментариев: 9796 документов: 488 редакций: 5664
Имено! Мы точно не знаем как меняются ключи в среднем, но есть ноды, которые загружаются с CDR и не хранят ни логов, ни изменяемых настроек. При каждом ребуте генерят ключ заново. Через час-два их снова регистрируют в сети.
и кстати:
Почему все так легко подхватили идею замедленной атаки? Изначально предполагалось, что подмена может быть осуществлена только за один шаг.
Вот как объяснялось:
1) Противник блокирует или нарушает доступ ко всей Tor сети, кроме подконтрольных DA: пользователь не может построить ни одной цепочки в сети.
2) Пользователю не остаётся ничего другого, кроме как скачать статус с DA.
3) Если он случайно выбрал неподконтрольный DA, то переходит к п.1
4) Если он выбрал подконтрольный DA, то соединение проходит (имитируется) успешно, но уже с виртуальным DA, от которого есть ключ у противника.
5) Пользователь скачиваем фальшивый статус с виртуального DA, где ключи всех Tor нод подменены, статус подписан большинством подконтрольных DA (от которых тоже есть ключи) и сразу оказывается в виртуальной сети.
Задача противника выполнена за один шаг, за один шаг она и выявляется.
Ну а как реально осуществить замедленную атаку?
Пусть п. 1-4 будут теми же самыми. А что дальше?
В п.5 противник даёт скачать статус, где подменено только 10% ключей? (Это для простоты примера, в реальности это уже слишком заметно).
дальше, если он не снимет блокировку, то пользователь сможет работать только с 10% подконтрольных нод, что тоже будет заметно.
Значит блокировку он снимет. И на что ему после этого надеяться?
Что пользователь с вероятностью 10% с подконтрольных узлов скачает очередную порцию "отзеркалированного с DA" фальшивого статуса? Ну там ему подменят ещё 10%. И того на следующий раз вероятность будет 20%. Но чтобы дойти до 100% нужно будет совместить девять событий с произведением вероятности П=0.1*0.2*0.3*0.4*...*0.9=.00036...
Не маловато ли? А если подменять на каждом шаге только 1% ключей для пущей незаметности, то можно и вообще не дождаться.
Гораздо больше вероятность того, что на каком-либо из шагов пользователь скачает с неподконтрольного узла настояющий статус и откатится назад. Ещё хуже для противника, если пользователь включит опцию alldiractionsprivate=1,
когда скачивание статистики идёт не только в подписанном, но и зашифрованном виде. Тогда противник вообще не сможет понять, когда пользователь скачал реальную статистику и с какого узла, а когда подставную, может он работает уже с реальной статистикой?
Получаем: или только атаку за один шаг (которая за один шаг и выявляется) или крайне неэффективную замедленную атаку, или если у противника есть способ осуществить замедленую атаку подменяя только часть узлов, но каким-то неведомым образом заставляя пользователя скачивать статусы только с подконтрольных (тогда он может обойти в принципе любой статистический контроль, если умеет так ловко работать с частично изменённой сетью).
комментариев: 9796 документов: 488 редакций: 5664
А для нестуденческой с изобретением нового TOR-протокола можно получить исследовательский грант
Это, интересно, каким таким образом заметно? Вы же сами объясняли, что если польхователь выбрает неподконтрольные ноды, то они проследуют только через реальный тор, а если подконтрольные ноды, то через виртуальную машинку + итиный тор.
Если предположить, что параметр S работает лишь как ограничитель на сравнение соседних скачанных статистик, а с исходной трастед-статистикой мы не сравниваемся, то через 10 скачиваний мы получим что противник подменил 100% ключей узолов. Если новая статистика скачивается каждые 15 минут, то на подмену полностью всей статистики понадобится примерно 2 с половиной часа, при это деанонимизация произойдёт почти точно раньше :-D
P. S.: я предполагал для простоты, что протвник смог захватить ключи всех DA. Вносим это в предположение.
комментариев: 9796 документов: 488 редакций: 5664
И скачает с любой из реальной ноды реальный, а не подставной статус и откатится назад, если не 100% ключей подменены. Поэтому и получим такую низкую вероятность. Скачивание может идти к тому же и с разных нод одновременно.
Как сегодняшний Tor-клиент в такой ситуации обрабатывать будет нестыковки и противоречия? По самой последней дате на статусе? Не знаю.
Или противник будет давать строить цепочки только через подставные узлы?
Каждый раз? Тогда почти каждое построение цепочки будет заблокировано, пока подконтрольных узлов мало. А если отпускать неподконтрольные цепочки в реальный Tor неперехваченными, то ещё раз – клиент просто на очередном шаге скачает статус не с DA, а с любой ноды, как с зеркала. И соединение будет подписано, а при определённых настройках и зашифровано ключём этой ноды.
Раз в 15 мин – это минимум. Реально, посмотрите свой кэш. Там обычно статус, устаревший от часа и больше. Раз в сутки он точно принудительно меняется. По какому принципу остальное время х.з.
Заметно всё будет, если контролировать число изменившихся ключей, которое не может изменяться слишком медленно или изменится скачком назад к реальному значению, если противник не достигнет 100% подмены.
В общем, тезис я понял. А как по-вашему могла бы выглядеть в принципе атака delayed cache poisoning – чтоб всё работало и получалось?
комментариев: 9796 документов: 488 редакций: 5664
Это Вы меня загрузили! Я с самого начала утверждал, что при нынешнем дизайне она маловероятна, а Вы стали рассуждать, как будто она есть.
В принципе противник может действительно вводить по 10% узлов за раз, а остальные блочить, чтобы не дать скачать реальные статусы, но это слишком топорно и заметно.
Другие варианты пока в голову не приходят (это не значит что их в принципе нет).
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
Да вернуться к началу обсуждения. Противник может подменять 100% или по крайней мере > 50% ключей за раз (если он хочет рисковать), что элементарно засекается пошаговым сравнением.
Я предлагал, что если > 90% ключей сменилось за короткий период времени.
После останова (а он при таких условиях будет редким) перепугавшиеся пользователи могут сравниваться между собой.
Ещё контрмера – сравнить статусы принудительно скачанные со старых и новых нод-зеркал.
unknoun? Кто это?
Я решыл полгядеть насколько быстро заметят – ведь всего одна буква... :)
Ладно, щас удалю.
Ну в общем, да. Тогда концептуальных нареканий к предыдущему письму вроде как нет, получается. Проверяем орфографию и отправляем?
комментариев: 9796 документов: 488 редакций: 5664