Take a pinch of autofill, mix in HTTP, and bake on a Wi-Fi admin page: Quirky way to swipe a victim's router password

If they fall for this social-engineering trick, of course

FACEPALM

Vid Beware using your web browser's autofill feature to log into your broadband router via Wi-Fi and unprotected HTTP. A nearby attacker can attempt to retrieve the username and password.

The problem – found by SureCloud's Elliott Thompson and detailed here – is the result of a mismatch in browser behavior and router configuration security.

It's not a particularly scary or an easy-to-leverage vulnerability, and we think most miscreants will find it too much of a faff to exploit. However, it is interesting and quirky, and worth checking out.

How to protect yourself

If you're using Chrome, make sure you're running at least version 69.0.3497.81, which was released this week and mitigates the security weakness Thompson privately disclosed to Google in March. This particular build brings the browser in line with Firefox, Edge, Internet Explorer, and Safari, which are all harder to exploit via Thompson's technique.

In short: if you're suddenly kicked off your Wi-Fi, and rejoin to a page trying to get you to confirm your router administration username and password, be on alert and don't autofill the login form. Check to make sure you're actually on the Wi-Fi network you think you're on and can trust. Alternatively, don't save your router login details in your browser's autofill feature.

The login page could instead be a spoof that's waiting for you to autofill the boxes so it can snatch the username and password.

UK-based SureCloud dubbed this information-stealing technique Wi-Jacking, explaining: “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.”

No walk in the park

In order to swipe someone's router login details in this manner, they need to be physically nearby and on the target wireless network. They could be a cafe owner using their own Wi-Fi from their own laptop at the counter, for instance. They also need to have joined an open wireless network at some point, with automatic reconnections allowed. Their browser should remember their router configuration login details. The router must also use plaintext HTTP for its configuration webpages. All these conditions are required.

You then flood the victim's computer with network deauthentication requests over the air to kick them off their own Wi-Fi, and onto an open wireless network you control. You then redirect any of their HTTP connections to a URL that matches their router's admin page URL, such as 192.168.1.1, and serve a webpage that masquerades as the gateway's login interface.

If the victim has previously used that URL to manage their router from their browser, and saved their credentials to autofill, a vulnerable browser may drop the username and password into the appropriate fields on the page, ready for your page to automatically obtain and use.

Chrome used to require the victim to interact with the spoofed login page, such as clicking somewhere on the page background, before the autofill kicked in.

Now, from this week, it's more robust, and works like Firefox, Internet Explorer, Safari, and Edge in that the user has to be tricked into selecting the router's credentials from a drop-down menu in order to autofill the login form. "At this point the attack is mostly social engineering," Thompson noted. If you can't get the details from autofill, then you could try guessing them – admin:password is a good start.

The next stage – whether you managed to get the victim to select their autofilled credentials, or simply guessed them – is to quickly and silently let the victim rejoin their wireless network with the spoofed admin page still open. Then some JavaScript on the malicious webpage can use the login details – autofilled or guessed – to access the gateway's configuration interface, grab the Wi-Fi access password, change its DNS settings to redirect other clients to dodgy websites, and so on.

According to Thompson:

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 Wi-Fi 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.

"Fundamentally this is just a flaw in the way origins are shared and trusted between networks," he added.

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

Below is a video showing how to exploit a victim's setup...

Youtube Video

Essentially, if you're using Chrome, update it. Then, regardless of your browser, be on alert for attempts to phish your router admin password if you're suddenly kicked off your Wi-Fi by making you autofill your router's admin page login boxes. As well as the above advice, consider deleting any open networks your machine has saved, refusing automatic reconnections, and don't use the router's default credentials, in order to avoid being Wi-Jacked. ®




Biting the hand that feeds IT © 1998–2018