Problem statement: Let’s assume security agent Nessus is installed in your Linux servers and security scan finds out below ssh related vulnerabilities. We need to fix these vulnerabilities.
|
Vulnerability |
Description |
|
SSH Weak
Key Exchange Algorithms Enabled |
Updates
and Recommendations for Secure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-20.
Section 4 lists guidance on key exchange algorithms that SHOULD NOT and MUST
NOT be enabled. This includes: diffie-hellman-group-exchange-sha1 diffie-hellman-group1-sha1 gss-gex-sha1-* gss-group1-sha1-* gss-group14-sha1-* rsa1024-sha1 Note that
this plugin only checks for the options of the SSH server, and it does not
check for vulnerable software versions. |
|
SSH Weak
MAC Algorithms Enabled |
MD5 or
96-bit MAC algorithms, both of which are considered weak. Note that
this plugin only checks for the options of the SSH server, and it does not
check for vulnerable software versions. |
|
SSH
Server CBC Mode Ciphers Enabled |
The SSH
server is configured to support Cipher Block Chaining (CBC) encryption. This may allow an attacker to recover the
plaintext message from the ciphertext. Note that
this plugin only checks for the options of the SSH server and does not check
for vulnerable software versions. |
How ssh works in background and its associated algorithm
Before we
directly jump into the solution lets first understand how ssh works and what
are the roles of different algorithms which we see from the vulnerability report.
Below are the steps associated with ssh connection
1.
Identification
string exchange: In
this phase client send ssh protocol version and software version to the server
in the form of packet.Then server sends back to its own identification message.
3. Key exchange phase:In this phase both client and server uses a key exchange algorithm to share their public key in a secret key format using algorithm like Diffie-helman etc…
Client
send its ephemeral public key in an encrypted message format.
As
soon as server receives the public key it generates its own private/public key.
Now
server calculate secret key using Diffie-helman algorithm combining clients
public key and its own private/public key
Public key is sent to server by the client
Server generates its own private/public key pair upon receiving public key from client
Server
generates secret key using clients public key + own public/private key
Now hashing algorithm sha2 comes into play which takes following input to create final hash value of the key
Clients
key exchange initialization identification
Server’s
key exchange initialization identification
Server’s
public host key
Clients
ephemeral public key (short term key pair generated by algorithm)
Shared
Secret key
Finally
hash is signed or encrypted by the servers private key
Server is authenticating client by this method.Server creates a message for key exchange and send to client.Client receives servers public key from the message and tries to generate secret key using Diffie hellman algorithm and clients ephermal public/private key pair.
Now
client using same hashing algorithm and same kind of input used in server side.
After
that it verifies server public key by searching local public key database. If
it does not find then it will ask whether to accept server’s public key.
Now client uses servers public key to decrypt the hash that was sent by the server and compares with the hash that is generated in client side. If both matches, then connection is established.
Solution approach: -
Let’s focus on
below vulnerability
|
Vulnerability |
Description |
|
SSH Weak
Key Exchange Algorithms Enabled |
Updates
and Recommendations for Secure Shell (SSH) draft-ietf-curdle-ssh-kex-sha2-20.
Section 4 lists guidance on key exchange algorithms that SHOULD NOT and MUST
NOT be enabled. This includes: diffie-hellman-group-exchange-sha1 diffie-hellman-group1-sha1 gss-gex-sha1-* gss-group1-sha1-* gss-group14-sha1-* rsa1024-sha1 Note that
this plugin only checks for the options of the SSH server, and it does not
check for vulnerable software versions. |
As per above
report we see Nessus has found list of key exchange algorithm which is
considered weak with respect to security standpoint.
How do we prove
that these algorithms are enabled in server side as we have not
enabled/disabled anything in server side.To test that whether any alogorithm is
enabled we can use below command.
If it is enabled,
then below command will not fail and ssh login will work without throwing any
error.
Otherwise,it
will throw below error highlighted in red.
ssh -o
KexAlgorithms="diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1"
<hostname/IP addres>
Unable
to negotiate with <IP> port 22: no matching key exchange method found.
Their offer: diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
You must be
curious at this point how to disable those weak key exchange algorithm.
Actually, we
have to find out list of supported algorithms for specific versions of Linux.After
that we have to specify those supported algorithms in sshd configuration file
except weak algorithms Nessus has found it.
man sshd_config
seach for
the string KexAlgorithms
Take a backup of sshd_config file under /etc/ssh directory.
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bkp
open sshd_config file in vi editor to append
below line
KexAlgorithms
curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group14-sha1,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
You can see
that I have excluded diffie-hellman-group1-sha1,
diffie-hellman-group-exchange-sha1
Save sshd_config
file and restart sshd service like below.
service sshd restart
After you
restart sshd service you can test whether you are able to connect using above
highlighted keyiexchange algorithm like below
ssh -o
KexAlgorithms="diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1"
<hostname/IP addres>
Lets focus on
weak Mac algorithm
|
Vulnerability |
Description |
|
SSH Weak
MAC Algorithms Enabled |
MD5 or
96-bit MAC algorithms, both of which are considered weak. Note that
this plugin only checks for the options of the SSH server, and it does not
check for vulnerable software versions. |
We will use
similar solution approach here.We will find out supported Mac algorithm
Use man sshd_config command
and search for the string MACs
Take a backup of sshd_config file explained in previous staep and append below line
MACs
hmac-sha1,hmac-sha2-256,hmac-sha2-512,umac-64@openssh.com,umac-128@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com
You can see I
have excluded all MD5 or 96 bit algorithms
hmac-md5,hmac-md5-96,hmac-sha1-96, hmac-md5-etm@openssh.com, hmac-md5-96-etm@openssh.com, hmac-sha1-96-etm@openssh.com
Now restart
sshd service and test whether above excluded MAC algorithm is disabled like below
ssh -o
"MACs=hmac-md5,hmac-md5-96,hmac-sha1-96" <servername/IP>
Lets focus on below
Ciphers related vulnerability
|
Vulnerability |
Description |
|
SSH
Server CBC Mode Ciphers Enabled |
The SSH
server is configured to support Cipher Block Chaining (CBC) encryption. This may allow an attacker to recover the
plaintext message from the ciphertext. Note that
this plugin only checks for the options of the SSH server and does not check
for vulnerable software versions. |
We will use
similar solution approach here.We will find out supported Ciphers algorithm
Use man sshd_config command
and search for the string Ciphers
Take backup of sshd_config and append below line exclusing cbc siphers
Ciphers
aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
Now restart
sshd service and test whether CBC Ciphers are disabled like below
ssh -o "Ciphers=aes128-cbc,aes192-cbc,aes265-cbc"
<servername/IP>
This
ends the solution here to fix ssh related vulnerability.
