In de SSH-clients OpenSSH en PuTTY ( in PuTTY en in OpenSSH), wat leidt tot uitlekken van informatie in het algoritme voor het onderhandelen van de verbinding. De kwetsbaarheid stelt een aanvaller in staat om het klantverkeer af te luisteren (bijvoorbeeld wanneer een gebruiker verbinding maakt via een door de aanvaller gecontroleerd draadloos toegangspunt), en de poging tot de eerste verbinding van de klant met de host te bepalen, terwijl de klant de hostsleutel nog niet heeft gecached.
Wetende dat de klant probeert voor de eerste keer verbinding te maken en nog geen hostsleutel heeft, kan de aanvaller de verbinding door zichzelf laten lopen (MITM) en de klant zijn eigen hostsleutel geven, die de SSH-client zal beschouwen als de sleutel van de doelhost, als de sleutelafdruk niet wordt gecontroleerd. Hierdoor kan de aanvaller een MITM organiseren zonder verdachte activiteit bij de gebruiker op te roepen en negeren sessies waarin de klant al gehoste sleutels in cache heeft, waarvan een vervangingspoging een waarschuwing over het wijzigen van de hostsleutel zou oproepen. De aanval is gebaseerd op de onoplettendheid van gebruikers die de handmatige controle van de fingerprint van de hostsleutel bij de eerste verbinding niet uitvoeren. Degenen die de sleutelafdrukken controleren, zijn beschermd tegen dergelijke aanvallen.
Als kenmerk voor het bepalen van de eerste poging tot verbinding wordt de volgorde van de genoemde ondersteunde algoritmen voor hostsleutels veranderd. In het geval van de eerste verbinding geeft de klant een standaardlijst van algoritmen door, en als de hostsleutel al in de cache staat, wordt het bijbehorende algoritme als eerste geplaatst (de algoritmen worden gesorteerd op voorkeur).
Het probleem manifesteert zich in versies van OpenSSH van 5.7 tot 8.3 en in PuTTY van 0.68 tot 0.73. Het probleem in de release door een optie toe te voegen om de dynamische opbouw van de lijst met algoritmen voor het verwerken van hostsleutels uit te schakelen ten gunste van een vaste volgorde van algoritmen.
Het OpenSSH-project is niet van plan het gedrag van de SSH-client aan te passen, aangezien als het algoritme van de bestaande sleutel niet als eerste wordt opgegeven, er een poging zal worden gedaan om een incompatibel algoritme met de gecachete sleutel toe te passen, wat een waarschuwing voor een onbekende sleutel oplevert. Dit betekent dat er een keuze ontstaat: ofwel informatielek (OpenSSH en PuTTY), ofwel waarschuwingen over de wijziging van de sleutel (Dropbear SSH) in het geval dat de opgeslagen sleutel niet overeenkomt met het eerste algoritme in de standaardlijst.
Om de beveiliging in OpenSSH te waarborgen, wordt voorgesteld alternatieve methoden voor de validatie van de hostsleutel te gebruiken via SSHFP-records in DNSSEC en hostcertificaten (PKI). Ook kan de adaptieve selectie van hostsleutelalgoritmen worden uitgeschakeld via de optie HostKeyAlgorithms en de optie UpdateHostKeys worden gebruikt om extra hostsleutels voor de client te verkrijgen na authenticatie.
Bron: opennet.ru
