Monday, August 3, 2015 At 9:11AM
The LogJam attack against the TLS protocol allows a man-in-the-middle attacker to downgrade a TLS connection such that it uses weak cipher suites (known as export cipher suites). More precisely, the attack forces a Diffie-Hellman (DH) key exchange based on a weak group. A group (multiplicative group modulo p where p is prime) is considered weak if the defining prime has a low bit length.
Many key exchange protocol implementations, including those for TLS, utilize publicly known DH groups such as the Oakley groups used for IKE. The disadvantage of employing a publicly known group is that an attacker may already have precomputed information that helps in breaking an instance of a DH key exchange relying on that group. To impede precomputation attacks, TLS implementations typically enable the configuration of unique DH groups on the server-side.
The DH key exchange protocol is not only used as part of the TLS protocol but for many other protocols including the SSH protocol. While there are test tools (e.g. the web tool from the LogJam authors or the command-line openssl tool) which check whether the LogJam vulnerability exists for TLS-based services, there are currently no test tools available for SSH.
Weak diffie-hellman groups in SSH
In contrast to TLS, the SSH protocol (defined in RFC 4253) does not support export cipher suites and does not suffer from a known design flaw that enables cipher suite downgrade attacks. The SSH protocol specification requires implementations to support at the least the following two DH key exchange methods:
-
diffie-hellman-group1-sha1
-
diffie-hellman-group14-sha1
Both methods use an Oakley group; the first method uses the Oakley Group 2 of size 1024 bits and the second method uses the Oakley Group 14 of size 2048 bits.
The authors of the LogJam paper envision that it may be possible for nation states to break 1024-bit groups. Therefore, the authors recommend disabling diffie-hellman-group1-sha1 on the server-side. For example, OpenSSH allows for enabling key exchange methods through the parameter KexAlgorithms in the server configuration file. The configuration file is typically located at /etc/ssh/sshd_config.This method is also expected to be disabled by default in the imminent OpenSSH 7.0 release.
Besides the two discussed DH key exchange protocols, many SSH clients and servers implement the two additional DH group exchange methods from RFC 4419:
-
diffie-hellman-group-exchange-sha1
-
diffie-hellman-group-exchange-sha256
When using either of these methods the SSH client starts the exchange protocol by proposing a minimal, preferred, and maximal group size in bits. The server then picks “a group that best matches the client’s request”. However, RFC 4419 leaves open how the server makes this choice. Therefore, the chosen group size is implementation-dependent. Finally, the client and server execute the DH protocol to exchange a key.
The authors of the LogJam paper recommend using ECDH or generating large, unique DH groups on the server for the DH group exchange protocols. For the OpenSSH server implementation, they provide the following commands that generate unique 2048-bit DH groups:
-
ssh-keygen -G moduli-2048.candidates -b 2048
-
ssh-keygen -T moduli-2048 -f moduli-2048.candidates
The file moduli-2048 is then used to replace the system SSH moduli file, typically /etc/ssh/moduli.
The DH key exchange protocol parameters that the client and server end up using depend on both the client and server configuration. As explained in RFC 4253, both the client and server propose a list of supported key exchange algorithms (in this context, the terms protocol and algorithm are interchangeable), ordered by preference where the first algorithm is the most preferred. In simple terms, if the client and server do not prefer the same suitable algorithm, the client and server iterate over the client’s key algorithm list and choose the first algorithm that both sides support and that is compatible with the other algorithms that SSH relies upon.
Contribution
We present a tool to identify whether an SSH server configuration permits the use of a weak DH key exchange group. To determine whether an SSH client is able to exchange a key using a weak DH group, our tool attempts to connect to the server with specific client configurations. The configuration parameters include the key exchange algorithm and the minimum, preferred, and maximum group sizes. While we provide diverse test configurations, it is straightforward to add new configurations or modify the existing ones. Furthermore, the user may configure additional client parameters such as the list of preferred encryption and MAC algorithms.
Our tool can actually be considered a tool chain consisting of three components: a shell script, a patched OpenSSH client, and a Python based analysis script. The shell script we provide allows for enumerating all user-specified configurations. This script uses an OpenSSH client that has been patched to abort the network connection after completing the key exchange. Consequently, this client does not attempt to authenticate to the server. Moreover, our OpenSSH client patch allows for specifying the minimum, preferred, and maximum group size in bits through the command-line option -d (mnemonic: Diffie-Hellman). The adapted client prints important information regarding the DH key exchange. The shell script then stores this output in files. To analyze these files we provide a Python script. The shell script automatically launches this analysis script. However, it is also possible to run the analysis script later on the output files.
We chose the OpenSSH client, since it is a widely used open source SSH client implementing an extensive set of features. Moreover, these features are easy to configure using a configuration file or command-line options. In particular, we patch the latest stable version of the portable OpenSSH client (OpenSSH 6.9p1). Testing was conducted on Ubuntu 14.04 and Mac OS X Yosemite.
Example
In the following example, we run our tool against an OpenSSH 6.6.1p1 server as it is shipped with Ubuntu 14.04, i.e. the server uses the default configuration.
To run our tool, we specify the host where the server is running and optionally specify the port number (defaults to 22).
Script invocation
KEX proposal client: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 KEX proposal server: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 KEX algorithm chosen: [email protected] ——— SNIP ——— KEX proposal client: diffie-hellman-group-exchange-sha256 KEX proposal server: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 KEX algorithm chosen: diffie-hellman-group-exchange-sha256 KEX client group sizes: min = 768, nbits = 768, max = 768 Connection closed by 127.0.0.1 KEX proposal client: diffie-hellman-group-exchange-sha256 KEX proposal server: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 KEX algorithm chosen: diffie-hellman-group-exchange-sha256 KEX client group sizes: min = 1024, nbits = 1024, max = 1024 KEX server-chosen group size in bits: 1024 ——— SNIP ——— KEX proposal client: diffie-hellman-group-exchange-sha256 KEX proposal server: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 KEX algorithm chosen: diffie-hellman-group-exchange-sha256 KEX client group sizes: min = 2048, nbits = 2048, max = 2048 KEX server-chosen group size in bits: 2048
Analysis of results
——— SNIP ——— The client proposed the following group size parameters (in bits): min=1024, nbits=1024, max=1024. The client and server negotiated a group size of 1024 using diffie-hellman-group-exchange-sha1. The security level is INTERMEDIATE (might be feasible to break for nation-states). ——— SNIP ——— The client proposed the following group size parameters (in bits): min=2048, nbits=2048, max=2048. The client and server negotiated a group size of 2048 using diffie-hellman-group-exchange-sha256. The security level is STRONG.
The trimmed output above shows that the server supports the [email protected] key exchange algorithm. Moreover, we can observe that the server closes the connection when the client requests a 768-bit group in conjunction with the diffie-hellman-group-exchange-sha256 algorithm. Another interesting finding from the output above is that the server permits DH key exchanges using a 1024-bit group. While a 1024-bit group is sufficient in many environments, attackers with nation-state size resources may be able to break the key exchange. If a higher level of security is needed a server administrator could reconfigure the SSH server and rerun our tool to validate that the configuration is as desired.
Conclusions
We presented a tool which establishes multiple connections to an SSH server, thereby enumerating through various client configurations, in order to determine whether the server allows a DH key exchange based on a weak group. We hope that our tool will be useful to check SSH servers for weak DH key exchange configurations.
The source code to the tool can be found on our Github repository:
https://github.com/GDSSecurity/SSH-Weak-DH
REFERENCES
Author: Fabian Foerg
©Aon plc 2023
