http://habrahabr.ru/company/mailru/blog/232563/



Тайминг-атаки являются известным слабым местом сети Tor и неоднократно обсуждались, в том числе на Хабре, где можно найти порядка 10 статей, так или иначе затрагивающих эту тему. Зачем нужна еще одна? Существует достаточно распространенное заблуждение, что подобные атаки всегда требуют статистического анализа и достаточно сложны в реализации. Ранее опубликованные статьи относятся именно к такому классу атак. Мы рассмотрим вполне реалистичный сценарий, в котором достаточно единственного запроса для деанонимизации пользователя сети.

Поскольку вопрос возможности деанонимизации пользователей Tor в очередной раз активно обсуждается в рунете, я публикую «печатную» версию фрагмента своей презентации с PHDays 2014. Приведенная ниже атака не специфична для Tor и может быть использована против любых low latency средств сокрытия источника трафика – VPN, цепочки прокси и даже их комбинации.

Мы рассмотрим сценарий, для реализации которого в Tor требуется соблюдение двух условий:

1. Иметь возможность вмешиваться в трафик между exit node и узлом назначения. Это можно сделать, имея доступ к конечному серверу, exit node или любой точке прохождения трафика между ними. То есть фактически это условие может выполнить любой желающий, организовав собственные exit node в достаточном количестве.
2. Иметь пассивный доступ к трафику между клиентом сети и entry node.

Причем здесь спецслужбы? Оборудование СОРМ, установленное у любого российского провайдера, как правило полностью пассивно, и умеет обнаруживать, протоколировать и интерпретировать (например, восстанавливать переписку в мессенджерах) трафик, обладающий заданными характеристиками. Отследить присутствие этого оборудования «со стороны» практически невозможно, так как оно не генерирует никакого собственного трафика и никак не влияет на прослушиваемый.

Наличие у атакующего доступа к оборудованию СОРМ вполне удовлетворяет второму из условий атаки. А значит у спецслужб, имеющих доступ к оборудованию и способных организовать некое количество exit node в Tor, есть все, что требуется, включая желание заниматься этим вопросом.

Принцип атаки

Со стороны exit node в трафик вносятся предопределенные изменения, не меняющие передаваемые данные, но затрагивающие «форму» трафика – меняются размеры проходящих пакетов и задержки между ними. Временные характеристики в low latency сетях меняются не значительно, этот факт обычно используется в timing-атаках. Размеры пакетов меняются достаточно прогнозируемым образом, как это будет продемонстрировано. Это значит, что переразбив трафик на пакеты определенной последовательности размеров с определенной последовательностью задержек можно со стороны exit node промаркировать трафик таким образом, что на стороне entry node эта маркировка может быть обнаружена, таким образом может быть сопоставлено соединение или запрос к серверу с пользователем Tor.

Более того, в этом трафике можно передать информацию для прослушивающей стороны, например, уникальный идентификатор клиентского запроса. То есть, при наличии 2 различимых вариантов размера пакета и 2 различимых вариантов временных задержек, можно скрытно от пользователя передать стороне, прослушивающей шифрованный трафик между пользователем и entry node, 2 бита информации каждым пакетом данных, начиная со второго. В действительности, различимых состояний можно ввести больше, но есть и дополнительные ограничения, которые мы рассмотрим ниже.

Насколько сложно это реализуется и как выглядит на практике?

Я реализовал атаку путем перенаправления трафика exit node в прокси-сервер, в который были внесены небольшие правки для организации шейпинга трафика по заранее определенному шаблону.

Как выглядит «обычный» трафик в Tor? Это фрагмент трафика от entry node к клиенту связанный с передачей результатов HTTP-запроса без внесения в трафик каких-либо маркировок:



Идет TLS-трафик, внутри которого содержатся блобы (пакеты) информации, преимущественно размером 3648 октетов. На уровене TCP они разбиваются на IP-пакеты размером преимущественно 1414 октетов, что связано с Path MTU. TCP-пакет может содержать как фрагмент одного блоба, так и конец одного блоба и начало следующего. Однако, встречаются и блобы размером 560 октетов и TCP-пакеты меньшего размера. Разбиение исходных данных на блобы и разбиение блобов по TCP-пакетам зависит от разных параметров — таймингов серверов, размеров буфера, которыми он передает данные, задержкам сети. При повторном запросе рисунок может быть немного другой. Однако статистически один и тот же запрос к одному и тому же серверу будет иметь достаточно четкую картину. Поскольку при загрузке одной и той же web-страницы происходит достаточно большое количество запросов с передачей, как правило, одних и тех же запросов и ответов, то есть типичных объемов информации с типичными задержками, то сопоставлением данных можно попытаться обнаружить к какому именно ресурсу обращается пользователь, особенно если он посещает его регулярно. На этом основаны классические тайминг-атаки.

