SSH-1 (Secure Shell 1) – это один из первых протоколов безопасной удаленной авторизации и передачи данных. Он был разработан для защиты соединений между клиентом и сервером, обеспечивая конфиденциальность, целостность и аутентификацию данных. Протокол SSH-1 не обеспечивает должного уровня безопасности при обмене ключами и подвержен атакам типа “Man-in-the-Middle” (MITM), когда злоумышленник может перехватывать и изменять передаваемые данные [1].

На данный момент считается устаревшим, однако существует ряд причин, почему его продолжают использовать в некоторых организациях и системах:

1. Совместимость со старыми системами: Некоторые старые системы или устройства могут поддерживать только SSH-1 и не имеют возможности обновиться до более безопасной версии протокола. В таких случаях организации могут решить продолжать использовать SSH-1 для поддержки совместимости с этими системами.
2. Наследие и отсутствие обновлений: В некоторых случаях, системы или устройства могут быть заброшены разработчиками или не получать регулярных обновлений. Это может привести к тому, что SSH-1 остается единственным доступным вариантом для удаленного доступа или передачи данных.
3. Ограниченная угроза безопасности: В некоторых средах, где риск атак низок или системы находятся в изолированной сети, использование SSH-1 может быть считаться достаточно безопасным. Однако, даже в таких случаях рекомендуется переходить на более безопасные версии протокола.

SSH-2 (Secure Shell 2) является более современной и безопасной версией протокола SSH. Он был разработан для обеспечения безопасного удаленного доступа, передачи данных и выполнения команд на удаленных системах [2].

Протокол SSH-2 предлагает ряд улучшений по сравнению с его предшественником SSH-1. Вот некоторые ключевые особенности SSH-2 относительно SSH-1:

1. Безопасность: SSH-2 предоставляет более сильные алгоритмы шифрования, аутентификации и обмена ключами. Это помогает защитить данные от перехвата и несанкционированного доступа.
2. Ключевые особенности: Протокол SSH-2 поддерживает различные методы аутентификации, включая аутентификацию на основе пароля, публичного ключа и сертификатов. Он также предоставляет возможность создания и управления ключами для более безопасного доступа.
3. Переносимость: SSH-2 является кросс-платформенным протоколом, что означает, что он может быть использован на различных операционных системах, включая Linux, macOS и Windows. Это обеспечивает гибкость и удобство при работе с удаленными системами.
4. Дополнительные функции: SSH-2 поддерживает сжатие данных, перенаправление портов, туннелирование X11 и другие дополнительные функции, которые облегчают удаленное управление и передачу данных между клиентом и сервером.

В целом, SSH-2 является более безопасным и функциональным протоколом, который рекомендуется для использования в современных системах безопасности. Он обеспечивает защиту данных и конфиденциальность при удаленном доступе и передаче данных, и является стандартом для безопасного управления удаленными системами.

Уязвимости SSH-1 и SSH-2

Первая версия протокола SSH, если в нем не применятся специальные меры по обеспечению конфиденциальности паролей, раскрывает точную длину используемого пароля при аутентификации интерактивной сессии между сервером и клиентом. Более безопасным, в отношении инициализации и аутентификации интерактивной сессии, является вторая версия протокола. Он не раскрывает точную длину пароля, однако все еще позволяет определить некий диапазон длин возможного пароля.

Также существуют уязвимости позволяющие обнаружить ввод пароля во время интерактивной сессии SSH и получить необходимую для компрометации паролей информацию, включая их точную длину (в 1-ой и 2-ой версиях протокола). Это может помочь злоумышленникам в атаке методом bruteforce, когда он пытается подобрать пароль, перебирая все возможные его комбинации.

Кроме того, инструменты анализа трафика, например Wireshark, могут обнаружить заголовки использования аутентификации RSA или DSA, а также количество параметров в файле authorized_keys (конфигурационный файл на сервере SSH, определяющий параметры аутентификации клиентов). Это может быть использовано злоумышленником для выявления факта наличия личного ключа на клиентском компьютере, что создает предпосылки к успешным атакам типа MitM. Если обнаружена сессия SSH с аутентификацией RSA, но без  параметра authorized_keys, злоумышленник может предположить, что на клиентском компьютере хранится незашифрованный личный ключ, который, при условии передачи по открытым каналам, возможно перехватить [3].

