Wi-Jacking - Wifi Attack to Access Neighbour’s WiFi Without Cracking

Newly identified WiFi attack called Wi-Jacking allow hackers to attack millions of WiFi network and accessing the neighbor’s WiFi without any form of Cracking.

Researchers identified this flow in the interaction of browser behavior and the existing weakness in almost every home router that allows accessing millions of WiFi networks.

This Wi-Jacking attack could be possible within certain limitation in browsers saved credentials which are reuse again for the same URL whenever its reuse by users.

Another Weakness in a home router which is simply used in unencrypted HTTP connection in the interface that used for accessing the router configuration setup in the browser.

These two combined weakness allows attackers to crack WPA/WPA2 network without cracking a single handshake.

There are a few pre-requisites that need to be met in order to Successfully perform this Wi-Jacking attack, here the following.

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

Steps to Follow to perform Wi-Jacking Attack

Initial step for this Wi-Jacking Attack starts with deauthentication requests that need to send via aireplay-ng to victims network along with Karma attack using ‘hostapd-wpe’.

So here We have successfully deauthentication and the next step will trigger the victim’s browser to load our URL which can be achieved using ‘dnsmasq’ and a Python script.

Here 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.

Later the router will be restarted.

Once the page started loading then the victim’s browser then it will check the following two steps in order to the browser automatically populates the page with the saved credentials.

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

According to surecloud researchers, 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

Once we obtain the credentials then the attacker will make victims to keep the page open just a little longer.

In this situation, karma attack will be stopped then attacker now release the victim’s network back to them.

“So Once the target device is successfully connected back to their original network, attacker page is sitting on the router admin interface’s origin with the admin credentials loaded into JavaScript.”

Then an XMLHttpRequest will help to log in the router and grab the PSK and also perform any change we need.

Researchers said, “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.”

In this case, the latest update of Chrome (69.0.3497.81) has this flaw where credentials are auto-filled on unencrypted HTTP pages.

Solution Suggested by surecloud

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.

Mitigations

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.