In SSH-kliënte OpenSSH en PuTTY ( in PuTTY en in OpenSSH), wat lei tot inligtinglekkasie in die verbindingsonderhandelingsalgoritme. Die kwesbaarheid stel 'n aanvaller in staat om kliëntverkeer te onderskep (byvoorbeeld wanneer 'n gebruiker deur 'n aanvaller-beheerde draadlose toegangspunt koppel) om 'n poging op te spoor om die kliënt aanvanklik aan die gasheer te koppel wanneer die kliënt nog nie die gasheersleutel gekas het nie.
Met die wete dat die kliënt vir die eerste keer probeer koppel en nog nie die gasheersleutel aan sy kant het nie, kan die aanvaller die verbinding deur homself (MITM) uitsaai en die kliënt sy gasheersleutel gee, wat die SSH-kliënt sal oorweeg om wees die sleutel van die teikengasheer as dit nie die sleutelvingerafdruk verifieer nie. Dus, 'n aanvaller kan MITM organiseer sonder om gebruikers agterdog te wek en sessies waarin die kliëntkant reeds gasheersleutels in die kas het, ignoreer, 'n poging om te vervang wat sal lei tot 'n waarskuwing oor die verandering van die gasheersleutel. Die aanval is gebaseer op die sorgeloosheid van gebruikers wat nie die vingerafdruk van die gasheersleutel handmatig nagaan wanneer hulle die eerste keer koppel nie. Diegene wat sleutelvingerafdrukke nagaan, word teen sulke aanvalle beskerm.
As 'n teken om die eerste verbindingspoging te bepaal, word 'n verandering in die volgorde van lys ondersteunde gasheersleutelalgoritmes gebruik. As die eerste verbinding plaasvind, stuur die kliënt 'n lys van verstekalgoritmes, en as die gasheersleutel reeds in die kas is, word die geassosieerde algoritme in die eerste plek geplaas (algoritmes word in volgorde van voorkeur gesorteer).
Die probleem verskyn in OpenSSH-vrystellings 5.7 tot 8.3 en PuTTY 0.68 tot 0.73. Probleem ter sprake deur 'n opsie by te voeg om die dinamiese konstruksie van 'n lys gasheersleutelverwerkingsalgoritmes te deaktiveer ten gunste van die lys van die algoritmes in 'n konstante volgorde.
Die OpenSSH-projek beplan nie om die gedrag van die SSH-kliënt te verander nie, want as u nie die algoritme van die bestaande sleutel in die eerste plek spesifiseer nie, sal 'n poging aangewend word om 'n algoritme te gebruik wat nie ooreenstem met die kassleutel nie en 'n waarskuwing oor 'n onbekende sleutel sal vertoon word. Dié. 'n keuse ontstaan - óf inligtinglekkasie (OpenSSH en PuTTY), óf waarskuwings oor die verandering van die sleutel (Dropbear SSH) as die gestoorde sleutel nie ooreenstem met die eerste algoritme in die versteklys nie.
Om sekuriteit te verskaf, bied OpenSSH alternatiewe metodes vir gasheersleutelverifikasie deur gebruik te maak van SSHFP-inskrywings in DNSSEC en gasheersertifikate (PKI). U kan ook die aanpasbare keuse van gasheersleutelalgoritmes deaktiveer deur die HostKeyAlgorithms-opsie en die UpdateHostKeys-opsie gebruik om die kliënt toe te laat om bykomende gasheersleutels te verkry na verifikasie.
Bron: opennet.ru