Kerberos явно не позволяет злоумышленнику получить учетные данные пользователя в сценарии SSH man-in-the-middle (когда злоумышленник заставил пользователя доверять открытому ключу своего сервера и перенаправляет трафик через этот сервер). Однако что, если злоумышленник не против не получать учетные данные пользователя, поскольку он сможет прослушать сеанс после аутентификации и потенциально получить ценную информацию, включая впоследствии введенные учетные данные.
Чтобы внести ясность, вот сценарий:
- SSH-сервер (Server1) и клиент (User1) настроены для Kerberos. Server1 имеет стандартную пару открытого/закрытого ключа для аутентификации и т. д.
- Пользователь1 изначально пытается подключиться к Серверу1, но его соединение перенаправляется злоумышленником на Сервер2.
- Пользователь 1 не обращает внимания на предоставленный открытый ключ от Сервера 2 и принимает его как известный ключ хоста для Сервера 1 (таким образом настраивая MITM).
- User1 проходит аутентификацию Kerberos с Server1 через Server2 (Server2 устанавливает два отдельных сеанса SSH и передает информацию между ними). Злоумышленник не получает никакой ценной информации во время аутентификации из-за особенностей работы Kerberos.
- Однако после аутентификации User1 начинает выполнять операции на Server1, включая sudo. Злоумышленник может видеть все содержимое сеанса, проходящего через Server2.
Будет ли это работать? Этот сценарий, очевидно, будет сорван с помощью аутентификации открытого ключа на этапе аутентификации. Но есть ли что-то в протоколе Kerberos или SSH, что предотвратит эту ситуацию?
решение1
Немного расширенный вариант обсуждения в комментариях:
Ваш вопрос: если вы перенаправляете трафик SSH с клиента на мошеннический сервер SSH, можно ли это использовать в атаке с повторным воспроизведением, перехватив и переслав билет Kerberos клиента мошенническим сервером SSH на настоящий Server1?
Это основано на механизмах безопасности SSH, предотвращающих сбой атак MiTM, т. е. клиент еще не кэшировал реальный ключ сервера от Server1, а если и кэшировал, то StrictHostKeyCheckingбыл отключен или проигнорирован.
Поскольку SSH + Kerberos GSS-API используют SSH для шифрования данных, вы предполагаете, что мошеннический SSH-сервер типа «man-in-the-middle» может, если аутентификация на Server1 прошла успешно, получить доступ ко всей передаваемой информации, поскольку SSH не использует шифрование данных на основе Kerberos поверх шифрования SSH.
Да, теоретически это сработает, но только в том случае, если ваш мошеннический SSH-сервер Server2 успешно выдаст себя за клиента Server1.
Я думаю, что настоящий Server1 отклонит (или, по крайней мере, должен) отклонить пересылаемые учетные данные. В рамках аутентификации Kerberos клиент отправляет два сообщения:Билет на обслуживание и Аутентификатор. Хотя пересланный билет на услугу действителен, сопутствующий аутентификатор не будет действительным.
RFC4121Спецификация Kerberos GSS-API, используемая SSH, содержит информацию о привязке канала как часть сообщения аутентификатора:
«Теги привязки канала предназначены для идентификации конкретного канала связи, для которого предназначены токены установления контекста безопасности GSS-API, тем самым ограничивая область, в которой перехваченный токен установления контекста может быть повторно использован злоумышленником».
То есть сообщение Authenticator включает в себя IP-адрес отправителя и исходный порт, а также IP-адрес назначения и номера портов. Если они не совпадают с данными фактического соединения, обмен Kerberos должен быть отклонен Server1.