Kerberos SSH Man-in-the-Middle para Data Sniffing

Question

O Kerberos claramente impede que um invasor obtenha as credenciais de um usuário em um cenário intermediário de SSH (em que o invasor fez o usuário confiar na chave pública de seu servidor e redireciona o tráfego por meio desse servidor). No entanto, o que acontece se um invasor não puder obter as credenciais do usuário, pois ele poderá ouvir a sessão após a autenticação e, potencialmente, obter informações valiosas, incluindo as credenciais inseridas posteriormente.

Para ser claro, aqui está o cenário:

1. O servidor SSH (Server1) e o cliente (User1) estão configurados para o Kerberos. O servidor1 tem um par de chaves pública / privada padrão para autenticação, etc.
2. Inicialmente, o Usuário1 tenta se conectar ao Servidor1, mas sua conexão é redirecionada por um invasor para o Servidor2.
3. O Usuário1 não examina a chave pública do Server2 apresentado e a aceita como uma chave do host conhecida para o Servidor1 (configurando, assim, o MITM).
4. O usuário1 passa pela autenticação Kerberos com o Servidor1 até o Servidor2 (o Servidor2 configura duas sessões SSH separadas e passa as informações entre elas). O atacante não obtém informações valiosas durante a autenticação devido à maneira como o Kerberos funciona.
5. Uma vez autenticado, no entanto, o Usuário1 começa a executar operações no Server1, incluindo o sudo. O atacante é capaz de ver todo o conteúdo da sessão enquanto passa pelo Servidor2.

Isso funcionaria? Esse cenário obviamente seria frustrado usando a autenticação de chave pública durante a etapa de autenticação. Mas há algo no protocolo Kerberos ou SSH que impediria essa situação?

    

Answer 1

Um pouco expandido da discussão nos comentários:

A sua pergunta é: se você desviar o tráfego SSH do cliente para um servidor SSH desonesto, isso pode ser usado em um ataque de repetição capturando e encaminhando o tíquete Kerberos do cliente pelo servidor não autorizado do SSH para o servidor real1?

Isso depende dos mecanismos de segurança do SSH que impedem a falha dos ataques do MiTM, ou seja, o cliente ainda não armazenou em cache a chave do servidor real do Server1 ou, se tiver, StrictHostKeyChecking foi desativado ou ignorado.

Como o SSH + Kerberos GSS-API depende do SSH para a criptografia de dados, sua suposição é de que o servidor SSH desonesto pode, se a autenticação para o Server1 for bem-sucedida, acessar todas as informações transmitidas, já que o SSH não • use criptografia de dados baseada em Kerberos na parte superior da criptografia SSH.

Sim, isso funcionaria em teoria, mas somente se o servidor SSH não autorizado, Server2, obtivesse êxito na representação do cliente no Server1.

Eu acho que o verdadeiro Servidor1 rejeitaria (ou pelo menos deveria) rejeitar as credenciais encaminhadas. Como parte da autenticação do Kerberos, o cliente envia duas mensagens, o ticket de serviço e o autenticador . Embora um ticket de serviço encaminhado seja válido, o autenticador que o acompanha não seria.

RFC 4121 a especificação Kerberos GSS-API usada pelo SSH tem a vinculação de canal Informações como parte da mensagem do autenticador:

"The channel binding tags are intended to be used to identify the particular communications channel for which the GSS-API security context establishment tokens are intended, thus limiting the scope within which an intercepted context establishment token can be reused by an attacker."

Ou seja. A mensagem do Autenticador inclui o endereço IP e a porta de origem do remetente, bem como o endereço IP de destino e os números de porta. Se esses não corresponderem aos da conexão real, a troca do Kerberos deve ser rejeitada pelo Server1.