There’s no such thing as free wi-fi – a lesson in VPN security

SecureData’s long-standing ethos has been to dispel cybersecurity myths with a dose of objectivity from research findings. Our dedicated security intelligence team regularly looks above the parapet to anticipate and stave off threats from the cyber battlefield. When the team uncovers something particularly meaningful, we share it. Today’s myth-busting story was originally told by our Chief Security Strategy Officer, Charl van der Walt, at our Cybersecurity Summit event in November 2019. It’s a cautionary tale about how there’s no such thing as free wi-fi. Here’s why.

Rush hour at Port 445

Earlier this year, the incident response team responded to an alarm triggered by our managed threat detection and response regarding outbound internet traffic coming out of some endpoints we were monitoring. What was curious about the alarm was that the traffic was going out onto the internet on TCP Port 445. This is the port used for server message block (SMB) protocol, which is effectively the language that Microsoft systems use to talk to each other – for authenticating onto a network, for mapping drives etc.

We pay particular attention to Port 445 because when your Windows machine connects to a service that purports to be an SMB service (like a printer or file server), your endpoint sends an encrypted hash of your password to the service. When we see the traffic of this nature, your endpoint could be believing that it’s connecting to a legitimate SMB service, and sending your password to that service without you knowing. This is bad news if it’s not actually a legitimate service

Curious and curiouser

What was even more curious about this alarm was that both of the endpoints belonged to employees at the same hotel, at the same time. Down the investigative rabbit hole we went, searching for malware, malicious documents, phishing. But we couldn’t find a single indicator of compromise on the machines. It was only when we looked at the historical event data that things got a bit fishy – a connection had been made from the endpoints to an internal server at the hotel called ‘Printer HQ’. The IP address associated with that server had been the same address we’d seen the traffic going out to. The endpoints believed they were connecting to an internal printer, but looking at the IP address, it was associated with a DNS domain called domain.com, a domain name provider using DNS wildcarding

You’ve been spoofed

We investigated domain.com, and in the IP configurations assigned to the endpoints belonging to the employees in the hotel, the DNS search suffix was domain.com. Imagine this – you join a wi-fi network with your computer and your IP address, your gateway router, your DNS server and the DNS search suffix are assigned to your computer by that wireless access point. The latter – the DNS search suffix – is used to qualify resources when you haven’t qualified them completely. As an example, if the internal website within your organisation is called ‘intranet’, and you type ‘intranet’ into your browser, your machine will peg that suffix onto the back of the search term and then go ask the DNS server for the IP address associated with it.

In this case, we suspected that the wireless access point’s default configuration contained domain.com, and the hotel simply never changed it. So, the endpoints were looking for their organisation’s internal printers, couldn’t find the resources on the hotel network, yet somehow came up with this internal IP address.

This is a form of DNS spoofing. A typical DNS spoofing attack involves your machine looking for an IP address associated with a resource. The machine speaks to the DNS server, but the attacker somehow fiddles with that and sends the wrong information to the machine. In this instance, when the employees were connecting to the wi-fi access point, they were subjecting themselves to a systemic DNS spoofing attack. What happened to the machines was not malicious, but accidental. In a malicious scenario, a hacker could easily mess with your DNS through the free wi-fi.

Time for some testing

We decided to set up a test and visited local hotels to replicate the scenario. The same thing happened. So, we decided to try and exploit the situation, using a hacking tool called Responder. We created a wi-fi access point, a software access point, the client joined it, and then we started Responder in a bid to execute the exact attack just described. It was possible to capture a hash of the user’s password. Fortunately, there is technology to mitigate this issue, right? If you run VPN software on your client, then you can connect safely to the internet through that encrypted tunnel running from your endpoint, over the wi-fi access point, to your corporate network. Well, in this testing scenario, the problem was mitigated. And actually, the employees in question did have VPN software running. So why then did the attack we saw from our managed threat detection still happen?

Security limbo

When you join free wi-fi – in an airport, or a hotel for example – you don’t just automatically join. There’s some form of pop up, with your browser taking you to what’s called a captive portal site. When you get there, you might be expected to authenticate, click ok, give an email address, whatever it may be before you finally gain access. But before you’re connected to the wi-fi access point, and your machine’s IP configuration has been assigned by that access point, you can’t actually connect to your VPN because you’re not on the internet yet.

