In den SSH-Clients OpenSSH und PuTTY ( in PuTTY und in OpenSSH), die zu einem Informationsleck im Verhandlungsalgorithmus führt. Die Schwachstelle ermöglicht es einem Angreifer, der den Traffic des Clients abfangen kann (z. B. bei einer Verbindung über einen vom Angreifer kontrollierten Wi-Fi-Hotspot), den ursprünglichen Verbindungsversuch des Clients zum Host zu identifizieren, während der Schlüssel des Hosts noch nicht im Cache des Clients gespeichert ist.
Da ein Kunde versucht, sich zum ersten Mal zu verbinden und noch keinen Host-Schlüssel auf seiner Seite hat, kann ein Angreifer die Verbindung über sich selbst leiten (MITM) und dem Kunden seinen eigenen Hosts-Schlüssel präsentieren. Dieser wird von dem SSH-Client als Schlüssel des Zielhosts angesehen, wenn keine Überprüfung des Fingerabdrucks des Schlüssels erfolgt. So kann der Angreifer einen MITM-Angriff durchführen, ohne Verdacht bei den Benutzern zu erregen, und ignorieren, wenn auf der Client-Seite bereits zwischengespeicherte Hosts-Schlüssel vorhanden sind, deren Austausch eine Warnung über eine Änderung des Hosts-Schlüssels auslösen würde. Der Angriff beruht auf der Nachlässigkeit von Benutzern, die beim ersten Verbindungsaufbau keine manuelle Überprüfung des Fingerabdrucks des Hosts-Schlüssels durchführen. Diejenigen, die Fingerabdrücke überprüfen, sind vor solchen Angriffen geschützt.
Als Zeichen für den ersten Verbindungsversuch wird die Reihenfolge der unterstützten Schlüsselalgorithmen verwendet. Bei der ersten Verbindung überträgt der Client die Standardliste der Algorithmen, während bei einem bereits im Cache vorhandenen Hostschlüssel der zugehörige Algorithmus an die erste Stelle gesetzt wird (die Algorithmen werden nach Präferenz sortiert).
Das Problem tritt in den Versionen von OpenSSH von 5.7 bis 8.3 und in PuTTY von 0.68 bis 0.73 auf. Das Problem im Release wurde durch das Hinzufügen einer Option zur Deaktivierung der dynamischen Erstellung der Liste von Hostschlüsselverarbeitungsalgorithmen zugunsten einer Aufzählung der Algorithmen in fester Reihenfolge behoben.
Das OpenSSH-Projekt plant keine Änderungen am Verhalten des SSH-Clients. Wenn der Algorithmus des vorhandenen Schlüssels nicht an erster Stelle angegeben wird, wird versucht, einen nicht passenden, im Cache gespeicherten Algorithmus anzuwenden, wobei eine Warnung über den unbekannten Schlüssel ausgegeben wird. Das bedeutet, es gibt zwei Optionen — entweder eine Informationsleckage (OpenSSH und PuTTY) oder die Ausgabe von Warnungen über den Schlüsselwechsel (Dropbear SSH), falls der gespeicherte Schlüssel nicht mit dem ersten Algorithmus in der Standardliste übereinstimmt.
Um Schutz in OpenSSH zu gewährleisten, werden alternative Methoden zur Überprüfung des Hostschlüssels vorgeschlagen, wie SSHFP-Einträge in DNSSEC und Hostzertifikate (PKI). Zudem kann die adaptive Auswahl der Hostschlüsselalgorithmen über die Option HostKeyAlgorithms deaktiviert und die Option UpdateHostKeys verwendet werden, um dem Client nach der Authentifizierung zusätzliche Hostschlüssel zu erhalten.
Quelle: opennet.ru
