техника на атака (CVE-2019-14899), позволяваща подменяне, променяне или подставяне на пакети в TCP-съединения, пробивани през VPN тунели. Проблемата засяга Linux, FreeBSD, OpenBSD, Android, macOS, iOS и други Unix-подобни системи. Linux поддържа механизъм rp_filter (обратна филтрация на пътищата) за 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“, но от , издаден през декември миналата година, режимът на работа по подразбиране беше заменен на „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 адреси/портове на източника и целта), но за да генерира фалшив пакет, който да възприеме системата на жертвата, атакуващият трябва да определи номерата на последователността и потвърждението (seq и ack) на TCP връзката. За да определи тези параметри, атакуващият непрекъснато изпраща фалшиви RST пакети, проверявайки различни номера на последователността, докато не улови отговорен ACK пакет, чието получаване показва, че номерът попада в TCP прозореца.
След това атакуващият уточнява точността на определянето, като изпраща пакети със същия номер и наблюдава получаването на ACK-отговори, след което подбира точния номер на текущата последователност. Задачата е усложнена, тъй като отговорите се изпращат в шифрован тунел и анализирането им в перехващания трафик може да стане само косвено. Фактът на изпращането на адресиран ACK пакет към VPN сървъра от клиента се определя на основата на размера и закъснението на шифрованите отговори, корелиращи с изпращането на фалшиви пакети. Например, за 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 методът за определяне на номера на последователността може да бъде блокиран, като се добави допълнително запълване към криптираните пакети, правещо размера на всички пакети еднакъв.
Източник: opennet.ru
