Група изследователи от канадски и американски университети разработиха техника на атаката Port Shadow, която позволява чрез манипулация с таблиците за транслация на адреси на страната на VPN-сервера да се постигне изпращане на отговор на запитване до друг потребител, свързан с един и същи VPN-сервер. Методът може да бъде използван за организиране на прихващане или пренасочване на криптиран трафик, провеждане на сканиране на портове и деанонимизиране на VPN потребители. Като пример е показано как може да се използва методът за пренасочване на хост на атакуващия DNS-запитвания на потребителя, работещ през VPN-сервера, към който атакуващият има възможност да се свърже като клиент.
За извършването на атаката, извършителят трябва да има възможност за свързване с един VPN-сървър с жертвата, което е възможно, например, при използване на типични VPN оператори и публични VPN услуги, предоставящи достъп на всички желаещи. Уязвимостта засяга VPN сървъри, които използват транслация на адреси (NAT) за организиране на обръщения на клиентите към външни ресурси, при условие че за приемането на трафик от клиентите и изпращането на запитвания към външни сайтове трябва да се използва един и същи IP адрес. сървър Атаката се основава на факта, че чрез изпращане на специално оформени запитвания, атакуващият, свързан с един и същи VPN сървър и използващ общ NAT, може да постигне изкривяване на съдържанието на таблиците за транслация на адреси, което ще доведе до това, че пакети, адресирани до един потребител, ще бъдат насочени към друг. В таблиците за транслация на адреси информацията за това, с кой вътрешен IP адрес е свързано изпратеното запитване, се определя на база номера на изходния мрежов порт, използван при изпращането на запитването. Атакуващият чрез изпращане на определени SYN и ACK пакети и едновременно манипулиране от страна на клиентската връзка към VPN сървъра и от страна на контролирането на атакуващия външен сървър може да постигне възникването на колизия в таблицата NAT и добавянето на запис с един и същи номер на изходния порт, но асоцииран с неговия локален адрес, което ще доведе до това, че отговорите на чуждо запитване ще бъдат върнати на адреса на атакуващия.
Атаката е основана на изпращането на специално оформени заявки, при което атакуващият, свързан към същия VPN сървър и използващ общ NAT, може да причини изкривяване на съдържанието на таблиците за адресно преобразуване. Това може да доведе до ситуация, в която пакети, адресирани до един потребител, бъдат насочени към друг потребител. В таблиците за адресно преобразуване информацията за това с кой вътрешен IP адрес е свързан изпратеният запитване, се определя на базата на номера на изходящия мрежови порт, използван при изпращането на запитването. Атакуващият, чрез изпращане на определени SYN и ACK пакети и едновременни манипулации на клиентската връзка към VPN сървъра и на контролиран от атакуващия външен сървър, може да предизвика колизия в NAT таблицата и добавяне на запис с идентичен номер на изходящия порт, но асоцииран с неговия локален адрес, което ще доведе до това, че отговорите на чуждото запитване ще бъдат върнати на адреса на атакуващия.
В хода на изследването бяха тествани системи за транслация на адреси Linux и FreeBSD в комбинация с VPN OpenVPN, OpenConnect и WireGuard. Платформата FreeBSD се оказа устойчива на методите на атака за пренасочване на заявки, извършвани от други потребители, свързани с един и същ VPN. Подмяната в таблиците NAT успя да бъде осъществена само в хода на атаката ATIP (Adjacent-to-In-Path), при която атакуващият може да се вмъкне в трафика между потребителя и VPN-сервера (например, когато потребителят се свързва с контролирана от атакуващия Wi-Fi мрежа) или между VPN-сервера и целевия сайт. При това NAT на FreeBSD също бе засегнато от атака, която позволява да се установи фактът на свързването на потребителя с определен сайт (Connection Inference).
Що се отнася до Linux, подистемата Netfilter се оказа подложена на атаки за подмяна на записи в таблицата за транслация на адреси, позволяващи пренасочване на входящите пакети към друг потребител, изпращане на пакети извън шифрованата VPN-тунел (Decapsulation) или откриване на отворени мрежови портове на клиентската страна.
Като мерки за блокиране на атаката, на VPN предоставителите се препоръчва да използват адекватни методи за рандомизиране на номерата на изходните портове в NAT, да ограничат броя на допустимите едновременни връзки към VPN-съвета от един потребител, а също така да блокират възможността за избиране от клиентската страна на мрежовия порт, който приема заявки на VPN-сервера.
Според представител на компания Proton AG, атаката не засяга VPN услуги, използващи отделни IP адреси за входящи и изходящи заявки. Освен това, има съмнения относно възможността за прилагане на атаката спрямо реални VPN услуги, тъй като успешната атака досега е демонстрирана само в лабораторни тестове и за нейното провеждане са необходими определени условия на VPN-сервера и атакувания клиент. Освен това, атаката може да бъде полезна само за манипулации с нешифровани заявки, като например запитвания към DNS, докато използването на TLS и HTTPS на ниво приложения прави пренасочването на трафика безполезно.
Манипулациите с таблиците за транслация на адреси са приложими не само за VPN, но и за безжични мрежи, в които за организиране на свързването на потребителите с външни ресурси на точка за достъп се използва NAT. През миналия месец бяха публикувани резултати от проучване за възможността за провеждане на подобна атака за прихващане на TCP-съединения на други потребители в безжичната мрежа. Методът на атака се оказа приложим за 24 от 33 тествани безжични точки за достъп.
Предложената атака за Wi-Fi се оказа значително по-лесна от споменатия по-горе метод за VPN, тъй като поради оптимизации много точки за достъп не проверяват коректността на номерата на последователностите в TCP-пакетите. В резултат на това, за атака беше достатъчно да се изпрати фалшив RST-пакет, за да се изчисти записа в таблицата за транслация на адреси, а след това да се постигне насочване на отговора към хоста на атакуващия за определяне на номерата на последователност (SEQ) и потвърждение (ACK), нужни за прихващане на TCP-съединението.
Източник: opennet.ru
