Das klappt selbst dann nicht, wenn der Angreifer den privaten Hostkey des Zielrechners hat und aktives MITM betreibt. Hab den Sourcecode von SSH vor Jahren mal zerlegt, weil ich genau das machen wollte. https://tools.ietf.org/html/rfc4251#section-9.3.3 -> hier wird zwar Replay beschrieben, aber laesst sich selbst auf aktives MITM anwenden In der session_id ist u.a. random Kram aus dem DH-Exchange drin, an den du - selbst mit Wissem um den Private Host Key - nicht drankommst :D Der Client kauft dir ab, dass du der Server bist, aber der echte Server laesst dich mit dem gesignten Blob nicht rein, weil die session_id zwischen dir und dem Client und dir und dem echten Server nicht gleich ist. Und da du nur einen Teil der session_id beeinflussen kannst, schaffst du es auch nicht, die bei beiden Verbindungen gleich zu machen. Der Angreifer kommt so nicht auf den echten Server, aber ein Problem bleibt. Du glaubst, du bist auf deinem Server. Je nachdem, welche Dateien du pushst koennte das ein Problem sein. Schoenes Wochenende :D Florian On Fri, 17 Apr 2020 13:53:16 +0200 Markus Witt <markus.witt@rwth-aachen.de> wrote:
Ohai,
weil mich das gerade auch noch im Detail interessiert hat, nochmal kurz zwei Links: In [0] wird beschrieben, dass der Client zur Authentifizierung gegenüber dem Server u.a. einen session identifier signiert. Nach [RFC4252] ist der session indentifier der "exchange hash H" des ersten key exchange, in den nach [RFC4253] für DH und [RFC5656] für ECC der öffentliche Key des Servers einfließt. Solange der MITM also nicht den privaten Key des Zielservers hat, kann er den Client nur einen session identifier signieren lassen, für den er die restlichen sessionkeys nicht kennt (bei passivem MITM, also nur Mitschneiden) oder bei dem dann der public key des echten Servers nicht enthalten ist (aktives MITM).
Gruß Markus
[0] <https://www.gremwell.com/ssh-mitm-public-key-authentication> [RFC4252] <https://tools.ietf.org/html/rfc4252> [RFC4253] <https://tools.ietf.org/html/rfc4253#page-23> [RFC5656] <https://tools.ietf.org/html/rfc5656#page-7>
On 17.04.20 13:22, Florian Kerber wrote:
Das waere kein Problem.
Zum einen hast du ja den Fingerprint des Servers, und beim Mismatch geht die Verbindung nicht weiter.
Selbst wenn du den ignorierst, waere das mit Pubkey-Auth kein Problem. Das Ding macht Challenge-Response und der gesignedte Blob hat u.a. auch teile deiner und der Server-Nonce drinne. Da funktioniert kein MITM. Schon versucht :D
Viele Gruesse
Florian
On Fri, 17 Apr 2020 13:16:19 +0200 Frank Knoben <admin@igpm.rwth-aachen.de> wrote:
Und kann mir mal einer sagen, ob der key nicht auch abgefangen werden kann?
Wenn ich mich beim ssh vertippe, z.b server.rwth-aache.de und die Adresse ist gerade registriert und hört auf port 22 zu.
Viele Grüße
Frank Knoben _______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de
_______________________________________________ rwth-security mailing list -- rwth-security@lists.rwth-aachen.de To unsubscribe send an email to rwth-security-leave@lists.rwth-aachen.de