ProSec GmbH

+49 261 45093090

  • About us
  • Services
    • Detection services
      • Classic penetration testing
      • Pentest as a service
      • Web application pentest
      • Vulnerability analysis
      • Red teaming
    • Solution services
      • IT security consulting
      • Data protection
        • GDPR
    • Education services
      • User awareness
      • Trainings
        • Junior penetration tester
        • Penetration tester web
        • Penetration tester network
  • Wiki
  • Jobs
  • Contact

Vulnerability in almost all the hot spots!

First of all, it is your fault who pays for the WiFi hotspot!

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?

Bild einer Welle im Meer

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.

Does your company's infrastructure have vulnerabilities?

We advise you!

Inquire now

So in any case, DNS works

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.

Ein Schema Grafik zu DNS Tunneling

How should you take advantage of this and even surf for free?

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.

The "test setup"

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.

DNS Tunneling 2

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.

–short Update 13.12.2017–

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

Bild des stellvertretenden Geschäftsführers Immanuel Bär

Do not want hackers to access your infrastructure?

Find out more about penetration tests now!

More about penetration testing!

Zuletzt aktualisiert am March 29, 2021

OUR LOCATIONS

  • Headquarters:
  • ProSec GmbH
  • Robert-Koch-Straße 1-9,
    D-56751 Polch, Germany

  • Berlin office:
  • ProSec GmbH
  • Friedrichstr. 123,
    D-10117 Berlin, Germany

 

  • Munich office:
  • ProSec GmbH
  • Franz-Joseph-Str. 11,
    D-80801 München, Germany

TOP-SERVICES

  • Penetration testing

  • Vulnerability analysis

  • Trainings

  • IT security consulting

  • Social engineering

All rights reserved. © 2022 ProSec GmbH | Imprint | Privacy policy | Sitemap