Уязвимость, позволяющая вклиниваться в TCP-соединения, осуществляемые через VPN-туннели

6 декабря 2019 года

Опубликована техника атаки (CVE-2019-14899), позволяющая подменить, изменить или подставить пакеты в TCP-соединения, пробрасываемые через VPN-туннели. Проблема затрагивает Linux, FreeBSD, OpenBSD, Android, macOS, iOS и другие Unix-подобные системы. Linux поддерживает механизм rp_filter (reverse path filtering) для IPv4, включение которого в режим "Strict" нейтрализует данную проблему.

Метод позволяет осуществить подстановку пакетов на уровне TCP-соединений, проходящих внутри шифрованного туннеля, но не позволяет вклиниваться в соединения, применяющие дополнительные слои шифрования (например, TLS, HTTPS, SSH). Применяемые в VPN алгоритмы шифрования не имеют значения, так как поддельные пакеты поступают из внешнего интерфейса, а обрабатываются ядром как пакеты из VPN-интерфейса. Наиболее вероятной целью атаки является вмешательство в незашифрованные соединения HTTP, но не исключается и использование атаки для манипуляции с ответами DNS.

Успешная подмена пакетов продемонстрирована для туннелей, создаваемых при помощи OpenVPN, WireGuard и IKEv2/IPSec.Tor проблеме не подвержен, так как использует SOCKS для проброса трафика и привязку к loopback-интерфейсу. Для IPv4 атака возможна в случае перевода rp_filter в режим "Loose" (sysctl net.ipv4.conf.all.rp_filter = 2). Изначально в большинстве систем применялся режим "Strict", но начиная с systemd 240, выпущенного в декабре прошлого года, режим работы по умолчанию был заменён на "Loose" и данное изменение отразилось в настройках по умолчанию многих дистрибутивов Linux.

Механизм rp_filter применяется для дополнительной проверки путей прохождения пакетов для предотвращения спуфинга адреса источника. При установке в значение 0 проверка адреса источника не производится и любой пакет может без ограничений перенаправляться между сетевыми интерфейсами. Режим 1 "Strict" включает проверку каждого приходящего извне пакета на соответствие таблице маршрутизации, и если сетевой интерфейс, через который был получен пакет, не связан с оптимальным маршрутом доставки ответа, то пакет отбрасывается. Режим 2 "Loose" смягчает проверку, чтобы допустить работу при применении балансировщиков нагрузки или асимметричной маршрутизации, при которой маршрут ответа может проходить не через тот сетевой интерфейс, через который поступил входящий пакет.

В режиме "Loose" входящий пакет проверяется на соответствие таблице маршрутизации, но считается допустимым, если адрес источника достижим через любой имеющийся сетевой интерфейс. Предложенная атака строится на том, что атакующий может отправить пакет с подменённым адресом источника, соответствующим интерфейсу VPN, и несмотря на то, что данный пакет поступит в систему через внешний сетевой интерфейс, а не через VPN, в режиме rp_filter "Loose" такой пакет не будет отброшен.

Для совершения атаки злоумышленник должен контролировать шлюз, через который пользователь выходит в сеть (например, через организацию MITM, при подключении жертвы к контролируемой атакующим точке беспроводного доступа или через взлом маршрутизатора). Контролируя шлюз, через который подключён к сети пользователь, атакующий может отправлять фиктивные пакеты, которые будут восприниматься в контексте сетевого интерфейса VPN, но ответы будут направляться через туннель.

Путём генерации потока фиктивных пакетов, в которых подставляется IP-адрес интерфейса VPN, осуществляются попытки повлиять на установленное клиентом соединение, но наблюдать за влиянием этих пакетов можно лишь через пассивный анализ за шифрованным потоком трафика, связанным с работой туннеля. Для проведения атаки необходимо узнать назначенный VPN-сервером IP-адрес сетевого интерфейса туннеля, а также определить, что в данный момент через туннель активно соединение к определённому хосту.

Для определения IP виртуального сетевого интерфейса VPN используется отправка на систему жертвы SYN-ACK пакетов, последовательно перебирая весь диапазон виртуальных адресов (в первую очередь перебираются адреса, используемые в VPN по умолчанию, например в OpenVPN используется подсеть 10.8.0.0/24). О существовании адреса можно судить на основе поступления ответа с флагом RST.

Аналогичным образом определяется наличие соединения с определённым сайтом и номер порта на стороне клиента - перебирая номера портов в сторону пользователя отправляется SYN-пакет, в качестве адреса источника, в котором подставлен IP сайта, а адреса назначения виртуальный IP VPN. Серверный порт можно предугадать (80 для HTTP), а номер порта на стороне клиента можно вычислить перебором, анализируя для разных номеров изменение интенсивности ACK-ответов в сочетании с отсутствием пакета с флагом RST.

На данном этапе атакующий знает все четыре элемента соединения (адреса/порт IP источника и адрес/порт IP назначения), но для того, чтобы сгенерировать фиктивный пакет, который воспримет система жертвы, атакующий должен определить номера последовательности и подтверждения (seq и ack) TCP-соединения. Для определения данных параметров атакующий непрерывно отправляет поддельные RST-пакеты, перебирая разные номера последовательности, до тех пор, пока не зафиксирует ответный ACK-пакет, поступление которого указывает, что номер попадает в окно TCP.

Далее атакующий уточняет правильность определения отправкой пакетов с тем же номером и наблюдая за поступлением ACK-ответов, после чего подбирает точный номер текущей последовательности. Задача усложнена тем, что ответы отправляются внутри шифрованного туннеля и анализировать их наличие в перехватываемом потоке трафика можно лишь косвенными методами. Факт отправки адресованного VPN-серверу ACK-пакета клиентом определяется на основе размера и задержки шифрованных ответов, коррелирующих с отправкой поддельных пакетов. Например, для OpenVPN шифрованный пакет с размером 79 позволяет точно судить, что внутри содержится ACK-подтверждение.

До того, как защита от атаки будет добавлена в ядро операционной системы, в качестве временного метода блокирования проблемы рекомендуется при помощи пакетного фильтра в цепочке "preroute" блокировать прохождение пакетов, в которых в качестве адреса назначения указан виртуальный IP-адрес туннеля.


iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP

или для nftables

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority 0; }'
nft add rule ip raw prerouting 'iifname != "wg0" ip daddr 10.182.12.8 fib saddr type != local drop'

Для защиты при использовании туннелей с адресами IPv4 достаточно перевести rp_filter в режим "Strict" ("sysctl net.ipv4.conf.all.rp_filter = 1"). Со стороны VPN метод определения номера последовательности может быть блокирован путём добавления к зашифрованным пакетам добавочного заполнения, делающего размер всех пакетов одинаковым.

Источники

править


 
 
Creative Commons
Эта статья содержит материалы из статьи «Уязвимость, позволяющая вклиниваться в TCP-соединения, осуществляемые через VPN-туннели», опубликованной OpenNET и распространяющейся на условиях лицензии Creative Commons Attribution (CC BY) — указание автора, источник и лицензию.
 
Эта статья загружена автоматически ботом NewsBots в архив и ещё не проверялась редакторами Викиновостей.
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.

Комментарии

Викиновости и Wikimedia Foundation не несут ответственности за любые материалы и точки зрения, находящиеся на странице и в разделе комментариев.