TOR: Халатность руководства

Original author: Piotr CHMIELNICKI
  • Translation

Преамбула
Tor — это Сеть, построенная на луковой маршрутизации, ее используют люди по всему миру для безопасного, анонимного и бесцензурного общения.
Более подробная информация о Tor Project: www.torproject.org

Интересные моменты:
  • По Сети передается много важной информации
  • Релеи создаются добровольно, каждый сам может стать TOR-релеем (подробнее тут — прим. переводчика)
  • Точки выхода очень важная часть сети, так как каждый конечный узел (точка выхода) может произвести дамп трафика (на точке выхода уже чистый (незашифрованный) трафик доходит до изначального адреса получателя (сервера) — прим. переводчика).

Руководство TOR'a

Tor использует свои сервера для публикации списка всех релеев

Перехват трафика на точке выхода

Перехват трафика на точке выхода это известная проблема. Она может быть решена с помощью использования протоколов шифрования. Обычно используется TLS и TLS поверх HTTPS.

Агрессивные MitM атаки

Шифрование можно обойти следующими способами:
  • Соединения с использованием TLS могут быть расшифрованы с помощью MitM атак. Конечно, это вызовет предупреждение о несовпадении сертификатов, но вполне вероятно, что пользователь проигнорирует это предупреждение. Пользователя, мало осведомленного о средствах криптографии легко заманить в ловушку
  • HTTPS можно перехватить лучшим способом, чем атакой «человек посередине» (MitM), к примеру просто заменяя <form action=”https://… на <form action=”http://… в HTTP (не зашифрованных) ответах. И никаких предупреждений в браузере пользователя.

Эти атаки довольно легко обнаруживаются, так как изменяют передаваемую информацию.

Проверяем релеи!

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

Proof of concept

По ссылке результат 3х дневного перехвата HTTP и HTTPS POST запросов, применяя агрессивный MitM и модифицированный sslstrip
http://perso.epitech.eu/~chmiel_p/TorPOC.zip
sha512 60fbb49b36b271f543ffb34b87ebccf889ddad070c5e04f386f530a639

CONTACT

piotr.chmielnicki@epitech.eu
Share post

Comments 8

    +3
    Пользовался исключительно как халявной прокси, да и не в целях безопасности, а в целях смены ip. С точки зрения секурности никогда не рассматривал TOR как серьезную систему анонимности, хотя хочется надеяться на будущее.
      +2
      Ну Tor, ну перехват на выходе, о чем топик то? О том, что это возможно?
      Так это возможно при использовании любых прокси, при использовании незащищенного или слабо защищенного wifi, на стороне провайдера, при физическом доступе к кабелю (а у многих до квартиры кабель). Много где это возможно. Только в случаях с wifi, провайдерами и доступом на физический уровень злоумышленник точно знает кого и зачем он ломает. А в случае с Tor — вышел чей-то непонятно чей трафик через твой узел и только к нему ты имеешь доступ. Рулетка.
        –2
        О том, что в TOR'e данные перехватываются так же легко, как и в других сетях.
        Мнение многих — что там все максимально конфиденциально и можно быть спокойным за пересылаемые данные.
          0
          Отчасти оно так и есть. Кто угодно не может получить доступ к произвольным данным кого угодно. Узел выхода случайный. Вот если бы можно было управлять и получить доступ к данным конкретного человека, вот тогда да, проблема.
        +2
        Простите, а что именно должен проверять скрипт относительно точки выхода? Какие сертификаты используются? Или не применяет ли точка выхода замену https на http?
        Если честно, мне последняя операция вообще непонятна: если соединение зашифровано, то оно зашифровано в обе стороны (вроде так SSL/TLS работает), и подменить что-то в ответе нельзя. Если же соединение перехвачено (путём внедрения своего сертификата), то зачем что-то внедрять?
        Касательно же атаки MitM на SSL — это не проблема TOR, это проблема SSL, насколько я понимаю. И почему именно администрация TOR должна с этим бороться — не очень ясно.
          0
          Не я автор, но изложу свои мысли (точнее домыслы)
          Думаю можно пересылать к примеру каждый час контрольный пакет (ничем по «внешнему» виду не отличающийся от «обычных») и смотреть, изменяется ли его данные/сертификат. В случае измененных данных делать алерт, блочить узел.
            +2
            > подменить что-то в ответе нельзя
            Когда https-соединение уже установлено, то подменить ничего нельзя, да. Но обычно пользователи заходят изначально по http на сайт. А он их перенаправляет на https (сразу или при отправки формы авторизации). Вот на этом этапе можно подменить содержимое сайта, так что переход на https вообще не произойдет. Продвинутые пользователи заметят этот подозрительный факт, но обычные пользователи этого не заметят.
            –2
            Уже второй горе-Колумб за неделю…

            Only users with full accounts can post comments. Log in, please.