Kerberos явно не позволяет злоумышленнику получить учетные данные пользователя в сценарии SSH «человек посередине» (когда злоумышленник заставляет пользователя доверять открытому ключу своего сервера и перенаправляет трафик через этот сервер). Однако что, если злоумышленник не получит учетные данные пользователя, потому что он сможет прослушать сеанс после аутентификации и потенциально получить ценную информацию, включая введенные впоследствии учетные данные.
Для ясности, вот сценарий:
Это сработает? Очевидно, что этому сценарию будет препятствовать использование аутентификации с открытым ключом на этапе аутентификации. Но есть ли что-то в протоколе Kerberos или SSH, что могло бы предотвратить эту ситуацию?
Немного расширено из обсуждения в комментариях:
Ваш вопрос: если вы перенаправляете SSH-трафик от клиента на несанкционированный SSH-сервер, можно ли его использовать в атаке воспроизведения путем перехвата и пересылки клиентского билета Kerberos мошенническим SSH-сервером на настоящий Server1?
Это зависит от механизмов безопасности SSH, предотвращающих сбои атак MiTM, то есть клиент еще не кэшировал реальный ключ сервера от Server1 или, если он есть, StrictHostKeyChecking был отключен или проигнорирован.
Поскольку SSH + Kerberos GSS-API полагается на SSH для шифрования данных, вы предполагаете, что несанкционированный SSH-сервер посредника может, если аутентификация на Server1 прошла успешно, получить доступ ко всей передаваемой информации, поскольку SSH не использует Kerberos на основе шифрования данных поверх шифрования SSH.
Да, теоретически это сработает, но только в том случае, если ваш несанкционированный SSH-сервер, Server2, успешно олицетворяет клиента для Server1.
Я думаю, что настоящий Server1 отклонит (или, по крайней мере, должен) отклонить перенаправленные учетные данные. В рамках проверки подлинности Kerberos клиент отправляет два сообщения: Сервисный билет и аутентификатор. Хотя переадресованный служебный билет действителен, сопровождающий его аутентификатор не действителен.
RFC 4121 спецификация Kerberos GSS-API, которая используется SSH, содержит информацию о привязке канала как часть сообщения аутентификатора:
«Теги привязки канала предназначены для использования для идентификации конкретного канала связи, для которого предназначены маркеры установления контекста безопасности GSS-API, тем самым ограничивая область, в которой перехваченный маркер установления контекста может быть повторно использован злоумышленником».
Т.е. Сообщение Authenticator включает IP-адрес отправителя и порт источника, а также IP-адрес назначения и номера портов. Если они не соответствуют фактическому соединению, обмен Kerberos должен быть отклонен сервером Server1.