OpenWRT Dropbear fails ssh-audit do to sha1

Here is the output of ssh-audit:

# general
(gen) banner: SSH-2.0-dropbear
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2020.79+
(gen) compression: disabled

# key exchange algorithms
(kex) curve25519-sha256              -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
                                     `- [info] default key exchange from OpenSSH 7.4 to 8.9
(kex) curve25519-sha256@libssh.org   -- [info] available since OpenSSH 6.4, Dropbear SSH 2013.62
                                     `- [info] default key exchange from OpenSSH 6.5 to 7.3
(kex) diffie-hellman-group14-sha256  -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                     `- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) kexguess2@matt.ucc.asn.au      -- [info] available since Dropbear SSH 2013.57
(kex) kex-strict-s-v00@openssh.com   -- [info] pseudo-algorithm that denotes the peer supports a stricter key exchange method as a counter-measure to the Terrapin attack (CVE-2023-48795)

# host-key algorithms
(key) ssh-ed25519                    -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
(key) rsa-sha2-256 (2048-bit)        -- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                     `- [info] available since OpenSSH 7.2, Dropbear SSH 2020.79
(key) ssh-rsa (2048-bit)             -- [fail] using broken SHA-1 hash algorithm
                                     `- [warn] 2048-bit modulus only provides 112-bits of symmetric strength
                                     `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
                                     `- [info] deprecated in OpenSSH 8.8: https://www.openssh.com/txt/release-8.8

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com  -- [info] available since OpenSSH 6.5, Dropbear SSH 2020.79
                                     `- [info] default cipher since OpenSSH 6.9
(enc) aes128-ctr                     -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes256-ctr                     -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) hmac-sha2-256                  -- [warn] using encrypt-and-MAC mode
                                     `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56

# fingerprints
(fin) ssh-ed25519: SHA256:AHVeoGcRauGqnVR19ODWKCNFVHyc8BTqkUKMFByvbow
(fin) ssh-rsa: SHA256:wCNSiKzpASEm6/xO8rqhoPIvHL5A01oj7xfOt8dV78c

# additional info
(nfo) Be aware that, while this target properly supports the strict key exchange method (via the kex-strict-?-v00@openssh.com marker) needed to protect against the Terrapin vulnerability (CVE-2023-48795), all peers must also support this feature as well, otherwise the vulnerability will still be present.  The following algorithms would allow an unpatched peer to create vulnerable SSH channels with this target: chacha20-poly1305@openssh.com.  If any CBC ciphers are in this list, you may remove them while leaving the *-etm@openssh.com MACs in place; these MACs are fine while paired with non-CBC cipher types.
(nfo) Potentially insufficient connection throttling detected, resulting in possible vulnerability to the DHEat DoS attack (CVE-2002-20001).  38 connections were created in 0.239 seconds, or 158.9 conns/sec; server must respond with a rate less than 20.0 conns/sec per IPv4/IPv6 source address to be considered safe.  For rate-throttling options, please see <https://www.ssh-audit.com/hardening_guides.html>.  Be aware that using 'PerSourceMaxStartups 1' properly protects the server from this attack, but will cause this test to yield a false positive.  Suppress this test and message with the --skip-rate-test option.

As seen above, Dropbear is failing ssh-audit do to the fact that it is still supporting SHA-1. In upstream Dropbear the weak ciphers have been officially deprecated for a while now so I'm not sure what the reason is for still supporting SHA1. This could be dangerous as some users are exposing SSH to the internet without realizing that Dropbear is configured in a way that could allow exploitation in some cases.

Host keys are stored in the /etc/dropbear/ directory. Try renaming the dropbear_rsa_host_key to something like ignored_dropbear_rsa_host_key and restarting the dropbear service. Does ssh-audit still complain about sha1?

This is only the case if those users are using clients that still use the ssh-rsa host key algorithm. Up-to-date clients like OpenSSH, Dropbear, and PuTTY prefer ssh-ed25519 by default and does not accept ssh-rsa.

Can you elaborate on that?

If no one is using ssh-rsa is there even a reason to keep it enabled? There are newer ciphers that still use RSA and since most people are using ed25519 it shouldn't be much of a impact to disable ssh-rsa by default.

This is a low risk but the fix is simple to do since it is just a build option. The idea is to try to make OpenWRT more secure even with bad clients and configs.

From Stack Overflow:

Use 3 is more questionable, since you're performing a signature, where collision resistance is required, although this is probably not practically attackable. The attacker would have to have some way of guessing the shared Diffie-Hellman secret or a derived value, and we generally expect that to be computationally infeasible. That's because SHA-1 is weak to collision attacks, so an attacker has to be able to produce two messages (which, with current attacks, are of a certain form) that hash to the same value, and it would be hard to do that in an online manner without the assistance of the server.

Use of SHA-1 as signature within a PKI (#3) is different though. A weak signature algorithm would allow the creation of a certificate which seems to be signed by the trusted CA and is thus accepted for authentication. The attacker has also sufficient time to create such a faked certificate.

This is more of a theoretical problem since it is very hard to exploit in practice. The biggest threat would be a man in the middle but to actually perform the attack is impossible from a feasibility perspective. However, this is pretty simple to fix so I think it still has some value. I'm fine making a PR since it just is a matter of changing some build options. Even though this theoretically impossible to exploit it still could be part of a exploit in the future.

In the case of PKI it is much worse though. SHA-1 is used for the key signature which means that someone with some compute horsepower could brute force a matching cert.

Initial claim about exploitation is thus
false by own admission.

In an open source project run by volunteers, the answer to this kind of question is almost always because no one took the time to change it. And since the risk is zero with modern SSH clients, it won't get prioritized among other bugs or features.

Also if you feel strongly about it, consider making a PR.

1 Like

always fun to look at things...

Dropbear

sfx@raspy:~ $ ssh-audit 192.168.1.1
# general
(gen) banner: SSH-2.0-dropbear
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+
(gen) compression: disabled

# key exchange algorithms
(kex) curve25519-sha256              -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
(kex) curve25519-sha256@libssh.org   -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) diffie-hellman-group14-sha256  -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) kexguess2@matt.ucc.asn.au      -- [info] available since Dropbear SSH 2013.57
(kex) kex-strict-s-v00@openssh.com   -- [warn] unknown algorithm

# host-key algorithms
(key) ssh-ed25519                    -- [info] available since OpenSSH 6.5
(key) rsa-sha2-256 (2048-bit)        -- [info] available since OpenSSH 7.2
(key) ssh-rsa (2048-bit)             -- [fail] using weak hashing algorithm
                                     `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
                                     `- [info] a future deprecation notice has been issued in OpenSSH 8.2: https://www.openssh.com/txt/release-8.2

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com  -- [info] available since OpenSSH 6.5
                                     `- [info] default cipher since OpenSSH 6.9.
