Kerberos claramente impede que um invasor obtenha as credenciais de um usuário em um cenário SSH man-in-the-middle (aquele em que o invasor faz com que o usuário confie na chave pública de seu servidor e redirecione o tráfego através desse servidor). No entanto, e se um invasor concordar em não obter as credenciais do usuário, porque ele poderá ouvir a sessão após a autenticação e potencialmente obter informações valiosas, incluindo credenciais inseridas posteriormente.
Para ser claro, aqui está o cenário:
- O servidor SSH (Servidor1) e o cliente (Usuário1) estão configurados para Kerberos. Server1 possui um par de chaves pública/privada padrão para autenticação, etc.
- O Usuário1 inicialmente tenta se conectar ao Servidor1, mas sua conexão é redirecionada por um invasor para o Servidor2.
- O Usuário1 não examina atentamente a chave pública do Servidor2 apresentada e a aceita como uma chave de host conhecida para o Servidor1 (configurando assim o MITM).
- O Usuário1 passa pela autenticação Kerberos com o Servidor1 até o Servidor2 (o Servidor2 configura duas sessões SSH separadas e passa informações entre elas). O invasor não obtém nenhuma informação valiosa durante a autenticação devido à forma como o Kerberos funciona.
- Uma vez autenticado, entretanto, o Usuário1 começa a executar operações no Servidor1, incluindo o sudo. O invasor consegue ver todo o conteúdo da sessão à medida que passa pelo Servidor2.
Isso funcionaria? Este cenário seria obviamente frustrado usando a autenticação de chave pública durante a etapa de autenticação. Mas há algo no protocolo Kerberos ou SSH que evitaria esta situação?
Responder1
Um pouco expandido da discussão nos comentários:
Sua pergunta é: se você desviar o tráfego SSH do cliente para um servidor SSH não autorizado, isso pode ser usado em um ataque de repetição, capturando e encaminhando o ticket Kerberos do cliente pelo servidor SSH não autorizado para o Servidor1 real?
Isso depende dos mecanismos de segurança SSH que evitam a falha dos ataques MiTM, ou seja, o cliente ainda não armazenou em cache a chave real do servidor do Servidor1 ou, se o fez, StrictHostKeyCheckingfoi desabilitado ou ignorado.
Como o SSH + Kerberos GSS-API depende do SSH para a criptografia de dados, sua suposição é que o servidor SSH desonesto do intermediário pode, se a autenticação no Servidor1 for bem-sucedida, acessar todas as informações transmitidas, já que o SSH não usa Kerberos criptografia de dados baseada na criptografia SSH.
Sim, isso funcionaria em teoria, mas somente se o seu servidor SSH não autorizado, Server2, conseguir representar o cliente para o Server1.
Acho que o verdadeiro Server1 rejeitaria (ou pelo menos deveria) rejeitar as credenciais encaminhadas. Como parte da autenticação Kerberos, o cliente envia duas mensagens, aTicket de serviço e o autenticador. Embora um tíquete de serviço encaminhado seja válido, o autenticador que o acompanha não o seria.
RFC 4121a especificação Kerberos GSS-API usada pelo SSH possui as informações de ligação do canal como parte da mensagem do autenticador:
"As tags de ligação de canal destinam-se a ser usadas para identificar o canal de comunicação específico para o qual os tokens de estabelecimento de contexto de segurança GSS-API se destinam, limitando assim o escopo dentro do qual um token de estabelecimento de contexto interceptado pode ser reutilizado por um invasor."
Ou seja, a mensagem do autenticador inclui o endereço IP e a porta de origem do remetente, bem como o endereço IP e os números da porta de destino. Se eles não corresponderem aos da conexão real, a troca Kerberos deverá ser rejeitada pelo Servidor1.