Наконец, в интерактивной сессии SSH можно определить длину команды выполняемой в командной оболочке и в некоторых случаях и сами команды.  Для успешной реализации описанных уязвимостей требуется наличие открытого незашифрованного канала между клиентом и сервером SSH.

В целом, понимание и устранение недостатков протокола SSH является важным шагом в обеспечении безопасности информационных систем при использовании SSH-соединений. Рекомендуется всем пользователям и администраторам активно следить за обновлениями и реализовывать рекомендации по снижению уязвимости для обеспечения безопасности своих систем.

Важно отметить, что атаки производимые посредством анализа трафика SSH, описанные выше, могут быть применимы не только к протоколу SSH, но и к другим “безопасным” (шифрованным) протоколам удаленного входа. Также следует учитывать, что существуют и другие методы атак, связанных с анализом трафика SSH, например, обнаружение заголовков в соединениях X11, туннелируемых посредством SSH, позволяющие произвести атаки типа MITM [4].

Уязвимость при аутентификации по паролю

При инкапсуляции текстовых данных в пакет протокола SSH, они дополняются до ближайшей границы, кратной 8 байтам (или размеру блока шифрования в SSH-2), затем шифруются и отправляются вместе с полем длины исходного текста. В SSH-1 это поле передается в открытом виде. В результате злоумышленник, пассивно отслеживающий сеанс SSH, может определить объем передаваемых текстовых данных в каждом пакете – точное значение для SSH-1 или диапазон возможных значений для SSH-2.

Поскольку пароль для входа отправляется в одном пакете протокола SSH-1 без особых мер предосторожности, злоумышленник может определить его точную длину.

В SSH-2 в пакет в котором содержится пароль, добавляется дополнительная информация, такая как имя пользователя и режимы работы, поэтому посредством анализа пакета можно определить только диапазон возможных длин пароля [4].

Однако, благодаря использованию Си подобных строк (при передачи их серверу все null значения отбрасываются, что позволяет создать ситуацию когда заявленная длинна больше фактической), в большинстве реализаций серверов SSH-1, SSH-клиент обычно позволяет добавлять заполняющие null-значений в поле пароля, что приводит к созданию фиктивной длинны в отправляемых пакетах. Данный метод рекомнадован к реализации в будущих дистрибутивах серверов SSH-1, даже если основные интерфейсы операционной системы не позволяют это сделать.

Альтернативным решением, предложенным Саймоном Татамом, является отправка последовательности сообщений протокола SSH-1, содержащих строки с увеличивающейся длиной. Но только одно из этих сообщений  содержит заголовок  SSH_MSG_PASSWORD и содержит строку пароля. Все остальные – SSH_MSG_IGNORE. Важно, чтобы количество отправляемых сообщений оставалось постоянным и было достаточным для покрытия самого длинного ожидаемого пароля. Для безопасной передачи паролей длиной до 32 символов требуется 1088 байт сообщений SSH-1, что может уместиться в одном сегменте пакета TCP. Этот подход имеет преимущество в том, что не раскрывается никаких предположений о реализации сервера SSH-1 [5].

Протокол SSH-2 предлагает решение с меньшими накладными расходами и без зависимости от особенностей реализации транспортных протоколов. Можно сформировать пару сообщений SSH-2, SSH_MSG_USERAUTH_REQUEST и SSH_MSG_IGNORE, таким образом, чтобы их совокупная длина оставалась постоянной. Затем эти последовательности сообщения могут быть отправлены клиенту (серверу) одновременно.

Уязвимости интерактивного сеанса

В интерактивных командных сеансах, обычно каждый вводимый символ отображается на удаленной машине (клиентском компьютере), что приводит к отправке эхо-пакета от сервера для каждого вводимого символа. Однако, если приложение отключает отображение ввода, например, при вводе пароля, пакеты начинают передаваться только в одном направлении – к серверу. Инструменты анализа трафика могут легко обнаружить это и захватить пакеты, содержащие символы вводимого пароля [6].

