ründetehnik (CVE-2019-14899), mis võimaldab asendada, muuta või sisestada pakette TCP-ühendustes, mis edastatakse VPN-tunnelite kaudu. Probleem mõjutab Linuxi, FreeBSD, OpenBSD, Androidi, macOS-i, iOS-i ja teisi Unixiga sarnaseid süsteeme. Linux toetab mehhanismi rp_filter (tagurpidi tee filter) IPv4 jaoks, mille sisselülitamine 'Strict' režiimis neutraliseerib selle probleemi.
Meetod võimaldab pakettide asendamist TCP-ühenduste tasemel, mis kulgevad krüpteeritud tunnelis, kuid ei võimalda sekkuda ühendustesse, mis kasutavad täiendavaid krüptimise kihte (näiteks TLS, HTTPS, SSH). VPN-is kasutatavad krüptimisalgoritmid pole olulised, kuna vale paketid tulevad välistelt liidestelt ja töödeldakse kärnaga nagu VPN-i liidese paketid. Ründeaarsi tõenäolisem siht on sekkumine krüpteerimata HTTP-ühendustesse, kuid ka rünnaku kasutamist DNS-i vastuste manipuleerimiseks.
Pakettide eduka asendamine on demonstreeritud tunnelite jaoks, mis on loodud OpenVPN, WireGuard ja IKEv2/IPSec abil. Tor ei ole sellele probleemile vastuvõtlik, kuna ta kasutab SOCKSi liikluse edastamiseks ja seondumist loopback-liidesega. IPv4 puhul on rünnak võimalik, kui rp_filter tõlgitakse "Loose" režiimi (sysctl net.ipv4.conf.all.rp_filter = 2). Enamikus süsteemides kasutati algselt "Strict" režiimi, kuid alates , mis ilmus eelmisel aastal detsembris, on vaikerežiim muutunud "Loose"-ks ja see muudatus on kajastunud paljude Linuxi jaotuste vaikeseadetes.
rp_filter mehhanism täiendava kontrolli jaoks pakettide edasiviimise teede üle, et vältida allikaaadressi valeesitamist. Kui väärtuseks on seatud 0, siis allikaaadressi kontrolli ei toimu ja iga pakett võib piiranguteta edastada erinevate võrguliideste vahel. Režiim 1 "Strict" hõlmab igalt poolt tuleva paketi kontrollimist vastavalt marsruutimise tabelile ning kui võrguliides, mille kaudu pakett saabus, ei vasta vastuse optimiseeritud marsruudile, siis pakett kõrvaldatakse. Režiim 2 "Loose" leevendab kontrolli, et võimaldada töö tegemist koormuse tasakaalustajate või asümmeetrilise marsruutimise rakendamise korral, kus
vastuse marsruut võib kulgeda mitte läbi selle võrguliidese, mille kaudu sisenev pakett saabus.
Loose-režiimis kontrollitakse sissetulevat paketti marsruuditabeli järgi, kuid see loetakse lubatavaks, kui allika aadress on kergesti ligipääsetav mistahes olemasoleva võrgu liidese kaudu. Pakkuja rünnak põhineb eeldusel, et ründaja saab saata paketi vale allika aadressiga, mis vastab VPN-liidesele. Hoolimata sellest, et see pakett siseneb süsteemi välise võrgu liidese kaudu ja mitte VPN-i kaudu, ei visata sellist paketti Loose-režiimis rp_filter'is välja.
Rünnaku sooritamiseks peab ründaja kontrollima väravat, mille kaudu kasutaja internetti pääseb (näiteks organisatsioonilise MITM-i kaudu, kui ohver ühendub ründaja hallatud juhtmevaba juurdepääsupunkiga või läbi ). Kontrollides väravat, mille kaudu kasutaja on võrgus ühendatud, saab ründaja saata vale pakette, mida tõlgendatakse VPN-liidese kontekstis, kuid vastused saadetakse tunneli kaudu.
Generaadi vale paki voolus, kus VPN liidese IP-aadress pannakse, püüab mõjutada kliendi poolt seadistatud ühendust, kuid nende pakettide mõju saab jälgida ainult passiivse analüüsi kaudu, mis on seotud tunneliga edastatava krüpteeritud liiklusega. Rünnaku teostamiseks on vajalik teada VPN-serveri määratud tunneliliidese IP-aadressi ning määrata, et hetkel on tunnelis aktiivne ühendus teatud hostiga.
VPN virtuaalse võrguliidese IP-aadressi määramiseks saadetakse ohvri süsteemile SYN-ACK pakette, järkjärguliselt läbides kogu virtuaalsete aadresside vahemiku (kõigepealt uuritakse vaikimisi VPN-is kasutatavaid aadresse, näiteks OpenVPN-is kasutatakse alamvõrku 10.8.0.0/24). Aadressi olemasolu saab tuvastada RST-flaagi vastuse saabumise põhjal.
Samamoodi määratakse kliendi poolse ühenduse olemasolu konkreetse saidiga ja pordiga — kasutades portide numbreid, saadetakse kasutajapoolele SYN-pakett, mille allikaks on saidi IP ja sihtkohaks on virtuaalne VPN IP. Serveri porti võib ennustatav (80 HTTP jaoks), kuid kliendi poolel oleva pordi numbrit saab arvutada, analüüsides erinevate numbrite ACK-vastuste intensiivsuse muutusi koos RST-lipuga pakettide puudumisega.
Selles etapis teab ründaja kõiki nelja ühenduse elementi (allika IP aadress/port ja sihtkoha IP aadress/port), kuid et genereerida vale pakett, mille süsteem ehk ohver tajub, peab ründaja kindlaks tegema TCP-ühenduse järjestuse ja kinnituse numbrid (seq ja ack). Nende parameetrite määramiseks saadab ründaja pidevalt vale RST-pakette, proovides erinevaid järjestuse numbreid, kuni ta fikseerib vastuse ACK-paketi, mille saabumine näitab, et number mahub TCP aknasse.
Seejuhul selgitab ründaja pakettide õige tuvastamise kinnitamist sama numbri saatmise kaudu ja jälgib ACK-vastuste saabumist, millega ta tuvastab praeguse järjestuse täpse numbri. Ülesanne on keeruline, kuna vastused saadetakse krüpteeritud tunneli kaudu ja nende olemasolu peidetud liiklusvoos saab analüüsida vaid kaudsete meetoditega. Fakt, et VPN-serverile suunatud ACK-pakett saadetakse kliendi poolt, määratakse krüpteeritud vastuste suuruse ja viivituse põhjal, mis on seotud vale pakettide saatmisega. Näiteks OpenVPN-i puhul võimaldab krüpteeritud paketi suurus 79 täpselt aru saada, et selle sees on ACK-kinnitus.
Enne kui rünnakute kaitse lisatakse operatsioonisüsteemi tuumasse, on kui ajutine meetod probleemi blokeerimiseks kasutades paketifiltrit 'preroute' ahelas, et blokeerida pakettide läbimine, mille sihtaadressiks on tunnel'i virtuaalne IP-aadress.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP
või nftables puhul
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’
IPv4 aadresside kasutamisel tunnelite kaitseks piisab rp_filter'i seadistamisest "Strict" režiimile ("sysctl net.ipv4.conf.all.rp_filter = 1"). VPNi küljest võib järjestuse määramise meetodit blokeerida, lisades krüpteeritud paketile täitematerjali, mis muudab kõikide pakettide suurused ühtlaseks.
Allikas: opennet.ru
