Terrapin Attack vs. SSH-MITM: Comparing Packet Handling

[hmaier1996]

I am reaching out to explore a potential similarity I noticed in packet handling between SSH-MITM and the Terrapin Attack, as highlighted in the discussion of Pull Request #163 on the SSH-MITM repository.

It appears that both methods involve discarding certain packets during the SSH key exchange process.

In SSH-MITM, packets are discarded during kex-init:

ssh-mitm/sshmitm/workarounds/transport.py

Lines 178 to 188 in 4fc3ef4

	if ptype not in self._expected_packet:
	if ptype == 30:
	# according to rfc 4253, the next packet should be ignored,
	# when first_kex_packet_follows is True
	# this is a workarround at the moment, but connection works
	continue
	raise SSHException(
	"Expecting packet from {!r}, got {:d}".format(
	self._expected_packet, ptype
	)
	) # noqa

According to the Terrapin Attack website, packet discarding is a crucial aspect of their methodology.

The packet handling techniques used in SSH-MITM, as seen in the GitHub blame for sshmitm/workarounds/transport.py, were implemented 1-2 years ago. This timeline suggests a noteworthy context: both SSH-MITM and the Terrapin Attack utilize similar methods for manipulating SSH packets. This parallel raises intriguing questions about the Terrapin Attack's exploitability and security implications. The pre-existing nature of these techniques in SSH-MITM might warrant a reevaluation of the Terrapin Attack's impact on SSH security.

I would like to respectfully request the SSH-MITM developers to conduct an evaluation of the Terrapin Attack. This evaluation would greatly benefit the cybersecurity community by clarifying the differences and similarities between SSH-MITM's techniques and those used in the Terrapin Attack. Understanding these nuances is crucial for assessing the relevance and impact of such attacks on both current and future Man-in-the-Middle (MitM) vulnerabilities.

[manfred-kaiser]

Thanks for the question. I've read the paper and their attack is different from SSH-MITM's. There are some similarities in handling MSG_KEXINIT packets because SSH-MITM needs to drop them, but the use cases are different.

Major differences:

Target server and fingerprint:

• SSH-MITM intercepts the connection and the client is forced to log in to SSH-MITM instead of the target server. Because of this the client must accept SSH-MITM's fingerprint. If the client already has a stored fingerprint for the intercepted connection, this can result in warnings about mitm attacks,
• Terrapin Attack works on the unencrypted parts of the intercepted SSH protocol. It's more like an intercepting TCP proxy server that can modify the raw TCP packets.. In this case the client accepts the targets ssh fingerprint and if that key is already known, no mitm warning should be raised.

Intercepting and modification of Shell, SFTP and other features

• SSH-MITM is able to modify the "encrypted" parts, because the client initiated a SSH connection to SSH-MITM and not the target server as expected by the user. This is possible because a valid ssh connection is established between the client and SSH-MITM. This allows reading and modifying all session data and send it to the destination server. In such cases SSH-MITM is able to intercept the login process, interactive shell, file transfers and so on.
• Terrapin Attack does not break encryption, except for the mentioned implementation flaws. Without further implementation flaws like those in AsyncSSH it should not be possible to modify the encrypted parts.

Ignoring specific packets during kex init protocol part

SSH-MITM modifies the kex init part, because there are some clients which have some incompatibilities with Paramiko during interception. Paramiko is a client and server library and not designed to intercept ssh connections and handling the intercepted packets. SSH-MITM tries to mimic the destination server as much as possible which breaks some functionality in Paramiko..

In such cases not only the mentioned packet is ignored. The possible KEX algorithms also need to be modified to avoid disconnects from some ssh client libraries.

As you can see, there are some similarities with the Terrapin Attack, but the attack vector is different.

The Terrapin Attack is a new vulnerability and attack vector, as one of the major differences is the weaknesses in the underlying cryptography from the mentioned algorithms in their paper.

[manfred-kaiser]

I have reopened this issue, because the Terrapin Attack might be relevant for conducting mitm attacks.

With vulnerabilities like CVE-2020-14145 it's possible to detect clients which have already the destinations fingerprint stored. Such clients will raise a mitm warning when intercepted by SSH-MITM.

In the past, the only option was to silently drop the connection before the client raises the warniing. To avoid further warnings, the clients connection could be proxied to the destination server without intercepting ssh.

Terrapin Attack allows a mitm attacks to intercept and manipulate those connections, if the client does not use "kex-strict".

Perhaps it's interesting to support Terrapin Attack to modify such connections for further audits of ssh connections.

Important! If you are a system administrator you should check if your distribution has released a patched version.

[manfred-kaiser]

I have created a pull request for paramikos type hints (python/typeshed#11218).
This pull request is necessary because SSH-MITM changes 2 methods in paramikos Transport class and without that changes linting will fail.

The next release will include compatibility with paramiko >=3.4 and supports the Terrapin Attack fixes.