UPDATE (5th September 2018). Since we published our original report, Google has now resolved the underlying vulnerability. The latest update of Chrome (tested against version 69.0.3497.81) addresses the issue we highlighted in this blog, where credentials are auto-filled on unencrypted HTTP pages. This makes the attack require significantly more user interaction, in the same way that Firefox, Edge Internet Explorer and Safari do.  This makes the exploit much closer to a phishing attack and much less likely to succeed.

It is important to note that the latest version of Opera is still vulnerable as of 2018-09-05, but will hopefully also be quickly patched. This is a positive response from Google and is great to see following our original report to them in March 2018.

As per our originally-proposed solution, it would also be great to see Microsoft adjust captive portals in Windows to behave in a similar way to those in MacOS (separate browser) and for router manufacturers to enforce HTTPS management by defaults on their devices. These changes would further limit this vector of attack.

Original Article:

During a recent engagement we found an interesting interaction of browser behaviour and an accepted weakness in almost every home router that could be used to gain access a huge amount of WiFi networks.

The browser behaviour relates to saved credentials. When credentials are saved within a browser, they are tied to a URL and automatically inserted into the same fields when they are seen again. The accepted home router weakness is simply the use of unencrypted HTTP connections to the management interfaces.

By combining these two components it was possible to gain access to various networks without cracking a single handshake, which is the currently most-used method of gaining access to a WPA/WPA2 network but requires a weak passphrase. The attack should work on most networks, but there are a few pre-requisites that need to be met for the attack to succeed:

• There MUST be an active client device on the target network
• Client device MUST have previously connected to any other open network and allowed automatic reconnection
• Client device SHOULD* be using a Chromium-based browser such as Chrome or Opera
• Client device SHOULD** have the router admin interface credentials remembered by the browser
• Target network’s router admin interface MUST be configured over unencrypted HTTP

Without those five pre-requisites, the attack is not possible. However, those are all somewhat likely occurrences given that most browsers prompt users to save credentials automatically. The main pre-requisites that lower the likelihood are Chromium usage and saved router credentials, but this will still affect a huge number of people.

*Firefox, IE/Edge and Safari require significant user interaction, so attack does work, but is more of a social engineering based. With Chrome it is significantly more seamless.
**If the router’s admin interface credentials are not saved, it is still possible to attempt to guess default values

It is also important to note that the attack has been demonstrated against home routers by extracting the WiFi key directly from the web interface. However, other devices can be targeted if they have a semi-predictable URL that is exposed over unencrypted HTTP. Many IoT devices fit into this category but none were specifically tested here.

Before getting to the meat of the attack, we are assuming that you are already familiar with the Karma/Jassager attack. Karma is used in part of the workflow and if you are not familiar with it, consider reading the following article:

https://wiki.wifipineapple.com/legacy/#!karma.md

Now for the actual walkthrough

Step 1. Bring the client device onto a network we control:

The first step is to start sending deauthentication requests with aireplay-ng and with the Karma attack using ‘hostapd-wpe’, both with an Alfa AWUS036NHA.

Step 2. Trigger the browser to load our URL:

We did this with ‘dnsmasq’ and a Python script. When we see a HTTP request, we create a response redirecting to our URL and serve our own page.

The URL and served page are different depending on the router we’re targeting. We can detect which URL/Page pair to send based on BSSID and ESSID or just take a guess, the range of options is limited anyway.

There are some extra options for redirection too. By default, we allow HTTPS through untouched and wait for an HTTP request. But if this is taking too long, triggering captive portal detection on Windows will automatically launch the default browser at a URL we specify. However, there are limitations to triggering a captive portal, primarily against MacOS, which launches a separate browser specific to dealing with captive portals, preventing us from accessing stored credentials.

Step 3. Steal the autocomplete credentials:

This is where things get interesting. When our page loads, the browser makes two initial checks.

1. Does our URL origin match the router’s admin interface origin (protocol & IP address/hostname)
2. Do the input fields on the page match what the browser remembers of the router’s interface

If these two checks pass, then the browser automatically populates our page with the saved credentials. In this case, the router’s admin details. Naturally these input fields are completely hidden from the target.

If the target is using Chrome, there is one more step: The Chromium feature “PasswordValueGatekeeper” requires a user to interact with the page in some way. A click anywhere on the page is fine, and after the click we can harvest the credentials.

