SSH configuration weakness

Product support balenaOS
,
1

Hello,

At my company, we have been using BalenaOS for our IoT product. We had a penetration test done on the device, and here is a vulnerability they found with how the SSH is configured by default with openSSH.

Vulnerabilities
Description
An SSH service on both devices were found to be configured with weaknesses that could allow establishment of
sessions with algorithms and protocols containing known faults. These weakened features are therefore
susceptible to attack, even if from a theoretical point of view. At some point in time, a working exploit could be
developed and published, therefore a defence-in-depth approach is recommended to ensure the best possible
security posture.
Specifically, the affected service was fingerprinted to permit the following weak algorithms and protocols:

Key Exchange Algorithms:

  • ecdh-sha2-nistp256,
  • ecdh-sha2-nistp384,
  • ecdh-sha2-nistp521,
  • diffie-hellman-group16-sha512,
  • diffie-hellman-group18-sha51,
  • diffie-hellman-group14-sha256
    Host -key Algorithms:
  • rsa-sha2-512,
  • rsa-sha2-256,
  • ecdsa-sha2-nistp256
    Message Authentication Code Algorithms:
  • umac-64-etm@openssh.com,
  • hmac-sha1-etm@openssh.com,
  • umac-64@openssh.com,
  • hmac-sha1

Recommendations:
Ensure that SSH configuration is hardened as per the recommendations below, provided the software is up to
date and supports the features listed:
• Disable weak Message Authentication Code algorithms (MD5, truncated SHA1), in favour of the
algorithms below:
o hmac-sha2-512-etm@openssh.com
o hmac-sha2-256-etm@openssh.com
o hmac-ripemd160-etm@openssh.com
o umac-128-etm@openssh.com
o hmac-ripemd160
• Disable arcfour and CBC-mode ciphers, in favour of CTR or GCM-mode ciphers listed below:
o aes128-ctr
o aes192-ctr
o aes256-ctr
o aes128-gcm@openssh.com
o aes256-gcm@openssh.com
o chacha20-poly1305@openssh.com
• Ensure that only ephemeral key exchange algorithms are used and prioritise Elliptic-Curve based ones:
o curve25519-sha256@libssh.org
o curve22519-sha256
o diffie-hellman-group-exchange-sha256
o diffie-hellman-group16-sha512
o diffie-hellman-group18-sha512
o diffie-hellman-group14-sha256
• Disable DSA public key support and prioritise ed25519 and ECDSA over RSA. Ideally RSA key support
should also be disabled.
• Ensure that SSH protocol version 2.0 is enforced exclusively.
• If possible, disable password authentication in favour of key-based authentication.
• Ensure that Elliptic-Curve key exchange algorithms are prioritised in favour of RSA based.

I wonder if this is just a general guidance on getting the latest, most secure version of SSH encryption. I was a bit reluctant to start changing stuff around the hostOS/OpenSSH as it might be integral to the functioning of the system.

For our application: the report mentions 2 devices. But only 1 interfaces with the wider internet and forwards all packets to and from the other device.
Once productionised, we would only use SSH through the Balena dashboard for tech support purposes.

Our system runs BalenaOS 2.75.0+rev1 with supervisor version 12.5.10

Let me know if there are any approaches for remedying this.

Thanks!

2

Hello,

thanks a lot for reporting this thorough report. To give a better guidance for how you can interpret and circumvent the situation I’d like to understand:

If you run in production mode, and have registered keys anywhere on the device or in the dashboard, you should cycle the keys to ed25519 keys to ensure that RSA keys are not used for connections anymore. This of course does not stop requestswith RSA keys to access the device but the keys are not existing, thus the device ssh service should drop the request anyway.
If you only use the dashboard terminal access to open ssh connections to the device, you should be save to proceed without tampering the device in any way.

In the meantime, I’d like to ask you to open a github issue Issues · balena-os/meta-balena · GitHub on our meta-balena repository in which the openssh service is defined here as: meta-balena/meta-balena-common/recipes-connectivity/openssh at master · balena-os/meta-balena · GitHub

Still, we strongly recommend to update the balenaOS to the latest existing release for your device type.

Let me know if this answers your questions.

Best Regards
Harald

1 Like