Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wireless Password Leak #374

Closed
adamast0r opened this issue Apr 23, 2017 · 11 comments
Closed

Wireless Password Leak #374

adamast0r opened this issue Apr 23, 2017 · 11 comments

Comments

@adamast0r
Copy link

adamast0r commented Apr 23, 2017

I have been using my sonoff basic version without any issues for the last weeks. I noticed something strange some days ago. I could not see the sonoff connected to my network, it seems that it went to the AP mode without any intervention from myself (bug?). This is a problem since it was in AP mode and anyone could:

  1. connect to the sonoff (http://192.168.4.1) via web interface
  2. view the source code of the page and get my current network wireless password
  3. connect with that password to my wireless network

I don't think the current passwords should be available when the source code of the page is seen. As a defense in depth I would suggest that this should be applied in other pages of the device that have the same password textboxes.

@davidelang
Copy link
Collaborator

davidelang commented Apr 23, 2017 via email

@adamast0r
Copy link
Author

adamast0r commented Apr 23, 2017

The problem is that nobody pressed the buttons or sent any command to switch the AP mode.

Because you have passwords in other places does not make the issue less serious, maybe they should also be fixed.

@davidelang
Copy link
Collaborator

davidelang commented Apr 23, 2017 via email

@fkahhaleh
Copy link

Not to hijack the thread, but David is it possible to not have the sonoff go into AP unless a physical hardware button is pressed? (and nothing else?)

Perhas Adam can start with that route and observe the behavior.
I am waiting on my units to arrive and looking forward to working on and using this firmware :)

@davidelang
Copy link
Collaborator

davidelang commented Apr 23, 2017 via email

@adamast0r
Copy link
Author

adamast0r commented Apr 26, 2017

@davidelang

It's very useful for troubleshooting, a config option to mask them is an option
(but takes code and memory that are both in short supply)

To be honest I think having a option is overkill, just don't write the current password in the web interface, no extra memory is required, leave the text field to input eventual new password changes, but not use the same textbox for current passwords.

If the person want to change the password it will still be possible, there is no reason to have the current password in the webinterface. In the current design the user can't even verify in a convenient way that he put the correct password, since the password is masked by the browser.

"the password is also visible on the web console and via mqtt."

Yes, but this is not at the same level, I can protect the mqtt/web interface with username and password. In that situation it would not be possible to discover the wireless password.

@richrd
Copy link

richrd commented Nov 1, 2017

This does seem to be an issue. If I set the mode to WIFI_RESTART in the user_config.h file it works as expected. Then if I press the button 4 times it starts wifi manager as expected. Everything ok at this point.

After that though, it always starts wifi manager instead of wifi restart every time it loses wifi (instead of simply restarting). I only want it to start wifi manager when I press the button. Never automatically. Is there a workaround? Why does it store what config tool was last used and use that every time in the future?

EDIT:
For now, I made some modifications to the firmware to harden the security. First I added a password to the wifi AP by adding this to the config file:
#define WIFI_CONFIG_PASS "some-secure-password" // Wifi AP password
And then changed line 395 in webserver.ino to this: WiFi.softAP(my_hostname, WIFI_CONFIG_PASS);
Then I also removed the password autofill from the wifi settings form (also in webserver.ino):

  page += FPSTR(HTTP_FORM_WIFI);
  page.replace(F("{h1"), Settings.hostname);
  page.replace(F("{s1"), Settings.sta_ssid[0]);
  // page.replace(F("{p1"), Settings.sta_pwd[0]);
  page.replace(F("{p1"), "");
  page.replace(F("{s2"), Settings.sta_ssid[1]);
  // page.replace(F("{p2"), Settings.sta_pwd[1]);
  page.replace(F("{p2"), "");

Hopefully this helps anyone concerned with this issue.

@lal12
Copy link

lal12 commented Feb 10, 2018

I noticed the same thing. When e.g. my Router updates its ap is down, then the Sonoff opens its own WiFi-AP, which is a very nice feature. But everyone could now read my wifi password.
It is not that uncommon for a router to shut down once in a while for an update. So I guess it really should be handled as @adamast0r proposed.

@ascillato
Copy link
Contributor

ascillato commented Feb 10, 2018

@lal12
This issue is old and it is fixed now #1527 #1587
This issue should be closed

EDIT: corrected reference.

@lal12
Copy link

lal12 commented Feb 10, 2018

@ascillato Ok, thanks but I guess you referenced the wrong Issue: #1587
And this here really should be closed

@ascillato
Copy link
Contributor

ascillato commented Feb 10, 2018

Yes. You are right! That one I wanted to reference. Thanks! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants