РегистрацияПростой способ атаки "в обход" 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
Да, отмечал окончание работы над которой работал последний год [можете поздравить :)] – только что появилась в свободном доступе. Кстати, vadim_z в соавторах :)
SATtva, вы невнимательно вдумывались. Необходимость жёстко вшивать этот код в код клиента возникает лишь когда юзер захочет априорную реакцию тор-клиента на подозрительность в сети. Если такая реакция не требуется, этим может заниматься сторонний скрипт (да, написанный через заднее место, ибо будет куча накладных расходов и по уму так скрипты не пишут – сторонняя утилита должна в реальном времени получать информацию с тор-клиента а не стучаться каждый фиксированный интервал на предмет "есть ли что новенького").
ent1 уже ответил. Давайте напишем так, как будто это атака важна и попытаемся внятно что-то предложить. Далее можно поглядеть на реакцию разработчиков.
Какой бы ответ разработчиков не был – он не помешает нам написать такую утилиту и анализировать траффик, на данный же момент обсуждает что им говорить. Я не вижу ничего предосудительного в том, чтобы грамотно изложить свою простенькую теорию и метод защиты от атаки. Неужто вы предлагаете вообще ничего не отвечать и ждать пол года пока наберётся статистика и кто-то оформит всё в виде красивых графичков в pdf'ке с объяснениями? Нас никто не заставляет выкабениваться перед разработчиками: есть идея – пришли, сказали.
Это не разные "модели", и не надо делать явных подмен. Я предложил некую вещь, котрая реально будет работать если протокол таков как сказал unknown. Пока я не вижу ни одного поста после опубликования короткой сводки, где бы мне написали пример атаки, которую он не ловит. Есть претензии – пример атаки в студию. Что же касается unknown'а и его сравнений соседних шагов, в этом нет ничего физичного – по кр. мере я на данный момент не вижу как придать разумный смысл таким сравнениям. Благо, что сравнения соседних шагов пропускают замедленное инфицирование тор-кэша, а тем самым и соответствующую атаку от которой мы пытаемся защититься. Всё что остаётся от модели unknown'а после выкидывания сравнения соседних шагов – это дебаг-уровень – писать всю статистику для возможности последующего её сравнения, но это и я предложил – одна опция в конфиге и делов-то... Заметим, что изначально я предлагал написать старонний скрипт, который сможет сравнивать любые две статистики – хоть соседние, хоть в год разницы между ними. тор-клиент лишь должен вызывать подобный скрипт после скачки статистики для того чтобы уметь априори прореагировать на атаку.
Если мы априори примем модель "разработчикам наплевать на собственный проект" – то да, можно вообще ничего не писать – вы правы.
Вначале письмо, а потом – всё остальное, продолжение, так сказать. Следует работать в кооперации с разработчиками – это продуктивнее, а не показывать свои "предъявы" когда нет на то никакой реальной необходимости.
Для начала они могли бы реализовать хотя бы часть предложенного – пусть тор-клиент выводит сравнение скачанной статистики с трастед-статистикой, но не реагирует. Хотя бы что-то для начала.
SATtva, я уже ответил: приведите пример атаки, котора не ловится моим методом+включение дебаг-уровня, когда ппишется вся статистика. А потом мы поговорим о взаимном дополнениии того что не ловит мой метод, зато ловит метод unknown'а (когда будут конкретные примеры). Вообще, вам уже стороние люди написали что надо сравнивать всё действительно с нулевой точкой отсчёта а не между соседними шагами по времени.
А вот это уже зависит от того, насколько грамотно и лакончино удастся изложить то, что мы предлагаем в письме.
В первом приближении? Думаю, нет. А до следующих приближений мы пока не добрались. Если есть подозрения что что-то не так – пишите реальный пример атаки которая должна ловиться алгоритмом и не ловится и тогда будем дорабатывать модель снова. Я пока такую атаку не вижу.
Всё нормально. Сейчас самое то изложить свои наработки, только надо постараться по-максимуму понятно это сделать.
Вроде устраняет. Цитирую:
Возражений на этот пост не последовало. Где они?
Я привёл только теоретическое обоснование. Далее уже можно думать как сделать обмен статистикой между юзерами удобным и практичным и т.п. – а пока мы пишем письмо только.
ent1, то что вы предлагаете в первом приближении нефизично. Такой подход можно использовать в умозрительных построениях, но на практике он работать не будет. Если сильно глубоко копать, может быть можно будет далеко впоследствии на основе протокола обмена тор-статистикой между пользователями сооррудить нечто, что в реальном времени будет вычислять то что вы хотите – само, автоматически. Но это отдельный протокол, отдельный огромный геморой, свои оценки, куча сложных случаев и т.п. Здесь на одно обсуждение тривиального сравнения двух статистик ушло уже 13 страниц форума, а ведь эта задача на порядка 2 просче. В общем, как идея такое есть, но "явно не для 'сейчас'".
В принципе на этом сайте есть люди которые это могли бы сделать (квалификации хватает), но пока не будем о пожарных случаях – начнём с обсуждения с разработчиками.
Подписываюсь.
Естественно. Такие тесты лишь часть разработки функционала для тор-клиента. Пока наше дело – изложить теоретический базис и показать: что можно предпринять, как это теоретически могло бы работать и что бы это дало. Далее, либо они сами напишут скрипт, либо предложат нам его напистаь, либо впараллель. Следующим шагом будет умение тор-клиента после скачки статистики вызывать такой скрипт и принимать решения об останове на основе ограничителей выставленных в конфиге.
комментариев: 9796 документов: 488 редакций: 5664
поздравляю :)
По поводу стаистики:
Вот статистика одной ноды (будет ругаться на серт.):
https://node.xenobite.eu/
график за день
за неделю
за месяц
за год
Это по пропускной способности, но общее впечатление о стабильности сети составить можно.
А вот на что стоит внимательнее посмотреть:
вот необновляющийся с 2007 года график за большой промежуток для всей сети Tor по количеству узлов
число узлов за год
число узлов за месяц
число узлов за две недели
число узлов за неделю
Что за неделю, что за месяц число нод менялось в интервале примерно 10-15%.
К сожалению только число узлов, а не графики изменения их ключей, которые никто не мерял.
Если даже разработать на основе этого какой-то эффективный средний критерий, то замедленную атаку он и регистрировать будет тоже замедленно, когда число изменений ключей превысит ожидаемое за месяц.
проект torstatus – не совсем то что нужно.
tor control protocol
Опция NEWDESC – это то, что нам нужно или нет?
Возможно, но м.б. в той опции ещё и много лишнего, что нам не нужно.
комментариев: 9796 документов: 488 редакций: 5664
если это мерять не за один шаг?
Пусть имеется некоторое количество узлов.
За месяц их число изменилось на 15%, допустим часть нод тоже сменилась по ключам (пока прикинем от фонаря) на 15%.
Т.e. что будем считать просто, что не должно выходить за эти пределы и в следующий месяц?
А если все меняют ключ в среднем раз в месяц? В две недели? Кто-нибудь это знает точно?
Эти формулы следует переопределить как
C=N_k/N_0 и D=I_k/I_max=I/(min (N_k, N_0))
Где N_0 – число ключей в трастед статистике, а N_k – в статистике на текущем шаге по времени, который мы и анализируем н вшивость.
Я уже раз 15 объяснил. Условно говоря,
Если не учитывать тонкости, то в вашем случае через месяц на каком-то k=10000 мы получим что-то вроде S = (1.15-1)2+(1.15-1)2= 0.045
Если все будут менять ключ раз в месяц то I_k = 0 (ноль совпадающих ключей), и тогда сразу D = 0, значит S = (C-1)2+(0-1)2>=1 (гипотенуза больше каждого из катетов потому что). Как видите, число S сразу подскочило с 0.045 до большего 1, перепад существенный :)
И в конце концов, это элементарная математика которую частично учат в школе.
Уменьшая промежуток с месяца до двух недель мы увеличиваем противодействие атаке, но тогда и тщательно сравниваться с соседями прийдётся в два раза чаще. В этом смысле "месяц" я взял условно для наглядного объяснения, пока я не утверждал что это оптимально. В пределе можно сравнивать каждые 15 минут, только вот насколько легко и анонимно это можно будет делать – другой вопрос (иначе противник сможет подделывать статистику для всех пользователей, следящих за статистикой).
комментариев: 9796 документов: 488 редакций: 5664
Вопрос именно в том, что в данный момент, пока никто из здесь обсуждающих точно не знает как часто в среднем меняются ключи. Это надо проверить просто.
Если ключи меняются раз в месяц или чаще, то мы и будем получать S=1 и не сможем пользоваться месячным средним.
Но допустим (и скорее всего так), сеть гораздо стабильнее.
Но, даже если в месяц в норме меняется 20% ключей, противник может месяц подсовывать нам старый файл со статистикой,
меняя в нём по одному ключу туда-сюда, а на 29 день дать файл, где 20% ключей поменялось, но на его фальшивые.
С трастед-средним расхождений, я так понимаю не будет, но каждый пятый узел в сети будет фальшивым, а это уже кое-что.
Это при условии, что пошаговые скачки не регистрируются.
Кстати, противник может подменить в первую очередь стабильные для пользователя адреса entry guard, входящих узлов, это существенно облегчит его задачу.
комментариев: 11558 документов: 1036 редакций: 4118
Мои поздравления обоим участникам! Хотя для меня что название работы, что резюме — китайская грамота.
Я тоже только "за". Только консенсуса пока нет, что именно излагать разработчикам.
Я этого не говорил. ;-)
А вообще, spinore, тяжко Ваши посты читать. Многабукаф...
комментариев: 9796 документов: 488 редакций: 5664
Пока участников мало это разрулить легко. Можно изложить все точки зрения по пунктам.
Первый пункт по любому общий – описание параметров. Другие – построение доверенной статистики и сравнение с ней;
альтернатива – пошаговое сравнение, координация возможных действий пользователей (варианты с упором на "до" и "после", понятно, что
"до" желательнее).
Кстати, вот ещё что.
Модифицированная версия атаки для обхода контроля статистики (более вероятностная, недетерминированная).
В фальшивом файле статуса противнику можно не менять много ключей узлов.
Достаточно поменять всего несколько для исходящих узлов, например выбрав их 10 штук.
И несколько для входящих.
А всем остальным узлам ключи не менять, но поменять для исходящих в их описании опцию с exit на middleman.
Также нужно немного фальшивых middlemano'в
Из этих исходящих 10 узлов половину сделать виртуальными, входящие – все.
Если траффик идёт через настоящий middleman – делать фальшивый exit недоступными отпускать его в настоящий Tor
неперехваченным. Как только клиент выберет ещё и фальшивый middleman из списка (пусть даже вероятность такой ситуации мала),
то соединение пройдёт через [фальшивый entry guard]-[фальшивый middleman]-[фальшивый exit] с вероятностью 1/2.
Защититься просто: кроме C и D для предотвращения подобных атак (вероятно возможны другие варианты) надо по типу D контролировать разность (difference) между описаниями нод, айпишниками и вообще всеми параметрами, которые можно извлечь из файла статуса сети.
Другое дело, что противник всегда может подсмотреть используемый юзером список guard-узлов и не меняя их описание принудительно, поменять хотя бы только им ключи. Виртуальный фальшивый Guard – тоже штука малоприятная – противнику не нужно фильтровать трафик от этого узла в цепочке, юзер в нём один. И можно блочить соединения, имитируя что это происходит уже за этим узлом, заставляя пользователя лишний раз когда нужно противнику перестроить цепочку.
Ну и атака с задержкой или подсовыванием устаревшей статистики, но с новым таймштампом позволяет профилировать юзера (уже тоже вероятностно, а не детерминированно).
Всё-таки предполагаемый противник такого уровня обладает слишком большими возможностями для контроля.
Спасибо :) [раскланялся на обе стороны]
Ничего сверхъестественного в работе не было. На этом форуме все слышали про пресловутую "квантовую криптографию", что более точно есть всего лишь "квантовое распределние ключа". Так вот, когда Алиса передаёт ключ Бобу или ещё кому-то, она использует нечто, что математически описывается понятием "квантового канала". В работе как раз был рассмотрен один из типов квантовых каналов и было показано, что можно при определённых условиях увеличить скорость передачи по нему за счёт специфических квантовых корреляций ("энтанглемента") между используемыми квантовыми состояниями. (Сорри за офтоп :))
Да, замечание справедливое. Я интуитивно предполагал что довольно редко (в среднем так же редко, как обычные пользователи меняют свои PGP-ключи).
Да, uknown, вы молодец, атаковали систему с неожиданного для меня направления :) © SATtva. В этом случае я бы модифицировал вашу атаку для пущей определённости вот каким образом: оператор тор-машинки знает верную статистику, а значит он в реальном времени может детектить смену ключей для тех или иных нод. Как только нода меняет свой ключ и репортит сей факт на DA, оператор устраивает атаку стиля MITM, предъявляя пользователю не истиный новый ключ той ноды, а свой, и далее предъявляет уже только "инфицированную статистику" в которой со временем будет всё больше и больше фальшивых ключей. В этом случае через какое-то время злоумышленнику удастся подменить ключи ровно такого количества нод, которое меняло свои ключи за данный период. Атака сработает. В то же время если пользователь сделает "перекрёстную проверку" ключей с соседями ранее момента своей деанонимизации, он засечёт эту атаку. Видимо, Ваша атака устанавливает одну из границ на максимально допустимый (ещё секъюрный) период между двумя перекрёстными сверками(!!!) статистики. Красиво :)
Что же касается дословно вашего описания атаки – она конкретно в таком виде не сработает. Если оппонент попытается "расшатать" статистику, введением левых ключей не учитывая "расписание" их смены для соответствующих нод, и конкретно сами ноды, то он добавит шума, что можно бдует обнаружить (+20% от естественной смены ключей +20% от смены ключей злоумышленника и -n% ключей из-за перекрывания множеств ключей, который менял злоумышленник и которые реально потом сменились).
Сама по себе информация об этих скачках всё равно ничего не даст для априорных действий. Выявить атаку можно будет только после перекрёстной сверки, но если вы возьмёте в какой-то момент времени свой последний файл статистики и сделаете эту сверку для него, также получите результат. Я призываю в первую очередь не к сравнению соседних по времени статистики, а к перекрёстной сверке. Сравнение соседних по времени важно только когда постфактум вы будете расследовать саму атаку и выявлять кто, когда и чьи ключи подменил.
Вроде уже движемся к концу, или нет? Может быть мы взялись за сильно амбициозную задачу, которая очень сложна, и постепенно будем находить всё больше и больше способов обойти алгоритм? Фактически это есть задача децентрализации доверия в сети тор, и к месту можно вспомнить про децентрализацию прав рута в системе – последняя задача отнюдь не из простых :)
Местами много повторений, которые можно было бы сжать (на что понадобилось бы больше времени для формулирования), но так не везде. Сложный баланс: если коротко без подробностей – не поймут, если с подробностями – много воды, оптимум достигается лишь при долгом и тщательным обдумывании каждого предложения перед опубликованием :)
Не знаю есть ли такое уже или нет, а я бы сделал так: ключ ноды + её описание + всё остальное касающееся этой ноды + её ключ ">" файл, и берём от него ХЭШ. Вот хэши тогда и будем сравнивать между собственно ключами нод (будет статистика хэшей нод в изложенном ранее фигурировать а не статистика ключей).
__Суммируя, 2 важных момента можно добавить к краткому описанию:
Ну что, ломаем дальше – я, вродь, отбился :)
В принципе меня больше привлекает топорное предложение Гостя, основанное на том, что все мониторят статистику тор-нод, и выявляют стабильные ноды. Далее, отъявленные параноики используют в своих цепочках лишь те стабильные ноды. В пределе довольно стабильной сети это было бы подалуй самым изящным решением, правда остаётся вопрос о том как достоверно получить информацию о том, какие ноды стабильны а какие нет, когда ключи DA уже украдены.
На совсем пожарный случай – заставлять ноды участвовать в PGP-сети доверия ещё можно. Это, конечно, неудобно и грубо, но зато надёжнее :) Впрочем, моя интуиция кажет что и в этом случае мощный оппонент, хорошо продумывающий свои шаги вперёд и владеющий ключами DA и в совершенстве знающий статистику тора, всё равно умудрится обмануть пользователя, просто атака будет выглядеть намного сложнее. Правда, это уже обсуждение атаки "глобальный наблюдатель", когда действительно у каждого провайдера кроме собственно сорма будет стоять ещё и антитор-машинка (возможно, как часть функционала сорм), и все такие машинки у разных провайдеров смогут общаться друг с другом.
P. S.: мне иногда кажется, что зря это обсуждение ведётся в открытой дискуссии – пока мы говорим, бб может "взять, да и сделать...".
комментариев: 9796 документов: 488 редакций: 5664
Стараюсь :-)
Вы просили придумать новую атаку, я это сделал, на уровне идеи по крайней мере, причём видно что их может быть несколько.
Слишком ультимативно вопрос был поставлен: "придумайте атаку, которую не ловит мой способ". А если бы не придумал?
Это же не значит, что система безопасна.
Если мы все упускаем что-то ещё?
Зачем? Можно каждое поле брать как параметр и поехали по вашей формуле: (A-1)2 + (B-1)2 + ... (Z-1)2.
Вы же сами утверждали, что параметров может быть дофига.
Если уже не. По хорошему пишут полную работу с действующими примерами, уведомляют и дают время разработчикам, после чего публикуют.
Но никто из нас заниматься этим не будет. Мы можем только поднять проблему.
Или лишний раз дать всем повод подумать, что из себя представляет Tor, не заложен ли в него такой скрытый функционал изначально.
комментариев: 9796 документов: 488 редакций: 5664
Потому что у нас нету уровня знаний для создания "provable security".
А для анонимных протоколов "proof" вообще редко используется. Tor не является "provable secure". И вообще это "experimental software. Don't rely on it for strong anonimity". Вот мы и экспериментируем.
комментариев: 11558 документов: 1036 редакций: 4118
Думаю, всё-таки чаще. Смена ключа PGP связана с серьёзными затратами на введение нового ключа в сеть доверия. Для Tor-узлов такой проблемы не стоит. Практически, смена ключа вообще ни на что не влияет (ну, guard-узлом "новичок" не станет, нужен определённый срок стабильной работы).
Мне кажется, это приведёт ко множеству ложных срабатываний. Есть, скажем, такая вещь, как exit policy — список сетей/портов, куда экзит разрешает или запрещает исходящий трафик. Так вот этот список может редактироваться оператором узла довольно часто.
Проблему можно решить, прибегнув к идее unknown'а и выбрав разные пороговые значения для срабатывания тревоги для разных полей:
Ну как сказать... безопасность – это очень текучая формулировка. Можно, например, сравнить 2 системы: у одной сорс открыт, баги все активно ищут, известны сплоиты (например, FF), и оперу – код закрыт, сплоитов нет, известных багов меньше. – Что проще сломать? Тонко тут всё. Мы нашли атаку и рассказали об ней людям => злоумышленникам теперь проще атаковать. Ранее им понадобилась бы ещё изобрести саму атаку... С другой стороны можно подойти в лоб и сказать что об этой атаке злоумышленник мог знать уже давно, а потому мы никак не повлияли на защиту тора. В общем, я пока строгого определения "безопасности программного продукта" не читал чтоб сравнивать :-D
Это всё можно, но надо понимать, что чем больше параметров тем громозче система и сложнее в управлении, менее чувствительна к возможным атакам, и более уязвима. Именно поэтому лучше сводить число используемых параметров к минимуму. Можно в лоб построить функцию хэшей: если они меняются действительно часто, то да, прийдётся рассматривать кучу параметров независимо. Мне хэши казались брутальней и надёжней: если они не порождают естественной большой дисперсии, то есть их достаточно для отлова атаки, то, имхо, оно самое то для нас. Хороший пример – недавняя новость про cold boot: были ли компьютеры ранее защищены больше лишь потому что широкая общественность не изнала о подобной возможности?
Согласен... Была ба хорошая работа для студента :-D – написать такую тор-машинку.