BT Wi-Fi Extender. Multiple security issues. Upgrade ASAP

I recently found some security issues with BT’s Wi-Fi extender/booster product.

This is the device in question:

https://www.amazon.co.uk/BT-Wi-Fi-Extender-300-Booster/dp/B00X7H36YA

Hardware version: V1.0.2

Firmware version: V1.1.5 (the upgraded versions is 1.1.8 – available here http://bt.custhelp.com/app/answers/detail/a_id/54345)

Product name: Wi-Fi Extender

Background

We start with a couple of low/medium risk issues and combine them to get your WPA passphrase if you visit a web page we’ve written while you’re connected to your home network.

BT tell me there is now updated firmware out to resolve this issue, so if you have one of these devices go and update now before reading on (links below).

Obviously we have held onto details until a fix was available. I have tested the firmware they sent me and it appears to block the major attack at least.

Updates for this and two other similar devices are available now:

• Wi-Fi Extender 300 software
• Dual-Band Wi-Fi Extender 600 software
• 11ac Dual-Band Wi-Fi Extender 1200 software

Low Risk ? – CSRF in web interface

I’ve discussed CSRF elsewhere – essentially, it’s possible to create a request using JavaScript which looks very similar to a genuine user-generated request.

This doesn’t look too bad initially, as a. we don’t know what IP address the device will have as a wifi extender – though we can just spray it all over the local subnet – and because it only seems to work if the user is logged in at the time.

(It is possible in some older versions of Firefox and current versions of Chrome to obtain a list of local interface addresses, from which we can infer the local subnet, e.g. 192.168.1.0/24)

Low Risk – you don’t need to give the old password to change it

You don’t need to supply the old password to change the password. Or maybe it’s getting it from the cookie, which is horrendous in itself – the purpose of prompting for the old password is to ensure that it’s the existing user that is changing the password.

Just remove the old password and the space, leaving only the new password:

And the password change goes through fine.

This isn’t great, as it would technically allow hijacking of the account if we can either CSRF, or find the thing logged in while the user is away from the console. Best practice is to require the old password before resetting it.

Medium Risk – Cross-site scripting

The var:errorpage parameter seems to be vulnerable to reflected cross-site scripting because it is not correctly validated on input, nor HTML-encoded when it is written out to the web page again.

Example:

Also, if we try it with instead of ‘1’, we get to see the username and password.

What’s worse is that we seem to be able to do this from an unauthenticated perspective:

High Risk – All the previous issues combined

Authentication bypass is not good. Together with the XSS and some poor UI design, this means I can steal your Wi-Fi password. (XSS allows us to bypass Same Origin Policy).

This is starting to get really bad. Let’s write some code [https://github.com/pentestpartners/bits-for-blog/blob/master/bt.html ] to spray this exploit over the local network, and see what we can get back.

If I now visit this page from a browser on my home network, it will determine the local network address, and send this exploit to each and every IP address on the subnet. For demo purposes, I’ve left it with a smaller range, so you see about 10 small image tags with no images in them – each one hitting a separate IP address.

NB – I’ve now found out this trick only works up to about Firefox 43 or so, but still does in Chrome.

The XSS (JavaScript) code has also been changed to send me the resulting passphrase as the only parameter of a new web request. So on my remote, evil server I find the following request logged, with my passphrase in it.

I then extended this to grab the cookies, as they hold the admin password. So we get the exit NAT IP, the admin password, the SSID and PSK. I’ve obscured my actual passphrase here for obvious reasons – and on the left that’s the browser grovelling over the entire subnet to find the BT device. On the right is the access log we get from Apache when the CSRF finds a BT Wi-Fi extender. At this point, we could look up the SSID on wigle.net, and try to locate it physically.

Advice for the vendor:

PDP wrote a very good series of articles, a great many years ago, on the early Home Hubs – you’ve made a lot of the same mistakes again. The people writing and QAing this software need to have a better understanding of security issues. Some checking of third party products would seem to be in order, before they are released to the general public.

Advice for users:

Update the firmware! It’s probably also best to log in, change the password and not use the “remember me” function in either Wi-Fi device or the “remember password” function in the browser.

Timeline

10/07/2016 – bought product.

10/07/2016 – (yes, the same day) notified BT support of the above issues

24/08/2016 – BT say there is updated firmware available and sends me a beta version to test.

03/09/2016 – Updated firmware confirmed as available, seems to fix the most serious issues.

Credits / References

Thanks to “mido” on stack overflow for a major part of the CSRF spray. (See http://stackoverflow.com/questions/391979/how-to-get-clients-ip-address-using-javascript-only)

I find this doesn’t work in Firefox since 43.0 or so – does still work OK with Chrome, or we can always just guess at the ranges.

Start here: http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub/

Read through to http://www.gnucitizen.org/blog/bt-home-flub-pwnin-the-bt-home-hub-5/

Recommended reading

Michal Zalewski’s The Tangled Web is a great book on securing web apps.

His Silence on the Wire is also a smashing resource, although not as relevant to what we’re looking at here.