Как только злоумышленник узнает, что жертва вводит пароль, все, что ему остается  сделать, это посчитать пакеты, на которые сервер не отправил эхо-пакет. В случае SSH-1, сумма размеров открытого текста дает точную длину пароля, за исключением символов backspace. В SSH-2 злоумышленник может только предположить, что каждый пакет содержит только один символ пароля, что обычно таковым и является.

Задержки между пакетами дают злоумышленнику дополнительную информацию о вероятности возможных символов в каждой позиции пароля. Например, если задержка перед символом больше, чем у большинства других задержек, вероятно, этот символ требует нажатия более одной клавиши, пример клавиша shift.

При вводе команд в командной оболочке через SSH каждый символ генерирует небольшой эхо-пакет от сервера. Однако, после ввода всей команды сервер отправляет один объемный общий пакет, содержащий приглашение оболочки и возможный  вывод команды.

Подсчитывая небольшие пакеты (или длины открытого текста в пакетах, отправленных на сервер, в случае SSH-1), злоумышленник может определить длину каждой команды оболочки.  Опять же, задержки могут быть использованы для определения фактически введенных команд оболочки из небольшого списка общих команд.

Частичным решением, которое позволит решить проблему перехвата команд, является модификация SSH-серверов таким образом, чтобы они эмулировали эхо-пакеты, когда отключено отображение терминала приложением. Сообщение типа SSH_MSG_IGNORE может использоваться, чтобы убедиться, что клиент фактически не обрабатывает содержимое этих фиктивных пакетов. Таким образом, не потребуется изменение протокола в целом [7].

Важно отметить, что это частичное решение может только противодействовать наиболее общему способу определения вводимого пароля. В более совершенных способах перехвата пароля используются мониторинг другого связанного сетевого трафика  генерируемого командной оболочкой и событий SSH-сервера.

Решение уязвимостей анализа трафика, не связанных с информацией о вводимом в командную оболочку пароле, значительно увеличит накладные расходы на транспортировку пакетов SSH в сети, поэтому практически не применимо для использования в современных условиях.

Применение сжатия данных

Использование сжатия значительно снижает надежность многих описанных выше атак анализа трафика. Это происходит потому, что одно количество открытого текста больше не приводит к передаче определенного количества данных. Размеры пакетов становятся отчасти “случайными” [5].

Однако, вероятно, что сжатие также позволяет проводить еще один класс атак анализа трафика, поскольку изменения размера пакетов из-за сжатия на самом деле не являются случайными – они зависят от содержимого пакета с открытым текстом.

Мы уже знаем о одной практической атаке, которая возможна из-за сжатия. В SSH-2 сообщение SSH_MSG_USERAUTH_REQUEST передается после согласования сжатия. Если включено сжатие, размер результирующего сегмента TCP будет зависеть от энтропии пароля с открытым текстом. Если сообщение SSH_MSG_IGNORE используется для заполнения пароля, как мы предложили, сжатие может уменьшить некоторую пользу, которую это могло бы принести. Эту проблему можно решить, передавая сообщения SSH_MSG_USERAUTH_REQUEST и SSH_MSG_IGNORE без сжатия. Однако, это не тривиально в реализации, если используется общая библиотека сжатия.

Заключение

В заключение, были подробно описывает недостатки в современных реализациях протокола SSH, которые могут привести к возможной утечки конфиденциальной информации к злоумышленником. Найденные уязвимости позволяют прослушивать зашифрованные SSH-сессии и использовать полученную информацию для атак методом перебора паролей. Для реализации описанных атак требуется возможность перехвата сетевого трафика между SSH-серверами и клиентами.

Была также представлена информация о внесенных исправлениях и рекомендации по снижению уязвимости к анализу перехваченного трафика.

В целом, понимание и устранение недостатков протокола SSH является важным шагом в обеспечении безопасности при использовании SSH-соединений. Рекомендуется всем пользователям и администраторам систем активно следить за обновлениями и реализовывать рекомендации по снижению уязвимости для обеспечения безопасности своих систем.