Тут два разных вектора атаки. Если у нас есть контроль над всеми восемью directory servers (которые, кстати, расположены в разных странах), то это надо использовать именно для того, чтобы заменить список релеев своими и временно, пока все не опомнились, снифать весь Tor трафик и, соответственно, узнать расположение всех .onion-ов и их клиентов. Хотя, такая атака скорее всего неосуществима из-за того, что каждый клиент Tor имеет несколько случайно выбранных релеев в качестве Entry guards и подключается к сети только через них (набор entry guards меняется только каждые несколько месяцев). Даже в случае подмены всех релеев на подконтрольные гебне, entry guards клиентов, которые подключались к Tor ранее, будут из неподмененного списка. А значит, даже сломав все directory servers, у атакующего в лучшем случае будет доступ к 2-м из 3-х релеев каждого пути, что ничего не даст в плане расшифровки трафика.
А если мы вычислили в какой стране сидит данный .onion, то остается только следить за трафиком всех соединений с сетью Tor в данной стране и тем же самым методом корреляции трафика (ну или отключениям разных частей сети от интернета) постепенно сужать область поиска... Опять же, результат не гарантирован, а если .onion активно предпринимает попытки воспрепятствовать своему нахождению (да хотя бы подключение к Tor через разных провайдеров, или через прокси), то и маловероятен.
> c) подмены destination tor трафика фишинговой обманкой
Вот этого в любом случае сделать не получится, т.к. адрес .onion представляет из себя хеш публичного ключа этого сервера. А для того, чтобы подтвердить свою аутентичность, серверу нужно знать соответствующий приватный ключ, которого ни у кого кроме самого .onion-а нет.
> Если у нас есть контроль над всеми восемью directory servers (которые, кстати, расположены в разных странах), > то это надо использовать именно для того, чтобы заменить список релеев своими и временно, пока все не опомнились, > снифать весь Tor трафик и, соответственно, узнать расположение всех .onion-ов и их клиентов Вообще говоря контроль и знание их ключей вещи довольно разные. Собственно, я так понял, что 'directory servers' отдают tor клиенту адреса для входа в tor сеть - "tor relays" подписанные этими самыми ключами. При этом адреса этих самых directory servers известны. Очевидная атака уровня "сговор кровавой гебни нескольких стран" может быть реализована так:
1. ставим на пути трафика к tor directory server "умную прерывалку", которая имеет полученные не важно как (например, средствами TEMPEST Attack или иным незаметным владельцам сопособом) приватные ключи данного directory server.
2. ставим N штук evil relay node, на которые можно будет перенаправить траф. Чем более незаметной и эффективной мы хотим сделать атаку, тем больше таких узлов ставим.
3. на каждой evil relay node заменяем алгоритм установки соединения так, чтобы транзитные соединения устанавливались только с нашими evil relay nodes + они сообщали друг другу ключи шифрования транзитного трафа для выявления полных цепочек.
4. На умной прерывалке коллекционируем реальные адреса tor клиентов и отдаем им адреса evil relay node подписанные умыкнутым ключём tor directory server.
5. Если мы имеем дело с искомым .onion, то на наших evil relays мы это сразу увидим. Если нет - перенаправляем траф в реальную tor сеть и складываем реальный IP в список уже прошедших первичную проверку чтобы игнорироровать на нашей умной прерывалке траф с этого адреса (пропускать к реальному tor directory).
Так вот наша задача, как атакующей стороны будет дождаться пока к нам не попадет траф от искомого .onion .
Так как клиентский трафик мы можем легко создать сами, запрашивая нужный .onion, то должно получиться быстро сузить список потенциальных держателей .onion следующими средствами:
A. Организуем кратковременные потери связности между сегментами реальной сети для того чтобы заставить держателя .onion пересоединится к tor выбрав случайным образом новый входной релей, а значит с какой-то вероятностью - наши evil relays.
B. Организуем периодические клиентские запросы к .onion чтобы искомый .onion и наш клиент строили новые цепочки-подключения по случайному принципу. При этом, с некоторой вероятностью, рано или поздно .onion войдет в сеть через наши evil relay, а значит оставит свои реальные адреса.
C. Ставим наши evil relays на широкий канал, обеспечивая их выбор в качестве точек рандеву. Так добиваемся, что нормальные тор релеи сдают нам свои реальные IP.
D. Периодически обеспечиваем потерю связности с обычной сетью (а значит и с tor) для нормальных tor релеев, адреса которых получены в предыдущем пункте, вынуждая таким образом держателя .onion сменить релей, а значит, с некоторой вероятностью вляпаться в наш блок evil relay nodes.
Конечно тут не рассмотрено что делать с адресами за NAT в пункте 5, но это только черновая схема атаки. )
Кстати, если искомый .onion скачет по проксям перед входом в tor сеть, то он вынужден постояно менять точки входа в tor, а значит попадет в наш evil relay с большей вероятностью, чем если будет сидеть на месте. =)
> набор entry guards меняется только каждые несколько месяцев Для того чтобы избежать необходимости поддерживать вышеописанную атаку годами нужно пользоваться откючением нормальных тор-релеев согласно пунктам C и D выше.
Если тор клиент обнаруживает все entry guards оффлайн, то ЕМНИП он самостоятельно не предпринимает попыток подключиться через другие ноды. В общем думаю, что такая атака маловероятна, такое крупномасштабное вклинивание в сеть будет очень быстро замечено, максимум у атакующих будет несколько часов, чтобы что-либо успеть сделать, пока не поднимется шум.
В общем случае не обязательно оффлайнить entry guards - надо только посмотреть детально способ их ротации и подстроить алгоритм атаки соответственно. Это правда сделает атаку дороже. =) Я так понимаю, что по остальным моим предложениям по организации атаки принципиальных возражений нет?
А если мы вычислили в какой стране сидит данный .onion, то остается только следить за трафиком всех соединений с сетью Tor в данной стране и тем же самым методом корреляции трафика (ну или отключениям разных частей сети от интернета) постепенно сужать область поиска... Опять же, результат не гарантирован, а если .onion активно предпринимает попытки воспрепятствовать своему нахождению (да хотя бы подключение к Tor через разных провайдеров, или через прокси), то и маловероятен.
> c) подмены destination tor трафика фишинговой обманкой
Вот этого в любом случае сделать не получится, т.к. адрес .onion представляет из себя хеш публичного ключа этого сервера. А для того, чтобы подтвердить свою аутентичность, серверу нужно знать соответствующий приватный ключ, которого ни у кого кроме самого .onion-а нет.
Reply
> то это надо использовать именно для того, чтобы заменить список релеев своими и временно, пока все не опомнились,
> снифать весь Tor трафик и, соответственно, узнать расположение всех .onion-ов и их клиентов
Вообще говоря контроль и знание их ключей вещи довольно разные. Собственно, я так понял, что 'directory servers' отдают tor клиенту адреса для входа в tor сеть - "tor relays" подписанные этими самыми ключами. При этом адреса этих самых directory servers известны. Очевидная атака уровня "сговор кровавой гебни нескольких стран" может быть реализована так:
1. ставим на пути трафика к tor directory server "умную прерывалку", которая имеет полученные не важно как (например, средствами TEMPEST Attack или иным незаметным владельцам сопособом) приватные ключи данного directory server.
2. ставим N штук evil relay node, на которые можно будет перенаправить траф. Чем более незаметной и эффективной мы хотим сделать атаку, тем больше таких узлов ставим.
3. на каждой evil relay node заменяем алгоритм установки соединения так, чтобы транзитные соединения устанавливались только с нашими evil relay nodes + они сообщали друг другу ключи шифрования транзитного трафа для выявления полных цепочек.
4. На умной прерывалке коллекционируем реальные адреса tor клиентов и отдаем им адреса evil relay node подписанные умыкнутым ключём tor directory server.
5. Если мы имеем дело с искомым .onion, то на наших evil relays мы это сразу увидим. Если нет - перенаправляем траф в реальную tor сеть и складываем реальный IP в список уже прошедших первичную проверку чтобы игнорироровать на нашей умной прерывалке траф с этого адреса (пропускать к реальному tor directory).
Так вот наша задача, как атакующей стороны будет дождаться пока к нам не попадет траф от искомого .onion .
Так как клиентский трафик мы можем легко создать сами, запрашивая нужный .onion, то должно получиться быстро сузить список потенциальных держателей .onion следующими средствами:
A. Организуем кратковременные потери связности между сегментами реальной сети для того чтобы заставить держателя .onion пересоединится к tor выбрав случайным образом новый входной релей, а значит с какой-то вероятностью - наши evil relays.
B. Организуем периодические клиентские запросы к .onion чтобы искомый .onion и наш клиент строили новые цепочки-подключения по случайному принципу. При этом, с некоторой вероятностью, рано или поздно .onion войдет в сеть через наши evil relay, а значит оставит свои реальные адреса.
C. Ставим наши evil relays на широкий канал, обеспечивая их выбор в качестве точек рандеву. Так добиваемся, что нормальные тор релеи сдают нам свои реальные IP.
D. Периодически обеспечиваем потерю связности с обычной сетью (а значит и с tor) для нормальных tor релеев, адреса которых получены в предыдущем пункте, вынуждая таким образом держателя .onion сменить релей, а значит, с некоторой вероятностью вляпаться в наш блок evil relay nodes.
Конечно тут не рассмотрено что делать с адресами за NAT в пункте 5, но это только черновая схема атаки. )
Кстати, если искомый .onion скачет по проксям перед входом в tor сеть, то он вынужден постояно менять точки входа в tor, а значит попадет в наш evil relay с большей вероятностью, чем если будет сидеть на месте. =)
> набор entry guards меняется только каждые несколько месяцев
Для того чтобы избежать необходимости поддерживать вышеописанную атаку годами нужно пользоваться откючением нормальных тор-релеев согласно пунктам C и D выше.
Покритикуйте схему?
Reply
Reply
Reply
(The comment has been removed)
Reply
Leave a comment