Kerberos SSH Man-in-the-Middle для сниффинга данных
Kerberos ясно мешает взломщику получать учетные данные пользователя в SSH man-in-the-middle сценарий (тот, где взломщик заставил пользователя доверять открытому ключу их сервера и трафику перенаправлений через тот сервер). Однако, что, если взломщик хорошо с не получением учетных данных пользователя, потому что они смогут слушать сессию после аутентификации и потенциально получить ценную информацию, включая впоследствии вводимые учетные данные.
Чтобы быть ясным, вот, сценарий:
- Сервер SSH (Server1) и клиент (User1) настраивается для Kerberos. Server1 имеет стандартную пару "открытый/закрытый ключ" для аутентификации и т.д.
- User1 первоначально пытается соединиться с Server1, но их соединение перенаправляется взломщиком к Server2.
- User1 не пристально смотрит на открытый ключ от Server2, который представлен и принимает его как известный ключ хоста для Server1 (таким образом настраивающий MITM).
- User1 проходит аутентификацию Kerberos с Server1 через Server2 (Server2 настраивает две отдельных сессии SSH и передает информацию между ними). Взломщик не получает ценной информации во время аутентификации из-за способа, которым работает Kerberos.
- После того, как аутентифицируемый, однако, User1 начинает выполнять операции на Server1, включая sudo. Взломщик может видеть все содержание сессии, поскольку они проходят через Server2.
Это работало бы? Этому сценарию, очевидно, мешали бы с помощью аутентификации с открытым ключом во время шага аутентификации. Но есть ли что-то в 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.