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