tehnica atacului (CVE-2019-14899) care permite substituirea, modificarea sau inserarea pachetelor în conexiunile TCP, care sunt direcționate prin tuneluri VPN. Problema afectează sistemele Linux, FreeBSD, OpenBSD, Android, macOS, iOS și alte sisteme de tip Unix. Linux suportă mecanismul rp_filter (filtrarea inversă a căii) pentru IPv4, activarea căruia în modul „Strict” neutralizează această problemă.
Metoda permite substituirea pachetelor la nivelul conexiunilor TCP care trec printr-un tunel criptat, dar nu permite interferența în conexiuni care folosesc straturi suplimentare de criptare (de exemplu, TLS, HTTPS, SSH). Algoritmii de criptare folosiți în VPN nu contează, deoarece pachetele falsificate provin din interfața externă și sunt tratate de nucleu ca pachete din interfața VPN. Cea mai probabilă țintă a atacului este intervenția asupra conexiunilor HTTP necriptate, dar și utilizarea atacului pentru manipularea răspunsurilor DNS.
Substituirea cu succes a pachetelor a fost demonstrată pentru tuneluri create cu ajutorul OpenVPN, WireGuard și IKEv2/IPSec. Tor nu este vulnerabil la această problemă, deoarece folosește SOCKS pentru redirecționarea traficului și legătura cu interfața loopback. Pentru IPv4, atacul este posibil în cazul în care rp_filter este setat pe modul „Loose” (sysctl net.ipv4.conf.all.rp_filter = 2). Inițial, în majoritatea sistemelor a fost folosit modul „Strict”, dar începând cu , lansat în decembrie anul trecut, modul de operare implicit a fost schimbat în „Loose” și această modificare a afectat setările standard în multe distribuții Linux.
Mecanismul rp_filter pentru a verifica suplimentar căile de trecere a pachetelor pentru a preveni spoofing-ul adreselor sursă. Când este setat pe 0, verificarea adresei sursă nu se face și orice pachet poate fi redirecționat fără restricții între interfețele de rețea. Modul 1 „Strict” include verificarea fiecărui pachet venit din exterior pentru a corespunde tabelului de rutare, iar dacă interfața de rețea prin care a fost primit pachetul nu este asociată cu ruta optimă pentru livrarea răspunsului, atunci pachetul este respins. Modul 2 „Loose” îmbunătățește verificarea, permițând funcționarea în condiții de utilizare a balansoarelor de încărcare sau rutare asimetrică, în care
ruta răspunsului poate trece printr-o interfață de rețea differentă față de cea prin care a sosit pachetul inițial.
În modul „Loose”, pachetul de intrare este verificat pentru a se conforma cu tabela de rutare, dar este considerat acceptabil dacă adresa sursă este accesibilă prin orice interfață de rețea disponibilă. Atacul propus se bazează pe faptul că atacatorul poate trimite un pachet cu o adresă sursă falsificată, corespunzătoare interfeței VPN, și, deși acest pachet ajunge în sistem printr-o interfață de rețea externă și nu prin VPN, în modul rp_filter „Loose”, un astfel de pachet nu va fi respins.
Pentru a realiza atacul, atacatorul trebuie să controleze gateway-ul prin care utilizatorul se conectează la rețea (de exemplu, printr-o organizație MITM, atunci când victima se conectează la un hotspot controlat de atacator sau prin ). Controlând gateway-ul prin care utilizatorul este conectat la rețea, atacatorul poate trimite pachete false, care vor fi percepute în contextul interfeței de rețea VPN, dar răspunsurile vor fi direcționate prin tunel.
Prin generarea unui flux de pachete false, în care se injectează adresa IP a interfeței VPN, se fac încercări de a afecta conexiunea stabilită de client, dar efectul acestor pachete poate fi observat doar prin analiza pasivă a fluxului de trafic criptat asociat cu activitatea tunelului. Pentru a desfășura atacul, este necesar să se cunoască adresa IP a interfeței de rețea a tunelului desemnată de serverul VPN și să se determine că, în acel moment, există o conexiune activă prin tunel la un anumit host.
Pentru a determina IP-ul interfeței de rețea virtuale VPN, se trimit la sistemul victimei pachete SYN-ACK, parcurgând secvențial întreaga gamă de adrese virtuale (în special, se testează mai întâi adreselor utilizate în mod implicit în VPN, de exemplu, în OpenVPN se folosește subnet-ul 10.8.0.0/24). Existența unei adrese poate fi judecată pe baza primirii unui răspuns cu flag RST.
În mod similar, se determină existența unei conexiuni cu un anumit site și numărul de port pe partea clientului — prin iterarea numărului de porturi către utilizator, se trimite un pachet SYN cu IP-ul site-ului ca adresă sursă, iar adresa de destinație este IP-ul virtual VPN. Portul serverului poate fi anticipat (80 pentru HTTP), iar numărul de port pe partea clientului poate fi calculat prin iterație, analizând pentru diferite numere schimbările în intensitatea răspunsurilor ACK împreună cu absența pachetului cu flag RST.
În această etapă, atacatorul cunoaște toate cele patru elemente ale conexiunii (adresele/porturile IP ale sursei și adresa/portul IP al destinației), dar pentru a genera un pachet fals care va fi acceptat de sistemul victimei, atacatorul trebuie să determine numerele de secvență și confirmare (seq și ack) ale conexiunii TCP. Pentru a determina acești parametri, atacatorul trimite continuu pachete RST false, iterând diferite numere de secvență, până când înregistrează un pachet de răspuns ACK, primirea căruia indică faptul că numărul se încadrează în fereastra TCP.
Apoi, atacatorul verifică corectitudinea determinării prin trimiterea de pachete cu același număr și observând sosirea răspunsurilor ACK, după care descoperă numărul exact al secvenței curente. Sarcina este complicată de faptul că răspunsurile sunt trimise în interiorul unui tunel criptat, iar analiza prezenței acestora în fluxul de trafic interceptat poate fi realizată doar prin metode indirecte. Faptul că un pachet ACK adresat serverului VPN este trimis de client este determinat pe baza dimensiunii și întârzierii răspunsurilor criptate, corelându-se cu trimiterea pachetelor false. De exemplu, pentru OpenVPN, un pachet criptat de dimensiune 79 permite evaluarea exactă că în interior se află o confirmare ACK.
Înainte ca protecția împotriva atacului să fie adăugată în nucleul sistemului de operare, ca o metodă temporară de blocare a problemei prin intermediul unui filtru de pachete în lanțul „preroute” pentru a bloca trecerea pachetelor în care adresa de destinație este adresa IP virtuală a tunelului.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! —src-type LOCAL -j DROP
sau pentru 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’
Pentru protecția utilizării tunelurilor cu adrese IPv4, este suficient să se schimbe rp_filter în modul „Strict” („sysctl net.ipv4.conf.all.rp_filter = 1”). Din partea VPN, metoda de determinare a numărului de secvență poate fi blocată prin adăugarea unei umpluturi la pachetele criptate, făcând dimensiunea tuturor pachetelor uniformă.
Sursa: opennet.ro
