TunnelCrack kontra TunnelVision: co naprawdę łamie każdy z nich

Dwie nazwy badawcze bywają używane zamiennie dla każdego ruchu VPN, który opuszcza tunel, ale mechanizmy za nimi nie są takie same. TunnelCrack opisuje dwie rodziny wyjątków routingu; TunnelVision opisuje trasę dostarczaną przez DHCP na urządzeniu końcowym. Żaden z nich nie łamie szyfrowania i żaden nie mówi, co dziś robi konkretna wersja klienta. Pięć kontroli oddziela mechanizmy od nagłówka.

Pierwszy krok: nazwij mechanizm, który przeglądasz

Ujawnienie TunnelCrack z sierpnia 2023 roku opisuje dwie rodziny ataków. W przypadku sieci lokalnej ruch, który klient uznaje za należący do sieci lokalnej, otrzymuje wyjątek dostępu lokalnego i opuszcza tunel. W przypadku adresu serwera trasa potrzebna klientowi do dotarcia do samego serwera VPN znajduje się poza tunelem, a przeciwnik kontrolujący ten adres może wykorzystać wyjątek.

TunnelVision to osobny raport o bezklasowych trasach statycznych dostarczanych przez DHCP. Złośliwy serwer DHCP może dać urządzeniu końcowemu trasy zmieniające drogę ruchu, w tym drogę do serwera VPN. Raport uznaje wcześniejsze prace nad powiązanymi efektami routingu, co przypomina, że mechanizm bazowy jest starszy niż nazwa.

Trzymaj nazwy przypisane do ich mechanizmów. Stosowanie poprawki dla jednego, dlatego że drugi jest w wiadomościach, to sposób, w jaki przegląd wytwarza ruch bez pokrycia.

Drugi krok: przyjrzyj się wyjątkowi dostępu lokalnego

Większość klientów wyłącza ruch sieci lokalnej, aby drukarki, transmisja ekranu i udostępnianie plików działały, gdy tunel jest aktywny. Ten wyjątek to decyzja polityczna z kosztem bezpieczeństwa: przeciwnik w tej samej sieci może przedstawić się jako host lokalny, a ruch, który do niego dociera, nigdy nie wszedł do tunelu.

Zapytaj, czy wdrożony profil w ogóle potrzebuje wyjątku. Zespół pracujący zdalnie, który nigdy nie używa lokalnego wykrywania, często może go wyłączyć, a pozostałe usługi lokalne są osiągalne udokumentowaną ścieżką. Tam, gdzie wyjątek jest konieczny, wskaż, które cele obejmuje, zamiast opisywać go jako ruch lokalny.

Kontrola to pytanie o konfigurację, nie przechwytywanie pakietów. Przeczytaj ustawienie profilu i dokumentację klienta dla wersji, którą wdrażasz, bo wartość domyślna różni się między produktami i między wersjami tego samego produktu. Zapisz odpowiedź obok profilu, aby następny recenzent nie musiał jej wywnioskować z zachowania. Wyjątek, którego nikt nie udokumentował, to wyjątek, którego nikt nie przegląda.

Trzeci krok: sprawdź, jak poznawany jest adres serwera

Klient musi dotrzeć do serwera VPN, zanim powstanie jakikolwiek tunel, więc ten cel jest z założenia routowany poza tunelem. Jeśli adres jest poznawany z nazwy, etap rozwiązywania jest częścią ścieżki zaufania, a przeciwnik, który może odpowiedzieć na to zapytanie, może skierować klienta do hosta, który kontroluje.

Przypięcie adresu, użycie zweryfikowanego certyfikatu z poprawną nazwą i odmowa przejścia na niezweryfikowany serwer wszystkie zmniejszają ekspozycję. Żadne z nich nie usuwa potrzeby dotarcia do serwera poza tunelem; zmieniają, kto może odpowiadać za ten adres.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

Wyszukanie trasy pokazuje interfejs, którego klient użyłby dla adresu serwera, i to jest wyjątek w konkretnej formie. Jeśli to wyszukanie zwraca interfejs tunelu, klient nie może nawet ustanowić tunelu, więc trasa zewnętrzna jest oczekiwana, a pytanie dotyczy tylko tego, jak wybierany jest jej cel.

Czwarty krok: przyjrzyj się trasom dostarczanym przez DHCP

Bezklasowe trasy statyczne pozwalają serwerowi DHCP rozdawać wpisy tabeli routingu, a urządzenie końcowe zwykle przyjmuje je bez pytania. W sieci, w której przeciwnik może odpowiedzieć na DHCP szybciej niż legalny serwer, te wpisy mogą przekierować ruch, który użytkownik uważa za znajdujący się w tunelu.

Porównaj trasy na urządzeniu końcowym z trasami, których oczekujesz. Trasa domyślna lub szeroki prefiks wskazujący na lokalną bramę, gdy tunel jest aktywny, to sygnatura warta zbadania, i jest widoczna bez żadnego ruchu atakującego.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

Ostatnie ustawienie to kontrola po stronie urządzenia końcowego, którą wielu klientów i platform udostępnia w jakiejś formie: ignorowanie tras dostarczanych przez sieć. Wyłączenie automatycznego akceptowania tras to kompromis, ponieważ wyłącza też legalny routing dzielony z firmowego serwera DHCP, więc decyduj o tym według klasy sieci, a nie globalnie.

Piąty krok: oddziel komunikat od bieżącej kompilacji

Opublikowany atak opisuje zachowanie zaobserwowane na konkretnych wersjach klienta w konkretnym czasie. Nie dowodzi, że laptop przed tobą jest dotknięty, ani nie dowodzi, że został naprawiony. Oba twierdzenia wymagają rzeczywistego numeru kompilacji i aktualnego komunikatu producenta.

Zapisz wersję klienta, platformę, ustawienia profilu rządzące powyższymi wyjątkami oraz datę sprawdzenia. Ten zapis starzeje się uczciwie, a notatka, że VPN załatano pod TunnelCrack, nie starzeje się uczciwie. Czytaj go ponownie przy każdej aktualizacji klienta, bo domyślna wartość profilu może się zmienić pod wersją, której nie dotykałeś.

Gdy naprawdę weryfikujesz, użyj zatwierdzonego planu przeciw własnemu urządzeniu końcowemu i nieszkodliwemu celowi. Odtwarzanie ataku przeciw innym użytkownikom w sieci współdzielonej nie jest testem, a wyłączenie weryfikacji partnera lub szyfrowania aplikacji, aby ułatwić obserwację, usuwa ochronę, którą próbowałeś zmierzyć.

Na koniec trzymaj w obrazie ochronę na poziomie aplikacji. Wyjątek routingu może ujawnić ruch, który tunel by niósł, a TLS aplikacji nadal chroni ten ruch od końca do końca. Obie warstwy zawodzą niezależnie, dlatego połączony kanał sterowania nie jest dowodem, że każdy przepływ poszedł zamierzoną ścieżką.