(enc) aes128-ctr                     -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes256-ctr                     -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52

# message authentication code algorithms
(mac) hmac-sha2-256                  -- [warn] using encrypt-and-MAC mode
                                     `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56

# fingerprints
(fin) ssh-ed25519: SHA256:r05/ijWuhycSHT6ABgg8Jo48i1p2y8nbKbu9osKNCzg
(fin) ssh-rsa: SHA256:JzPf7QDyiz3BIW+44pANYNAoanA4kovlRLGpoitVHWo

# algorithm recommendations
(rec) -ssh-rsa                       -- key algorithm to remove
(rec) -hmac-sha2-256                 -- mac algorithm to remove

# additional info
(nfo) For hardening guides on common OSes, please see: <https://www.ssh-audit.com/hardening_guides.html>



!!! WARNING: unknown algorithm(s) found!: kex-strict-s-v00@openssh.com.  Please email the full output above to the maintainer (jtesta@positronsecurity.com), or create a Github issue at <https://github.com/jtesta/ssh-audit/issues>.

and now OpenSSH from current Ubuntu...

sfx@raspy:~ $ ssh-audit 192.168.15.120
# general
(gen) banner: SSH-2.0-OpenSSH_8.9p1
(gen) software: OpenSSH 8.9p1
(gen) compatibility: OpenSSH 8.5+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)

# key exchange algorithms
(kex) curve25519-sha256                     -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) sntrup761x25519-sha512@openssh.com    -- [warn] using experimental algorithm
                                            `- [info] available since OpenSSH 8.5
(kex) diffie-hellman-group-exchange-sha256 (2048-bit) -- [info] available since OpenSSH 4.4
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group14-sha256         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) kex-strict-s-v00@openssh.com          -- [warn] unknown algorithm

