Cyber Surveillance During Your Afternoon Coffee Break
Pushed by technology and competition, organizations are adopting the use of mobile devices for an empowered remote workforce. No longer are businesses limiting smartphone and tablet use to email and scheduling. Instead entire suites of business services are accessed through mobile browsers and, increasingly, through mobile apps. Business users use public wireless networks, often out of necessity.
Virtual private network (VPN) technology and ubiquitous Transport Layer Security (TLS) encryption have mitigated many eavesdropping tactics used against mobile workers. But companies are not deploying the full protection afforded by VPN technology to business mobile devices as widely as they could, leaving these users more vulnerable to eavesdropping.
More ominously, often Domain Name System (DNS) exchange data is overlooked as an attack vector. As shown by the recent ransomware attacks out of Europe, a minor security breach can ripple across the Internet.
Using Public Networks
As the remote workforce continues to grow, the practice of working from a coffee shop or other public space is often seen as essential. Given that almost all Internet services are protected by TLS these days, does the use of public networks remain a concern?
While TLS protects the majority of web apps and mobile interfaces, DNS data is still transmitted in the open, without encryption. Over wireless networks, this trait makes this data free for the taking by a passive eavesdropper. Any public wireless network is a risk, even those using WPA2 encryption where the key is shared among all users. Using VPN technologies can alleviate some issues, but a misconfiguration or limitation of a VPN solution may leak data.
Let’s examine common circumstances that can expose seemingly insignificant information.
A user’s Google Chrome web browser often attempts to determine if a DNS server behaves as expected. One way it does this is by querying random names using the configured DNS domain:
- 10.0.0.23 → 10.0.0.1 DNS Standard query A zxcvjvvcnai.AGENCY.local
- 10.0.0.23 → 10.0.0.1 DNS Standard query A ggdkijpezsvsa.AGENCY.local
- 10.0.0.23 → 10.0.0.1 DNS Standard query A mjavypnmcnxqypz.AGENCY.local
Here, Chrome made this request using the DNS domain of an internal network, most likely from a VPN interface not yet connected. An attacker can now assume that his target may be doing work with this AGENCY.
DNS service record queries also may leak information:
- 10.0.0.42 → 10.0.0.1 DNS Standard query SRV _ldap._tcp.Reston._sites.dc._msdcs. COMPANY.com
The eavesdropper can conclude that this user’s machine is a member of an Active Directory at the EXAMPLE company, and he may be affiliated with the Reston office.
Even security tools may provide useful data:
- 10.0.0.99 → 10.0.0.1 DNS Standard query A csm90-en.url.VENDOR.com
- 10.0.0.99 → 10.0.0.1 DNS Standard query AAAA csm90-en.url.VENDOR.com
- 10.0.0.99 → 10.0.0.1 DNS Standard query A wfbs9.icrc.VENDOR.com
The adversary recognizes the name of a security VENDOR and can assume that the user has installed VENDOR’s anti-malware software.
A Wi-Fi user works for an organization that offers the convenience of access to their business tools over the public Internet from a mobile device:
- 10.0.0.14 → 10.0.0.1 DNS Standard query A wiki. COMPANY.com
- 10.0.0.14 → 10.0.0.1 DNS Standard query A timesheets. COMPANY.com
- 10.0.0.14 → 10.0.0.1 DNS Standard query A bugs. COMPANY.com
The snooper now knows what kind of corporate services COMPANY uses, and now has a list of systems to target in attacks.
By collecting DNS traffic, the snooper acquires insight into how to shape an attack more effectively. He could develop a targeted phishing attack, contacting all COMPANY users that work on the AGENCY contract and asking them to click on a link to get an update of the VENDOR’s security software.
While no Internet service provider is private, eliminating the threat of local, passive eavesdropping is relatively easy.
- Configure VPN clients, including mobile devices, as “always-on,” requiring VPN use for all traffic. Many VPN solutions (Cisco, Palo Alto, strongSwan) provide how-to guides. This measure can reduce the leakage of DNS and other metadata. Configure the client so DNS isn’t required to establish the VPN tunnel.
- Provide wireless hotspots (either dedicated or enabled on an employee’s smartphone) and give training on how to configure them with unguessable WPA2 passphrases. In other words, don’t use publicly available Wi-Fi.
- Remember, however, that mobile hotspots do not eliminate the threat of cellular network interception. It’s best to combine these hotspot devices with VPN.
- Test laptop and mobile device configurations. Setup a “public network” lab, capture traffic, and see how the laptop behaves in the real world. Understand what information your clients leak, the risks, and develop a mitigation strategy if warranted.