If the target is using Firefox, Internet Explorer, Safari or Edge, then we can’t have the input fields hidden. The attack would still work, but only if the target clicks on our form field and select their credentials from the drop-down instead. At this point the attack is mostly social engineering.

But let’s not stop here, these credentials are almost useless right now. There’s even a good chance we might have guessed them before we even started the attack (for example, admin:password) but we can’t use them from our current position on the outside of the network.

Step 4. Send the target to their home WiFi

Once we have the credentials, we want the target to keep our page open just a little longer. At this point we stop our Karma attack, releasing the target back to their own network.

Once the target device is successfully connected back to their original network, our page is sitting on the router admin interface’s origin with the admin credentials loaded into JavaScript. We then login using an XMLHttpRequest and grab the PSK or make whatever changes we need. In most WiFi routers that we tested, we could extract the WPA2 PSK directly from the web interface in plaintext, negating the entire need to capture a handshake to the network. But if a router hides the key, we could enable WPS with a known key, create a new access point or anything else we can do from within the router’s interface.

We wouldn’t even need to know the HTML structure of the router’s interface. We could just grab the entire page DOM, send it home and extract anything useful by hand. Using BeEF Project it would also be possible to proxy through to the page, granting the attacker access to the router interface as if they were logged in directly.

Solution

Fundamentally this is just a flaw in the way origins are shared and trusted between networks. In the case of home routers, they are predictable enough to be a viable target.

The easiest solution would be for browsers to avoid automatically populating input fields on unsecured HTTP pages. It is understandable that this would lower usability, but it would greatly increase the barrier to credential theft.

The most complete solution would be to implement HTTPS with trusted keys and certificates on these devices. But this requires support for custom HTTPS certificates as well as your own certificate management infrastructure, in an enterprise this is commonplace but for home users this is extremely unlikely. Vendors might consider implementing HTTPS on their devices by default, but those keys could simply be stolen by anyone with one of the devices by reverse-engineering the firmware.

Microsoft could also make the process more difficult to exploit by using a separate captive portal browser instead of simply launching the default browser similar to how MacOS behaves.

Disclosure Timeline

Chromium:

• SureCloud: Disclosed March 2^nd
• Chromium: Response Received March 2^nd (“working as designed”)

Microsoft

• SureCloud: Disclosed March 27^th
• SureCloud: Chase Sent April 13^th
• [Microsoft’s messages were all being flagged as spam]
• Microsoft: Response Received May 25^th (Clarification requested)
• SureCloud: Clarification Sent June 4^th
• Microsoft: Case opened June 5^th
• Microsoft: Requested disclosure details June 6^th
• SureCloud: Clarification sent June 6^th
• Microsoft: Flagged for consideration, but no immediate action June 21^st

Asus

• SureCloud: Disclosed March 21^st
• Asus: Responded March 22^nd (Discussing with engineers)
• SureCloud: Discussing solutions April 4^th
• SureCloud: Sent notice to publish May 25^th
• Asus: Discussing solutions June 11^th
• SureCloud: Discussing solutions and notice to publish July 11^th

Following the discussions with ASUS, it’s became clear we’d exhausted all options for ethical disclosure with this Proof of Concept.

References

While this was only discovered after disclosing to Chromium, someone named Chris had beaten us to the underlying idea. We have however taken it much further and demonstrated a real-world attack.

Original report: https://bugs.chromium.org/p/chromium/issues/detail?id=777272

Our submission (merged into original): https://bugs.chromium.org/p/chromium/issues/detail?id=818156

Tools

All the tools used to perform the attack are standard components of Kali except for router specific payloads themselves and the selection script.

A copy of the scripts we’ve used can be found here:

https://gitlab.com/eth01/Wi-Jacking-PoC

These are Proof of Concept only and the community will no doubt take this attack much further. The long-term goal is to build a module for the WiFi Pineapple to automate the attack, with this is expected in the coming months.

Video

Mitigations

As highlighted we are exploiting ‘by design’ features, which will hopefully change with public release of this article. However, in the meantime there are a few key steps that can be taken to help protect yourself:

• Only login to your router using a separate browser or incognito session
• Clear your browser’s saved passwords and don’t save credentials for unsecure HTTP pages
• Delete saved open networks and don’t allow automatic reconnection
• As it is nearby impossible to tell if this attack has already happened against your network, change your pre-shared keys and router admin credentials ASAP. Again, use a separate/private browser for the configuration and choose a strong key.