Vulnerability in almost all the hot spots!

In pentesting, we have repeatedly listed the recursive DNS resolution from the LAN and especially in guest W-LANs as a weak point (no security gap!). However, since the scenario was never really understandable for our customers, we thought about how we could make the weak point more tangible, which is the reason for this article.

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

Many companies already protect their networks effectively against misuse,  for example with a proxy.  To surf the guest WiFi you need a “voucher” – usually only valid for a few hours. Without user data, there is no access to the Internet.

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

Especially in cafes and hospitals in our region, I see cloud services that are used for a voucher system. If you start the browser, you end up on any URL on the Internet. The same applies to Telekom and Vodafone hotspots: the address is also here on the Internet and is resolved via DNS.

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

To do this, we have to know about DNS protocol a little. DNS is a hierarchical system, which means that when 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 his “father DNS” (usually the DNS of the provider) whether he knows the IP. If he does not know this, the domain is resolved to piece by piece by the zone managers, starting backward. “.de”, then “google.de”, then “www.google.de and so on. Since the responsible DNS server for Google is known below the de DNS server, this is then requested by us directly for further inquiries, i.e. for everything that comes “below” Google.

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

We have created an NS record for one of our domains (no, we do not publish this here because we are actively using 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 corresponding responses; in our case, this is done using TXT records. If we now receive a DNS (TXT) request from WiFi with a voucher, we can process the data normally and send responses.

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

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. For this, we have made some adjustments to the “Iodine” software. 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 via DNS from our server to our client (SSH reverse tunnel).

Using this reverse tunnel (already over 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 Vodafone and McDonald’s hotspots. In the PoC video, you can see the successful SSH connection over the Internet in a Telekom McDonald’s hotspot without prior registration.

We were also able to successfully test it in a Deutsche Bahn ICE, but we were not surprised …