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.
No comments:
Post a Comment