[BreachExchange] Google fixes Chrome issue that allowed theft of WiFi logins

[Destry Winant]

https://www.zdnet.com/article/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.

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.

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.