The router of all evil
Underestimated threats of Home-office
How vulnerable home-routers can compromise corporate security
A major new element we need to consider since our workforce is connecting remotely is the security of the user’s home router. A totally new set of threats, risks and potential compromises is introduced by vulnerable or misconfigured home routers. And the traditional network security controls we’re currently using to protect remote workers are not suited well for dealing with this situation.
Clear technical strategies and perhaps unconventional approaches are required to fully defend remote workers that are connecting via untrusted routers from home.
All your users’ LAN belong to someone else…Find detailed advice in the paper
an underestimated threat
- Remote work using Wi-Fi has become commonplace
- Captive Portals are commonplace
- Home routers are insecure, or insecurely configured
- Home routers are a target
- Our primary security response appears to be Secure Remote Access
- Traditional security solutions don’t fully mitigate the threats, they could even make things worse
- A holistic approach, new thinking, and a precise application of technology are needed to reduce the risk
Why DHCP and Captive Portals exist
Dynamic Host Configuration Protocol
The DHCP protocol is used by the home router to define important configuration settings for the endpoint. As such, a compromised home router can exert extraordinary influence over the configuration and behaviour of a remote workers computer, and needs to be considered in your threat model.
- Assign network config to devices
- Rich set of Options
(IPv4 & IPv6, Routes, DNS, Preboot eXecution Environment)
Captive Portals exert even more influence by blocking outbound internet connections (required to establish a VPN) and influencing the behaviour of the default browser.
- “Free” internet with strings attached
- Controlled by the provider via AP
- Influences the behavior of the browser
Attack scenario 1: Routing control through DHCP
Since we control DHCP, we also control routing. Using DHCP and routes we can bypass a VPN and steal RDP credentials.
Attack scenario 2: OS-boot control through DHCP
Since we control DHCP, we also control the OS booted. Using DHCP and PXE we can boot the endpoint into our very own Operating System.
Attack scenario 3: Browser control
Since we control the Internet, we also control the browser. We are tricking the VPN into believing it’s faced with a Captive Portal and afterwards proceed to tricking the user into triggering malware.
Attack scenario 4: Responder attack
We run a Responder attack, getting fully connected even in lock-down mode. Because we can inject a DNS search suffix we can PiTM any traffic to an unresolved host name.
Putting secure remote access to the test
We have tested several commonly used solutions in different configurations against various kinds of attacks
Tested attack scenarios:
- Sniffing sensitive data
- DNS ‘Person in the Middle’ (PiTM) or spoofing
- Harvesting credentials using spoofed website
- Capturing Windows hashes via Responder
- Using the Browser as a tunnelling proxy
- Using IPv6 to interact with host
These findings are a cause for concern.
- Our initial concerns about the failure of VPNs to protect machines behind malicious AP all hold true.
- Even once fully established, a carelessly configured VPN barely does better at mitigating the identified threats.
- ‘Lock down’ features that are intended to mitigate the captive portal problems do indeed address some issues, but are not universally effective in mitigating the full set of threats we considered.
- The findings are not consistent across all vendors, so vendor selection does matter.
Comparing 'Zero Trust' and 'Secure Remote Access'
- Identity Access Management
- Granular control to resources
- Monitor and inspect network
Different in principle
- Zero Trust is not an extension of the perimeter
- Every transaction is authenticated and authorized
- Assumes breach
Zero Trust is a mindset, not a technology!
The Zero Trust security model eliminates implicit trust in any one element, node, or service and instead requires continuous verification of the operational picture via real-time information fed from multiple sources to determine access and other system responses. The Zero Trust security model assumes that a breach is inevitable or has likely already occurred…
What to do now
What actions can be taken in the short, medium and long term to address the problem?
Next week you should start to:
- Update your VPN to the latest version
- Ensure ‘route precedence’ is enforced and working
- Review your ‘split tunnelling’ configuration options with contemporary threats in mind – Forced Tunnel, with exceptions should be your model-approach
- Control all DNS settings
- Fully qualify internal host names
- Review VPN session time-out settings
- Use a firewall or EDP to control sensitive outbound connections (e.g. SMB).
In the next three months:
- Review our prior research and detailed technical guidance on Secure Remote Access
- Evaluate and control dual stack use (IPv4 & IPv6)
- Internalize the true risks faced by your home users
- Carefully consider what security threats your security technology is supposed to address
- Engage with your vendors
- Examine your vendor choices carefully. Not all products address these risks equally.
Within six months:
Consider some fresh paradigms, e.g.
- Sponsoring and controlling home network connectivity & home IT
- Deploying SD-WAN or a ‘Remote Access Point’ for all users, or where appropriate
- Mobile data and / or private APN for remote workers
- Begin your (proper) Zero Trust journey