Раскрытие IP-адреса пользователей TOR через 301 HTTP Redirect Cache Poisoning.

KryptonFG

Max
Дней с нами
2.131
Розыгрыши
2
Сообщения
274
Репутация
9
Реакции
350
В этой статье пойдет речь о раскрытии реального IP-адреса пользователей TOR при помощи атаки 301 HTTP Redirect Cache Poisoning. Разберем пример практического применения атаки "HTTP 301 Cache Poisoning", которая может использоваться вредоносным выходным узлом Tor для раскрытия реального IP-адреса выбранных клиентов.

PoC Video


  • Клиент: Chrome Canary (76.0.3796.0)
  • Реальный IP-а


Код:
iptables -A OUTPUT -p tcp -m tcp --dport 80 -j DNAT --to-destination ip_address:80

iptables -A FORWARD -j ACCEPT

Описание сценария атаки

Предположения:

  • Браузерное приложение (в данном случае стандартный браузер), которое будет подключаться через сеть Tor и, наконец, через вредоносный выходной узел Tor.
  • Вредоносный выходной узел Tor, который перехватывает, и кэш HTTP 301 отравляет весь не-tls HTTP-трафик.

ea30c3521996fba7bc4b5.png


Рассмотрим следующие шаги сценария атаки:

  1. Пользователь подключается к Интернету через сеть Tor либо путем настройки параметров браузера для использования Tor SOCKS5, либо в масштабе всей системы, где весь трафик ОС направляется через сеть TOR.
  2. Пользователь начинает свой типичный сеанс просмотра в своем любимом браузере, где обычно через туннель Tor отправляется много HTTP-трафика, не относящегося к TLS.
  3. Выходной узел Evil Tor перехватывает эти запросы, не относящиеся к TLS, и отвечает перенаправлением HTTP 301 на каждый из них. Эти перенаправления будут постоянно кэшироваться браузером и будут указывать на URL отслеживания с назначенным идентификатором клиента TOR. URL-адрес отслеживания можно создать следующим образом: http: //user-identifier.evil.tld. Где 'evil.tld' будет собирать всю информацию об IP-адресе источника и перенаправлять клиентов на первоначально запрошенные хосты ... или, в качестве альтернативы, на прозрачный обратный прокси-сервер, который будет пытаться перехватить все клиенты при последующем потоке трафика HTTP. Кроме того, поскольку также возможно выполнить автоматическое загрязнение кэша для самых популярных доменов (как описано в предыдущем посте ), например TOP Alexa 100, злоумышленник может максимизировать свои шансы раскрытия реального IP-адреса.
  4. Пользователь, после закрытия сессии Tor, переключится обратно в свою обычную сеть.
  5. Как только пользователь вводит в адресную строку URL одну из ранее отравленных записей, например, «google.com», браузер будет использовать кэш и внутренне перенаправлять на URL отслеживания с идентификатором контекста узла выхода.
  6. Выходной узел теперь сможет сопоставлять ранее перехваченный HTTP-запрос и реальный IP-адрес пользователя через информацию, собранную на внешнем хосте, который использовал URL-адрес отслеживания с идентификатором пользователя. Evil.tld хост будет иметь информацию обо всех IP - адресов , которые были использованы для доступа к этому URL отслеживания.
Очевидно, что это дает возможность эффективно сопоставлять выбранные HTTP-запросы с IP-адресом клиента выходным узлом Tor. Это связано с тем, что ранее сгенерированный URL-адрес отслеживания будет запрошен клиентом через Tor-туннель, а затем, после подключения через стандартное соединение с ISP, снова. Это из-за отравленных записей в кэше.



Другой подход может основываться на внедрении модифицированного JavaScript с внедренными URL-адресами отслеживания в соответствующие ответы, не относящиеся к TLS, и настройке правильных заголовков (например, Cache-Control: max-age=31536000). Однако такой подход не будет очень эффективным.



Также возможно отслеживание пользователей с помощью стандартных файлов cookie с помощью различных веб-приложений, но нелегко заставить клиента посетить один и тот же контролируемый злоумышленником домен дважды: один раз, когда он подключается через выходной узел Tor, и позже, после того как он переключился обратно на стандартное интернет-соединение.

Выводы

Злоумышленник может злоупотреблять тем фактом, что можно добиться определенной устойчивости в кэше браузеров путем внедрения зараженных записей, чтобы раскрыть реальный IP-адрес пользователей Tor, которые отправляют не-TLS HTTP-трафик через вредоносные выходные узлы. Кроме того, отравление значительного числа популярных доменных имен увеличит вероятность получения HTTP-запроса обратного вызова (с назначенным идентификатором пользователя), что позволит раскрыть пользователям реальный IP. Можно также попытаться «перехватить домен» некоторых клиентов на основе браузера и надеяться, что неправильно набранное доменное имя не будет замечено пользователем или не будет отображено (например, веб-приложения мобильного приложения).

Возможная минимизация атаки для пользователя TOR:

  • При подключении через сеть Tor убедитесь, что весь трафик не-TLS отключен. Примеры плагинов для браузера, которые можно использовать: «Firefox» , «Chrome» .
  • Кроме того, всегда используйте браузер «приватный» режим для просмотра через Tor.
  • Не маршрутизируйте весь трафик вашей ОС через Tor, не убедившись, что там только трафик TLS…
  • По возможности используйте последнюю версию браузера Tor для просмотра веб-страниц (предпочтительно с отключенным трафиком, отличным от TLS, в противном случае могут возникнуть некоторые риски, например перехват сеанса просмотра HTTP).
 
  • Like
Реакции: max24555
не совсем понял каким хуем сюда правила фаерволла с под линуксов приписаны