An issue in Unix virtual private networks was disclosed recently, where an attacker could potentially hijack a TCP stream, even though that stream is inside the VPN. This attack affects OpenVPN, Wireguard, and even IPSec VPNs. How was this possible? Unix systems support all manner of different network scenarios, and oftentimes a misconfiguration can lead to problems. Here, packets sent to the VPNs IP address are processed and responded to, even though they are coming in over a different interface.
The attack initially sounds implausible, as an attacker has to know the Virtual IP address of the VPN client, the remote IP address of an active TCP connection, and the sequence and ACK numbers of that connection. That’s a lot of information, but an attacker can figure it out one piece at a time, making it a plausible attack.
The scenario suggested in the disclosure was a rogue access point with multiple clients. An attacker can scan the private address space, 10.*.*.* for example, and discover all the VPN clients on the network. Unless the client’s firewall is configured to block it, the VPN interface will happily respond to that scan when the correct IP address is probed.
Once a target has been found, the next step is to figure out an active TCP connection. An attacker can’t see the data inside the VPN, but can see the packet size and frequency. Sending a TCP SYN packet with a spoofed source address will trigger a different response based on whether it matches the addresses and ports. Keep in mind the address and port space here: An attacker could make an educated guess about the remote port, and already has the target’s IP address. The remote IP address and the target’s source port still need to be guessed.
After the addresses and ports are discovered, the TCP sequence number and ACK number can each be discovered in a similar way, with the VPN packet size and timing. Once an attacker has all this information, he can inject data into a TCP stream, but can’t read data from within the VPN. An HTTPS connection still completely protects against this attack, so it’s of limited real world value. Even so, it’s a clever attack, and the resulting fixes will make the entire network stack more secure.
When I heard about this attack, I reached out to [Jason Donefeld], creator of Wireguard, and asked about the status of this vulnerability.
WireGuard’s wg-quick(8) has had mitigations in place since before that
announcement came out on oss-sec.
[Jason] has had a busy few days, with Wireguard finally pulled into the Linux net-next tree, meaning it should land in the 5.6 release. I was glad to hear that fixes were already landing for this problem, and am looking forward to Wireguard’s official inclusion in Linux.
Patch Tuesday
Windows Patch Tuesday included quite the roundup of vulnerabilities, including an escalation of privilege being actively exploited in the wild. That zero-day, CVE-2019-1458, is being used in conjunction with a Chrome zero-day. The Chrome vulnerability is a race condition that results in a use after free. These two together have been observed as part of the WizardOpium attack, which has primarily spread through Korean web sites.
A second vulnerability, CVE-2019-1468, was patched this Tuesday. It wasn’t actively being exploited, but was quite the bug in the font handling code. Documents or web sites could embed a malicious font that would execute arbitrary code simply by being displayed. This exploit is a good example of why running Windows 7 after January 2020 is a dangerous proposition. This one will get fixed, but the next one won’t.
Plundervault
Stealing a play from the world of overclockers, researchers have discovered that undervolting certain Intel processors can cause errors in the secure CPU enclave. Calling the attack Plundervolt, researchers used an undocumented instruction to change CPU voltage on the fly and change protected bits.
Intel responded quickly, and has released a microcode update to fix the issue. This flaw affects processors all the way up to Intel’s 9th generation. The full paper is available, go check it out to learn more.
Ring
Making the news recently is Ring, particularly the creepy videos of “internet hackers” talking to children through Ring cameras in their home. It was humorous to watch the evening news, and hear the announcers report on this near mystical hacking activity. Let’s see if we can pierce the veil of mystery.
The obvious starting point is password reuse. It’s likely we have all had at least one account exposed in a data breach. Many of those breaches, unfortunately, included plaintext passwords. A very quick path to getting your account compromised is to reuse a username and password that’s been exposed in a breach. Ring claims that each account breach was the result of weak passwords or password reuse, combined with the lack of two factor authentication.
It appears that a tool has been circulating the forums that loads a username/password list, and attempts to log in to the Ring service through a list of proxies. Those proxies allow an attacker to make many guesses in parallel without tripping Ring’s brute force mitigations. These accounts were almost certainly not targeted against the accounts that were cracked, they were just the unlucky ones.
Vice’s Motherboard turned up some additional information about what was behind these pranks. Apparently a podcast called NulledCast specializes in trolling people on the air. It appears that these incidents were a part of that podcast, and the pranksters didn’t intend to attract nearly so much attention.
can someone show me something that uses SGX? I’ve been following it since the first chips and know of no product that uses it…
Have they gotten it working? Only one’s who really benefit are cloud providers.
It’s used primarily for DRM.
“Intel responded quickly, and has released a microcode update to fix the issue.”
Never trust binary blobs.
“This flaw affects processors all the way up to Intel’s 9th generation.”
So, even the Intel 4004 is affected?
Yes
Plundervolt…
No as pointed out in the article its “Plundervault”
Oh wow, it looks like the paper itself does call it plundervolt. Heh, oops.
Plundervolt was also called V0LTpwn ( https://arxiv.org/abs/1912.04870 ) by another group, which independently discovered it (but reported it a bit later to Intel). A third group found it, too. There are Acknowledgements at the bottom of the Intel security advisory website giving credit to all of the groups ( https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00289.html )
All it boils down is the discovery of the undocumented MSR register that shouldn’t exist. It completely punches a hole through privilege levels. Fault Attacks are well known, and are possible if voltage or frequency can be controlled by an attacker. It was a huge oversight by Intel to keep this MSR (I guess it existed earlier) when introducing SGX.
About the VPN hack: From what I read in the original release and I read up on this from another news source earlier this requires the victim machine to accept what the Linux devs used to (if they still don’t) amusingly call Martian packets. The researchers specifically mention that the attack was not effective against Ubuntu versions until later versions infected with SystemD. They went on to say it was due to a SystemD config that turns off martian filtering.
I don’t use SystemD. I also use martian filtering and since I’m paranoid about address spoofing I also add filters to all public ports for all of the private and demonstration address ranges. I do need to beef up my IPv6 defenses though. And probably add dest address filtering.
I’ve always found it an annoying habit of *nix systems to treat all addresses to a machine the same regardless of interface. And now its biting. I knew it was a bad idea.