SSH Decryption Opens Door to Very Old Security Vectors

Secure Shell, or SSH, is a cryptographic (encrypted) network protocol for initiating text-based shell sessions on remote machines in a secure way. SSH uses the client-server model with public host key fingerprints in order to prevent MiTM (Man in The Middle) attacks.

Cybercriminal usage

It’s very common for hackers to use SSH in order to stay under the radar of security products.

SSH can be exploited for hacking in many ways:

1. SSH is a very common and is usually accepted by most security devices.
2. SSH Tunneling allows an attacker to transfer any traffic he desires over the standard SSH connection – Hackers Are Using SSH Tunnels to Send Spam
3. SSH doesn’t have certificates that the Security Devices could compare against an Certificate Authority to authenticate the server

The main issue with blocking “malicious” SSH connections is that it’s close to impossible to tell the difference between malicious and non-malicious SSH connections without decrypting the traffic. SSH represents a potential way to bypass security by creating connections the security device is not able to fully inspect.

To mitigate this threat, a few major security vendors recently published statements that they are mitigating malicious-SSH usage by creating a feature that enables the ability to intercept and decrypt SSH traffic. Following our research we noticed that current available SSH decryption solutions are exposing organizations to MiTM attacks.
The Technical Details 

The Security Vendors use the SSH-Decryption approach of “One to rule them all” (A single Fingerprint that controls the entire decryption flow). Unfortunately this method doesn’t have any MiTM countermeasure.

Figure 1 – SSH fingerprint warning message

That fingerprint intercepts every SSH connection, unlike the common SSL-Decryption that generates a unique certificate for every server and is therefore much more secure.

SSH-Decryption presents the same Security Device fingerprint for SSH connection.

SSH flow without SSH-Decryption Alice ↔ Bob:

1. Alice initiate SSH connection to the server Bob
2. The server Bob received Alice’s request and transfer her his SSH fingerprint
3. Alice confirm Server Bob and validating that fingerprint haven’t changed and continues the session

* If Bob fingerprint changed Alice will notified about the change to avoid MiTM attacks (see figure 1)

SSH flow with SSH-Decryption (Alice ↔ Chuck) ↔ (Chuck ↔ Bob):

1. Alice initiate connection to the SSH server Bob
2. The Security Device Chuck received Alice’s request and intercepted the connection and presents Alice his fingerprint
3. Alice verifies that the fingerprints haven’t changed and continues the session
4. Chuck also initiates a connection with Bob on Alice behalf
5. Chuck links the connection with Alice with the connection with Bob

Since SSH clients are only aware of MiTM attempts when the fingerprint changes and SSH-Decryption doesn’t present different fingerprints it renders, the MiTM countermeasure is ineffective and vulnerable to MiTM attacks such as DNS-Spoof, Arp-Poisoning, etc. In the following blog post, there is a PoC that shows how user (Alice) been tricked via MiTM attack, however since her SSH connection is handled by Security Device (Chuck) she is not getting warning messages, and as a result her credentials are easily stolen.

Unlike SSL-Decryption, where the security gateway ensures the connection between it and the destination site hasn’t been tampered with by validating the server certificate the same way a web browser would.

In addition, by using those MiTM attacks very simple to steal login credentials by redirecting the client request to the attacker malicious server and restore the sessions after the credentials are stolen

Moreover, by stealing the Security Device credentials as well it is GG (Total Victory) for the attacker side.

Best Practices:

1. In case you are doing SSH decryption, ensure that the security device is presenting a unique fingerprint for each host or verify that the host fingerprint haven’t changed
2. In case you don’t have SSH decryption.
   1. Limit outgoing SSH usage only to trusted servers from trusted users.
   2. Deny incoming SSH connections.