Encryption for SSH and TLS

Two most common cryptography protocols: SSH and TLS/SSL, are commonly mis-configured in many ways.

 

SSH (22/tcp)

The SSH key exchange algorithm is fundamental to keep the protocol secure. It is what allows two previously unknown parties to generate a shared key in plain sight, and have that secret remain private to the client and server.

Nearly all encryption schemes require parties to have a shared secret. Key Exchange algorithms are what allow two parties to create a shared secret while exchanging information in public sight. Key Exchange algorithms do not actually exchange keys, but rather partial variables that allows both parties to create a shared secret.

Over time, some implementations of this algorithm have been identified as weak or vulnerable.

A weak Key Exchange Algorithms use components with fundamental security flaws. There are only two primary reasons they are be regarded as ‘weak’:

1. The algorithm uses SHA1. 
2. The algorithm uses RSA 1024-bit modulus keys.

When flaws were identified in SHA1, it was believed this could potentially impact SSH security. An attack against the protocol would carry an extreme level of difficulty and would be nearly impossible to conduct in practice.

Despite the unlikeliness of an attack occurring, using encryption algorithms with known weaknesses such as SHA1 will raise a Low Risk issue on a network penetration test.

A list of known weak key exchange algorithms:

• diffie-hellman-group-exchange-sha1
• Diffie-hellman-group1-sha1
• gss-gex-sha1-*
• gss-group1-sha1-*
• rsa1024-sha1

Besides that, there is also issue of SSH weak MAC algorithms. These algorithms exist in the majority of SSH configurations and are generally considered Low Risk.

As with most encryption schemes, SSH MAC algorithms are used to validate data integrity and authenticity. A ‘MAC algorithm’ should not be conflated with a MAC (Message Authentication Code) as these are two distinct components. The MAC algorithm uses a message and private key to generate the fixed length MAC.

A weak MAC algorithm may be considered weak for the following reasons:    

1. A known weak hashing function is used (MD5) 
2. The digest length is too small (Less than 128 bits) 
3. The tag size is too small (Less than 128 bits) 
   

The following are the most common known weak MAC algorithms encountered in SSH:    

• hmac-md5
• hmac-md5-96
• hmac-sha1-96
• hmac-sha2-256-96
• hmac-sha2-512-96

TLS/SSL (443/tcp)

3 commonly mis-configured ciphers in TLS/SSL server:

• Information disclosure with predicted IV in CBC
  
• NULL ciphers supported
• 'Export Ciphers' enabled  
  

SSLv3 and TLS1.0 implementations using Chained-block ciphers (CBC) may be vulnerable to plain-text recovery attacks. When predictable IVs are used in CBC mode, an attacker can leverage this in more advanced attacks as demonstrated in the ‘BEAST’ attack.

There are two ways to remediate this: 1) Disable TLS 1.0 completely to enforce TLS 1.1 and TLS 1.2; 2) Leave TLS 1.0 support enabled, but disable Chained Block Ciphers (CBC).

NULL ciphers offer no true cryptographic data confidentiality. Instead of secure mathematical algorithms to protect data, null ciphers use predefined blocks of data to obfuscate plain-text. No protection is actually provided by null ciphers and should not be used in production environments where confidentiality is required.

Examples of null ciphers:

• TLS_NULL_WITH_NULL_NULL
• TLS_RSA_WITH_NULL_MD5 / NULL-MD5
• TLS_DHE_PSK_WITH_NULL_SHA / DHE-PSK-NULL-SHA

Export ciphers’ are low-grade cryptographic ciphers that were authorized to be used outside the US during the 1990’s. During this time encryption was heavily regulated by the US government as auxiliary military equipment. This allowed intelligence agencies greater ease to eavesdrop on foreign communication channels of interest.

Although export ciphers may be strong enough to secure data from the general public, they include many well known flaws that would allow state-sponsored actors to break the encryption if intercepted. Supporting export ciphers poses an excessive risk to users who may be using older web clients.

Because most SSL/TLS services negotiate ciphers in a top-down fashion, it is rare that clients such as web browsers will negotiate all the way to down to export grade encryption. Despite this, consideration should be given to downgrade attacks where negotiation of export ciphers may be forced by a MITM vector. 

Examples of 'export ciphers':

• SSL_RSA_EXPORT_WITH_RC4_40_MD5 / EXP-RC4-MD5
• TLS_RSA_EXPORT_WITH_DES40_CBC_SHA / EXP-DES-CBC-SHA

 

Links:

• https://www.virtuesecurity.com/kb/ssh-weak-key-exchange-algorithms-enabled/
• https://www.virtuesecurity.com/kb/ssh-weak-mac-algorithms-enabled/
• https://www.virtuesecurity.com/kb/tls-1-0-initialization-vector-implementation-information-disclosure-vulnerability/
• https://www.virtuesecurity.com/kb/null-ciphers-supported/
• https://www.virtuesecurity.com/kb/export-ciphers-enabled/

SSH and TLS Enumeration

SSH and TLS/SSL are the two (2) most common encrypted protocols used daily by sysadm. Here, I listed some cmdline commonly used by me daily in troubleshooting the 2 protocols and some links below.

SSH (22/tcp):

Enumerate SSHD configuration with SSHscan

