Wireless Network Authentication at Vantone Inn

The wireless network at Vantone Inn requires username and password authentication. On Windows, as soon as you connect to the “Vantone Inn” access point, a browser window will pop up, displaying the user authentication interface. Visiting any HTTP address will also redirect to the authentication interface. Once authenticated, the wireless network is unobstructed. Today, a classmate asked me, how can this access point be so NB, can force the computer to pop up a window, is it a virus?

I don’t know the answer to this question, so I captured some packets and then Googled it. For ease of understanding, let’s not discuss the automatic pop-up of the browser first, let’s think about how to implement “visiting any HTTP address will redirect to the authentication interface”.

What are the steps to visit an HTTP page?

DNS queries the IP address of the domain name
Connect to port 80 of this IP
Send GET /path/to/page HTTP/1.1 request
Receive the returned HTML and display it in the browser
We see that when visiting any HTTP page without authentication, it will redirect to http://172.16.1.2/webAuth/index.htm?http_referer this authentication interface (where http_referer is the URL trying to be accessed), enter the username and password to authenticate successfully, and then it will redirect to the http_referer, the URL that was previously trying to be accessed.

There are two ways to hijack normal browser access:

Hijack DNS resolution, return the IP of the authentication server for all DNS requests. This method cannot handle the situation of directly accessing the IP address.
Hijack routing, route all 80 port requests of unauthenticated users to the authentication server, and the authentication server pretends to be the target IP to return the authentication page. It is speculated that Vantone Inn uses this scheme.
Specific to the implementation used by Vantone Inn, the 80 port request of unauthenticated users, except for the IP in the whitelist (of course including 172.16.1.2), all return HTTP 302 redirect, redirect to http://172.16.1.2/webAuth/index.htm?http_referer, where http_referer is the actual request URL in the HTTP header.

Observant students may have found that when unauthenticated, visiting Google, Gmail and other HTTPS pages cannot connect, and will not redirect to the user authentication interface. This is because the access device only sends the 80 port request of unauthenticated users to the authentication server, and all requests of other ports (except the 53 port used by DNS) drop packet, refusing access. HTTPS is port 443, so it cannot connect.

Some people will ask, why not hijack HTTPS? Because HTTPS needs to verify the server certificate, the Internet authentication system obviously cannot get Google’s private certificate, so it cannot hijack. It is this certificate signature mechanism that makes man-in-the-middle attacks impossible, thereby ensuring the credibility of HTTPS connections.

Now let’s go back to the beginning and talk about “pop-up browser”. In fact, this is the result of some kind of “tacit agreement” reached between the operating system and the Internet authentication system, because this so-called Captive Portal Web authentication technology has been widely used in public wifi access points.

We know that Windows will prompt “Internet connection”, “connection is limited” and so on when connecting to the network. How does Windows know whether it is an Internet connection? After Windows connects to a network, it will automatically visit www.msftnsci.com. If it can return the correct result, it is an Internet connection. On public wifi using Captive Portal, the return is a 302, obviously not the correct result, so it will show “connection is limited”. On Windows 7 or Windows 8, when this happens, the system will automatically pop up the default browser, and then users will see the Internet authentication page.

In Android 4.0 and above systems, connecting to the “Vantone Inn” access point will also prompt “Network connection requires verification” system information, click to enter the browser’s Internet authentication page. The principle is similar to Windows. Fortunately, Android is open source, and we can explore it from the source code [1]:

private final static String mWalledGardenUrl = "http://clients3.google.com/generate_204";

private boolean isWalledGardenConnection() {
    HttpURLConnection urlConnection = null;
    try {
        URL url = new URL(mWalledGardenUrl); // "http://clients3.google.com/generate_204"
        urlConnection = (HttpURLConnection) url.openConnection();
        urlConnection.setInstanceFollowRedirects(false);
        urlConnection.setConnectTimeout(WALLED_GARDEN_SOCKET_TIMEOUT_MS);
        urlConnection.setReadTimeout(WALLED_GARDEN_SOCKET_TIMEOUT_MS);
        urlConnection.setUseCaches(false);
        urlConnection.getInputStream();
        // We got a valid response, but not from the real google
        return urlConnection.getResponseCode() != 204;
    } catch (IOException e) {
        if (DBG) {
            log("Walled garden check - probably not a portal: exception "
                    + e);
        }
        return false;
    } finally {
        if (urlConnection != null) {
            urlConnection.disconnect();
        }
    }
}

Android visits http://clients3.google.com/generate_204, if the return is HTTP 204, it is considered a normal connection, otherwise it is considered to require authentication, and a reminder is popped up in the system message bar. Users click this reminder, visit the above website, and will be redirected to the login page by the Internet authentication system. The Chromium OS official document has a more detailed description [5] of this process. (Chromium OS and Android are both Google’s own sons)

The only downside is that after a successful login, it returns to the page before login, resulting in a 204 No Content, so the browser might just stay on the login page, as if there is no response. In this regard, Windows does better than Android, visiting www.msftnsci.com/some_url (I forgot the specifics), it will redirect to bing search, which serves as a product promotion. At first, I even thought Microsoft had a partnership with Wantong Posthouse. A classmate even threw out the conspiracy theory that “Microsoft monitors the network of intern residences”, it seems that this evidence is not valid.

We will also find that disconnecting and reconnecting wifi, as long as it is within a certain time interval, there is no need to authenticate again. The simplest guess is that the DHCP server, in the absence of conflicts, will generally assign the same IP address to the same MAC address, and the rules of the authentication system have a certain timeout, so reconnecting before the timeout will use the existing rules. Of course, it may also use a more complete mechanism, save the MAC address of the authenticator, and refresh the corresponding rules after reconnecting. Because my IP address has never changed, I can’t verify which hypothesis is correct.

By the way, the wifi of Wantong Posthouse actually has two vulnerabilities: it allows unauthenticated users to ICMP packets to any IP and UDP packets on port 53. Allowing ICMP packets doesn’t make sense, it may be overlooked by the developers; allowing UDP port 53 is for DNS resolution, but it does not restrict only its own DNS server. As long as there is an OpenVPN server working on port 53 outside, you can connect to the VPN, thereby breaking through the wifi access restrictions. Similarly, there are protocols like IP over ICMP that exploit ICMP vulnerabilities. In comparison, CMCC’s wireless hotspot does not have these two vulnerabilities, state-owned enterprises are indeed state-owned enterprises~

References:

Wireless Network Authentication at Vantone Inn

Comments