update dropbear or disable ssh-dss support?

[Brockp]

We have a remote office with a service that scans for vulnerabilities. It's for PCI compliance (this site doesn't require it it's just a staff work from home office) and its triggering because if we have SSH enabled it picks up that ssh-dss is still available and running ssh -v <host> does show ssh-dss being offered.

The actual public key (password login disabled) is an 2048 key, but it still offeres it and the scanner picks that up making our report look messy. Overall though reading it sounds like dropbear dropped a number of less secure exchanges and cypers a while ago but appears ASUS hasn't updated? Is this something we can override in JFFS or someting else?

I can set it to a non-standard port but that's just hiding the issue not actually resolving it and in general be nice to force more secure settings.


Actual report:

Threat
The SSH protocol (Secure Shell) is a method for secure remote login from one computer to another. The SSH Server is using a small Public Key.

Best practices require that RSA digital signatures be 2048 or more bits long to provide adequate security. Key lengths of 1024 are acceptable through 2013, but since 2011 they are considered deprecated.

For more information, please refer to NIST Special Publication 800-131A (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf).
Only server keys that are not part of a certificate are reported in this QID. OpenSSH certificates using short keys are reported in QID 38733. X.509 certificates using short

keys are reported in QID 38171.

IMPACT:

A man-in-the-middle attacker can exploit this vulnerability to record the communication to decrypt the session key and even the messages.

SOLUTION:

DSA keys and RSA keys shorter than 2048 bits are considered vulnerable. It is recommended to install a RSA public key length of at least 2048 bits or greater, or to switch to ECDSA or EdDSA.
RESULT:

Algorithm Length
ssh-dss 1024 bits

 

[ColinTaylor]

Dropbear was updated to the most current version (2022.82) in 386.6.

Disable SSH if it's a problem?

 

[sfx2000]

Disable SSH if it's a problem?

I agree - for PCI/EMV and perhaps also HIPAA compliance, one shouldn't enable SSH on the router itself, as there it has limited security checks, and the dropbear daemon runs as admin/root (e.g. privileged user).

Best just to disable the service on the router - if you need remote SSH for external use, better to use a jumpbox in with a current OpenSSH-server properly configured, and then port forward the jumpbox...

 

[Brockp]

Thanks, I could do that but given this site doesn't actually handle any of that data like I said its not in scope for compliance.
But also it's all windows desktops machines. SSH is used specifically for port forwarding for some monitoring checks for services that don't have anything more secure. We have migrated most of those to VPN instead but the SSH was convenient for remotely managing the router also because the router admin page is not accessible over the VPN connection (as far as we have it configured).

A quick sear it looks like there might be OpenSSH available on windows 10 without the need for Windows server. I know they had ssh client native now, I'll check that out as an alternative tunnel to the router admin page.

Thanks,

 

[Martinski]

SSH is used specifically for port forwarding for some monitoring checks for services that don't have anything more secure. We have migrated most of those to VPN instead but the SSH was convenient for remotely managing the router also because the router admin page is not accessible over the VPN connection (as far as we have it configured).

If for some reason the OpenVPN server on the router is not an option for remote access over the WAN, an alternative to Dropbear SSH (which is not good enough for remote access, IMO) would be to install the OpenSSH Server package via Entware on a USB disk.

opkg install openssh-server openssh-keygen

The setup of the OpenSSH server requires changes in "/tmp/ etc/passwd" & "/tmp/ etc/shadow" files which can be easily done using the F/W built-in script hooks ("/jffs/configs/passwd.add" & "/jffs/scripts/shadow.postconf").

In the OpenSSH configuration file "/opt/ etc/ssh/sshd_config" you can explicitly remove any of the algorithms used for public key authentication:
For example:

PubkeyAcceptedAlgorithms -ssh-dss

My 2 cents.

EDIT:
The blank space in the paths "/xxx/ etc/" was necessary; otherwise, the forum would not allow the post to go thru.

 

[egc]

When you compile the build it should be fairly easy to change the default settings in dropbear/default_options.h

/* Hostkey/public key algorithms - at least one required, these are used
* for hostkey as well as for verifying signatures with pubkey auth.
* Removing either of these won't save very much space.
* SSH2 RFC Draft requires dss, recommends rsa */
#define DROPBEAR_RSA 1
#define DROPBEAR_DSS 0

Maybe that is something RMerlin would consider?

 

[RMerlin]

When you compile the build it should be fairly easy to change the default settings in dropbear/default_options.h

/* Hostkey/public key algorithms - at least one required, these are used
* for hostkey as well as for verifying signatures with pubkey auth.
* Removing either of these won't save very much space.
* SSH2 RFC Draft requires dss, recommends rsa */
#define DROPBEAR_RSA 1
#define DROPBEAR_DSS 0

Maybe that is something RMerlin would consider?

Why? If DSS is not secure, then just don't use a DSS keypair...

As the quoted code says, DSS is required by the RFC to be fully compliant.

 

[egc]

The RFC draft requires dss but recommends rsa, it does mean as a minimum it should have dss but rsa is better, it does not mean dss has to be available if you have rsa.
As it is not secure as the OP already explained why keep it available?

 

[ColinTaylor]

As it is not secure as the OP already explained why keep it available?

