У SSH-клієнтах OpenSSH і PuTTY виявлена вразливість CVE-2020-14002 в PuTTY і CVE-2020-14145 в OpenSSH), що приводить до витоку інформації в алгоритмі узгодження з'єднання. Уразливість дозволяє атакувальнику, здатному перехопити трафік клієнта (наприклад, при підключенні користувача через контрольовану атакувальником точку безпроводового доступу), визначити спробу початкового підключення клієнта до хосту, коли клієнтом ще не прокешований ключ хоста.
Знаючи, що клієнт намагається під'єднатися в перший раз і ще не має на своєму боці ключ хоста, атакувальник може транслювати з'єднання через себе (MITM) і видати клієнту свій хостовий ключ, який SSH-клієнт вважатиме ключем цільового хоста, якщо не виконає звірку відбитка ключа. Таким чином, атакувальник може організувати MITM не викликавши підозри у користувача та ігнорувати сеанси, в яких на стороні клієнта вже є прокешовані ключі хостів, спроба підміни яких призведе до виводу попередження про зміну ключа хоста. Атака будується на безтурботності користувачів, які не виконують ручну перевірку fingerprint-відбитка ключа хоста при першому підключенні. Ті, хто перевіряють відбитки ключів від подібних атак захищені.
Ознакою для визначення першої спроби підключення використовується зміна порядку перерахування підтримуваних алгоритмів хостовых ключів. У разі якщо відбувається перше підключення клієнт передає список алгоритмів за замовчуванням, а якщо ключ хоста вже є в кеші, то пов'язаний з ним алгоритм виставляється на перше місце (алгоритми сортуються в порядку переваги).
Проблема проявляється у випусках з OpenSSH c 5.7 по 8.3 і в PuTTY з 0.68 за 0.73. Проблема усунена у випуску PuTTY 0.74 через додавання опції для відключення динамічної побудови списку алгоритмів обробки хостових ключів на користь перерахування алгоритмів в постійному порядку.
Проєкт OpenSSH не планує змінювати поведінку SSH-клієнта, оскільки якщо не вказати алгоритм наявного ключа на першому місці, буде застосована спроба застосування не відповідного прокешованому ключу алгоритму з виводом попередження про невідомий ключ. Тобто постає вибір - або витік інформації (OpenSSH і PuTTY), або вивід попереджень про зміну ключа (Dropbear SSH) у разі, якщо збережений ключ не відповідає першому алгоритму в списку за замовчуванням.
Для забезпечення захисту в OpenSSH пропонується використовувати альтернативні способи перевірки ключа хоста за допомогою записів SSHFP в DNSSEC і сертифікатів хоста (PKI). Також можна відключити адаптивний вибір алгоритмів хостових ключів через опцію HostKeyAlgorithms і використовувати опцію UpdateHostKeys для отримання клієнтом додаткових ключів хоста після аутентифікації.
Коментарі (2)