Google fixes a Chrome issue that allowed the theft of WiFi connections

The latest version of the Chrome browser, version 69, released yesterday, includes a critical fix for a design problem that an attacker could exploit to steal Wi-Fi connections from a home or business network.

The problem is that older versions of Chrome automatically fill in usernames and passwords in login forms loaded via HTTP.

Elliot Thompson, a researcher at SureCloud, a UK cyber security company, has developed a technique that exploits this design problem in a complex, multi-step attack by which he could steal WiFi connection data. first place.

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

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

2nd step: The attacker uses a classic Karma attack to bring the victim to connect to the malicious network of the attacker.

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

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

Step 5: This captive page or any other page that mimics a router-specific portal will contain hidden login fields. Since 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 legitimate router of the ################################################################################### 39; user. As a result, if users have allowed their Chrome instances to automatically fill in the credentials and have saved the Router's back panel credentials in Chrome, they will automatically be populated with the Chrome credentials. hidden fields of the captive portal page of the attacker.

Step 6: The attacker stops the Karma technique and allows the user to connect to his original WiFi network.

Step 7: If the user clicks anywhere on the page or after a while, the malicious captive portal page, still loaded in the user's browser, will submit the credentials located in the masked connection fields at the router's main panel. This authenticates the victim and allows the attacker to recover the WPA / WPA2 pre-shared PSK from the WiFi settings of the user's router.

With the PSK WPA / WPA2, the attacker can then connect to the private or private business network of a victim.

See also: Google investigates the problem of fuzzy fonts on the new Chrome 69

Thompson was very outspoken in his research published yesterday and admitted that several prerequisites must be met for a Wi-Jacking attack to work properly.

But he also points out that many prerequisites are not so difficult to reach. For example, the backplane of the router must be loaded via HTTP – most routers do not support HTTPS connections and the loading of the administration panel via HTTP is almost the standard method of serving the configuration panels of the routers. routers.

In addition, victims must have previously connected to an open WiFi network and allowed automatic reconnection – which is not a problem either, as users often connect to open WiFi networks and allow automatic reconnection. enabled for their WiFi settings.

In addition to this, the user must have previously configured Chrome to automatically remember and fill in passwords, and remember the router's interface management identification information in the Navigator.

This is probably the most delicate prerequisite, but no one has said that the Wi-Jacking attack was universal.

See also: Google Open-Source internal tool for finding font-related security bugs

Thompson says he reported the problem to Google, Microsoft and ASUS last March. Google has submitted its report by not allowing Chrome to automatically fill passwords on HTTP fields.

The researcher also recommended that Microsoft use a separate browser for loading WiFi / router capture portal pages, similar to the way Apple handles capture portals in macOS. Microsoft responded that it did not plan to act on this suggestion.

ASUS, contacted by Thompson because he was using an ASUS router in his proof of concept, never provided a definitive answer to this problem after months of discussions.

In addition to Chrome, Opera is also susceptible to Wi-Jacking attacks, but Opera typically requires an extra month to incorporate patches and changes to the Chromium codebase, the open source project on which Chrome and Opera are both based.

Other browsers like Firefox, Edge, Internet Explorer, and Safari are not vulnerable to this attack because they do not automatically fill in the credentials in the login fields unless the user clicks or clicks. focuses on the field itself. would never work as easily as in Chrome and Opera.

Updating to Chrome 69.0.3497.81 or later should protect users from Wi-Jacking attacks. Thompson has also released an explanatory video for the Wi-Jacking technique, which we recommend to watch.