technika ataku (CVE-2019-14899), pozwalająca na podmienianie, modyfikowanie lub wstawianie pakietów w połączenia TCP przechodzące przez tunel VPN. Problem dotyczy systemów Linux, FreeBSD, OpenBSD, Android, macOS, iOS oraz innych systemów podobnych do Unix. Linux wspiera mechanizm rp_filter (reverse path filtering) dla IPv4, którego włączenie w trybie „Strict” neutralizuje ten problem.
Metoda pozwala na podmienianie pakietów na poziomie połączeń TCP, które przechodzą wewnątrz zaszyfrowanego tunelu, ale nie pozwala na ingerencję w połączenia korzystające z dodatkowych warstw szyfrowania (np. TLS, HTTPS, SSH). Stosowane w VPN algorytmy szyfrowania nie mają znaczenia, ponieważ fałszywe pakiety pochodzą z zewnętrznego interfejsu, a są przetwarzane przez jądro jako pakiety z interfejsu VPN. Najbardziej prawdopodobnym celem ataku jest ingerencja w niezaszyfrowane połączenia HTTP, ale i wykorzystanie ataku do manipulacji odpowiedziami DNS.
Udana podmiana pakietów została zademonstrowana dla tuneli tworzonych za pomocą OpenVPN, WireGuard i IKEv2/IPSec. Tor nie jest podatny na ten problem, ponieważ używa SOCKS do przekazywania ruchu oraz wiązania z interfejsem loopback. Dla IPv4 atak jest możliwy w przypadku zmiany rp_filter na tryb „Loose” (sysctl net.ipv4.conf.all.rp_filter = 2). Początkowo w większości systemów stosowano tryb „Strict”, jednak od , wydania w grudniu ubiegłego roku, domyślny tryb pracy został zmieniony na „Loose” i ta zmiana została odzwierciedlona w domyślnych ustawieniach wielu dystrybucji systemu Linux.
Mechanizm rp_filter dla dodatkowej weryfikacji ścieżek przechodzenia pakietów w celu zapobiegania spoofingowi adresu źródła. Ustawiając na wartość 0, sprawdzanie adresu źródła nie jest przeprowadzane i każdy pakiet może być bez ograniczeń przesyłany między interfejsami sieciowymi. Tryb 1 „Strict” włącza sprawdzanie każdego nadchodzącego pakietu spoza sieci w odniesieniu do tabeli routingu, a jeśli interfejs sieciowy, przez który otrzymano pakiet, nie jest związany z optymalną trasą dostarczenia odpowiedzi, pakiet jest odrzucany. Tryb 2 „Loose” łagodzi sprawdzanie, aby umożliwić działanie przy użyciu równoważników obciążenia lub asymetrycznego routingu, przy którym
trasa odpowiedzi może przebiegać nie przez ten interfejs sieciowy, przez który dotarł przychodzący pakiet.
W trybie „Loose” przychodzący pakiet jest sprawdzany pod kątem zgodności z tabelą routingu, ale uznaje się go za dopuszczalny, jeśli adres źródła jest osiągalny przez dowolny dostępny interfejs sieciowy. Proponowany atak opiera się na tym, że atakujący może wysłać pakiet z podmienionym adresem źródła, odpowiadającym interfejsowi VPN, i mimo że pakiet dotrze do systemu przez zewnętrzny interfejs sieciowy, a nie przez VPN, w trybie rp_filter „Loose” taki pakiet nie zostanie odrzucony.
Aby przeprowadzić atak, przestępca musi kontrolować bramę, przez którą użytkownik wychodzi do sieci (na przykład poprzez organizację MITM, podczas gdy ofiara łączy się z kontrolowanym przez atakującego punktem dostępu bezprzewodowego lub przez ). Kontrolując bramę, przez którą użytkownik jest połączony z siecią, atakujący może wysyłać fałszywe pakiety, które będą postrzegane w kontekście interfejsu sieciowego VPN, ale odpowiedzi będą kierowane przez tunel.
Poprzez generowanie strumienia fałszywych pakietów, w których podstawiany jest adres IP interfejsu VPN, przeprowadza się próby wpływu na nawiązane połączenie przez klienta, jednak wpływ tych pakietów można obserwować tylko poprzez pasywną analizę zaszyfrowanego strumienia ruchu związanego z działaniem tunelu. Aby przeprowadzić atak, należy poznać przypisany przez serwer VPN adres IP interfejsu sieciowego tunelu oraz ustalić, że w danym momencie przez tunel aktywne jest połączenie z określonym hostem.
Aby określić adres IP wirtualnego interfejsu sieciowego VPN, wysyła się do systemu ofiary pakiety SYN-ACK, kolejno przeszukując cały zakres wirtualnych adresów (w pierwszej kolejności sprawdzane są adresy używane domyślnie w VPN, na przykład w OpenVPN używany jest podsieć 10.8.0.0/24). O istnieniu adresu można wnioskować na podstawie otrzymania odpowiedzi z flagą RST.
Podobnie ustala się obecność połączenia z danym serwisem oraz numer portu po stronie klienta — przeszukując numery portów w stronę użytkownika wysyłany jest pakiet SYN z adresem źródłowym, w którym podstawiony jest adres IP serwisu, a adresem docelowym jest wirtualny adres IP VPN. Port serwera można przewidzieć (80 dla HTTP), a numer portu po stronie klienta można obliczyć, przeszukując, analizując dla różnych numerów zmiany intensywności odpowiedzi ACK w połączeniu z brakiem pakietu z flagą RST.
Na tym etapie atakujący zna wszystkie cztery elementy połączenia (adresy/porty IP źródła i adres/port IP docelowego), ale aby wygenerować fałszywy pakiet, który zostanie odebrany przez system ofiary, atakujący musi określić numery sekwencji i potwierdzenia (seq i ack) połączenia TCP. Aby określić te parametry, atakujący nieprzerwanie wysyła fałszywe pakiety RST, przeszukując różne numery sekwencji, aż zarejestruje odpowiedni pakiet ACK, którego przyjście wskazuje, że numer mieści się w oknie TCP.
Następnie atakujący potwierdza prawidłowość określenia, wysyłając pakiety z tym samym numerem i obserwując nadejście odpowiedzi ACK, po czym dobiera dokładny numer bieżącej sekwencji. Zadanie komplikuje fakt, że odpowiedzi są wysyłane w szyfrowanym tunelu, a ich obecność w przechwytywanym strumieniu ruchu można analizować jedynie pośrednimi metodami. Fakt wysłania pakietu ACK skierowanego do serwera VPN przez klienta jest określany na podstawie rozmiaru i opóźnienia szyfrowanych odpowiedzi, korelujących z wysyłaniem fałszywych pakietów. Na przykład dla OpenVPN szyfrowany pakiet o rozmiarze 79 pozwala trafnie sądzić, że wewnątrz zawarte jest potwierdzenie ACK.
Zanim ochrona przed atakiem zostanie dodana do jądra systemu operacyjnego, jako tymczasową metodę blokowania problemu z pomocą filtru pakietów w łańcuchu „preroute” zablokować przejście pakietów, w których jako adres docelowy wskazany jest wirtualny adres IP tunelu.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! —src-type LOCAL -j DROP
lub dla 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’
Aby zapewnić ochronę podczas korzystania z tuneli z adresami IPv4, wystarczy przełączyć rp_filter w tryb „Strict” („sysctl net.ipv4.conf.all.rp_filter = 1”). Ze strony VPN metoda określania numeru sekwencji może być zablokowana poprzez dodanie do zaszyfrowanych pakietów dodatkowego wypełnienia, co sprawia, że rozmiar wszystkich pakietów jest identyczny.
Źródło: opennet.ru
