На конференции по кибербезопасности SecureWV 2019, проходившей в Чарльстоне, Западная Вирджиния, мы с Пейсу представили наш доклад "Рассмотрение мостов Tor и подключаемого транспорта". Теперь мы делимся более подробной информацией об этом исследовании, и наш анализ публикуется в двух статьях. В первой части этой серии из двух частей мы воспользуемся реверс-инжинирингом, чтобы объяснить, как найти встроенные мосты Tor и как браузер Tor работает с включенным мостом.
Браузер Tor и сеть Tor
Tor Browser - это инструмент, который обеспечивает анонимное подключение к Интернету в сочетании с уровнями шифрования через сеть Tor. Когда пользователи исследуют веб-сайты с помощью Tor Browser, их реальный IP-адрес скрывается сетью Tor, поэтому конечный веб-сайт никогда не знает, каков истинный исходный IP-адрес. Пользователи также могут создать свой собственный веб-сайт в сети Tor с доменным именем, заканчивающимся на ".onion". Таким образом, только браузер Tor может получить к нему доступ, и никто не знает его реальный IP-адрес. Это одна из причин, по которой преступники-вымогатели требуют от жертв доступа к странице оплаты на веб-сайте .onion через браузер Tor. Команда проекта Tor знает об этой практике, потому что в блоге проекта Tor четко сказано, что "Tor используется злоумышленниками не по назначению".
Tor Browser - это проект с открытым исходным кодом, созданный на основе Mozilla Firefox. Вы можете скачать исходный код с его официального сайта. Сеть Tor - это всемирная оверлейная сеть, состоящая из тысяч управляемых добровольцами ретрансляторов.
Что такое мост Тор?
Сеть Tor состоит из двух типов узлов ретрансляции: обычных узлов ретрансляции и узлов ретрансляции мостов. Обычные узлы ретрансляции перечислены в основном каталоге Tor, и соединения с ними могут быть легко идентифицированы и заблокированы цензорами. Информация о мосте Tor определяется в файле профиля Firefox, поэтому вы можете отобразить их, введя "about:config" в адресную строку браузера Tor, как показано на рисунке 1.
Однако узлы ретрансляции мостов не перечислены в основном каталоге Tor, а это означает, что цензоры не могут легко заблокировать подключения к ним. В этом блоге я расскажу, как найти эти мосты и узлы ретрансляции с помощью функций, встроенных в Tor Browser.
Чтобы использовать мост-ретранслятор в Tor Browser, есть два варианта. В Tor Browser есть несколько встроенных мостов, которые пользователи могут выбирать. Если встроенные мосты не работают, пользователи могут получить дополнительные мосты в настройках сети Tor, посетив TorProject.org или отправив электронное письмо по адресу bridges@bridges.torproject.org.
Анализ платформы браузера Tor
Этот анализ проводился на следующей платформе, а также на следующих версиях и расширениях Tor Browser:
- Windows 7 32-bit SP1
- Tor Browser 8.0
- TorLauncher 0.2.16.3 (one extension)
- Torbutton 2.0.6 (one extension)
На рисунке 2 показана информация о версии Tor Browser, над которым я работал.
Во время моего анализа Tor Browser выпустил новую версию: Tor Browser 9.0 22 октября 2019 года. Вы можете обратиться к Приложению этого анализа для получения дополнительной информации о нем.
Как запустить браузер Tor со встроенными мостами
Эта версия Tor Browser, которую я проанализировал, предоставляет четыре типа мостов: "obfs4", "fte", "meek-azure" и "obfs3". Их называют подключаемыми транспортами. Вы можете увидеть подробные настройки на рисунке 3.
Obfs4 Bridge настоятельно рекомендуется на официальном сайте Tor. Весь анализ, представленный ниже, основан на этом виде моста. Я выбрал мост "obfs4" в списке, показанном на рисунке 3, чтобы начать анализ. Изучая трафик, когда Tor Browser устанавливает соединение "obfs4", я обнаружил, что сеансы TCP создаются obfs4proxy.exe, который является клиентским процессом моста.
На рисунке 4 показан снимок экрана дерева процессов при запуске Tor Browser с "obfs4". Как видите, "firefox.exe" запускает "tor.exe", который затем запускает "obfs4proxy.exe". Процесс "obfs4proxy.exe" находится в «Папка_установки Tor\Browser\TorBrowser\Tor\PluggableTransports». Первоначально я думал, что встроенные мосты "obfs4" должны быть жестко запрограммированы внутри процесса "obfs4proxy.exe".
Трассировка и отслеживание в процессе Tor Bridge "obfs4proxy.exe"
Я запустил отладчик и присоединил его к "obfs4proxy.exe". Затем я устанавливаю точку останова на API "connect", который часто используется для установления TCP-соединений. Обычно с помощью реверс инжиниринга можно быстро обнаружить IP-адреса и порты из этого API. Однако у меня он не сработал до того, как были установлены соединения с мостом "obfs4". После дальнейшего анализа процесса "obfs4proxy.exe" я узнал, что вместо этого он использует другой API под названием "MSAFD_ConnectEx" из mswsock.dll.
На рисунке 5 показано, что "obfs4proxy.exe" собирается вызвать API "mswsock.MSAFD_ConnectEx()", чтобы установить TCP-соединение со встроенным мостом "obfs4", чей IP-адрес и порт - "192.95.36.142:443". Второй аргумент этой функции - указатель на структурную переменную struct sockaddr_in, которая содержит IP-адрес и порт для подключения. Позже он вызывает API WSASend и WSARecv для связи с мостом obfs4. Как вы могли заметить, отладчик OllyDbg не смог распознать этот API, потому что это не функция экспорта "mswsock.dll". Анализируя файл mswsock.dll в IDA Pro, мы видим, что адрес 750A7842 - это просто API "MSAFD_ConnectEx()". Кстати, инструкция "call dword ptr [ebx]" используется для вызова почти всех системных API-интерфейсов, которые нужны "obfs4proxy.exe", что позволяет скрыть API-интерфейсы от анализа.
По моему анализу, большинство PE-файлов (exe и dll-файлов, таких как "obfs4proxy.exe"), используемых Tor, похоже, скомпилированы "компилятором GCC MINGW-64w", который всегда использует "mov [esp],…" для передачи аргументов функциям вместо инструкций "push …", которые создают проблемы для статического анализа. Отслеживая и отслеживая поток стека вызовов из "MSAFD_ConnectEx()", я понял, что моя первоначальная мысль была неправильной, потому что встроенные IP-адреса и порты не жестко запрограммированы в "obfs4proxy.exe", а взяты из родительского процесса "Tor.exe" через локальное петлевое TCP-соединение.
Обычно третий пакет от tor.exe к obfs4proxy.exe содержит один встроенный IP-адрес моста obfs4 и порт в двоичном формате, как показано на рисунке 6. Это пакет Socks5 длиной 0xA байтов. "05 01 00 01" - это заголовок его протокола Socks5, а остальные данные - это IP-адрес и порт в двоичном формате. Пакет указывает, что он просит "obfs4proxy.exe" установить соединение с мостом с двоичным IP-адресом и портом. Затем "obfs4proxy.exe" анализирует пакет и преобразует двоичный IP-адрес и порт в строку, которая в данном случае — "154.35.22.13:16815".
Переход в Tor.exe
"Tor.exe" использует сторонний модуль с именем "libevent.dll" из libevent (библиотеки уведомлений о событиях), чтобы заставить Tor выполнять свои задачи. Tor помещает большинство своих задач сокетов (connect(), send(), recv() и т.д.) на события, которые будут автоматически вызываться libevent. При отслеживании пакета с IP-адресом и портом моста в "Tor.exe" вы можете увидеть в контексте стека вызовов, что многие адреса возврата находятся в модуле "libevent.dll". На рисунке 7 отладчик приостановил работу Tor.exe, вызвав API ws2_32.send(), чтобы отправить пакет, содержащий IP-адрес и порт моста, точно так же, как полученный пакет, показанный на рисунке 6.
На рисунке 7 показано окно "Стек вызовов", в котором показаны адреса возврата "libevent.dll".
Посредством трасировки/отслеживания "tor.exe", отправляющего IP-адрес и порт моста, я нашел место, где он запускает новое событие с функцией обратного вызова, которая затем отправляет IP-адрес и порт моста. Приведенный ниже фрагмент кода ASM показывает контекст вызова libevent.event_new() в tor.exe. Второй аргумент - дескриптор сокета; его третий аргумент - это действие при событии, которое здесь 14H, что означает EV_WRITE и EV_PERSIST; его четвертый аргумент - функция обратного вызова (в данном случае sub_2833EE); а его пятый аргумент содержит IP-адрес и порт моста, которые будут переданы функции обратного вызова (sub_2833EE) после ее вызова libevent.
Следующий фрагмент кода ASM взят из "tor.exe", чей базовый адрес на этот раз - 00280000h.
Путем непрерывной обратной трассировки в "tor.exe" я обнаружил группу мостов Obfs4, которые находятся в структуре данных команды "SETCONF", как показано на рисунке 8.
Это фрагмент данных команды "SETCONF", где "SETCONF" - это имя команды в начале структуры, за которым следует информация о встроенных мостах. Данные в красных линиях - это один блок Obfs4 Bridge, называемый линией конфигурации моста. Каждый узел моста должен быть сохранен в одной строке конфигурации моста. Всего таких линий конфигурации моста здесь 27. Как видите, тип моста "obfs4", а также IP-адрес моста и порт внутри него имеют строковый формат.
Информация о мосте также не запрограммирована жестко внутри процесса "tor.exe". Теперь мы сталкиваемся с другим вопросом: откуда берутся все данные SETCONF? Фактически, это полученный TCP-пакет от "firefox.exe", который является родительским процессом "tor.exe". После запуска tor.exe открывает порт управления TCP 9151 для получения команд от firefox.exe и порта прокси TCP 9150. Я объясню, как firefox.exe отправляет ему команды позже.
Продолжая анализ в "tor.exe", я заметил, что помимо команды "SETCONF", он также поддерживает другие команды, такие как "GETCONF", "SAVECONF", "GETINFO", "AUTHENTICATE", "SETEVENTS", "+LOADCONF", "QUIT" и так далее. "Tor.exe" имеет функцию для обработки этих команд и выполнения различных ветвей кода.
"Tor.exe" выполняет множество различных задач в соответствии с этими командами. Например: команда "SAVECONF" указывает "tor.exe" сохранить информацию о мосте в файл, расположенный в "Папка_установки Tor\Browser\TorBrowser\Tor\Data\torrc"; а "SETCONF" сообщает "tor.exe" информацию о мосте, которая затем передается процессам моста для установления мостовых соединений.
Поиск встроенных мостов Tor в Firefox.exe
Tor использует множество петлевых TCP-соединений для передачи команд между процессами для выполнения своих задач.
Wireshark начал поддерживать локальный адаптер обратной петли в версии 3.0.1, позволяя захватывать трафик на интерфейсе обратной петли, например пакет "SETCONF" от "firefox.exe" к "tor.exe" через порт управления TCP 9151 на локальном петлевом интерфейсе. RawCap - еще один инструмент, который может делать то же самое. "Firefox.exe" отправляет пакет команд в "tor.exe" особым образом: один байт - один пакет. Как вы можете видеть на рисунке 9, существует много пакетов длиной 1. Их повторное ассемблирование дает полную команду "SETCONF".
До версии 9.0 в Tor Browser было два расширения: Torbutton и TorLauncher. Они находятся в папке "Папка_установки Tor\Browser\TorBrowser\Data\Browser\profile.default\extensions". Соответствующие файлы расширения - torbutton@torproject.org.xpi и tor-launcher@torproject.org.xpi, как показано на рисунке 10, которые представляют собой Zip-архивы, содержащие файлы и модули JS.
Однако, начиная с версии 9.0 браузера Tor, эти два расширения были удалены. Вместо этого их код и функции были включены в браузер Tor. Обратитесь к Приложению для получения дополнительной информации.
Torbutton используется для установки и отображения настроек Tor, а также для отображения информации Tor, такой как "О Tor". Вы можете найти его, щелкнув значок Tor на панели инструментов браузера Tor (см. Рисунок 3).
TorLauncher отвечает за управление процессом Tor в соответствии с настройками, установленными через Torbutton.
TorLauncher загружается, и его JS-код выполняется в модуле "xul.dll" Firefox, который является основным компонентом Mozilla Firefox, а также реальным модулем, отправляющим команды "tor.exe", например «SETCONF» ( реализовано в network-setting.js), "GETCONF" (tl-protocol.js) и "GETINFO" (tl-protocol.js, torbutton.js). Модуль "xul.dll" представляет собой своего рода JS-движок для анализа и выполнения JS-кода этих команд.
Теперь давайте посмотрим на внутренний рабочий механизм Tor Browser с включенными мостами. После запуска Tor Browser с включенными мостами он выполняет следующие шаги:
- firefox.exe загружает основные профили, определение предпочтений и расширения [задействованные модули: firefox.exe, xul.dll]
- Расширение TorLauncher запускает tor.exe с настройками в командной строке [задействованный модуль: xul.dll)
- В любое время Вы можете изменить настройки Tor с помощью Torbutton [задействованный модуль: xul.dll]
- Он отправляет команды в "tor.exe" и сообщает ему, как работать, на основе настроек, предоставленных через локальные петлевые TCP-соединения [задействованные модули: xul.dll, tor.exe]
- tor.exe затем запускает один соответствующий процесс моста (obfs4proxy.exe для "obfs3" и "obfs4", fteproxy.exe для "fte" и terminateprocess-buffer.exe для "meek-azure") для установления мостовой связи [задействовано модули: tor.exe, мостовые процессы]
- tor.exe взаимодействует с этими мостовыми процессами через локальные петлевые TCP-соединения. [задействованный модуль: tor.exe, мостовые процессы]
- Процессы моста подключаются к релею моста [задействованный модуль: процессы моста]
Браузер Tor отправляет команды через локальный интерфейс обратной связи для управления работой клиента Tor. Затем он получает и анализирует результаты команд от клиента Tor.
Согласно моему анализу, вся информация о мосте "obfs4" определена в ряде именованных глобальных переменных, называемых настройками в Firefox, и хранится в локальном файле. Они инициализируются при запуске "ofirefox.exe", и к ним обращаются и используются в TorLauncher путем считывания настроек по их именам, производным от "oxul.dll".
В целях безопасности я скрыл имя файла, который содержит весь набор определений информации о мостах для всех типов мостов. В анализируемой мной версии браузера Tor она включает 27 мостов "obfs4", 4 моста "obfs3", 1 мост meek-azure и 4 моста "fte".
Подключаемый транспорт
В приведенном выше анализе мы упомянули типы мостов: "obfs4", "obfs3", "meek-azure" и "fte". Все они называются подключаемым транспортом (ПТ). Их основная задача - преобразовать трафик Tor и передать его между клиентом и его первым переходом (ретранслятор Tor). Таким образом, использование PT может затруднить идентификацию и блокировку трафика Tor с помощью цензуры.
Obfs4 - более сильный и популярный ПТ. Первый переход Obfs4 обычно представляет собой реле-мост, который не указан в главном каталоге Tor. Обфускатор Obfs4 был разработан и поддерживается Yawning Angel. Это проект с открытым исходным кодом, написанный на языке Go, к которому вы можете получить доступ на GitHub. Раньше у Obfs Bridges было несколько версий, таких как Obfs2 и Obfs3. Obfs4 не сильно на них похож, но ближе к ScrambleSuit, потому что концепция Obfs4 взята из протокола ScrambleSuit Филиппа Винтера. Вот почему клиентский процесс Obfs4 также может выступать в роли клиента ScrambleSuit.
Все возможности Obfs4 предоставляются программой "obfs4proxy.exe", которая является клиентским процессом Obfs4 для пользователей Tor.
Как мы уже знаем, браузер Tor построен на базе браузера Firefox и использует расширения Firefox для предоставления пользователям анонимного доступа в Интернет. После запуска браузера Tor он фактически запускает "firefox.exe", который загружает два расширения Tor (TorLauncher и Torbutton). Позже одно из расширений Tor запускает tor.exe, то есть клиентский процесс Tor. Когда браузер Tor настроен на включение моста Obfs4 в "Сетевых настройках Tor", "tor.exe" запустит "obfs4proxy.exe".
Как браузер Tor взаимодействует с клиентом Tor
Процессы firefox.exe (браузер Tor) и tor.exe (клиент Tor) взаимодействуют друг с другом через TCP-порт Tor, прослушивая интерфейс обратной связи (127.0.0.1).
Из рисунка 4 выше видно, что "firefox.exe" запускает "tor.exe". Чтобы быть более конкретным, "tor.exe" запускается расширением Firefox "TorLauncher", которое загружается и анализируется модулем "xul.dll"». Когда он вызывает собственный API Windows ShellExecuteExW() для запуска tor.exe, многие параметры командной строки передаются в tor.exe. На рисунке 11 показан снимок экрана с параметрами командной строки, переданными в "tor.exe", когда "firefox.exe" собирался запустить "tor.exe".
В "tor.exe" передается 10 параметров. Для наглядности я разделил их на таблицу ниже, по одному параметру в одной строке. В таблице 1 "… \" - это сокращение от пути установки браузера Tor.
В таблице 1 выделено два порта: "+__ControlPort 9151" и "+__SocksPort» 127.0.0.1:9150 IPv6Traffic PreferIPv6 KeepAliveIsolateSOCKSAuth". "Tor.exe" будет прослушивать эти два TCP-порта 9151 и 9150 интерфейса обратной связи (127.0.0.1), которые являются номерами портов по умолчанию, которые использует "tor.exe".
Пользователи могут изменять значения по умолчанию для двух портов, которые определены в нескольких локальных файлах. Вот пример кода в локальном файле.
// Proxy and proxy security
pref("network.proxy.socks", "127.0.0.1");
pref("network.proxy.socks_port", 9150);
TCP-порт 9151 - это порт управления, используемый для обмена управляющими командами и результатами между "firefox.exe" и "tor.exe". Tor предоставляет прокси-сервис SOCKS5 на TCP-порту 9150, который используется для передачи пакетов SOCKS5 между firefox.exe и tor.exe.
Ниже приведен пример управляющей команды. "Firefox.exe" отправил команду "GETINFO" в "tor.exe" через TCP-порт 9151 и запросил некоторую информацию, затем "tor.exe" проанализировал команду и отправил результат обратно в "firefox.exe" с TCP-порта 9151.
GETINFO status/bootstrap-phase
250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=0 TAG=starting SUMMARY="Starting"
250 OK
Tor выполняет функции прокси на 127.0.0.1:9150, который передает обычные пакеты (незашифрованные Tor) между firefox.exe и tor.exe. На рисунке 12 показан снимок экрана с захватом пакетов в WireShark, где я разделил их на две части: верхняя часть - это рукопожатие Tor SOCKS5, нижняя - транспортировка пакетов.
На рисунке 12 показаны пакеты при посещении https://www.google.com в Tor Brower. В части установления связи "firefox.exe" сообщает "tor.exe", что адресатом доступа является "www.google.com" в пакете SOCKS5. После того, как рукопожатие SOCKS5 завершено, firefox.exe начинает посылать пакет приветствия клиента Google TLS в tor.exe, где этот пакет зашифровывается в клиенте Tor. Кроме того, клиент Tor отправляет обратно пакет Google TLS Server Hello. С этого момента firefox.exe начинает отправлять пакеты запросов и получать пакеты ответов от tor.exe через TCP-порт 9150.
На стороне клиента Tor он принимает пакеты через TCP-порт 9150 и завершает квитирование SOCKS5. Затем он получает обычные пакеты от "firefox.exe", которые затем шифруются. Пакеты, зашифрованные Tor, передаются входному релею Tor в выбранной цепочки Tor. Наконец, выходной релей Tor расшифровывает полученные пакеты, чтобы получить обычные пакеты, как показано между "firefox.exe" и "tor.exe", которые затем будут отправлены на целевой сервер (например, www.google.com).
В обратном направлении "tor.exe" получает зашифрованные пакеты от входного ретранслятора Tor, а затем расшифровывает их, чтобы получить пакеты с открытым текстом, которые в конечном итоге отправляются в "firefox.exe" из "tor.exe" через TCP-порт 9150, как показано ранее на рисунке 7.
Как клиент Tor взаимодействует с клиентом Obfs4
Клиент Tor ("tor.exe") запускает клиент Obfs4 "bfs4proxy.exe", как только клиент Tor получает команду "SETCONF" от браузера Tor. "Obfs4proxy.exe" открывает случайный TCP-порт на интерфейсе обратной связи для предоставления службы моста Obfs4 для Tor. Он уведомляет свой родительский процесс "tor.exe" о номере порта TCP через межпроцессный пайп.
На рисунке 13 приведен снимок экрана OllyDbg, показывающий, что точка останова в Windows API WriteFile() сработала, когда "obfs4proxy.exe" собирался сообщить "tor.exe" о своем TCP-порте. Как вы можете видеть в памяти, "CMETHOD obfs4 socks5 127.0.0.1:49496" - это данные с TCP-портом, отправляемые клиенту Tor.На этот раз случайный TCP-порт — 49496. Первый аргумент WriteFile() - дескриптор файла межпроцессного пайп, на этот раз 00000100.
После этого "tor.exe" может установить соединение с этим TCP-портом для связи с клиентом Obfs4. Tor отдельно отправляет узлы моста на этот порт, один мост за раз. На снимке экрана TCPView на рисунке 14 вы можете ясно видеть, что "tor.exe" отправляет мосты на "obfs4proxy.exe" отдельно.
Это весь процесс взаимодействия браузера Tor ("firefox.exe") с клиентом Obfs4 ("obfs4proxy.exe") через клиент Tor ("tor.exe"). В следующеq статье мы объясним, как клиент Obfs4 ("obfs4proxy.exe") устанавливает соединение с мостом Obfs4 и как Obfs4 преобразует пакеты для обхода цензуры.
Браузер Tor версии 9.0
В конце октября 2019 года был выпущен браузер Tor версии 9.0, в котором были удалены два расширения (TorLauncher и Torbutton). Без них браузер Tor теперь выполняет задачи, которые эти два расширения выполняли ранее. Фактически, в ходе своего анализа я обнаружил, что новая версия не удаляла код двух расширений, а вместо этого интегрировала их код в файл Firefox JAR под названием "omin.ja". Этот файл загружается и анализируется Firefox при запуске. После этого вы можете найти настройки сети Tor, используя меню “Options”-> “Tor”, как показано на Рисунке 15 ниже.
Это изменение в новой версии не влияет на рабочий механизм Tor Browser, поэтому этот анализ все еще действителен, даже если он был основан на старой версии 8.0.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://www.fortinet.com/blog/threat-research/dissecting-tor-bridges-pluggable-transport
Браузер Tor и сеть Tor
Tor Browser - это инструмент, который обеспечивает анонимное подключение к Интернету в сочетании с уровнями шифрования через сеть Tor. Когда пользователи исследуют веб-сайты с помощью Tor Browser, их реальный IP-адрес скрывается сетью Tor, поэтому конечный веб-сайт никогда не знает, каков истинный исходный IP-адрес. Пользователи также могут создать свой собственный веб-сайт в сети Tor с доменным именем, заканчивающимся на ".onion". Таким образом, только браузер Tor может получить к нему доступ, и никто не знает его реальный IP-адрес. Это одна из причин, по которой преступники-вымогатели требуют от жертв доступа к странице оплаты на веб-сайте .onion через браузер Tor. Команда проекта Tor знает об этой практике, потому что в блоге проекта Tor четко сказано, что "Tor используется злоумышленниками не по назначению".
Tor Browser - это проект с открытым исходным кодом, созданный на основе Mozilla Firefox. Вы можете скачать исходный код с его официального сайта. Сеть Tor - это всемирная оверлейная сеть, состоящая из тысяч управляемых добровольцами ретрансляторов.
Что такое мост Тор?
Сеть Tor состоит из двух типов узлов ретрансляции: обычных узлов ретрансляции и узлов ретрансляции мостов. Обычные узлы ретрансляции перечислены в основном каталоге Tor, и соединения с ними могут быть легко идентифицированы и заблокированы цензорами. Информация о мосте Tor определяется в файле профиля Firefox, поэтому вы можете отобразить их, введя "about:config" в адресную строку браузера Tor, как показано на рисунке 1.
Однако узлы ретрансляции мостов не перечислены в основном каталоге Tor, а это означает, что цензоры не могут легко заблокировать подключения к ним. В этом блоге я расскажу, как найти эти мосты и узлы ретрансляции с помощью функций, встроенных в Tor Browser.
Чтобы использовать мост-ретранслятор в Tor Browser, есть два варианта. В Tor Browser есть несколько встроенных мостов, которые пользователи могут выбирать. Если встроенные мосты не работают, пользователи могут получить дополнительные мосты в настройках сети Tor, посетив TorProject.org или отправив электронное письмо по адресу bridges@bridges.torproject.org.
Анализ платформы браузера Tor
Этот анализ проводился на следующей платформе, а также на следующих версиях и расширениях Tor Browser:
- Windows 7 32-bit SP1
- Tor Browser 8.0
- TorLauncher 0.2.16.3 (one extension)
- Torbutton 2.0.6 (one extension)
На рисунке 2 показана информация о версии Tor Browser, над которым я работал.
Во время моего анализа Tor Browser выпустил новую версию: Tor Browser 9.0 22 октября 2019 года. Вы можете обратиться к Приложению этого анализа для получения дополнительной информации о нем.
Как запустить браузер Tor со встроенными мостами
Эта версия Tor Browser, которую я проанализировал, предоставляет четыре типа мостов: "obfs4", "fte", "meek-azure" и "obfs3". Их называют подключаемыми транспортами. Вы можете увидеть подробные настройки на рисунке 3.
Obfs4 Bridge настоятельно рекомендуется на официальном сайте Tor. Весь анализ, представленный ниже, основан на этом виде моста. Я выбрал мост "obfs4" в списке, показанном на рисунке 3, чтобы начать анализ. Изучая трафик, когда Tor Browser устанавливает соединение "obfs4", я обнаружил, что сеансы TCP создаются obfs4proxy.exe, который является клиентским процессом моста.
На рисунке 4 показан снимок экрана дерева процессов при запуске Tor Browser с "obfs4". Как видите, "firefox.exe" запускает "tor.exe", который затем запускает "obfs4proxy.exe". Процесс "obfs4proxy.exe" находится в «Папка_установки Tor\Browser\TorBrowser\Tor\PluggableTransports». Первоначально я думал, что встроенные мосты "obfs4" должны быть жестко запрограммированы внутри процесса "obfs4proxy.exe".
Трассировка и отслеживание в процессе Tor Bridge "obfs4proxy.exe"
Я запустил отладчик и присоединил его к "obfs4proxy.exe". Затем я устанавливаю точку останова на API "connect", который часто используется для установления TCP-соединений. Обычно с помощью реверс инжиниринга можно быстро обнаружить IP-адреса и порты из этого API. Однако у меня он не сработал до того, как были установлены соединения с мостом "obfs4". После дальнейшего анализа процесса "obfs4proxy.exe" я узнал, что вместо этого он использует другой API под названием "MSAFD_ConnectEx" из mswsock.dll.
На рисунке 5 показано, что "obfs4proxy.exe" собирается вызвать API "mswsock.MSAFD_ConnectEx()", чтобы установить TCP-соединение со встроенным мостом "obfs4", чей IP-адрес и порт - "192.95.36.142:443". Второй аргумент этой функции - указатель на структурную переменную struct sockaddr_in, которая содержит IP-адрес и порт для подключения. Позже он вызывает API WSASend и WSARecv для связи с мостом obfs4. Как вы могли заметить, отладчик OllyDbg не смог распознать этот API, потому что это не функция экспорта "mswsock.dll". Анализируя файл mswsock.dll в IDA Pro, мы видим, что адрес 750A7842 - это просто API "MSAFD_ConnectEx()". Кстати, инструкция "call dword ptr [ebx]" используется для вызова почти всех системных API-интерфейсов, которые нужны "obfs4proxy.exe", что позволяет скрыть API-интерфейсы от анализа.
По моему анализу, большинство PE-файлов (exe и dll-файлов, таких как "obfs4proxy.exe"), используемых Tor, похоже, скомпилированы "компилятором GCC MINGW-64w", который всегда использует "mov [esp],…" для передачи аргументов функциям вместо инструкций "push …", которые создают проблемы для статического анализа. Отслеживая и отслеживая поток стека вызовов из "MSAFD_ConnectEx()", я понял, что моя первоначальная мысль была неправильной, потому что встроенные IP-адреса и порты не жестко запрограммированы в "obfs4proxy.exe", а взяты из родительского процесса "Tor.exe" через локальное петлевое TCP-соединение.
Обычно третий пакет от tor.exe к obfs4proxy.exe содержит один встроенный IP-адрес моста obfs4 и порт в двоичном формате, как показано на рисунке 6. Это пакет Socks5 длиной 0xA байтов. "05 01 00 01" - это заголовок его протокола Socks5, а остальные данные - это IP-адрес и порт в двоичном формате. Пакет указывает, что он просит "obfs4proxy.exe" установить соединение с мостом с двоичным IP-адресом и портом. Затем "obfs4proxy.exe" анализирует пакет и преобразует двоичный IP-адрес и порт в строку, которая в данном случае — "154.35.22.13:16815".
Переход в Tor.exe
"Tor.exe" использует сторонний модуль с именем "libevent.dll" из libevent (библиотеки уведомлений о событиях), чтобы заставить Tor выполнять свои задачи. Tor помещает большинство своих задач сокетов (connect(), send(), recv() и т.д.) на события, которые будут автоматически вызываться libevent. При отслеживании пакета с IP-адресом и портом моста в "Tor.exe" вы можете увидеть в контексте стека вызовов, что многие адреса возврата находятся в модуле "libevent.dll". На рисунке 7 отладчик приостановил работу Tor.exe, вызвав API ws2_32.send(), чтобы отправить пакет, содержащий IP-адрес и порт моста, точно так же, как полученный пакет, показанный на рисунке 6.
На рисунке 7 показано окно "Стек вызовов", в котором показаны адреса возврата "libevent.dll".
Посредством трасировки/отслеживания "tor.exe", отправляющего IP-адрес и порт моста, я нашел место, где он запускает новое событие с функцией обратного вызова, которая затем отправляет IP-адрес и порт моста. Приведенный ниже фрагмент кода ASM показывает контекст вызова libevent.event_new() в tor.exe. Второй аргумент - дескриптор сокета; его третий аргумент - это действие при событии, которое здесь 14H, что означает EV_WRITE и EV_PERSIST; его четвертый аргумент - функция обратного вызова (в данном случае sub_2833EE); а его пятый аргумент содержит IP-адрес и порт моста, которые будут переданы функции обратного вызова (sub_2833EE) после ее вызова libevent.
Следующий фрагмент кода ASM взят из "tor.exe", чей базовый адрес на этот раз - 00280000h.
Путем непрерывной обратной трассировки в "tor.exe" я обнаружил группу мостов Obfs4, которые находятся в структуре данных команды "SETCONF", как показано на рисунке 8.
Это фрагмент данных команды "SETCONF", где "SETCONF" - это имя команды в начале структуры, за которым следует информация о встроенных мостах. Данные в красных линиях - это один блок Obfs4 Bridge, называемый линией конфигурации моста. Каждый узел моста должен быть сохранен в одной строке конфигурации моста. Всего таких линий конфигурации моста здесь 27. Как видите, тип моста "obfs4", а также IP-адрес моста и порт внутри него имеют строковый формат.
Информация о мосте также не запрограммирована жестко внутри процесса "tor.exe". Теперь мы сталкиваемся с другим вопросом: откуда берутся все данные SETCONF? Фактически, это полученный TCP-пакет от "firefox.exe", который является родительским процессом "tor.exe". После запуска tor.exe открывает порт управления TCP 9151 для получения команд от firefox.exe и порта прокси TCP 9150. Я объясню, как firefox.exe отправляет ему команды позже.
Продолжая анализ в "tor.exe", я заметил, что помимо команды "SETCONF", он также поддерживает другие команды, такие как "GETCONF", "SAVECONF", "GETINFO", "AUTHENTICATE", "SETEVENTS", "+LOADCONF", "QUIT" и так далее. "Tor.exe" имеет функцию для обработки этих команд и выполнения различных ветвей кода.
"Tor.exe" выполняет множество различных задач в соответствии с этими командами. Например: команда "SAVECONF" указывает "tor.exe" сохранить информацию о мосте в файл, расположенный в "Папка_установки Tor\Browser\TorBrowser\Tor\Data\torrc"; а "SETCONF" сообщает "tor.exe" информацию о мосте, которая затем передается процессам моста для установления мостовых соединений.
Поиск встроенных мостов Tor в Firefox.exe
Tor использует множество петлевых TCP-соединений для передачи команд между процессами для выполнения своих задач.
Wireshark начал поддерживать локальный адаптер обратной петли в версии 3.0.1, позволяя захватывать трафик на интерфейсе обратной петли, например пакет "SETCONF" от "firefox.exe" к "tor.exe" через порт управления TCP 9151 на локальном петлевом интерфейсе. RawCap - еще один инструмент, который может делать то же самое. "Firefox.exe" отправляет пакет команд в "tor.exe" особым образом: один байт - один пакет. Как вы можете видеть на рисунке 9, существует много пакетов длиной 1. Их повторное ассемблирование дает полную команду "SETCONF".
До версии 9.0 в Tor Browser было два расширения: Torbutton и TorLauncher. Они находятся в папке "Папка_установки Tor\Browser\TorBrowser\Data\Browser\profile.default\extensions". Соответствующие файлы расширения - torbutton@torproject.org.xpi и tor-launcher@torproject.org.xpi, как показано на рисунке 10, которые представляют собой Zip-архивы, содержащие файлы и модули JS.
Однако, начиная с версии 9.0 браузера Tor, эти два расширения были удалены. Вместо этого их код и функции были включены в браузер Tor. Обратитесь к Приложению для получения дополнительной информации.
Torbutton используется для установки и отображения настроек Tor, а также для отображения информации Tor, такой как "О Tor". Вы можете найти его, щелкнув значок Tor на панели инструментов браузера Tor (см. Рисунок 3).
TorLauncher отвечает за управление процессом Tor в соответствии с настройками, установленными через Torbutton.
TorLauncher загружается, и его JS-код выполняется в модуле "xul.dll" Firefox, который является основным компонентом Mozilla Firefox, а также реальным модулем, отправляющим команды "tor.exe", например «SETCONF» ( реализовано в network-setting.js), "GETCONF" (tl-protocol.js) и "GETINFO" (tl-protocol.js, torbutton.js). Модуль "xul.dll" представляет собой своего рода JS-движок для анализа и выполнения JS-кода этих команд.
Теперь давайте посмотрим на внутренний рабочий механизм Tor Browser с включенными мостами. После запуска Tor Browser с включенными мостами он выполняет следующие шаги:
- firefox.exe загружает основные профили, определение предпочтений и расширения [задействованные модули: firefox.exe, xul.dll]
- Расширение TorLauncher запускает tor.exe с настройками в командной строке [задействованный модуль: xul.dll)
- В любое время Вы можете изменить настройки Tor с помощью Torbutton [задействованный модуль: xul.dll]
- Он отправляет команды в "tor.exe" и сообщает ему, как работать, на основе настроек, предоставленных через локальные петлевые TCP-соединения [задействованные модули: xul.dll, tor.exe]
- tor.exe затем запускает один соответствующий процесс моста (obfs4proxy.exe для "obfs3" и "obfs4", fteproxy.exe для "fte" и terminateprocess-buffer.exe для "meek-azure") для установления мостовой связи [задействовано модули: tor.exe, мостовые процессы]
- tor.exe взаимодействует с этими мостовыми процессами через локальные петлевые TCP-соединения. [задействованный модуль: tor.exe, мостовые процессы]
- Процессы моста подключаются к релею моста [задействованный модуль: процессы моста]
Браузер Tor отправляет команды через локальный интерфейс обратной связи для управления работой клиента Tor. Затем он получает и анализирует результаты команд от клиента Tor.
Согласно моему анализу, вся информация о мосте "obfs4" определена в ряде именованных глобальных переменных, называемых настройками в Firefox, и хранится в локальном файле. Они инициализируются при запуске "ofirefox.exe", и к ним обращаются и используются в TorLauncher путем считывания настроек по их именам, производным от "oxul.dll".
В целях безопасности я скрыл имя файла, который содержит весь набор определений информации о мостах для всех типов мостов. В анализируемой мной версии браузера Tor она включает 27 мостов "obfs4", 4 моста "obfs3", 1 мост meek-azure и 4 моста "fte".
Подключаемый транспорт
В приведенном выше анализе мы упомянули типы мостов: "obfs4", "obfs3", "meek-azure" и "fte". Все они называются подключаемым транспортом (ПТ). Их основная задача - преобразовать трафик Tor и передать его между клиентом и его первым переходом (ретранслятор Tor). Таким образом, использование PT может затруднить идентификацию и блокировку трафика Tor с помощью цензуры.
Obfs4 - более сильный и популярный ПТ. Первый переход Obfs4 обычно представляет собой реле-мост, который не указан в главном каталоге Tor. Обфускатор Obfs4 был разработан и поддерживается Yawning Angel. Это проект с открытым исходным кодом, написанный на языке Go, к которому вы можете получить доступ на GitHub. Раньше у Obfs Bridges было несколько версий, таких как Obfs2 и Obfs3. Obfs4 не сильно на них похож, но ближе к ScrambleSuit, потому что концепция Obfs4 взята из протокола ScrambleSuit Филиппа Винтера. Вот почему клиентский процесс Obfs4 также может выступать в роли клиента ScrambleSuit.
Все возможности Obfs4 предоставляются программой "obfs4proxy.exe", которая является клиентским процессом Obfs4 для пользователей Tor.
Как мы уже знаем, браузер Tor построен на базе браузера Firefox и использует расширения Firefox для предоставления пользователям анонимного доступа в Интернет. После запуска браузера Tor он фактически запускает "firefox.exe", который загружает два расширения Tor (TorLauncher и Torbutton). Позже одно из расширений Tor запускает tor.exe, то есть клиентский процесс Tor. Когда браузер Tor настроен на включение моста Obfs4 в "Сетевых настройках Tor", "tor.exe" запустит "obfs4proxy.exe".
Как браузер Tor взаимодействует с клиентом Tor
Процессы firefox.exe (браузер Tor) и tor.exe (клиент Tor) взаимодействуют друг с другом через TCP-порт Tor, прослушивая интерфейс обратной связи (127.0.0.1).
Из рисунка 4 выше видно, что "firefox.exe" запускает "tor.exe". Чтобы быть более конкретным, "tor.exe" запускается расширением Firefox "TorLauncher", которое загружается и анализируется модулем "xul.dll"». Когда он вызывает собственный API Windows ShellExecuteExW() для запуска tor.exe, многие параметры командной строки передаются в tor.exe. На рисунке 11 показан снимок экрана с параметрами командной строки, переданными в "tor.exe", когда "firefox.exe" собирался запустить "tor.exe".
В "tor.exe" передается 10 параметров. Для наглядности я разделил их на таблицу ниже, по одному параметру в одной строке. В таблице 1 "… \" - это сокращение от пути установки браузера Tor.
В таблице 1 выделено два порта: "+__ControlPort 9151" и "+__SocksPort» 127.0.0.1:9150 IPv6Traffic PreferIPv6 KeepAliveIsolateSOCKSAuth". "Tor.exe" будет прослушивать эти два TCP-порта 9151 и 9150 интерфейса обратной связи (127.0.0.1), которые являются номерами портов по умолчанию, которые использует "tor.exe".
Пользователи могут изменять значения по умолчанию для двух портов, которые определены в нескольких локальных файлах. Вот пример кода в локальном файле.
// Proxy and proxy security
pref("network.proxy.socks", "127.0.0.1");
pref("network.proxy.socks_port", 9150);
TCP-порт 9151 - это порт управления, используемый для обмена управляющими командами и результатами между "firefox.exe" и "tor.exe". Tor предоставляет прокси-сервис SOCKS5 на TCP-порту 9150, который используется для передачи пакетов SOCKS5 между firefox.exe и tor.exe.
Ниже приведен пример управляющей команды. "Firefox.exe" отправил команду "GETINFO" в "tor.exe" через TCP-порт 9151 и запросил некоторую информацию, затем "tor.exe" проанализировал команду и отправил результат обратно в "firefox.exe" с TCP-порта 9151.
GETINFO status/bootstrap-phase
250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=0 TAG=starting SUMMARY="Starting"
250 OK
Tor выполняет функции прокси на 127.0.0.1:9150, который передает обычные пакеты (незашифрованные Tor) между firefox.exe и tor.exe. На рисунке 12 показан снимок экрана с захватом пакетов в WireShark, где я разделил их на две части: верхняя часть - это рукопожатие Tor SOCKS5, нижняя - транспортировка пакетов.
На рисунке 12 показаны пакеты при посещении https://www.google.com в Tor Brower. В части установления связи "firefox.exe" сообщает "tor.exe", что адресатом доступа является "www.google.com" в пакете SOCKS5. После того, как рукопожатие SOCKS5 завершено, firefox.exe начинает посылать пакет приветствия клиента Google TLS в tor.exe, где этот пакет зашифровывается в клиенте Tor. Кроме того, клиент Tor отправляет обратно пакет Google TLS Server Hello. С этого момента firefox.exe начинает отправлять пакеты запросов и получать пакеты ответов от tor.exe через TCP-порт 9150.
На стороне клиента Tor он принимает пакеты через TCP-порт 9150 и завершает квитирование SOCKS5. Затем он получает обычные пакеты от "firefox.exe", которые затем шифруются. Пакеты, зашифрованные Tor, передаются входному релею Tor в выбранной цепочки Tor. Наконец, выходной релей Tor расшифровывает полученные пакеты, чтобы получить обычные пакеты, как показано между "firefox.exe" и "tor.exe", которые затем будут отправлены на целевой сервер (например, www.google.com).
В обратном направлении "tor.exe" получает зашифрованные пакеты от входного ретранслятора Tor, а затем расшифровывает их, чтобы получить пакеты с открытым текстом, которые в конечном итоге отправляются в "firefox.exe" из "tor.exe" через TCP-порт 9150, как показано ранее на рисунке 7.
Как клиент Tor взаимодействует с клиентом Obfs4
Клиент Tor ("tor.exe") запускает клиент Obfs4 "bfs4proxy.exe", как только клиент Tor получает команду "SETCONF" от браузера Tor. "Obfs4proxy.exe" открывает случайный TCP-порт на интерфейсе обратной связи для предоставления службы моста Obfs4 для Tor. Он уведомляет свой родительский процесс "tor.exe" о номере порта TCP через межпроцессный пайп.
На рисунке 13 приведен снимок экрана OllyDbg, показывающий, что точка останова в Windows API WriteFile() сработала, когда "obfs4proxy.exe" собирался сообщить "tor.exe" о своем TCP-порте. Как вы можете видеть в памяти, "CMETHOD obfs4 socks5 127.0.0.1:49496" - это данные с TCP-портом, отправляемые клиенту Tor.На этот раз случайный TCP-порт — 49496. Первый аргумент WriteFile() - дескриптор файла межпроцессного пайп, на этот раз 00000100.
После этого "tor.exe" может установить соединение с этим TCP-портом для связи с клиентом Obfs4. Tor отдельно отправляет узлы моста на этот порт, один мост за раз. На снимке экрана TCPView на рисунке 14 вы можете ясно видеть, что "tor.exe" отправляет мосты на "obfs4proxy.exe" отдельно.
Это весь процесс взаимодействия браузера Tor ("firefox.exe") с клиентом Obfs4 ("obfs4proxy.exe") через клиент Tor ("tor.exe"). В следующеq статье мы объясним, как клиент Obfs4 ("obfs4proxy.exe") устанавливает соединение с мостом Obfs4 и как Obfs4 преобразует пакеты для обхода цензуры.
Браузер Tor версии 9.0
В конце октября 2019 года был выпущен браузер Tor версии 9.0, в котором были удалены два расширения (TorLauncher и Torbutton). Без них браузер Tor теперь выполняет задачи, которые эти два расширения выполняли ранее. Фактически, в ходе своего анализа я обнаружил, что новая версия не удаляла код двух расширений, а вместо этого интегрировала их код в файл Firefox JAR под названием "omin.ja". Этот файл загружается и анализируется Firefox при запуске. После этого вы можете найти настройки сети Tor, используя меню “Options”-> “Tor”, как показано на Рисунке 15 ниже.
Это изменение в новой версии не влияет на рабочий механизм Tor Browser, поэтому этот анализ все еще действителен, даже если он был основан на старой версии 8.0.
Переведено специально для xss.pro
Автор перевода: yashechka
Источник: https://www.fortinet.com/blog/threat-research/dissecting-tor-bridges-pluggable-transport
