Up first is a clever attack against VPNs, using some clever DNS and routing tricks. The technique is known as TunnelCrack (PDF), and every VPN tested was vulnerable to one of the two attacks, on at least one supported platform.
The first attack assumes an attacker is on the same network as the victim, and works by manipulating the victim’s routing tables. How? DHCP. We’re used to DHCP giving out local network addresses, but there’s nothing to prevent giving a client a fully routable address. Now here’s the trick: Many VPN clients make an exception for traffic sent to the local network. An attacker just hands out an address and subnet telling the victim machine that the entire Internet is on the local network. The attacker can capture all that traffic, route it correctly, and the VPN user doesn’t know the difference.
The mitigation is to disable local network access while the VPN is connected. Many clients do this, at least on some platforms. It was interesting to see that on iOS every tested app was vulnerable to this data leaking attack, and nearly every one of them on the macOS. It appears that the iOS API for working with VPNs has only recently introduced a control for how to handle local network traffic, leading to the abysmal results.
The second attack moves that attacker out of the local network, and somewhere on the network path, able to capture traffic and mess with DNS. Keep in mind that once a VPN is established, DNS traffic should flow though the VPN, but there is a narrow window to cause grief — when the VPN client does the DNS resolution to find the VPN server IP address. Now keep in mind, that is an attack pattern that VPNs are designed to handle. Any VPN client worth its salt authenticates the VPN server it’s connecting to. The problem is that most VPN clients also have a rule, that traffic sent to the connected VPN server is exempt from being encrypted by the VPN.
The attack is to spoof the VPN DNS to point at the Internet address that will receive the traffic you want to capture. Let’s just say you know my VPN server is at vpns.example.com, and you want to capture my connection to Hackaday. Hackaday uses the IP 192.0.66.96. So you spoof the vpns.example.com DNS request, and tell my VPN client that it should connect to 192.0.66.96. Then, because you are on the network path, you can redirect those VPN packets to the real VPN server. But when I connect to Hackaday on purpose, the destination IP matches the VPN IP, and some clients will just send that traffic outside the VPN.
The twofold solution is to use one of the various secure DNS extensions, like DNSSEC or DoH, and then to write VPN clients that can keep track of which connections are VPN traffic, and which are not. For those wondering, our favorite VPN technology, Wireguard, fared well on the test. On Linux and Android, it got a perfect score, and only the macOS and iOS versions really had a problem, allowing local network traffic to escape the VPN.
Decipher the Mutant, Capture the Flag
[Vikrant] put together a Capture the Flag (CTF) entry for AppSec Village at DEF CON this year. It was based around the Mutant language, which is an attempt at compiling code into an encrypted state, to keep it secure and hard to reverse-engineer. The problem with those obscured-code ideas is that there has to be a way to disentangle that code in order to run it.
The way to solve this challenge was to borrow code from the official Mutant compiler, and build a deobfuscator using the official code. That’s not to say it’s an easy challenge, but it’s not clear that Mutant will do a whole lot to actually improve security. But as a project, it’s a lot of fun, and makes for a great CTF challenge.
The Other Discord
760,000 user records have leaked from Discord.io. That’s a bunch of usernames, email addresses, and password hashes from the Discord.io service, which is completely separate from the Discord web site. Discord.io is a third party service that provides customized Discord invites. And while it’s no fun that this information escaped, at least it wasn’t the Discord user database. That would be just about all of us.
Bits and Bytes
Nmap is great for scanning for machines and open ports. The only down side is… it’s kinda slow. This irritated [Joshua] enough to dig into why — and how to fix it. It turns out nmap is being slow on purpose. There is something to be said for not DOS’ing the scan target after all. If it’s just too slow for your tastes too, it turns out the solution is a tweaked value in service_scan.h and a recompile. Now you know.
Apple has joined the ranks of OS vendors that now include anti-malware scanners in their OS. On macOS, that’s XProtect Remediator (XPR). And if you’ve ever checked up on what XPR is doing on a Mac machine, you may find it a bit odd. Apple has picked some unique names for the malware XPRD is looking for, so you’ll see log messages like FloppyFlipper NoThreatDetected status_code 20. Silly name, but all is well. The other message to know about is BadPluginServiceSignature, which sounds terrible, but just means that the XPR definitions have been updates, and the scanning services are restarting to grab the new definitions.
And if you didn’t make Black Hat this year, you can join in some of the fun a bit late, as the slides from various presentations have been released. Those will have to hold us over for now, though keep an eye on the Black Hat Youtube channel, to eventually get the talk recordings, too. And if you see something in there that we missed, let us know about it!
0 Commentaires