Buongiorno, il succo del messaggio di Leviathan security group in merito al "nuovo" attacco Tunnelvision (WandaVision?) è questo: https://www.tunnelvisionbug.com/ --8<---------------cut here---------------start------------->8--- VPNs are marketed as a security service that protects users even on untrusted networks (e.g. public Wi-Fi). However, it has been known within the security industry that these claims are questionable, and small leaks have been discovered over the years. Most research has been focused on VPN servers rather than leaking client traffic on a local network. Recently, a technique known as TunnelCrack allowed attackers to leak data from a VPN. Simultaneously, we have been working on a more general technique we call “TunnelVision.” TunnelVision leaks VPN traffic more simply and powerfully. We have demonstrated an attacker can leak all traffic just by being on the same local network as a VPN user. From the user’s perspective, they appear as if they are connected to the VPN. --8<---------------cut here---------------end--------------->8--- Aggiungo io che questo attacco, di tipo man in the middle, funziona solo quando il client VPN viene usato per redirigere _tutto_ il traffico (route all traffic) da/per Internet attraverso la VPN, che serve per nascondere i dati (se non già crittografati) e i _metadati_ (es. query DNS) usati durante la trasmissione. [1] Un altro modo di utilizzare la VPN (meno raro di quanto di creda) è quello di connettere due reti locali tra loro o un dispositivo "roaming" a una rete locale e fare in modo che tutti i dispositivi in rete VPN "si vedano" tra loro come se fossero locali. Il succo della vulnerabilità è che _nessuno_ può nascondere le proprie "tracce digitali" se è connesso a una rete /untrusted/, tantomeno a una rete _locale_ untrusted. 380° <g380@biscuolo.net> writes:

...

*Novel attack against virtually all VPN apps neuters their entire purpose*

Novel?!? Anche Leviathan security group ha cancellato "novel" dal proprio blog post: https://www.leviathansecurity.com/blog/tunnelvision (in HTML rende meglio) --8<---------------cut here---------------start------------->8--- Recently, we identified a n̶o̶v̶e̶l̶ network technique that bypasses VPN encapsulation. An attacker can use this technique to force a target user’s traffic off their VPN tunnel using built-in features of DHCP (Dynamic Host Configuration Protocol). The result of this is the user transmits packets that are never encrypted by a VPN, and an attacker can snoop their traffic. --8<---------------cut here---------------end--------------->8--- [...]

https://github.com/leviathansecurity/TunnelVision

Hint: la "hostile network" è una rete (Wi-Fi o Ethernet) dove l'attaccante può riesce ad inviare specifici pacchetti DHCP

La classe generale di questo attacco è denominata "rogue DHCP" e questa falla di sicurezza di DHCP è conosciuta da sempre, anche se generalmente completamente ignorata: --8<---------------cut here---------------start------------->8--- Because the client has no way to validate the identity of a DHCP server, unauthorized DHCP servers (commonly called "rogue DHCP") can be operated on networks, providing incorrect information to DHCP clients.[32] This can serve either as a denial-of-service attack, preventing the client from gaining access to network connectivity,[33] or as a man-in-the-middle attack.[34] Because the DHCP server provides the DHCP client with server IP addresses, such as the IP address of one or more DNS servers,[8]: sec. 7  an attacker can convince a DHCP client to do its DNS lookups through its own DNS server, and can therefore provide its own answers to DNS queries from the client.[35] This in turn allows the attacker to redirect network traffic through itself, allowing it to eavesdrop on connections between the client and network servers it contacts, or to simply replace those network servers with its own.[35] --8<---------------cut here---------------end--------------->8--- (https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Security) Non è ancora stata "inventato" un _tappabuchi_ per questa falla, contrariamente ad altri _tabbabuchi_ implementati per quel colabrodo di rete chiamata Internet. Saluti, 380° [1] in merito a "ficcanasare" nel traffico di rete locale, ci sono poi altre tecniche sofisticate di deep packet inspection: https://en.wikipedia.org/wiki/Deep_packet_inspection#At_the_enterprise_level -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.

Buongiorno, in merito ai metodi disponibili su GNU/Linux per evitare possibili attacchi come quello in oggetto... 380° <g380@biscuolo.net> writes: [...]

https://www.leviathansecurity.com/blog/tunnelvision

--8<---------------cut here---------------start------------->8--- It is not feasible to fix the issue by simply removing support for the DHCP feature because this could break Internet connectivity in some legitimate cases. The strongest recommendation we have is for VPN providers to implement network namespaces on operating systems that support them, similar to the method described in WireGuard’s documentation [1]. Network namespaces are a Linux feature that can segment interfaces and routing tables away from the local network’s control --8<---------------cut here---------------end--------------->8--- Bingo! In alternativa al metodo documentato da wireguard (The New Namespace Solution) [1], che è un po' macchinoso, chi ha necessità di effettuare il routing di tutto il traffico generato dalle proprie applicazioni via VPN (wireguard o altra che sia) non deve far altro che eseguirle in un container (detto guest) LXC, magari creato/gestito via virt-manager [2]), opportunamente configurato [3] [4] [5]. Il risultato netto è una topologia di rete guest/host di tipo "Ordinary Containerization" [6] che è del tutto analoga a quella illustrata nel diagramma di rete in "The New Namespace Solution" [1] (vale con qualsiasi VPN), indicata da Leviathan security group come soluzione adeguata all'attacco da loro denunciato. Sbaglio? (mi pare di no). Happy hacking! 380° [1] https://www.wireguard.com/netns/#the-new-namespace-solution [2] https://virt-manager.org/ [3] per OpenVPN: https://wiki.archlinux.org/title/Linux_Containers/Using_VPNs#OpenVPN_in_clie... [4] per wireguard: https://wiki.archlinux.org/title/Linux_Containers/Using_VPNs#WireGuard [5] la documentazione indicata vale per _tutti_ i container LXC, non solo per quelli su host con Arch Linux [6] https://www.wireguard.com/netns/#ordinary-containerization -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.