Данная статья описывает пример практического применения атаки «искажение кэша через 301 редирект», которая может быть использована выходным узлом сети «Tor» с вредоносным кодом для выявления реальных IP-адресов выбранных пользователей.

Сценарий атаки

Сценарий атаки выглядит следующим образом:

• Клиент: Chrome Canary (76.0.3796.0)
• Реальный IP-адрес клиента: 5.60.164.177
• Параметр отслеживания клиента: 6b48c94a-cf58-452c-bc50-96bace981b27
• IP-адрес выходного узла сети «Tor»: 51.38.150.126
• Transparent Reverse Proxy: tor.modlishka.io (Modlishka — updated code to be released.)

Примечание: В данном сценарии браузер «Chrome» был настроен через сетевой протокол SOCKS5 для использования сети «Tor». Канал сети «Tor» был настроен на конкретный тестовый выходной узел: ‘51.38.150.126’. Это также является проверкой правильности концепции и многие настройки могут быть оптимизированы в дальнейшем …

В случае с зловредным выходным узлом сети «Tor», весь трафик перенаправляется через прокси-сервер «Modlishka»:

iptables -A OUTPUT -p tcp -m tcp --dport 80 -j DNAT --to-destination ip_address:80
iptables -A FORWARD -j ACCEPT

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

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

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

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

1. Пользователь подключается к интернету через сеть «Tor» путём настройки браузера для использование сетевого протокола SOCKS5 системы «Tor», или же настроив так, чтобы весь трафик операционной системы перенаправлялся через сеть «Tor».
2. Пользователь начинает свой обычный сеанс выхода в интернет с помощью своего любимого браузера, где обычно очень много HTTP-трафика без протокола безопасности «TLS» отправляется через туннель сети «Tor».
3. Зловредный выходной узел сети «Tor» перехватывает запросы и отвечает переадресацией каждого с помощью кода ответа «HTTP 301». Эти перенаправления будут постоянно кэшироваться браузером и будут отправлять на URL-адрес для отслеживания с назначенным идентификатором Tor-клиента. URL-адрес для отслеживания может быть создан следующим способом: user-identifier.evil.tld, где ‘evil.tld’ будет собирать всю информацию об IP-адресе источника и перенаправлять пользователей на первоначально запрашиваемые хосты … или, как альтернатива, на прозрачный обратный прокси-сервер, который попробует перехватить весь последующий поток HTTP-трафика клиентов. Кроме того, поскольку есть возможность автоматического искажения кэша для большинства самых популярных доменов (как описано в предыдущей статье), напр. топ 100 сайтов по статистике компании «Alexa», злоумышленник максимизирует свои шансы на выявление настоящих IP-адресов.
4. После выхода из сессии сети «Tor», пользователь переключится на свою обычную сеть.
5. Как только пользователь введёт в адресную строку адрес одного из предыдущих искажённых доменов, (например, «google.com») браузер использует кэш для внутреннего перенаправления на URL отслеживания с контекстным идентификатором выходного узла.
6. Выходной узел сможет сопоставить ранее перехваченный HTTP-запрос с реальным IP-адресом пользователя с помощью информации, полученной с внешнего хоста, который использовал URL отслеживания с идентификатором пользователя. Хост «evil.tld» будет обладать информацией обо всех IP-адресах, которые были использованы для доступа к URL отслеживания.

Очевидно, что данный способ позволяет эффективно сопоставлять выбранные HTTP-запросы с IP-адресами клиента с помощью выходного узла сети «Tor». Происходит это потому, что ранее сгенерированная URL для отслеживания будет запрошена клиентом через туннель сети «Tor», а потом снова, как только произойдёт подключение через стандартное соединение интернет-провайдера. Всё из-за искажённого кода в кэше.

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

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

Выводы

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

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

Способы уменьшения риска:

• При подключении к интернету через сеть «Tor» убедитесь, что отключён весь трафик, который не использует протокол безопасности «TLS». Пример браузерных плагинов, которые могут быть использованы: для браузеров Firefox” и “Chrome”.
• Кроме того, всегда используйте «приватный» режим браузера при подключении к интернету через сеть «Tor».
• Не перенаправляйте трафик всей вашей операционной системы через сеть «Tor» до тех пор, пока не убедитесь, что весь исходящий трафик использует протокол безопасности «TLS» …
• Для просмотра веб-страниц, по возможности, всегда используйте последнюю версию «Tor» браузера.

---

На DEDIC.SH доступны новейшие двухпроцессорные конфигурации выделенных серверов с процессорами Intel Scalable 2019 года:

• 2x Xeon Silver 4214 — суммарно 24 ядра
• 2x Xeon Gold 5218 — суммарно 32 ядра
• 2x Xeon Gold 6240 — конфигурация с 36 ядрами.

Стоимость сервера с двумя Xeon Silver 4214 — от 15210 руб/мес
Так же мы готовы собрать для Вас любую конфигурацию — напишите нам!

Если большие мощности выделенного сервера не требуются — VDS от 150 руб/мес — то, что вам нужно!