Опубликована техника атаки (CVE-2019-14899), позволяющая подменить, изменить или подставить пакеты в TCP-соединения, пробрасываемые через VPN-туннели. Проблема затрагивает Linux, FreeBSD, OpenBSD, Android, macOS, iOS и другие Unix-подобные системы, поддерживающие технику защиты от спуфинга rp_filter (reverse path filtering) для IPv4. Для IPv6 атака может быть совершена независимо от применения rp_filter.
Метод позволяет осуществить подстановку пакетов на уровне TCP-соединений, проходящих внутри шифрованного туннеля, но не позволяет вклиниваться в соединения, применяющие дополнительные слои шифрования (например, TLS, HTTPS, SSH). Наиболее вероятной целью атаки является вмешательство в незашифрованные соединения 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, при подключении жертвы к контролируемой атакующим точке беспроводного доступа или через взлом маршрутизатора). В ходе атаки, путём генерации потока фиктивных пакетов, в которых подставляется 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
Для защиты при использовании туннелей с адресами IPv4 достаточно перевести rp_filter в режим "Strict" ("sysctl net.ipv4.conf.all.rp_filter = 1"). Со стороны VPN метод определения номера последовательности может быть блокирован путём добавления к зашифрованным пакетам добавочного заполнения, делающего размер всех пакетов одинаковым.
Источник: https://www.opennet.ru/opennews/art.shtml?num=51986
