ssh-audit
ssh-audit copied to clipboard
Server policies don't account for '[email protected]', yet?
Debian just released updated packages;
https://lists.debian.org/debian-security-announce/2023/msg00283.html
When installed, the relevant server policies start failing because it now finds [email protected] in the kex list, which does not match its expectations. This happens for both Bullseye and Bookworm, with the following server policies applied, respectively;
- Hardened OpenSSH Server v8.4 (version 4)
- Hardened OpenSSH Server v9.2 (version 3)
I suspect the server policy may need an update? Thanks for all the hard work and fast response, in the meantime 🙂
Example error when ran against a Debian Bullseye target;
Policy: Hardened OpenSSH Server v8.4 (version 4)
Result: ❌ Failed!
Errors:
* Key exchanges did not match.
- Expected: curve25519-sha256, [email protected], diffie-hellman-group16-sha512, diffie-hellman-group18-sha512, diffie-hellman-group-exchange-sha256
- Actual: curve25519-sha256, [email protected], diffie-hellman-group16-sha512, diffie-hellman-group18-sha512, diffie-hellman-group-exchange-sha256, [email protected]
Thanks for reporting this.
The intent of the OpenSSH policies was to track the best configuration that the official release offered. At the same time, I made Ubuntu- specific policies which revolve around that distro. Ubuntu back-ported into their OpenSSH v8.2, v8.9, etc, packages the Terrapin counter- measures implemented by the OpenSSH team in v9.6. So I updated those Ubuntu policies in ssh-audit v3.1.0.
Now that you bring up this topic, perhaps a workaround can be added to consider the kex-strict marker as optional in those policies. The real solution would be to add official Debian-specific policies; I'll have to think about this more. I don't want to overextend myself and fall behind too much on the backlog of issues.
In the meantime, you could create a custom policy with the -M option and use that to evaluate your Debian machines.
This new KEX algo is also seen on SUSE linux systems with the latest openssh patch which also mitigates the "Terrapin Attack".
If there are no specific sshd patches available for the used platform, several distributors recommend to (temporary) disable the following protocols (NIST CVE):
Cipher: [email protected]
MAC: *[email protected]
This conficts with the current recommandations of ssh-audit.
@mejofi : I updated the output of the -L arg to include the following note: "the general OpenSSH policies apply to the official releases only. OS distributions may back-port changes that cause failures (for example, Debian 11 back-ported the strict KEX mode into their package of OpenSSH v8.4, whereas it was only officially added to OpenSSH v9.6 and later). In these cases, consider creating a custom policy (-M option)."
I think using custom policies would be the way to go in this situation. The other option would be for me to keep all those existing policies up-to-date, which, realistically, I'm not going to be able to do long-term; my development time would be better spent on other bug fixes and new features.
Thanks for reporting!