$ python sshscan.py -t 192.168.31.1

Enumerate SSH algorithm with NMAP

$ nmap --script ssh2-enum-algos 192.168.1.1

Print its (client) configuration after evaluating Host and Match blocks.

$ ssh -G 192.168.31.1

Queries ssh for the algorithms supported: cipher, cipher-auth, mac, kex, keq-gss, key, key-cert, key-plain, key-sig, protocol-version.

$ ssh -Q query_option

TLS/SSL (443/tcp):

$ sslyze www.facebook.com

$ ./sslscan.exe 192.168.31.1

$ tlsscan 192.168.31.1

$ ./tls-scan -c www.facebook.com --cacert=./ca-bundle.crt --pretty

Links:

• https://myseq.blogspot.com/2022/07/ssltls-recon.html
• https://myseq.blogspot.com/2022/07/sshscan.html
• https://myseq.blogspot.com/2022/07/sslyze-fast-and-powerful-ssltls.html
• https://myseq.blogspot.com/2022/07/ssl-configuration-generator.html
• https://security.stackexchange.com/questions/94390/whats-the-purpose-of-dh-parameters
• https://www.infoworld.com/article/3027557/openssl-patches-two-vulnerabilities-in-cryptographic-library.html
• https://nmap.org/nsedoc/scripts/ssh2-enum-algos.html
• https://stackoverflow.com/questions/16212816/setting-up-openssh-for-windows-using-public-key-authentication?rq=1 
• https://www.activestate.com/blog/how-to-manage-tls-certificate-expiration-with-python/
  

CodExt – Python Codecs extension

CodExt is a (Python2-3 compatible) library that extends the native codecs library (namely for adding new custom encodings and character mappings), hence its name combining CODecs EXTension. It provides 120+ new codecs and also features a guessing mode for decoding multiple layers of encoding and CLI tools for convenience.

Links:

• https://github.com/dhondta/python-codext
• https://hakin9.org/codext-encode-decode-anything-with-python/
  

TLS/SSL Server Supports The Use of Static Key Ciphers

Today, I have a colleague that asks me about a vulnerability called "TLS/SSL Server Supports The Use of Static Key Ciphers " (ssl-static-key-ciphers).

This vulnerability has CVSS 2.6 (rated by Rapid7). According to Rapid7:

The server is configured to support ciphers known as static key ciphers. These ciphers don't support "Forward Secrecy". In the new specification for HTTP/2, these ciphers have been blacklisted.

Here're the questions to me:

• What kind of vulnerability is this?
• Since this vulnerability has low (<4) CVSS rating, can we skip the remediation?
• Why the vulnerability still exist even I have follow the PCI compliance by only allowing TLS 1.1 and TLS 1.2?

My answers:

• To me, this is a kind of mis-configuration, rather than a (missing) patching issue.
• To me, this is not an urgent but it is an important vulnerability. With advanced cracking using GPU, we are not sure if anyone will finally able to crack a session key and lead to full compromise of encrypted channel given some amount of time.
  
• Yes, even if you have only TLS 1.2 enabled, your system may still vulnerable to static key cipher attack.Referring to the post on Static Key Cipher Vs Perfect Forward Secrecy, by disable all the weak cipher suites (SSLv2/SSLv3/TLS1.0) and only allowing recommended cipher suites (TLS1.1/TLS1.2), does not guarantee forward secrecy is always used.
  

Static Key Cipher Vs Perfect Forward Secrecy

In cryptography, symmetric encryption, there are 2 ways to handle the session key. One is static key cipher, and another is Perfect Forward Secrecy (or simply Forward Secrecy).

Forward secrecy, is a feature key management that ensures session key will not be compromised if the long-term secrets (private signing key) used in the session key exchange are compromised. This means by compromise a single session key, it will not affect any data other than that exchanged in the specific session protected by the key.

Thus, FS can protects past sessions against future compromises of keys. But static key cipher is the other way. By using static key cipher, compromise of single session key (in the future) will lead to compromise of all the past encrypted session.

During the cipher suite negotiation, the client sends a handshake message with a list of cipher suites it will accept.  The server chooses from the list and sends a handshake message back indicating which cipher suite it will accept.  Although the client may order the list with the strongest cipher suites listed first, the server may choose any of the cipher suites proposed by the client.  (The client may even send those cipher suite with weakness to server) Therefore there is no guarantee that the negotiation will settle on the strongest suite in common.  If no cipher suites are in common the connection is aborted. 

Cipher suites using ephemeral DH and ephemeral ECDH (i.e., those with DHE or ECDHE in the mnemonic) provide perfect forward secrecy, ensuring long-term confidentiality of the session. 

Note that by restricting to TLS 1.2 cipher suite doesn't guarantee forward secrecy is always been used. For example, below are a list of TLS 1.2 approved ciphers, and those highlighted are still using static key cipher.

•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
•     Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
•     Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
•     Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
•     Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
•     Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
•     Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
•     Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
•     Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
•     Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

Note that FS is designed to prevent the compromise of a long-term secret key from affecting the confidentiality of past conversations. But, FS cannot defend against a successful cryptanalysis of the underlying ciphers being used. This is because, FS only protects keys (not the ciphers). If a cryptanalysis found a way to decrypt an encrypted message without the key, then FS cannot help here.