техника на атака (CVE-2019-14899), позволяваща замяна, изменение или подмяна на пакети в TCP-соединения, преминаващи през VPN тунели. Проблемата засяга Linux, FreeBSD, OpenBSD, Android, macOS, iOS и други Unix-подобни системи. Linux поддържа механизма rp_filter (филтриране на обратен път) за IPv4, като включването му в режим „Ситен“ неутрализира този проблем.
Методът позволява подмяна на пакети на ниво TCP-съединения, преминаващи в рамките на криптиран тунел, но не позволява вмешателство в съединения, прилагащи допълнителни слоеве на криптиране (например, TLS, HTTPS, SSH). Приложените в VPN алгоритми на криптиране нямат значение, тъй като фалшивите пакети постъпват от външния интерфейс, а се обработват от ядрото като пакети от VPN интерфейса. Най-вероятната цел на атаката е намеса в нешифрованите HTTP съединения, но и използване на атаката за манипулиране на DNS отговори.
Успешната подмяна на пакети е демонстрирана за тунели, създадени с помощта на OpenVPN, WireGuard и IKEv2/IPSec. Tor не е подложен на проблема, тъй като използва SOCKS за пренасочване на трафик и свързване с loopback интерфейса. За IPv4 атаката е възможна в случай на превключване на rp_filter в режим „Разхлабен“ (sysctl net.ipv4.conf.all.rp_filter = 2). Първоначално в повечето системи е приложен режим „Ситен“, но от , издаден през декември миналата година, режимът по подразбиране беше заменен на „Разхлабен“ и това изменение се отрази на настройките по подразбиране на много дистрибуции на Linux.
Механизмът rp_filter за допълнителна проверка на пътищата на преминаващите пакети, за да се предотврати спуфингът на изходния адрес. При настройка на 0 проверката на изходния адрес не се извършва и всеки пакет може без ограничения да бъде пренасочван между мрежовите интерфейси. Режим 1 „Ситен“ включва проверка на всеки входящ пакет от външната страна за съответствие с таблицата за маршрутизация, и ако мрежовият интерфейс, през който е получен пакетът, не е свързан с оптимален маршрут за доставка на отговора, пакетът се отхвърля. Режим 2 „Разхлабен“ облекчава проверката, за да позволи работата при прилагане на балансировачи на натоварването или асиметрична маршрутизация, при която
маршрутът на отговора може да преминава не през този мрежов интерфейс, през който е постъпил входящият пакет.
В режим «Loose» входящият пакет се проверява за съответствие с таблицата за маршрутизация, но се счита за допустим, ако адресът на източника е достижим чрез всеки наличен мрежови интерфейс. Предложената атака предполага, че атакуващият може да изпрати пакет с подменен адрес на източника, съответстващ на интерфейса VPN, и въпреки че този пакет ще влезе в системата през външен мрежови интерфейс, а не през VPN, в режим rp_filter «Loose» такъв пакет няма да бъде отхвърлен.
За да осъществи атаката, злонамереният потребител трябва да контролира шлюза, през който потребителят излиза в мрежата (например, чрез организация MITM, когато жертвата е свързана с контролиран от атакуващия безжичен достъп или чрез ). Контролирайки шлюза, през който потребителят е свързан към мрежата, атакуващият може да изпраща фалшиви пакети, които ще бъдат възприемани в контекста на мрежовия интерфейс VPN, но отговорите ще се изпращат през тунела.
Чрез генериране на поток от фалшиви пакети, в които се вмъква IP адресът на интерфейса VPN, се правят опити да се повлияе на установената от клиента връзка, но влиянието на тези пакети може да се наблюдава само чрез пасивен анализ на шифрования трафик, свързан с работата на тунела. За извършване на атаката е необходимо да се установи IP адресът на тунеловия интерфейс, назначен от VPN сървъра, а също така да се определи, че в момента през тунела е активна връзка към определен хост.
За определяне на 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 в режим „Строг“ („sysctl net.ipv4.conf.all.rp_filter = 1“). От страна на VPN, методът за определяне на номера на последователността може да бъде блокиран чрез добавяне на запълващи пакети към криптираните пакети, така че размерът на всички пакети да е еднакъв.
Източник: opennet.ru
