TunnelCrack versus TunnelVision: ce anume sparge fiecare

Două nume de cercetare sunt folosite interschimbabil pentru orice trafic VPN care iese din tunel, dar mecanismele din spate nu sunt aceleași. TunnelCrack descrie două familii de excepții de rutare; TunnelVision descrie o rută furnizată de DHCP pe echipamentul final. Niciunul nu sparge criptarea și niciunul nu vă spune ce face astăzi o anumită versiune a clientului. Cinci verificări separă mecanismele de titlu.

Primul pas: numiți mecanismul pe care îl verificați

Dezvăluirea TunnelCrack din august 2023 descrie două familii de atacuri. În cazul rețelei locale, traficul pe care clientul îl consideră ca aparținând rețelei locale primește o excepție de acces local și părăsește tunelul. În cazul adresei serverului, ruta de care clientul are nevoie pentru a ajunge la serverul VPN însuși se află în afara tunelului, iar un adversar care controlează acea adresă poate exploata excepția.

TunnelVision este un raport separat despre rute statice fără clasă livrate de DHCP. Un server DHCP rău intenționat poate oferi echipamentului final rute care schimbă calea traficului, inclusiv calea spre serverul VPN. Raportul recunoaște lucrări anterioare despre efecte de rutare înrudite, ceea ce amintește că mecanismul de bază este mai vechi decât numele.

Țineți numele legate de mecanismele lor. Aplicarea unei corecții pentru unul pentru că celălalt este în știri este modul în care o revizuire produce mișcare fără acoperire.

Al doilea pas: priviți excepția de acces local

Majoritatea clienților exceptează traficul rețelei locale pentru ca imprimantele, transmiterea ecranului și partajarea fișierelor să funcționeze în timp ce tunelul este activ. Această excepție este o decizie de politică cu un cost de securitate: un adversar din aceeași rețea se poate prezenta drept gazdă locală, iar traficul care ajunge la el nu a intrat niciodată în tunel.

Întrebați dacă profilul implementat are nevoie de excepție. O forță de muncă la distanță care nu folosește niciodată descoperirea locală o poate adesea dezactiva, iar serviciile locale rămase pot fi atinse printr-o cale documentată. Unde excepția este necesară, spuneți ce destinații acoperă în loc să o descrieți ca trafic local.

Verificarea este o întrebare de configurare, nu o captură de pachete. Citiți setarea profilului și documentația clientului pentru versiunea pe care o implementați, pentru că valoarea implicită diferă între produse și între versiunile aceluiași produs. Scrieți răspunsul lângă profil, ca următorul revizor să nu trebuiască să îl deducă din comportament. O excepție pe care nimeni nu a documentat-o este o excepție pe care nimeni nu o verifică.

Al treilea pas: priviți cum este învățată adresa serverului

Clientul trebuie să ajungă la serverul VPN înainte să existe vreun tunel, așa că acea destinație este rutată în afara tunelului prin proiectare. Dacă adresa este învățată dintr-un nume, pasul de rezolvare face parte din calea de încredere, iar un adversar care poate răspunde la acea interogare poate îndrepta clientul către o gazdă pe care o controlează.

Fixarea adresei, folosirea unui certificat verificat cu numele corect și refuzul de a reveni la un server neverificat reduc toate expunerea. Niciuna nu înlătură nevoia de a ajunge la server în afara tunelului; ele schimbă cine poate răspunde pentru acea adresă.

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

Căutarea rutei arată interfața pe care clientul ar folosi-o pentru adresa serverului, iar aceasta este excepția în formă concretă. Dacă acea căutare returnează interfața tunelului, clientul nu poate nici măcar stabili tunelul, deci o rută exterioară este de așteptat, iar întrebarea este doar cum este aleasă destinația ei.

Al patrulea pas: priviți rutele furnizate de DHCP

Rutele statice fără clasă permit unui server DHCP să distribuie intrări din tabela de rutare, iar echipamentul final le acceptă de obicei fără să întrebe. Într-o rețea în care un adversar poate răspunde la DHCP mai repede decât serverul legitim, acele intrări pot redirecționa trafic pe care utilizatorul crede că este în interiorul tunelului.

Comparați rutele de pe echipamentul final cu rutele pe care le așteptați. O rută implicită sau un prefix larg care indică poarta locală în timp ce tunelul este activ este semnătura care merită investigată și este vizibilă fără niciun trafic de atac.

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

Ultima setare este controlul din partea echipamentului final pe care mulți clienți și platforme îl expun într-o formă sau alta: ignorarea rutelor furnizate de rețea. Dezactivarea acceptării automate a rutelor este un compromis, pentru că dezactivează și rutarea divizată legitimă de la un server DHCP corporativ, așa că decideți pe clasă de rețea și nu global.

Al cincilea pas: separați avizul de versiunea actuală

Un atac publicat descrie comportament observat pe anumite versiuni ale clientului la un anumit moment. Nu stabilește că laptopul din fața dumneavoastră este afectat și nu stabilește că a fost reparat. Ambele afirmații necesită numărul real de build și avizul actual al furnizorului.

Notați versiunea clientului, platforma, setările profilului care guvernează excepțiile de mai sus și data la care ați verificat. Acea înregistrare îmbătrânește cinstit, în timp ce o notă care spune că VPN-ul a fost corectat pentru TunnelCrack nu îmbătrânește cinstit. Recitiți-o la fiecare actualizare a clientului, pentru că o valoare implicită a profilului se poate schimba sub o versiune pe care nu ați atins-o.

Când validați cu adevărat, folosiți un plan aprobat împotriva propriului echipament final și a unei destinații inofensive. Reproducerea atacului împotriva altor utilizatori într-o rețea partajată nu este un test, iar dezactivarea verificării partenerilor sau a criptării aplicației pentru a ușura o observație elimină protecția pe care încercați să o măsurați.

În final, păstrați protecția la nivel de aplicație în imagine. O excepție de rutare poate expune trafic pe care tunelul l-ar fi purtat, iar TLS-ul aplicației protejează în continuare acel trafic de la un capăt la altul. Cele două straturi eșuează independent, motiv pentru care un canal de control conectat nu este dovada că fiecare flux a urmat calea dorită.