Backward compatibility? Bear in mind this is a home router. You're not likely to be targeted by some state-level man in the middle attack. If you are then you shouldn't be using this sort of device. Alternatively, if your internal LAN is so untrustworthy that you think this sort of attack is likely then again you're using the wrong equipment.

 

[tgl]

I'm a little confused why you think you need a software update? AFAICT the scanner's complaint is merely about a short key being offered. You could remove /etc/dropbear/dropbear_dss_host_key and be good ... unless something in the router regenerates that file at reboot, in which case maybe replacing it with a longer key would provide a permanent fix.

 

[RMerlin]

I have to wonder tho, how old would a client app be to ONLY support DSS and not RSA?

 

[Martinski]

... unless something in the router regenerates that file at reboot, in which case maybe replacing it with a longer key would provide a permanent fix.

Currently, DSS keys have a fixed size of 1024 bits (see both Dropbear & OpenSSH key generator tools).

 

[tgl]

Currently, DSS keys have a fixed size of 1024 bits (see both Dropbear & OpenSSH key generator tools).

Right, so the point is to not offer a DSS key. I believe that you could simply remove that key file and dropbear would be perfectly happy. The question is will something in the router's bootup sequence insist on recreating it. If so though, I suspect you could replace it with a file containing a non-DSS key of sufficient bit length to satisfy the security scanner. It's highly unlikely that any script that might think it's supposed to regenerate key files will inquire into exactly what kind of key is in dropbear_dss_host_key --- at most it's checking the file's existence.

 

[tgl]

Currently, DSS keys have a fixed size of 1024 bits (see both Dropbear & OpenSSH key generator tools).

That is demonstrably incorrect so far as OpenSSL is concerned, and I am not sure I believe it for Dropbear either, seeing that dropbearkey's man page defines a "-s bits" option and doesn't suggest that it doesn't work for DSS keys.

Having said that ... I tried making a 2048-bit DSA key on a Linux machine, using

$ openssl dsaparam -out dsaparams 2048
Generating DSA parameters, 2048 bit long prime
...
$ openssl gendsa -out dsa.key dsaparams
Generating DSA key, 2048 bits
...

and then overwrote /jffs/.ssh/dropbear_dss_host_key with that dsa.key file on an ET8 running ASUSWRT 3.0.0.4.386_49873. This failed miserably: after rebooting, the router still works but it refuses ssh connections, so I suppose dropbear failed to start.

I think there are two plausible explanations:

* dropbear doesn't actually work with DSA key sizes above 1024;

* dropbear doesn't like the textual PEM key format I got from the above-given openssl command. I noticed that the other key files in the directory were in some binary format, so this doesn't seem unlikely.

I guess I'm going to have to factory-reset my ET8 before I can get into it again, and I don't have time to do that right now, so I'll leave further exploration to somebody else. But what I'd suggest is seeing whether dropbearkey will accept "-t dss -s 2048" and if so whether dropbear is happy with the result. That should at least take the file format question out of the equation.

 

[Martinski]

Right, so the point is to not offer a DSS key. I believe that you could simply remove that key file and dropbear would be perfectly happy. The question is will something in the router's bootup sequence insist on recreating it. If so though, I suspect you could replace it with a file containing a non-DSS key of sufficient bit length to satisfy the security scanner.

All security scan tools that I'm aware of don't actually check what set of key files exists on the host running the SSH server. What they do is (in simple terms) try to open an SSH session which starts with the 2 sides (client & server) negotiating the set of encryption protocols to be used, and this is accomplished by each side sending its own list of all the supported algorithms so they can both agree to use one common protocol from the lists for public key authentication. And this is the part where the security scan can pick up & check which of the algorithms it considers insecure. IOW, it wouldn't matter whether you have the DSS key file available on the router; it's Dropbear itself that reports the list of supported algorithms.

For example, from Dropbear SSH in my ASUS router, this is the list that I get:

And therein lies the problem with "ssh-dss" being available in the list.

 

[tgl]

And therein lies the problem with "ssh-dss" being available in the list.

Well, maybe, but the OP's security scanner report isn't saying that it's unhappy because DSS is there at all. It's saying that it's unhappy because the key length is just 1024 bits. As far as I've been able to tell from googling, you can't get dropbear to not offer a DSS key; but it seems likely that you can replace the auto-generated key with something longer.

 

[Martinski]

That is demonstrably incorrect so far as OpenSSL is concerned, and I am not sure I believe it for Dropbear either, seeing that dropbearkey's man page defines a "-s bits" option and doesn't suggest that it doesn't work for DSS keys.
...

But what I'd suggest is seeing whether dropbearkey will accept "-t dss -s 2048"

Both Dropbear & OpenSSH (at least as of the latest release versions) will generate and accept DSS keys that are 1024-bit only, regardless of what OpenSSL can do.

Well, maybe, but the OP's security scanner report isn't saying that it's unhappy because DSS is there at all. It's saying that it's unhappy because the key length is just 1024 bits. As far as I've been able to tell from googling, you can't get dropbear to not offer a DSS key; but it seems likely that you can replace the auto-generated key with something longer.

For all intents & purposes, Dropbear having the DSS algorithm available is the same as having a 1024-bit key available. Both statements are one and the same as far as the security scanner is concerned.

 

[Brockp]

Thanks, everyone. I didn't think of Entware I think that might be a good path because then I can control sshd_config directly to disable offering up dss. A lot of good discussions here. Really IMHO DSS should be retired based on everything I have read.