manfred-kaiser
commented
9 months ago 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.
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:
https://github.com/ssh-mitm/ssh-mitm/blob/4fc3ef418847c35d17d0c427e2701b33a03c323c/sshmitm/workarounds/transport.py#L178-L188
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.