Dalam klien SSH OpenSSH dan PuTTY ( dalam PuTTY dan dalam OpenSSH), yang membawa kepada kebocoran maklumat dalam algoritma rundingan sambungan. Kerentanan membenarkan penyerang yang mampu memintas trafik klien (contohnya, apabila pengguna menyambung melalui titik akses wayarles dikawal penyerang) untuk mengesan percubaan untuk menyambungkan klien kepada hos pada mulanya apabila klien belum lagi menyimpan kekunci hos.
Mengetahui bahawa klien cuba menyambung buat kali pertama dan belum mempunyai kunci hos di sisinya, penyerang boleh menyiarkan sambungan melalui dirinya sendiri (MITM) dan memberikan kunci hos kepada klien, yang akan dipertimbangkan oleh klien SSH menjadi kunci hos sasaran jika ia tidak mengesahkan cap jari kunci. Oleh itu, penyerang boleh mengatur MITM tanpa menimbulkan syak wasangka pengguna dan mengabaikan sesi di mana pihak klien sudah mempunyai kunci hos cache, percubaan untuk menggantikan yang akan menghasilkan amaran tentang perubahan kunci hos. Serangan itu berdasarkan kecuaian pengguna yang tidak memeriksa cap jari kunci hos secara manual apabila mereka mula-mula menyambung. Mereka yang memeriksa cap jari kunci dilindungi daripada serangan sedemikian.
Sebagai tanda untuk menentukan percubaan sambungan pertama, perubahan dalam susunan penyenaraian algoritma kunci hos yang disokong digunakan. Jika sambungan pertama berlaku, pelanggan menghantar senarai algoritma lalai, dan jika kunci hos sudah ada dalam cache, maka algoritma yang berkaitan diletakkan di tempat pertama (algoritma diisih mengikut keutamaan).
Masalahnya muncul dalam keluaran OpenSSH 5.7 hingga 8.3 dan PuTTY 0.68 hingga 0.73. Masalah dalam isu dengan menambah pilihan untuk melumpuhkan pembinaan dinamik senarai algoritma pemprosesan kunci hos yang memihak kepada penyenaraian algoritma dalam susunan yang berterusan.
Projek OpenSSH tidak merancang untuk mengubah tingkah laku klien SSH, kerana jika anda tidak menentukan algoritma kunci sedia ada pada mulanya, percubaan akan dibuat untuk menggunakan algoritma yang tidak sepadan dengan kunci cache dan amaran tentang kunci yang tidak diketahui akan dipaparkan. Itu. pilihan timbul - sama ada kebocoran maklumat (OpenSSH dan PuTTY), atau amaran tentang menukar kunci (Dropbear SSH) jika kunci yang disimpan tidak sepadan dengan algoritma pertama dalam senarai lalai.
Untuk menyediakan keselamatan, OpenSSH menawarkan kaedah alternatif untuk pengesahan kunci hos menggunakan entri SSHFP dalam DNSSEC dan sijil hos (PKI). Anda juga boleh melumpuhkan pemilihan penyesuaian algoritma kunci hos melalui pilihan HostKeyAlgorithm dan menggunakan pilihan UpdateHostKeys untuk membolehkan pelanggan mendapatkan kunci hos tambahan selepas pengesahan.
Sumber: opennet.ru