Your VPN tunnel, the thing that’s supposed to protect you, is not working. You’re instead captured on the wi-fi access point, under its control. Your machine will be trying the whole time to make connections to the internet – your browser and your apps talking into the other, trying to connect. If the captive portal is in place, it will respond with a HTTP request and deny your access to the site, redirecting you to the captive portal interface. The minute you get access to the internet, as content starts to render, your VPN can establish, and you’ll be freed from the captive portal limbo.

Plugging the leak

Unfortunately, while you’re in that captive state, benign data can still leak out. The endpoint believes it’s on a network, so it starts doing all the usual things – broadcasting its IP, looking for resources etc. The VPN is not effective at this point. Also, the minute you connect the endpoint to the wi-fi access point, the apps on the device start to go crazy with pop-ups. This is the captive portal redirecting the encrypted web traffic to its own server. This is essentially a warning; our SSL telling us that we’re connecting to something we shouldn’t be. But you’re essentially subjecting yourself to a man in the middle attack. Connections are flying out to servers in the background, but it’s not you surfing to those sites, it’s all of the apps and widgets on your endpoint talking to the web, trying to find the right servers. It’s a dangerous situation to be in.

Time for lockdown

There is, theoretically, a solution. VPN software usually comes with a ‘Lockdown Mode’ (Captive Portal Mitigation). Essentially, it’s supposed to completely lock down the traffic from your endpoint while you’re connecting through the captive portal. We decided to test it as part of our investigation, and it worked like a dream. The VPN client provides you with an embedded browser, preventing any traffic from going out while the connection is being established.

However, in this particular experiment, there still seemed to be some DNS requests going out, even though the VPN had been established and was up and running. We thought we’d discovered something groundbreaking and remarkable with this but, as it turns out, this is exactly how captive portal mitigation works. It specifically allows certain traffic out, so that your machine can operate on the network. It’s not exactly clear why all of this traffic is allowed, but essentially a user can still be vulnerable to a Responder attack in the way we illustrated through our experiment – even when technically locked down.

The trouble with VPN networks

What can we learn from this curious case of wi-fi and VPNs?

  • Operating systems behave differently to Windows. We ran a subsequent test, establishing VPNs on Apple and Android environments to see if the same incident happened. Largely speaking, Apple and Android are less ‘talkative’ than Windows, which makes them less vulnerable (although not immune) to SMB protocol issues.
  • The mobile operating system makes a huge difference. Having a 3G connection active before you authenticate to the captive portal (and therefore being able to establish your VPN before joining) can help mitigate the problem we’ve outlined here. However, if travelling and therefore roaming, you probably won’t want to use your 3G connection.
  • Security software isn’t necessarily secure. Over the past month, we’ve sent out around 40 advisories to clients, which included information on recent issues with VPN products, such as NordVPN. Like any other software, security solutions are software. Security software needs to be patched and updated regularly. You can’t install security software and forget about it. You have to maintain it. Same goes with VPN software.
  • Think about authentication. The incident we’ve described here comes down to hackers trying to steal your passwords, and this is usually the big thing that attackers steal. Regardless of whether you’re on a corporate network or wi-fi access point, bad guys will be targeting your passwords, and they’re pretty successful at it. Organisations should consider multi-factor authentication as an alternative.
  • Take an endpoint approach. What this particular incident serves to highlight is you can’t just protect your perimeter. You have to understand that the bad guys are also aiming for your endpoints, and sometimes endpoints are outside of your perimeter.At SecureData, we often talk about ‘knowing thyself’. In these types of security scenario, to effectively mitigate the problem at hand, you need to know who should and shouldn’t have access to the network/endpoints (identity and access management). You need to know your threat model – threat modelling is a discipline that requires you to partner with someone, think creatively and laterally about where risks really are, and how to react to those assaults. The latter comes back to testing your networks and endpoints, and using telemetry on the endpoint to actually investigate what happened in an incident and what it means for your business.But ultimately, you need to be asking yourselves, the industry and the providers of security solutions – does it actually work?
  • Share