Vulnerability in almost all hotspots!

First of all, who pays in the W-Lan hotspot, it's your own fault!.

In penetration testing (pentesting), we have repeatedly listed the recursive DNS resolution from the LAN and especially in guest W-LANs as a weak point (not a security gap!).

However, since the scenario was never really comprehensible for our customers, we thought about how we can make the vulnerability more tangible, which is the reason for this article.

Why is recursive, unauthenticated name resolution so dangerous, especially in free W-LANs or guest W-LANs with a voucher system?.

Table of Contents

Businesses protect their networks

Many companies already protect their networks effectively against improper use - for example with a proxy - without user data there is no access to the Internet. You need a “voucher” to surf the guest WiFi network – usually only valid for a few hours.

In open W-LANs, you may know it from Telekom hotspots at McDonald's, you can often surf for three hours for free, but otherwise you have to buy access. In other hotspots you have to authenticate yourself with Facebook or receive a voucher.

Especially in cafés and hospitals in our region, I keep seeing cloud services that are used for a voucher system - if you start the browser, you end up on some URL on the Internet - the same applies to Telekom and Vodafone hotspots: Here, too, the address is im Internet and is resolved via DNS.

Does your corporate IT have weaknesses?
We advise you!
Inquire now

In any case, DNS works

Unfortunately, it is possible to send DNS queries out into the world without a voucher or other authentication and at the same time receive answers. Simply tested with "dig www.google.de" you get the IP address back. That means there is a way to the internet.

DNS tunneling in hotspots

How should one take advantage of that or even surf for free?

To do this we have to go a little into this DNS protocol Get in - DNS is a hierarchical system, which means that if I ask for AAAAA.www.google.de, this request goes first to the DNS server in the (W-)LAN. This does not know the IP address and first asks its “father DNS” (usually the provider’s DNS) whether it knows the IP. If he doesn't know this, the domain will be dissolved piece by piece by those responsible for the zone, starting backwards. “.de”, then “google.de”, then “www.google.de” and so on. Since the responsible DNS server for Google is known below the DNS server, we will then query this directly for further queries, i.e. for everything that comes “below” from Google.

This is exactly the weak point, because if we now send requests with data, for example "Text123.www.google.de", the "data packet" ends up on Google's name server.

The test setup

We have created an NS record for one of our domains (no, we don't publish it here because we actively use it). This NS record now points to a server controlled by us. Here we have now set up a fake DNS server, which receives the data and sends the appropriate answers; In our case, this is done using TXT records. If we now receive a DNS (TXT) request from a WLAN with a voucher, we can process the data normally and send replies.

Since DNS and TXT requests are plain text, this can be super compressed, which is why acceptable speeds can be achieved.

 
DNS tunneling

Now we have programmed a client on our MacBook with which it is possible to tunnel network requests (encrypted, of course) to our controlled DNS server. We have made some adjustments to the "Iodine" software for this purpose. Using password authentication to our DNS server and AES256 bit encryption, we are now talking to our DNS server via BASE64 coding.

To do this, our client establishes a permanent connection using the DNS server. We then tunnel SSH over DNS from our server to our client (SSH reverse tunnel).

Using this reverse tunnel (already via the Internet without authentication!), SSH can be used as a SOCKS proxy, so that you can also surf the Internet - via our "proxy", if you like to call it that.

We tested this in various hotspots from Vodafone and McDonald's. In the PoC video you can see the successful SSH connection via the Internet in a McDonald's hotspot from Telekom without prior registration, but see for yourself.

–small update 13.12.2017–

We were also able to test it successfully in an ICE train from Deutsche Bahn last night, but it didn't surprise us...

 
Are you interested in comprehensive advice on the subject of IT security?
Call us or use the contact form!
Contact us now