Но мы идем другим путем. Вместо пассивного измерения тайминга, в исходный трафик со стороны exit node вносим шейпинговую маркировку (maRk). Чистый нешифрованный трафик, пущенный мимо Tor, теперь выглядит следующим образом:



Как происходит маркировка? Передаем маленькие пакеты двух разных размеров. Различие в размерах в несколько сот байт в данном случае ни на что не влияет, но позволяет визуально различить два разных типа пакетов в серии. Задержки между двумя типами пакетов 60 и 110 миллисекунд, они подобраны так, чтобы показать наиболее интересную картинку на выходе.

Когда тот же трафик проходит через Tor, между entry node и пользователем он выглядит следующим образом:



Что мы теперь видим. Все блобы в TLS теперь имеют размер 560 октетов (а значит мы умеем управлять размером, 3648 или 560 октетов за счет отправки больших или маленьких порций трафика). Кстати, в этом месте наблюдается проблема амплификации трафика — минимальный пакет данных увеличивается более чем в 10 раз. Каждый отправленный нами пакет приходит отдельным блобом в TLS. При этом IP-пакет размером 1414 октетов содержит два полных блоба и начало третьего, пакет 389 октетов — конец третьего блоба и пакет в 619 октетов — отдельный четвертый блоб. То есть 4 IP-пакета исходного трафика приходят в 3 IP-пакетах в трафике Tor. Хорошо это или плохо? Плохо, так как мы потеряли часть информации о таймингах.

Что случилось и почему такая странная последовательность: это вызвано особенностями работы TCP-стека, а именно совместной работой алгоритма Нагла и TCP delayed acknowledgements. Однако между группами пакетов и между пакетами в группе интервал остается неизменным, то есть как минимум половину информации по таймингам мы получаем. Чтобы «побороть» ожидание и группировку в алгоритме Нагла, можно отправить количество трафика такое, чтобы передаваемые блобы превысили размер MTU (но недостаточное для формирования «большого» блоба в 3648 байт).

Если сравнить третью картинку с первой, то понятно, что в трафик вносится достаточно четкая и легко детектируемая аномалия, которая позволяет следящему оборудованию «сработать» при ее обнаружении. Причем в случае СОРМ детектируемость этой аномалии достаточна для доказательной базы.

Данная атака может применяться к практически любому шифрованному или нешифрованному соединению, как по направлению от сервера к клиенту, так и в обратном.

Какие есть ограничения?

«Нелинейное» поведение трафика из-за алгоритма Нагла может приводить к потере части информации о таймингах, однако, эту потерю можно обнаружить на принимающей стороне и компенсировать избыточностью передаваемой информации. Для того, чтобы трафик можно было шейпить, он должен быть достаточным. Казалось бы, сложно промаркировать таким образом, например, ssh-соединение с запущенным bash’ем и периодически выдаваемыми командами, так как в нем не передается достаточно данных, чтобы сформировать пакеты с нужными maRk-сигнатурами.

На самом деле, промаркировать можно даже соединение, в котором данные совсем не передавалось. Дело в том, что даже после того, как клиентское приложение инициировало закрытие TCP-соединения, данные, отправленные через Tor в сторону клиента, будут продолжать доставляться. Это дает возможность после получения FIN+ACK в соединении со стороны клиента отправить в его сторону промаркированную порцию случайных данных. Эти данные никогда не будут считаны клиентским приложением, но они все равно дойдут до клиента и таким образом раскроют его. То есть атака может быть проведена полностью скрытно от клиента и объем информации, которым можно промаркировать соединение, более чем достаточен. Аналогичный способ можно применить и в большинстве VPN, но, к счастью, он не сработает с прокси и другими прикладными шлюзами.

Есть ли надежное решение?

Атаку может быть сложнее провести при активной работе клиента, так как необходимо детектировать пакеты, относящиеся к одной цепочке, посторонний трафик зашумляет сигнатуру. Можно так же взять на себя роль relay в сети Tor, что затруднит обнаружение маркированного трафика. Есть несколько способов дополнительно усложнить атаку: комбинация Tor, VPN и цепочки прокси затрудняет угадывание финальной формы трафика и частично устраняет атаку через полузакрытое соединение. Можно усложнить обнаружение испортив известные сигнатуры нестандартными параметрами TCP-стека. Но надежного способа полностью устранить подобные угрозы в рамках Tor или распространенных VPN-сетей нет. Атаки шейпинга, как разновидность тайминг-атак находятся за пределами их профиля защиты.

Единственное надежное решение – использовать внутри шифрованного соединения виртуальный линк, в котором идет постоянный поток ячеек фиксированной длины с фиксированной пропускной способностью. Так работают, например, сети ATM (Asynchronous Transfer Mode). Причем шифрование должно проводиться без сжатия данных, то есть потребляемая полоса трафика должна быть неизменной. Такие технологии не могут пока широко использоваться для повседневной работы, так как слишком высоки дополнительные расходы на канал, который активно используется даже в момент простоя.