ataktekniko (CVE-2019-14899) kiu permesas pakaĵetojn esti falsitaj, modifitaj aŭ anstataŭigitaj en TCP-konektoj plusenditaj tra VPN-tuneloj. La problemo influas Linukson, FreeBSD, OpenBSD, Android, macOS, iOS kaj aliajn Unikso-similajn sistemojn. Linukso subtenas la mekanismon rp_filter (inversa vojo filtrado) por IPv4, ŝalti ĝin en "Stricta" reĝimo neŭtraligas ĉi tiun problemon.
La metodo permesas pakaĵetanstataŭigon je la nivelo de TCP-konektoj pasantaj ene de ĉifrita tunelo, sed ne permesas kojnadon en ligojn kiuj uzas kromajn ĉifradavolojn (ekzemple, TLS, HTTPS, SSH). La ĉifradaj algoritmoj uzataj en la VPN ne gravas, ĉar la falsitaj pakaĵoj venas de la ekstera interfaco kaj estas prilaboritaj de la kerno kiel pakaĵetoj de la VPN-interfaco. La plej verŝajna celo de la atako estas enmiksiĝi kun neĉifritaj HTTP-konektoj, sed kaj uzi atakon por manipuli DNS-respondojn.
Sukcesa pakaĵeto estas pruvita por tuneloj kreitaj per OpenVPN, WireGuard kaj IKEv2/IPSec. Tor ne estas sentema al la problemo, ĉar ĝi uzas SOCKS por plusendi trafikon kaj estas ligita al loopback-interfaco. Por IPv4, atako eblas se rp_filter estas agordita al "Loose" reĝimo (sysctl net.ipv4.conf.all.rp_filter = 2). Komence, plej multaj sistemoj uzis la "Strictan" reĝimon, sed ekde , publikigita lastan decembron, la defaŭlta operacia reĝimo estis ŝanĝita al "Loose" kaj ĉi tiu ŝanĝo estis reflektita en la defaŭltaj agordoj de multaj Linukso-distribuoj.
rp_filtrila mekanismo por plia konfirmo de pakaĵetvojoj por malhelpi fontadreson falsifikadon. Kiam agordita al 0, neniu fontadreskontrolo estas farita kaj ajna pakaĵeto povas esti plusendita inter retaj interfacoj sen restriktoj. Reĝimo 1 "Stricta" inkluzivas kontroli ĉiun pakaĵeton venantan de ekstere por konformeco al la vojigtabelo, kaj se la retinterfaco tra kiu la pakaĵeto estis ricevita ne estas rilata al la optimuma respondlivervojo, tiam la pakaĵeto estas forĵetita. Reĝimo 2 "Loza" malstreĉas la kontrolon por permesi ke ŝarĝbalancintoj aŭ nesimetria envojigo funkcii kiam
La responditinero povas trapasi retan interfacon krom tiu tra kiu la envenanta pakaĵeto alvenis.
En Loza reĝimo, alvenanta pakaĵeto estas kontrolita kontraŭ la vojigtabelo, sed estas konsiderita valida se la fontadreso estas atingebla tra iu havebla retinterfaco. La proponita atako baziĝas sur la fakto, ke la atakanto povas sendi pakaĵeton kun falsita fontadreso responda al la VPN-interfaco, kaj malgraŭ tio, ke ĉi tiu pako eniros la sistemon per la ekstera reto-interfaco kaj ne per la VPN, en la rp_filter "Loose" reĝimo tia pako ne estos forĵetita.
Por fari atakon, la atakanto devas kontroli la enirejon tra kiu la uzanto aliras la reton (ekzemple, tra MITM-organizo, kiam la viktimo ligas al atak-kontrolita sendrata alirpunkto, aŭ tra ). Kontrolante la enirejon tra kiu uzanto estas konektita al la reto, atakanto povas sendi falsajn pakaĵetojn, kiuj estos perceptitaj en la kunteksto de la VPN-retinterfaco, sed la respondoj estos direktitaj tra la tunelo.
Generante fluon de fikciaj pakaĵetoj en kiuj la IP-adreso de la VPN-interfaco estas anstataŭigita, provoj estas faritaj por influi la ligon establitan fare de la kliento, sed la influo de tiuj pakaĵetoj povas esti observita nur per pasiva analizo de la ĉifrita trafikfluo asociita. kun la funkciado de la tunelo. Por fari atakon, vi devas ekscii la IP-adreson de la tunela reto-interfaco asignita de la VPN-servilo, kaj ankaŭ determini, ke konekto al specifa gastiganto estas nuntempe aktiva tra la tunelo.
Por determini la IP de la VPN-virtuala reto-interfaco, SYN-ACK-pakoj estas senditaj al la viktimsistemo, sinsekve listigante la tutan gamon da virtualaj adresoj (antaŭ ĉio, la adresoj uzitaj en la VPN estas listigitaj defaŭlte, ekzemple, OpenVPN. uzas la subreton 10.8.0.0/24). La ekzisto de adreso povas esti taksita surbaze de la kvitanco de respondo kun la RST-flago.
Simile, la ĉeesto de konekto al certa retejo kaj la havenombro ĉe la klientflanko estas determinitaj - per ordigo de la havenaj nombroj, SYN-pako estas sendita al la uzanto, kiel la fontadreso, en kiu la retejo de IP estas anstataŭigita, kaj la cela adreso estas virtuala IP VPN. La servila haveno povas esti antaŭdirita (80 por HTTP), kaj la havennumero ĉe la klientflanko povas esti kalkulita per krudforto, analizante por malsamaj nombroj la ŝanĝon en la intenseco de ACK-respondoj en kombinaĵo kun la foresto de pakaĵeto kun la RST. flago.
En ĉi tiu etapo, la atakanto konas ĉiujn kvar elementojn de la konekto (fonto IP-adresoj/haveno kaj celo IP-adreso/haveno), sed por generi fikcian pakaĵeton, kiun la viktimsistemo akceptos, la atakanto devas determini la TCP-sekvencon kaj agnoskaj nombroj (sekv kaj ack) - konektoj. Por determini ĉi tiujn parametrojn, la atakanto senĉese sendas falsajn RST-pakaĵojn, provante malsamajn sinsekvo-nombrojn, ĝis li detektas ACK-respondpakaĵon, kies alveno indikas, ke la nombro falas ene de la TCP-fenestro.
Poste, la atakanto klarigas la ĝustecon de la difino sendante pakaĵetojn kun la sama nombro kaj observante la alvenon de ACK-respondoj, post kio li elektas la ĝustan nombron de la nuna sekvenco. La tasko estas malfaciligita pro la fakto, ke respondoj estas senditaj ene de ĉifrita tunelo kaj ilia ĉeesto en la kaptita trafikfluo nur povas esti analizita per nerektaj metodoj. Ĉu kliento sendas ACK-pakaĵeton adresitan al la VPN-servilo estas determinita surbaze de la grandeco kaj latenteco de la ĉifritaj respondoj, kiuj korelacias kun la sendado de parodiitaj pakaĵetoj. Ekzemple, por OpenVPN, ĉifrita paka grandeco de 79 permesas al vi precize juĝi, ke estas ACK ene.
Ĝis ataka protekto estas aldonita al la operaciuma kerno kiel provizora metodo de blokado de la problemo uzante pakaĵfiltrilon en la "preroute" ĉeno, bloku la trairejon de pakaĵoj en kiuj la virtuala IP-adreso de la tunelo estas specifita kiel la cel-adreso.
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j FALO
aŭ por nftables
nft aldoni tablon ip kruda
nft add chain ip raw prerouting '{ tipo filtrila hoko prerouting prioritato 0; }'
nft add rule ip raw prerouting 'iifname != "wg0" ip daddr 10.182.12.8 fib saddr type != loka guto'
Por protekti vin kiam vi uzas tunelojn kun IPv4-adresoj, simple agordu rp_filter al "Stricta" reĝimo ("sysctl net.ipv4.conf.all.rp_filter = 1"). Sur la VPN-flanko, la viknumera detekta metodo povas esti blokita aldonante kroman remburaĵon al la ĉifritaj pakaĵoj, farante ĉiujn pakaĵojn la saman grandecon.
fonto: opennet.ru