SSH or Secure Shell

For those of you that don't know, SSH is, in simple terms, an encrypted network protocol that allows network services to operate securely over an unsecured network.

SSH provides a secure channel between a client and a server. Commonly used to manage remote machines and transfer files in a secure form, SSH is usually found on TCP port 22.

On this blogpost we will start by looking at the data we acquire, then we will do a general analysis of the different fields, followed by a quick look at a problem that occurred in 2008.

Data

The data we currently get regarding SSH and which was used to develop this blogpost looks as follows:

{ "origin": "grabber", "src": { "port": 22, "ip": "XXX.XXX.XXX.XXX" }, "result": { "data": { "banner": "SSH-2.0-OpenSSH_6.6.1", "capabilities": { "compression_algorithms": [ "none", "zlib@openssh.com" ], "mac_algorithms": [ "hmac-md5-etm@openssh.com", "hmac-sha1-etm@openssh.com", "umac-64-etm@openssh.com", "umac-128-etm@openssh.com", "hmac-sha2-256-etm@openssh.com", "hmac-sha2-512-etm@openssh.com", "hmac-ripemd160-etm@openssh.com", "hmac-sha1-96-etm@openssh.com", "hmac-md5-96-etm@openssh.com", "hmac-md5", "hmac-sha1", "umac-64@openssh.com", "umac-128@openssh.com", "hmac-sha2-256", "hmac-sha2-512", "hmac-ripemd160", "hmac-ripemd160@openssh.com", "hmac-sha1-96", "hmac-md5-96" ], "encryption_algorithms": [ "aes128-ctr", "aes192-ctr", "aes256-ctr", "arcfour256", "arcfour128", "aes128-gcm@openssh.com", "aes256-gcm@openssh.com", "chacha20-poly1305@openssh.com", "aes128-cbc", "3des-cbc", "blowfish-cbc", "cast128-cbc", "aes192-cbc", "aes256-cbc", "arcfour", "rijndael-cbc@lysator.liu.se" ], "server_host_key_algorithms": [ "ssh-rsa", "ecdsa-sha2-nistp256", "ssh-ed25519" ], "kex_algorithms": [ "curve25519-sha256@libssh.org", "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" ] }, "cyphers": [{ "fingerprint": "cc:34:05:6d:13:54:69:a3:a1:c3:6a:6a:2a:96:47:d5", "key": "AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEt23Ji1LNak3Viqu5TuJhfpnHw/4TOqkDyXjrEXxVxsV4yP+f3XtB/GF0nvDKq39+r6b1JgP3wpYGQSCrRptBk=", "cypher": "ecdsa-sha2-nistp256" }, { "length": 2048, "fingerprint": "56:c1:42:ae:49:1c:a4:8b:6a:9d:42:c0:36:7e:06:a1", "key": "AAAAB3NzaC1yc2EAAAADAQABAAABAQDJa6+PGqbgMj7Dl2PIlfORSP5oDlUWTGtOm9hRWgv4RcmYFegk2rTje6FRh1zB/n+Cm6ETzsidvYMfBH5dVxGOysssbBzsE/gMWcaAhM65EJg5gAL53SPYOU6R2wwtafpYVjL5Ws6t4cfQ9NBAkJA7qtm7qFlJ+lh6VD0XkYkTF2L4RvxWjKKZb3y6D3qmt3VR9 Ib33un49RLWaSkWwvnBRvCyC6IXZfQrmbpCpl / 3 Ur34OCN1277Q51hls2qFL / 3 xaenDnLw1H1RBz69 / sPHm9G5i6XLWh1TK2OVPMZOL12Fkks7NAaflkCCvszSSPdIZwWZt + UujV6diH + k / tXat ", "cypher": "ssh-rsa" }] } } }

The different fields are self-explanatory from a technical perspective. We have the IPv4 address (removed for privacy reasons) and TCP port, the banner of the service running on the port, the different encryption algorithms that are accepted by the server and the cypher section which contains the fingerprints and key lengths. One important note is that we only asked for ECDSA and SSH-RSA keys - although there are others.

General Analysis

Our scans found 16,532,281 IP addresses that responded to our requests. It's important to notice that not all Internet reachable SSH servers are present in the dataset, as we respect blacklist/no-scan requests sent to us by end users/entities.

