I am very pleased to see security being taken this seriously.
This is a good solution to a serious potential flaw.
Given the fact that the password is known password and you can get a javascript ssh client and mDNS works having the ssh daemon on by default will enable drive by attacks where a user visits a page located on the web in that then causes their web browser to connect to the local emonpi via its .local domain name. The web browser has kindly removed any protection that was provided by a firewall. These kind of attacks have been seen in the wild on routers already.
By forcing a user to turn on the ssh daemon they are much more likely to also change the password.
Other possibilities would be to only enable ssh if there was a private key and the password was not set but those would still all need added.
My two cents, since I inadvertently stirred this hornetās nest. I was trying to start an emonBase; I donāt NEED ssh access but I feel a lot more comfortable when I do have it, so I tried it, when I got to the point on 1. Connect - Guide | OpenEnergyMonitor where it is mentioned. (i.e. the Assign static IP section) It failed, and thereās nothing on that page that tells me why (for that matter, I see thereās a typo - shh for ssh - so even the cut-and-paste commands arenāt ) So the first thing I would suggest is updating that page to match current reality.
Then I searched for the symptoms, both here and on google, and didnāt find anything about the emonBase in particular but did about the pi in general, so I started a thread to check the facts.
It turns out there are two possible ways to enable ssh and it so happens that I canāt do either simply. I believe an adapter will be shipped in future, so in my particular circumstances I would have been able to enable ssh fairly easily, if I had been told I needed to.
I also intend to buy a spare HDMI lead, since I think its a sensible thing to have (I used my last spare in the hi-fi rats nest). So I would be able to use either method to enable ssh. It just happens to be an irritation this time because of the particular hardware I happen not to have.
Incidentally, shorting two pins together is not an approach I like. Firstly I would have to dismantle the device to access the pins, and secondly itās quite error-prone.
I do appreciate the attempts to make the system more secure, and as has been pointed out, there are several other weaknesses that should be addressed. Iām no expert but is it worth doing an analysis of security specifically - maybe the likes of OWASP could help?
Itās true, assigning a static IP is one of the few actions that SSH is currently required for. This could in the future be included as part of the WiFi GUI setup.
Thanks for reporting, this has now been fixed:
Did you manage to get static IP to work? Think that section may need to be updated for Raspbien Strech. What worked for you in the end? Iāve not tried setting up static IP on Stretch yet. Best discuss this on a new topic
Thatās good to hear.
I agree.
Weāre reviewing all aspects of security following the UK Gov publication on āSecure by design IoT code of Practiceā: Secure by design - GOV.UK
Unsurprisingly it states that default passwords should not be used and all unnecessary ports and access services should be disabled (points 1 and 6)
We have a legal responsibility under GDPR to enable security by default for our users. This is why I consider this decision to disable SSH by default non-negotiable. We are reviewing the security of all aspects of the system.
Sorry, no idea. I had set up a static IP on my router (mentioned in my thread) so that wasnāt what I was trying to do; it was just the point that testing ssh access occurred to me.
Is that review process open? Are conclusions and rationale published somewhere, for example, and open to discussion?
Itās more secure than a default password since will be unique to each system.
We would like to publish to guide to enabling SSL/TLS on the emonPi. We could install a certificate on the emonPi bit it would have to be self-signed if access over local network which would cause browsers to preset the user with worrying errors even though the connection would then be encrypted. Happy to discuss options for this, again we should start a new topic to discuss further.
Itās incredibly important to enable security by default, and Iām pleased to see this change. It strikes me that most of the opposition to this issue is around the inconvenience of enabling SSH explicitly. Thereās certainly work that could be done to improve the user experience of that, but that doesnāt mean itās acceptable to ship something thatās knowingly insecure.
The risk of exposing SSH with a default password is quite significant. The obvious example is where an instance is exposed to the internet, but even on a private network if an attacker gains access to the network it becomes an easily hackable target. Itās not reasonable to place the responsibility for security on other parties and say āif the networkās compromised then thatās your faultā, or āif a user doesnāt disable SSH or change the password even though theyāve been told itās on themā.
There are plenty of horror stories about IoT devices being recruited into botnets and used as staging platforms for further attacks. Most of the time, the owner of the device isnāt even aware that the device has been compromised.
We have to assume that a portion of users are not experts, and donāt necessarily understand how to use SSH. An even larger portion of users donāt understand the importance of securing that connection. Therefore itās not safe to assume all users will disable SSH (or set a secure password/keypair). The concept of security by default is really important here, and itās good to see the move towards that.
AFAIK thereās no suggestion that SSH will be disabled for existing instances, so thereās no breaking change for users upgrading existing installations (which I agree could be problematic).
Other potential attack vectors have been raised, and they should be addressed separately, but the lack of security in another area doesnāt invalidate the concept of security overall.
Iām not convinced this is an issue that should be up for negotiation. Itās fundamentally wrong to advocate shipping something thatās easily compromised, and a commercial company would be hauled over the coals if they shipped SSH enabled with a default password. It really is part of the fundamentals of security.
There is a huge flaw in the thinking here. Equating SSH with default passwords. The only link between the two is the implementation of the default password. SSH, as implemented in OpenSSH, is incredibly secure in the context of providing a legitimate service while defending against attacks and other types of access flaws.
I am all for NEVER EVER having default passwords - generate one that can be displayed on the LCD at first boot, maybe only made visible using the button, but please donāt throw the baby out with the bath water.
I didnāt read the full proposals, but how will users access the web interface? Thatās a far bigger attack surface than the sshd - worse code, more code, external code. OpenSSH is well inspected, uses many mitigation techniques and is proven in millions - literally - of installations to work and work reliably, only depending on the configuration outside the authorās control.
Hi @Peter, I completely agree ā OpenSSH itself is not the main problem (provided itās patched and up-to-date, of course), it is the presence of the default username/password, however itās a bit hyperbolic to say itās throwing the baby out with the bathwater. There has been no suggestion that SSH should be banned, only that it should be manually enabled. This suggestion has come about precisely as a solution to the default password problem, not separately.
Even trusting OpenSSH, itās sensible to reduce your attack surface by disabling services users donāt need by default, allowing them to be enabled later (possibly through the web interface).
Your point about the web interface is valid, but itās a separate discussion for a separate tranche of work ā pointing out that something else is insecure doesnāt invalidate the move to secure this attack vector. Also, while the web interface is absolutely a much larger attack surface, a compromised SSH connection gives root access to the device for script kiddies an bots, so the severity of this issue is still high.
Letās not forget that SSH can be enabled by pushing a button for 5s, or adding an empty file onto the SD card.
I really am not advocating the current solution as the final one, but as thereās a working fix with a workaround to enable it on any device/VM configuration, it doesnāt seem that contentious to use it and iterate on a solution with a flow you would find more acceptable separately.
Also @Peter, FWIW your idea for a randomly generated password thatās displayed on the LCD on first boot is really interesting and worth exploring separately. If we could think of a way to take a similar approach for devices without an LCD/button that could work quite nicely (potentially having a toggle within the web interface?).
Can I just put in my vote for SSH disabled by default. This is considered best practice and not doing it is frequently criticised by security experts. I would worry about the reputational risks for OEM and Megni if their products were continuing to be sold with this. You only need to misconfigure the local network (thatās assuming you have any control over the local network) and you could have an open SSH port on the internet with a default username/password. For people selling hardware security should not be based on external systems which you have no control or knowledge of.
The government has produced security by design guidance for consumer iot products , partly to help companies with their compliance requirements under GDPR. Recommendation 1 is ā¦ āno default passwordsā , recommendation 6 is āminimise exposed attack surfaceā.
But that is is āData Protectionā and there is no personal data to be protected. It has absolutely nothing to do with GDPR as OEM are not a data controller in this situation. No data controller - no GDPR implications.
āSecurity by Designā Iād agree but there are no regulations or laws that enforce that.
Precisely my point - bad information being peddled and conflation of different issues.
I think it is potentially relevant here. If the device is configured to connect to the emoncms.org service (as the emonPi is designed to do) and the credentials for that are stored on the device then it potentially becomes a data protection issue.
Whether strictly required by law or not, it is clearly regarded as best practice for people selling internet connected devices to not use default passwords.
Ha, on that basis, Iād run a mile from providing the emoncms.org service. I donāt agree though, on the definition of āpersonal dataā nothing here fits the relevant categories.
Except there are still default passwords and as this bit is a discussion on the relevance of quoting the great god GDPR as a reason to do it, it is an irrelevant argument.
Good suggestions. Iād add treating EmonPi and SD images as a separate entities. The second requiring login from console / SSH before EmonCMS would start where a password change is forced.
Ha, on that basis, Iād run a mile from providing the emoncms.org service. I donāt agree though, on the definition of āpersonal dataā nothing here fits the relevant categories.
Note the definition of āpersonal dataā has also been expanded/changed - even if data does not directly relate to an individual, if it can be used indirectly to identify someone it can constitute personal data. For example, some combination of IP address, postal code, and monitoring data could be sufficient to identify someone and therefore, under the new regulation, is regarded as personal data.
Except there are still default passwords and as this bit is a discussion on the relevance of quoting the great god GDPR as a reason to do it, it is an irrelevant argument.
I donāt think we are going to agree on this. I understand your point of view about there being two discussions here, all I am saying is that these are connected IMHO.
) So the first thing I would suggest is updating that page to match current reality.