emonPi SSH disabled by default

Tags: #<Tag:0x00007f1fe9bb90d0> #<Tag:0x00007f1fe9bb8f90> #<Tag:0x00007f1fe9bb8e50>

(David Hunnisett) #42

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.

(Dave Howorth) #43

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 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 :frowning: ) 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?

(Glyn Hudson) #44

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”:

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.

(Dave Howorth) #45

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?

(Glyn Hudson) #46

Certainly, we will be posting on the forum any changes we make. Happy to discuss any aspect of security openly.

@TrystanLea is currently working on a more advanced authentication for Mosquitto MQTT server using your Emoncms admin login to authenticate with MQTT.

@emrys is also working on an Emoncms remote access feature via MQTT over TLS without opening any ports.

(Dave Howorth) #47

Given that the emoncms login and password are sent in the clear, that doesn’t seem very secure.

edit: Oh I just got ssh working. I’ll post details on my thread, as it wasn’t straightforward.

(Glyn Hudson) #48

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.

(Brian Orpin) #49

Sigh, whichever highly paid numpty consultant told you that, needs to be thrown out. There is so much bad advice out there on GDPR it is frightening.

(Ryan Brooks) #50

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.

(Peter Galbavy) #51

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.

(Ryan Brooks) #52

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.

(Ryan Brooks) #53

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?).

(Ben Aylott) #54

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.

(Ben Aylott) #55

Glyn is referring to the requirement for ‘privacy by design’ :

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

(Brian Orpin) #57

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.

(Ben Aylott) #58

I think it is potentially relevant here. If the device is configured to connect to the 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.

(stuart) #59

My thoughts, SSH should be “protected” in a manner in which makes it simple and idiot proof for “normal” users to be secure and protected.

To this end, I’d support:

  1. Having SSH disabled and a push button to enable (or perhaps a header jumper pin for emonbase?)
  2. Having a method to enable SSH through the web interface (perhaps also allowing upload of client SSH certificate/public key to avoid default password)
  3. Having SSH enabled by default but only for the first X number of reboots (or perhaps only for 1st day of power on)
  4. Having a dirty great big banner at the top of emoncms about SSH being enabled and default password being used

(Brian Orpin) #60

Ha, on that basis, I’d run a mile from providing the 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.

(Brian Orpin) #61

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.

(Ben Aylott) #62

Ha, on that basis, I’d run a mile from providing the 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.