A recent vulnerability, titled “Terrapin,” (CVE-2023-48795) has been discovered in SSH connections where attackers can bypass integrity checks and downgrade the security of a connection between a host and client machine. This attack, which can only occur with someone who can act as a man-in-the-middle (MitM), targets the extension negotiator¹ within the SSH protocol, compromising the integrity of the secure channel and essentially reducing your SSH connection to a vulnerable state similar to that of an RSH (Remote Shell) connection.
How Terrapin Exploits the SSH Handshake
An SSH connection is like a digital tunnel linking two machines together through the Internet.
One of the easiest ways to explain the Terrapin attack is with the following diagram2 of a simple socket connection below:
Each step is numbered to correlate with the steps within the diagram.
Step 1. During an SSH handshake connection, the client first sends a synchronization request to the host.
Step 2. The host replies with an acknowledgement and synchronizes with the client.
Step 3. From here the attacker (man in the middle), injects a purposely ignored packet (more on this later).
Step 4. Having established a successful sync and sync/ack, the client and host exchange keys.
Step 5. Depending on the type of SSH connection, a client and host would carry out their algorithm and extension negotiation either before or after exchanging keys. With our example, we are assuming that this negotiation occurs after the exchange of keys.
Step 6. The message that contains the client’s supported extensions is truncated by the attacker. Though packet deletion (or truncation) is commonly detected by either the client or host (due to mismatched sequence numbers), it goes undetected here because of the purposely injected, ignored packet sent earlier, which offsets the sequence numbers accordingly.
What is the significance of dropping that extension message? If the attacker prevents the client from sending the extension negotiation message to the host, this can result in both the client and host machines agreeing to utilize less secure client authentication algorithms in addition to deactivating security countermeasures (such as keystroke timing attacks).
How to Defend Yourself Against Terrapin Attacks
NoPorts SSH is the permanent networking solution developed by Atsign® to defend against Terrapin Attacks. When initiating conventional SSH sessions, the process commences with the creation of a standard socket (no additional features or extensions - just a plain old socket), and the SSH client and daemon negotiate various communication aspects over that socket. NoPorts SSH v5 takes this SSH connection a step further by making traffic over the 'plain old socket' be end-to-end encrypted. This means that everything the SSH client and daemon exchange is encrypted, providing a robust defense against man-in-the-middle attacks–including Atsign itself.
How does NoPorts SSH prevent even Atsign from compromising any transmissions sent over the connection? The answer is quite simple! Atsign does not possess any of the keys that atSigns utilize to establish these connections. If Atsign were to try and tamper with a NoPort connection, any information it would come across would be gibberish because the content is encrypted before it even leaves the domain.
NoPorts SSH, for those leveraging it for its core value proposition (no ports listening on public network interfaces), provides the additional value that when faced with a perfectly positioned man-in-the-middle, the security of your SSH session remains uncompromised. In addition to this, NoPorts SSH acts as a safeguard against compromise by any man-in-the-middle attack. In the worst-case scenario, an attacker may disrupt a session, but the security of the session remains intact, and nothing is compromised.
This simple diagram shows how NoPorts SSH is protected from Terrapin Attacks:
To explain how this works, let’s start from the very far left in the client domain. Within this domain, before an SSH connection is established with the device, the client communicates locally with NoPorts SSH’s client socket rendezvous (SRV). From here, this port encrypts all information before being transmitted through the Internet. The client SRV communicates directly with Atsign’s Socket Rendezvous Daemon (SRVD). From here, the SRVD can connect the client SRV directly to the device SRV. With this, the two machines can now carry out and establish an SSH connection. One important thing to note about the atProtocol® is that devices can only make outbound connections (as displayed in the diagram). If you are interested in how this works more in depth, the atProtocol is open source and can be found on the Atsign-Foundation GitHub Organization. If you are also interested in how NoPorts SSH works in more depth, you may read the documentation here.
If an attacker attempts a man-in-the-middle attack with this architecture, they would have very little to work with as any attempt in disturbing the communication between the two machines will result in termination of the connection. Why is this? Since our client’s rendezvous port has encrypted the transmission before being sent out to the Internet, even if an attacker intercepts this message, they would be incapable of reading its information. If an attacker tries to inject information into the outbound message, they won’t possess the keys needed for decryption, resulting in junk being added. Consequently, the decryption process of the device’s rendezvous port will fail and terminate the connection.
Closing Notes
It is important to understand vulnerabilities if you wish to maintain the integrity of your network architecture and system. Atsign’s approach of NoPorts SSH not only defends against man-in-the-middle attacks such as Terrapin but creates a powerful shield against many other attack surfaces.
Learn more:
Have a question?
Contact us at support@noports.com
Join our Discord and talk to us!
¹The targeted extension negotiator within the SSH protocol is the RFC 8308.
²We've simplified this diagram. The original diagram can be found on the Terrapin-Attack site.