# host-key algorithms
(key) rsa-sha2-512 (3072-bit)               -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (3072-bit)               -- [info] available since OpenSSH 7.2
(key) ecdsa-sha2-nistp256                   -- [fail] using weak elliptic curves
                                            `- [warn] using weak random number generator could reveal the key
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5

# encryption algorithms (ciphers)
(enc) chacha20-poly1305@openssh.com         -- [info] available since OpenSSH 6.5
                                            `- [info] default cipher since OpenSSH 6.9.
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes128-gcm@openssh.com                -- [info] available since OpenSSH 6.2
(enc) aes256-gcm@openssh.com                -- [info] available since OpenSSH 6.2

# message authentication code algorithms
(mac) umac-64-etm@openssh.com               -- [warn] using small 64-bit tag size
                                            `- [info] available since OpenSSH 6.2
(mac) umac-128-etm@openssh.com              -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha2-512-etm@openssh.com         -- [info] available since OpenSSH 6.2
(mac) hmac-sha1-etm@openssh.com             -- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 6.2
(mac) umac-64@openssh.com                   -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using small 64-bit tag size
                                            `- [info] available since OpenSSH 4.7
(mac) umac-128@openssh.com                  -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 6.2
(mac) hmac-sha2-256                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1                             -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28

# fingerprints
(fin) ssh-ed25519: SHA256:RxG/hlj2donYn5nZmHVaf9Qd/f597RaerI7hP2VNfGk
(fin) ssh-rsa: SHA256:5hgw3+wKp6nXoukhMY5lbCJtxcFJg0uyGpya1gNep1o

# algorithm recommendations (for OpenSSH 8.9)
(rec) -ecdh-sha2-nistp256                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521                   -- kex algorithm to remove
(rec) -ecdsa-sha2-nistp256                  -- key algorithm to remove
(rec) -hmac-sha1                            -- mac algorithm to remove
(rec) -hmac-sha1-etm@openssh.com            -- mac algorithm to remove
(rec) -hmac-sha2-256                        -- mac algorithm to remove
(rec) -hmac-sha2-512                        -- mac algorithm to remove
(rec) -sntrup761x25519-sha512@openssh.com   -- kex algorithm to remove
(rec) -umac-128@openssh.com                 -- mac algorithm to remove
(rec) -umac-64-etm@openssh.com              -- mac algorithm to remove
(rec) -umac-64@openssh.com                  -- mac algorithm to remove

# additional info
(nfo) For hardening guides on common OSes, please see: <https://www.ssh-audit.com/hardening_guides.html>



!!! WARNING: unknown algorithm(s) found!: kex-strict-s-v00@openssh.com.  Please email the full output above to the maintainer (jtesta@positronsecurity.com), or create a Github issue at <https://github.com/jtesta/ssh-audit/issues>.

1 Like

It wouldn't matter if this was the biggest post of the decade. I've noticed that you are constantly negative and disrespectful throughout the forums. I would really appreciate if you would refrain from gatekeeping OpenWRT as it is incredibly off putting. You always look for ways on how you can make others feel stupid instead of actually trying to be helpful.

Just something to keep in mind

1 Like

Stock OpenSSH server could very much be improved out of the box. I would recommend that you run ssh-audit against anything public facing.

Like I said above, this is more of a nice to have security benefit instead of something that is highly vulnerable. It is unlikely that someone is going to exploit it in practice but it is trivial to disable so I don't see any benefit of leaving it turned on.

Ad hominem attacks wont help, ssh router to router is quite common and taking out rsa keys support from dbclient would make that go away. IMO better approach would be not generating rsa key if others are permitted.

Well - security is a bus going down the street that folks are trying to catch...

We'd all like to be perfect in hardening things, I get it, but we've all got devices of different capabilities..

I raged on my companies Hosted Jira instance, where Firefox and Chrome got serious about TLS support and couldn't access any more...

There's another thread here around WPA*-Enterprise, and TLS support there.

Best we can hope for is to nudge folks forward on the client side, and do the best on the server side ...

1 Like

I think one of the issues here with OpenSSH vs Dropbear...

OpenSSH - we can directly config the daemon and do a restart...

Dropbear - it's in the localoptions.h file, and a rebuild...

For example...

#define DROPBEAR_RSA_SHA1 0
#define DROPBEAR_DH_GROUP14_SHA1 0
#define DROPBEAR_SHA1_HMAC 0

As just one thing...

RSA 2048+ is a completely secure cipher. The issue is SHA1 as it can be brute forced to find a collision on modern hardware.

There are ciphers based on RSA and SHA256 which would be better to have enabled.

1 Like

Then you have to brush the dust off telnet for interoperability.