» »

Ranljivost v izvedbi VPN v Linuxu in Unixu

Ranljivost v izvedbi VPN v Linuxu in Unixu

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.

24 komentarjev

Matthai ::

Proti vrivanju se pa verjetno da vsaj malo ubraniti s HMAC podpisovanjem paketkov...
All those moments will be lost in time, like tears in rain...
Time to die.

MrStein ::

Če prav razumem, se lahko vrine le v smer web_server-->client ?
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Matthai ::

Ne vem, jaz tega nisem tako razumel. Po moje ni posebnega razloga, da se ne bi vrivalo v obe smeri...
All those moments will be lost in time, like tears in rain...
Time to die.

MrStein ::

Kako bi vrinil v tok klient--->web server?

Torej da bi web server videl, kot da bi podatek bil od klienta, v resnici pa je od napadalca.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Matthai ::

Hmm, na podoben način kot v drugo smer?
All those moments will be lost in time, like tears in rain...
Time to die.

MrStein ::

V bistvu ja, samo na celi poti mora biti izklopljen reverse path filtering. Pa VPN server ne sme imeti NAT-a za kliente (večina verjetno nima).
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Matthai ::

NAT-a za kliente?
All those moments will be lost in time, like tears in rain...
Time to die.

MrStein ::

Če se VPN-aš v svoje domače omrežje, boš imel NAT. Na primer. Preprosti.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Matthai ::

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.

Ne vem, če isto misliva...?
All those moments will be lost in time, like tears in rain...
Time to die.

SeMiNeSanja ::

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!)

Matthai ::

Mislim, da ne rabiš biti povezan na isti VPN strežnik. Moraš pa biti v omrežju svoje tarče.
All those moments will be lost in time, like tears in rain...
Time to die.

SeMiNeSanja ::

Matthai je izjavil:

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!)

Matthai ::

Ne, problem je vezan na network na splošno. Kolikor sem jaz razumel, ima pa predvsem posledice na odjemalcih.
All those moments will be lost in time, like tears in rain...
Time to die.

SeMiNeSanja ::

Matthai je izjavil:

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!)

Matthai ::

Ja, s tem napadom pa lahko ugotovi še VPN naslov žrtve.
All those moments will be lost in time, like tears in rain...
Time to die.

MrStein ::

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!

Zgodovina sprememb…

  • spremenil: MrStein ()

Matthai ::

Ja, saj to je jasno. Samo če uporabljaš https://cnn... pač ne bo šlo.
All those moments will be lost in time, like tears in rain...
Time to die.

SeMiNeSanja ::

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!)

MrStein ::

Fail je v izklopu reverse path filtering-a. Saj lepo piše, no.
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

Zgodovina sprememb…

  • spremenil: MrStein ()

SeMiNeSanja ::

MrStein je izjavil:

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!)

MrStein ::

Linux kernel, po nastavitvah iz sistema. Katerega default so v shituntu 19.10 spremenili is "do it" na "leave it".
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!

SeMiNeSanja ::

MrStein je izjavil:

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!)

jype ::

SeMiNeSanja je izjavil:

Edino problem: kako to dopovedat vsem tistim, ki nikoli nič ne posodabljajo in vse pustijo na defaultu....
Taki ne uporabljajo VPN v "sovražnih" omrežjih.

MrStein ::

SeMiNeSanja je izjavil:

MrStein je izjavil:

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!

Zgodovina sprememb…

  • spremenil: MrStein ()


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Ranljivost v izvedbi VPN v Linuxu in Unixu

Oddelek: Novice / Varnost
242379 (670) MrStein
»

Huda ranljivost v vseh napravah z Wi-Fi (strani: 1 2 )

Oddelek: Novice / Varnost
7211570 (6535) SeMiNeSanja
»

Nenehni napadi na porte (strani: 1 2 3 )

Oddelek: Informacijska varnost
10019646 (16120) Jst
»

IPTABLES in TCP flags problem

Oddelek: Operacijski sistemi
171035 (864) Bojan xxxx

Več podobnih tem