Sounds like it requires that your DHCP server is hostile, which is actually a very small (though nonzero, yes) number of the attack scenarios that VPNs are designed for
"there are no ways to prevent such attacks except when the user's VPN runs on Linux or Android" is a very funny way of saying "in practice applies only to Windows and iOS".
Sounds like it requires that your DHCP server is hostile, which is actually a very small (though nonzero, yes) number of the attack scenarios that VPNs are designed for
In most situations, any host on the LAN can become a DHCP server.
“there are no ways to prevent such attacks except when the user’s VPN runs on Linux or Android” is a very funny way of saying “in practice applies only to Windows and iOS”.
No. There are certainly ways of mitigating it, but afaict no Linux distros have done so yet.
When I use a VPN, I very rarely imagine that the coffee shop / home internet that I'm hooked up to will have a malicious actor or compromised host physically inside it. I mean, maybe. But more likely is that I'm protecting against a malicious ISP, or effectively doing an extra level of authentication to my work network before I get access to non-world-visible elements of it (that shouldn't be exposed to anyone in the world that wants to poke at it). The "someone else at the cafe is malicious" case isn't un-heard of, but it's not the most common threat model. That's my point.
From the article:
When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.
"Deanonymize" and denial of service are very very different from hijacking the connection and rerouting destination traffic to a hostile device, which it sounds like are what's possible on iOS and Windows.
I don't really know the full details (e.g. what does it mean that "there's a setting", and is activating that setting starting this week any different in practice from applying the patch that will surely come this week for Windows and iOS). But it does sound fair to say that there's a serious level of vulnerability that's exclusive to Windows and iOS.
For this scenario, are you imagining that a person may have physically entered the coffee shop who's both tech savvy and malicious enough to run a malicious device there?
Or were you thinking a remote compromise of their router? That one seems moderately more probable, but eliminates anything special about the coffee shop's router specifically as opposed to your home router or your workplace's router.
For this scenario, are you imagining that a person may have physically entered the coffee shop who’s both tech savvy and malicious enough to run a malicious device there?
I mean.. Yeah. I've sat in a coffee shop or airport in the past and sniffed traffic out of mere curiosity. Why wouldn't a malicious actor be there?
I have done, and friends of mine have done a lot more than that. My point is that I'm unusually nerdy and the number of people who've ever been subjected to it by me being near them is probably in the double digits for a few minutes over my entire life.
I will bet you any amount of money that you can go to any coffee shop and set up an insecure VPN there all day and not a single person will randomly come in, set up a malicious DHCP server, and reroute the VPN traffic through their hardware so they can spoof it and spy on your traffic.
The fact that it's possible means it's worth defending against, sure. If it sounds like I'm saying it's not a big deal I am not. I'm just saying that it is not the most common threat that you need to defend against most urgently or even in the top 10 (primarily because it requires one of this little handful of people nearby to you to be a malicious actor, where most of the ones that are really commonly-encountered threats are the ones that literally any one of billions of people on the planet could at any time randomly target you with, so you're going to run into a lot more frequently.)
I can enumerate the ISPs that have will-hand-your-traffic-over-for-general-vacuuming-up deals with the American government, and the ISPs worldwide that do some form of traffic editing on behalf of differently-repressive-than-the-US regimes, and I can go to Starbucks tomorrow and we can compare that proportion of ISPs to the proportion of people I find actively tampering with my traffic from the cafe.
You need to compare "everybody who has ever done anything malicious at a cafe" if you want to make a valid comparison to "all the ISPs in the world". In the US nobody would be using an ISP that would be doing anything malicious in a cafe. "has deals with the American government" paranoia notwithstanding.
I am comparing the question, is my traffic being spied on by the ISP (in practice, passed off from the ISP to the NSA for sure and in practice maybe whoever else) actively as I'm running my connection, versus is my traffic being spied on by my fellow patrons. I would describe harvesting all my traffic and giving it to the government as "malicious." That, to me, is more likely (I mean, more or less 100% chance, within the US) than someone randomly being at the cafe acting maliciously to the point of setting up a spoof DHCP server randomly during the time that I am there.
(Part of the Snowden revelations were that the NSA had deals with more or less every major data carrier to harvest in bulk more or less everything that goes over the long-distance internet.)
What percentage of people in the world do you imagine set up spoof DHCP servers at cafes? 1%? And what percent of their time do you imagine they spend doing it? I cannot possibly make the math work out to make it make sense unless the cafe literally has at bare minimum thousands of people in it at all times. I mean, sure, it's worth making sure your VPN is secure against it.
I don't really want to argue continuously back and forth about this for too too long. I feel like I've said what I needed to say to communicate my piece about it at this point.
I'm going to go ahead and say we just differ in what we consider to be "malicious behavior". Yes, the NSA spying is bad, but they're not "stealing credit cards bad".
It doesn't sound to me like this really negates the purpose of a VPN, more accurately it provides a way for someone on your local network to snoop on VPN traffic, if I understand correctly.
From how the article describes the attack, someone on your local network would have to set up a malicious DHCP server/gateway. The average home user who is using a VPN to mask their public IP probably doesn't need to worry about this.
Sounds like the attack bypasses the VPN entirely. It’s not a worry on your home network if you control the DHCP server. But, on public networks, where you really should always use a VPN, you can’t be sure your traffic is going through the VPN.
Maybe, you can check a trusted site like the VPN provider’s webpage to see if you’re going through the VPN. But, a really sophisticated attack could potentially route just that traffic through the VPN and everything else outside of it.
VPNs have several purposes but the big two are hiding your traffic from attackers on the local area network and concealing your location from sites that you visit.
If you're using a VPN on wifi at a cafe and anyone else at the cafe can run a rogue DHCP server (eg, with an app on their phone) and route all of your traffic through them instead of through the VPN, I think most VPN users would say the purpose of the VPN has been defeated.
The vast majority of LANs do not do anything to prevent rogue DHCP servers.
Just to be clear, a "DHCP server" is a piece of software which can run anywhere (including a phone). Eg, if your friend's phone has some malware and you let them use the wifi at your house, someone could be automatically doing this attack against your laptop while they're there.
Researchers have devised an attack against nearly all virtual private network applications that forces them to send and receive some or all traffic outside of the encrypted tunnel designed to protect it from snooping or tampering.
TunnelVision, as the researchers have named their attack, largely negates the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and to cloak the user’s IP address.
The attack works by manipulating the DHCP server that allocates IP addresses to devices trying to connect to the local network.
A setting known as option 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel.
When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.
This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation.
The original article contains 903 words, the summary contains 196 words. Saved 78%. I'm a bot and I'm open source!
A lot of times the concern is less the location and more deviations from normal behavior. Geo location is something of a mixed bag. The local IP via an external lookup isn't particularly reliable if someone happens to use VPNs at home, or locating it several miles away when ISPs cover whole regions. Combine it with a system similar to how Google maps known WiFi hotspots as an alternate location marker and you can get a lot more reliable.
If someone logs in outside their normal hours and shows up from halfway across the globe an hour later you can bet it's going to raise some alarms, or at least it should.
Some things it becomes a case of contractual needs. A lot of government work comes with a requirement it be performed by someone within a certain country.
I suspect that if you connected to your work vpn from a personal VPN IP address that may raise some questions. "Dave keeps connecting from inside Amazons data center, thats weird".
Turning on wifi to scan would be trivial technically. Hidden GPS maybe, but its more likely that they would just have an overt GPS module if they cared.
A wired in airtag or similar would probably be doable, and wouldnt be visible to the OS.
Latency analysis would probably be quite tricky. If you had starlink or dialup your latency would be pretty bad to begin with.
Realistically, if the employer was concerned about company data leaving the country they wouldnt be allowing WFH at all.
Hackers backed by a powerful nation-state have been exploiting two zero-day vulnerabilities in Cisco firewalls in a five-month-long campaign that breaks into government networks around the world, researchers reported Wednesday.
These devices are ideal targets because they sit at the edge of a network, provide a direct pipeline to its most sensitive resources, and interact with virtually all incoming communications.
Those characteristics, combined with a small cast of selected targets all in government, have led Talos to assess that the attacks are the work of government-backed hackers motivated by espionage objectives.
“Our attribution assessment is based on the victimology, the significant level of tradecraft employed in terms of capability development and anti-forensic measures, and the identification and subsequent chaining together of 0-day vulnerabilities,” Talos researchers wrote.
“Regardless of your network equipment provider, now is the time to ensure that the devices are properly patched, logging to a central, secure location, and configured to have strong, multi-factor authentication (MFA),” the researchers wrote.
It stems from improper validation of files when they’re read from the flash memory of a vulnerable device and allows for remote code execution with root system privileges when exploited.
The original article contains 533 words, the summary contains 191 words. Saved 64%. I'm a bot and I'm open source!
For encryption, the client and server need to share their private keys.
This is incorrect, for asymmetric (public-private) encryption. You never, ever share the private key, hence the name.
The private key is only used on your system for local decryption (someone sent a message encrypted with your public key) or for digital signature (you sign a document with your private key, which can be validated by anyone with your public key).
For the server, they are signing their handshake request with a certificate issued by a known certificate authority (aka, CA, a trusted third party). This prevents a man-in-the-middle attack, as long as you trust the CA.
The current gap is in inconsistent implementation of Organization Validation/Extended Validation (OV/EV), where an issuer will first validate that domains are legitimate for a registered business. This is to help prevent phishing domains, who will be operating with TLS, but on a near-name match domain (www.app1e.com or www.apple.zip instead of www.apple.com). Even this isn’t perfect, as business names are typically only unique within the country/province/state that issues the business license, or needed to be enforced by trademark, so at the end of the day, you still need to put some trust in the CA.
You've missed a key detail in how asymmetric encryption works:
For asymmetric encryption algorithms, you essentially have two keys - a "private" key, and a "public" key
If you know the private key it is trivial to calculate the public key, but the reverse isn't true - just given the public key, it is essentially impossible to calculate the private key in a reasonable amount of time
If you encrypt something with the public key you must use the private key to decrypt it, and if you encrypt with the private key you can only use the public key for decryption
This means that my server can advertise a public key, and you can use that to encrypt the traffic so that only the server that knows the private key can decrypt it
But how does the encryption work if you have the public key? Since your computer knows how to encrypt the data with the public key, couldn't you use that same public key to run that algorithm in reverse? If not, since the public and private keys are not the same, how does the private key go about decrypting that data?
The actual math is way beyond me, but the algorithm is "one way" - it exploits the fact that given two prime numbers (ie, the private key) it is trivial to multiply them together, but if you only know the result (ie, the public key) it is computationally very expensive to determine the original prime factors. If you pick big enough numbers, it becomes effectively impossible to undo the multiplication
Security
Hot
This magazine is not receiving updates (last activity 50 day(s) ago).