[Severe Security Issue] Password Sent Despite Host Key Verification Failure

[0x07E5]

Describe the problem:
Tabby attempts to connect to the server and sends the SSH username and password even when the host key verification fails.

To Reproduce:

1. Set up an SSH honeypot to log attempted passwords.
   docker run -dp 8888:2222 cowrie/cowrie:latest
2. Create an SSH profile using Tabby, select "Password" as the authentication method, and enter any password. For this example, I'll use "TABBY_VERY_SECURE_PA.SS.WORD".
3. Connect to this profile, and after the host key verification prompt appears, wait a few seconds, then click "Disconnect."
4. The password "TABBY_VERY_SECURE_PA.SS.WORD" appears in the honeypot logs
   

[Eugeny]

Thank you for the report!

@all-contributors add @0x07E5 for security

[barseghyanartur]

I wonder, which versions of Tabby were affected? Was this issue recently introduced, or did it exist for a longer time already?

[Eugeny]

It has existed for a long time unfortunately.

[iBug]

(In response to 7# in this V2EX thread: https://www.v2ex.com/t/1074838)

Just want to add that this issue presents minimal risk to public key authentication, as the authentication protocol doesn't sign an arbitrary challenge (let alone giving out your private key), but rather a session-specific payload (RFC 4252 section 7). The best thing a malicious server can have is knowledge of your possession of the corresponding private key. It can do nothing more than that.

V2EX

Tabby 的 SSH 主机密钥验证形同虚设，完全无法阻止中间人攻击 - V2EX

信息安全 - @drymonfidelia - 之前在 /t/1074154 问 V 友有没有开源的 SSH 客户端推荐，很多人推荐了 Tabby ，今天闲下来打算试试，这类工具我用前都会先简单测试一下安全性，结果我都还没开始用，第一个测试就发现了

[0x07E5]

(In response to 7# in this V2EX thread: https://www.v2ex.com/t/1074838)

Just want to add that this issue presents minimal risk to public key authentication, as the authentication protocol doesn't sign an arbitrary challenge (let alone giving out your private key), but rather a session-specific payload (RFC 4252 section 7). The best thing a malicious server can have is knowledge of your possession of the corresponding private key. It can do nothing more than that.

No. Even though in public key authentication, the client does not "give out" its private key, the process involves signing data specific to the session. This includes information like a session identifier (as defined in RFC 4252 Section 7), and this signature is meant to prove the client’s possession of the corresponding private key.
In a MITM scenario, if the client does not verify the host key, the attacker can create a separate connection to the real server and act as a proxy. When the client sends the signed data, the attacker forwards it to the real server. The real server will think it’s talking to the legitimate client, as the signed session data is valid. However, the client never realizes it is talking to an attacker, as it never verified the real server's host key.

[Eugeny]

In both DH and ECDH exchanges, neither client nor server have full control over the session ID as it includes the server's host key, whose ownership is validated by client during kex (note that this is distinct from a known host validation, which was broken by this bug).

So a MitM actor cannot abuse this bug to replay the key exchange to another server.