Google fixes Chrome issue that allowed theft of WiFi logins

The latest version of the Chrome browser, version 69, released yesterday, includes a critical patch for a design issue that an attacker could exploit to steal WiFi logins from home or corporate networks.

The issue is that older versions of Chrome would auto-fill usernames and passwords in login forms loaded via HTTP.

Elliot Thompson, a researcher with UK cyber-security firm SureCloud, put together a technique that exploits this design issue in a complex multi-step attack through which he was able to steal WiFi login data, something that Chrome doesn't even handle in the first place.

His attack, which he named Wi-Jacking (also WiFi Jacking), works with Chrome on Windows. The steps for executing a Wi-Jacking attack are detailed below:

Step 1: An nearby attacker able to reach the victim's WiFi network sends deauthentication requests to the victim's router, disconnecting the user from his legitimate WiFi network.

Step 2: Attacker uses a classic Karma attack to trick the victim into connecting to the attacker's malicious network.

Step 3: The attacker sits back and waits for the victim to access an HTTP website.

Step 4: Because HTTP traffic is easy to modify, the attacker replaces the intended HTTP page with a page that mimics a captive portal page, specific to home or corporate routers.

Step 5: This captive page, or any other page mimicking a router-specific portal, will contain hidden login fields. Because the user is connected to the attacker's network, the attacker can set the URL of this captive portal page to the exact URL of the user's legitimate router. As a result, if users have allowed their Chrome instances to auto-fill credentials and if they saved router backend panel credentials inside Chrome, they'll be auto-completed in the hidden fields of the attacker's captive portal page.

Step 6: Attacker stops Karma technique and lets the user connect back to his original WiFi network.

Step 7: If the user clicks anywhere on the page, or after a certain time, the malicious captive portal page, still loaded in the user's browser, will submit the credentials located in the hidden login fields to the actual router backend panel. This authenticates the victim and allows the attacker to grab the WPA/WPA2 PSK (pre-shared key) from the user's router WiFi settings.

With the WPA/WPA2 PSK, the attacker can then log into a victim's home or private corporate network.

See also: Google investigating issue with blurry fonts on new Chrome 69

Thompson was very candid in research published yesterday and admitted that various pre-requisites must be met for a Wi-Jacking attack to work successfully.

But he also points out that many pre-requisites aren't that hard to achieve. For example, the router backend panel must be loaded via HTTP --most routers don't support HTTPS connections, and loading the admin panel via HTTP is almost the standard method of serving router configuration panels for many router brands.

Furthermore, victims must have previously connected to any open WiFi network and allowed automatic reconnection --which is also not an issue, as users often connect to open WiFi networks and leave automatic reconnection enabled for their WiFi settings.

On top of this, the user should have previously configured Chrome to remember and auto-fill passwords, and have the router admin interface credentials remembered in the browser.

This is probably the most tricky pre-requisite, but nobody said the Wi-Jacking attack was universal.

See also: Google open-sources internal tool for finding font-related security bugs

Thompson says he reported the issue to Google, Microsoft, and ASUS in March, this year. Google addressed his report by not allowing Chrome to auto-fill passwords on HTTP fields.

The researcher also recommended that Microsoft use a separate browser for loading WiFi/router capture portal pages, similar to how Apple handles capture portals in macOS. Microsoft responded that it doesn't plan on acting on this suggestion.

ASUS, who Thompson contacted because he used an ASUS router in his proof-of-concept, never provided a final answer to the issue after months of discussions.

Besides Chrome, Opera is also susceptible to Wi-Jacking attacks, but Opera usually takes one extra month to incorporate patches and modifications made to the Chromium codebase, the open-source project on which Chrome and Opera are both based on.

Other browsers like Firefox, Edge, Internet Explorer, and Safari are not vulnerable to this particular attack because they don't auto-fill credentials in login fields unless the user clicks or focuses on the form field itself, hence an automated Wi-Jacking attack would never work as seamlessly as it does in Chrome and Opera.

Updating to Chrome 69.0.3497.81 or later should keep users safe from Wi-Jacking attacks. Thompson also released a video explainer for the Wi-Jacking technique, which we recommend on watching.