Slo-Tech - Raziskovalci z Univerze v Novi Mehiki so v večini distribucij Linuxa in nekaterih drugih izpeljankah iz Unixa (FreeBSD, OpenBSD, macOS, iOS, Android) odkrili ranljivost v načinu, kako se vzpostavljajo povezave prek navideznih zasebnih omrežij (VPN). Ranljivost napadalcem omogoča, da ugotovijo, ali je uporabnik povezan v VPN, kateri naslov IP mu je bil dodeljen in ali je aktivno povezan na neko spletno stran. S štetjem paketkov in analizo njihove velikost je moč izluščiti vrednosti seq in ack. V nekaterih primerih je mogoče vrivati podatke v povezavo. Ranljive so distribucije, ki uporabljajo systemd od lanskega 28. novembra (izklop reverse path filtering); prav tako je ranljivost tudi v IPv6.
Ranljivost je tako neodvisna od konkretne implementacije VPN, torej je vseeno, ali uporabljamo OpenVPN, WireGuard ali IKEv2/IPSec. Kaže pa, da se s Torom izognemo ranljivosti, ker uporablja SOCKS in se ugotavljanje pristnosti in šifriranje izvajata v uporabniškem delu in ne v jedru. Da napad deluje, mora biti napadalec v istem delu omrežja kakor uporabnik. To je najlaže doseči tako, da napadalec ustvari lažno dostopno točko, prek katere se uporabnik poveže. Pri uporabni neznanih dostopnih točk je VPN način, kako se izognemo prisluškovanju, a nova ranljivost kaže, da vseeno puščamo nekaj drobtinic podatkov. Napada ne moremo uporabiti na vseh sistemih na enak način; na primer na macOS/iOS je treba uporabiti odprta vrata, denimo 5223.
Napad gre takole: ko se žrtev poveže na nevarno dostopno točko in vzpostavi povezavo s strežnikom VPN, dobi virtualni naslov IP. Napadalec lahko potem pošilja paketke SYN-ACK na celoten prostor in ko ugane IP, dobi odgovor RST. Na podoben način lahko preverimo, ali je žrtev povezana z določenim spletnim strežnikom. Če ji, ko IP naslov poznamo, pošljemo lažen paketek, ki ima ponarejen virni naslov IP, se bo v primeru, da ga zadenemo, odziv glasil drugače. Tedaj dobimo več ACK in ne RST. Nadaljnje preizkušanje in analiza omogočata ugotoviti tudi zaporedni številki seq ack, kar na koncu omogoča vrivanje paketkov v povezavo.
Ne razumem čisto...v domačem omrežju si postaviš VPN server... kar pomeni, da mora biti del omrežja odprt, da se lahko povežeš vanj. Ko si notri, si pa pač del notranjega omrežja. Samo promet poteka preko virtualnega omrežnega vmesnika.
Razlaga zgoraj je malo zmedena. Kot da bi imel Google Translate svoje prste vmes.
Izgleda kot neka MITM varianta, ni mi pa jasno, kaj mislijo z pošiljanjem SYN paketov na 'vse naslove' - v lastnem omrežju tako vidiš v ARP-u in iz DHCP, katero IP adreso ima 'opazovani odjemalec'. Torej ni govora o tem delu, temveč o virtualnem delu - VPN povezavi.
Tako potem mora biti 'napadalec' povezan na isti VPN strežnik. Če pa je že tam, potem imaš precej večji problem, kot tega, da ti lahko vrine kakšen paketek....
Skratka, če je napadalec enako kot ti povezan na tvoj VPN strežnik, potem lahko preko pošiljanja SYN paketov ugotovi tvoj virtualni naslov in v nadaljevanju vrine še kakšen dodaten paktek, itd.
Že res da je to ranljivost....ampak ne vidim kakšne hujše panike zaradi nje, saj mora napadalec biti povezan na isti VPN strežnik, za kar potrebuje user/pass. Čim si enkrat gor na strežniku oz. v notranjem omrežju, pa lahko narediš veliko bolj kritične zadeve, kot se mučiti s sosedom - zakaj nebi pognal kar TCPDump in v Wiresharku brez hude znanosti prebiral, kaj počne kolega na istem VPN?
Ali pa celo štorijo narobe razumem....?
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)
Mislim, da ne rabiš biti povezan na isti VPN strežnik. Moraš pa biti v omrežju svoje tarče.
Bolj kot razmišljaš, manj je jasno, ali se gre za problem VPN strežnika ali VPN odjemalca....
Bo treba iti pogledat v izvorno poročilo oz. kakšno malo bolj konkretno razlago problema.
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)
Ne, problem je vezan na network na splošno. Kolikor sem jaz razumel, ima pa predvsem posledice na odjemalcih.
Kaj pa vem... - če hoče napadalec s pomočjo SYN paketov ugotoviti vitualni IP naslov žrtve, potem mora napadalec biti bodisi na istem VPN omrežju ali na omrežju, na katerega se žrtev povezuje preko VPN.
V obeh primerih ima napadalec že dostop do žrtvinega domačega omrežja in v prvi fazi zgolj ugotavlja virtualni IP naslov žrtve. Včasih se je to počelo z nmap...?
Če namreč na oddaljenem omrežju pošiljaš SYN pakete, boš zgolj ugotovil kateri od lokalnih IP-jev se odziva ali ne. V povezavi z zlonamerno dostopno točko pa je to početje nepotrebno, saj ti že dostopna točka pove kateri IP naslov je dodelila odjemalcu žrtve (ARP / DHCP). Zgolj z SYN 'pinganjem' lahko kvečjem (pogojno) ugotoviš, kdo je tisti lokalni IP, ki trenutno poganja VPN povezavo - če ima ta VPN nastavljen, da gre default routa preko VPN tunela, venda tudi v teh primerih odjemalci večinoma še vedno ohranijo routo za lokalno omrežje na katerem se nahajajo - torej nebi smeli pošiljati RST odgovorov.
Skratka nelogično in zmedeno vse skupaj... škoda tuhtanja - kdor ima čas, naj gre pogledat izvorno poročilo in sporoči bistvo (če ga bo razumel) :)
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)
Na AP napadalca se poveže žrtev. Žrtev na if0 dobi naslov 192.11 Žrtev vzpostavi VPN tunel na oddaljeni VPN strežnik 2.99, kreira si virtualni interface vf1, na katerem nastavi IP naslov 8.22
napadalec iz AP pošlje testne pakete (SYN) na vse 8.* naslove, na if0 od žrtve. Na paket namenjen 8.22 bo žrtev (preko VPN) poslala odgovor. Napadalec na AP to vidi, in zdaj pozna virtualni naslov (8.22) žrtve.
Podobno ugotovi druge parametre (seq nr itd...).
Zdaj (če žrtev komunicira z www.cnn.com) lahko žrtvi pošlje paket, ki ima source IP www.cnn.com, destination 8.22, s poljubno vsebino. In žrtev bo to sprejela kot da prihaja iz CNN.com.
Podobno lahko napadalec pošlje na ponarejen paket na ww.cnn.com, tako da zgleda, kot da prihaja od VPN klienta (naslova 8.22). Kar je malo težje, ker morajo vsi svetovni ruterji spustiti paket s source 8.22 (ki je recimo kanadski), čeprav je bil posla iz omrežja slovenskega telekoma. PA VPN server ne sme imeti NAT, ker potem source IP ni enak, kot ga vidi strežnik www.cnn.com
Hmm, samo težki poznavalci tule...
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
Na hitro šel pogledat izvorni dokument, pa stvar sploh ni nujno tako preprosta, saj izhaja iz predpostavke, da se žrtvi dodeli virtualni IP iz default območja OpenVPN-a. Čim nekdo ne uporablja default IP, boš lahko dolgo pingal, sploh če je v VPN-u uporabljen IPv6. Vsekakor pa je tam bistveno boljša razlaga, kot ta tukaj.
In ne, ni problem v serverju - problem je na strani odjemalca. Je pa res čudno, da se sistem z virtualno adreso odziva na SYN iz lokalnega omrežja.
Fail nekje v kernelu? Očitno ni fail VPN odjemalca, ker je problem skupen različnim VPN variantam.
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)
Fail je v izklopu reverse path filtering-a. Saj lepo piše, no.
a) sem samo na hitro pogledal do "how to replicate" b) za reverse path filtering je pa zadolžen kdo?
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)
Linux kernel, po nastavitvah iz sistema. Katerega default so v shituntu 19.10 spremenili is "do it" na "leave it".
Potem le nisem toliko zgrešil, ko sem s prstom kazal na kernel.
Ampak ni videt kot problem zaradi katerega bi bilo za zganjati vik in krik. Smo v preteklosti videl veliko hujše (beri: težje popravljive). Če je potreben zgolj recompile kernela, to res ni konec sveta.
Edino problem: kako to dopovedat vsem tistim, ki nikoli nič ne posodabljajo in vse pustijo na defaultu....
Pričujoče sporočilo je (lahko) oglasno sporočilo
- četudi na prvi pogled ni prepoznavno kot tako.
(Zdaj me pa obtožite prikritega oglaševanja, če morete!)
Linux kernel, po nastavitvah iz sistema. Katerega default so v shituntu 19.10 spremenili is "do it" na "leave it".
Potem le nisem toliko zgrešil, ko sem s prstom kazal na kernel.
Ampak ni videt kot problem zaradi katerega bi bilo za zganjati vik in krik. Smo v preteklosti videl veliko hujše (beri: težje popravljive). Če je potreben zgolj recompile kernela, to res ni konec sveta.
Dovolj je runtime opcijo spremeniti.
Sicer Linux ni edini:
We have discovered a vulnerability in Linux, FreeBSD, OpenBSD, MacOS, iOS, and Android
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