One field we found interesting to start looking at is the key length. The following plot shows the top 10 key lengths:

In total we found 109 different key lengths. In the plot, four key lengths are shown that have a much higher number of occurrences than the rest - 1032, 2048, 1040 and 1024.

Other interesting fields to look at are the kex_algorithms, mac_algorithms and encryption_algorithms.

Looking at the kex_algorithms some interesting issues pop up:

For "diffie-hellman-group1-sha1", we believe that the NSA has some really fast computers that are able to break keys up to 1024 bit in length. Reference: https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

We know that NIST curves are considered insecure as they have a set of problems with them. Yet, we still see them dominating the top 10, falling only to "diffie-hellman-group14-sha1".

One interesting fact here is that we probably see the NIST curves being the most used likely because DJB curves only came much later and are only supported in later versions of SSH. Reference: http://cr.yp.to/talks/2013.09.16/slides-djb-20130916-a4.pdf

We then moved onto the mac_algorithms...

One big red flag here is the use of MD5 and SHA1. MD5 and SHA1 should never be used and yet there they are. Even though for HMAC you are most likely still safe , why bother with old, antiquated and bad crypto? Do not risk the security of your servers. Attacks only get better so, unless you have legacy maintenance issues, go for better crypto.

But what about the encryption_algorithms?

At a minimum on block ciphers you should have blocks of 128 bits.

Fingerprints

11,196,975 of the 16,532,281 fingerprints found were duplicated - only 32.3% of the fingerprints were unique.

The following plot presents the top 20 fingerprint occurrences:

As one can observe, there is one fingerprint that stands out - e7:86:c7:22:b3:08:af:c7:11:fb:a5:ff:9a:ae:38:e4 - and it actually accounts for 63.8% of the total results.

Here is the geographical distribution of all duplicated fingerprints found :

Top 10 key lengths:

And here are the top 20 ASNs with duplicated SSH fingerprints:

SSH, like any other software, has different versions that also run in different architectures. The following plot shows the breakdown of the top 20 versions found:

Out of all the IPv4 addresses we found:

9,423,225 are affected by the CVE-2015-5600 - "The kbdint_next_device function in auth2-chall.c in sshd in OpenSSH through 6.9 does not properly restrict the processing of keyboard-interactive devices within a single connection, which makes it easier for remote attackers to conduct brute-force attacks or cause a denial of service (CPU consumption) via a long and duplicative list in the ssh -oKbdInteractiveDevices option, as demonstrated by a modified client that provides a different password for each pam element on this list."

1,530,566 are affected by the CVE-2013-4421 - "The buf_decompress function in packet.c in Dropbear SSH Server before 2013.59 allows remote attackers to cause a denial of service (memory consumption) via a compressed packet that has a large size when it is decompressed."

83,357 are affected by the CVE-2015-6565 - "sshd in OpenSSH 6.8 and 6.9 uses world-writable permissions for TTY devices, which allows local users to cause a denial of service (terminal disruption) or possibly have unspecified other impact by writing to a device, as demonstrated by writing an escape sequence."

Debian - The old problem



Source: xkcd.com

This is a joke/image you might have seen before.

On May 13th 2008, CVE-2008-0166 revealed that "OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems uses a random number generator that generates predictable numbers, which makes it easier for remote attackers to conduct brute force guessing attacks against cryptographic keys." At the time HDMoore generated a set of SSH keys that were affected by this vulnerability.

We decided to cross check these common keys against our dataset: we found 2064 of those present (after duplicate removal, 3907 before doing so!)

Top 20 matched common keys:

Debian worldwide distribution:

Debian key length:

Conclusion

Although a service designed to be secure, SSH will only be as secure as the people maintaining the servers running it.

It's important that you, as a system administrator, sit down and really understand what you are maintaining, which ciphers can/should your clients and servers accept and in which order, so that you can set your configurations correctly.

Don't forget that there are many reasons why you should be worried about the security of your servers and the internet.

There are websites which currently have some good breakdowns about secure configurations to use.

Follow them. Also if you want to learn more about NIST curves and crypto have a look at this website.

We would like to thank Joao Poupino and pmsac for the review of the article and suggestions given.