Aproveitando os ProxyChains quando o SSH Tunneling requer alguma configuração, e estou curioso sobre o porquê do aspecto

1

Dado informações: Eu tenho acesso root a uma máquina no ip 1.1.1.1 e abro a porta 22.

Em vez de ter que entrar na máquina novamente através de uma exploração para obter acesso root E não instalar aplicativos em sua máquina (Se eu criei um shell reverso na máquina, ele pode ser detectado), tentei uma nova abordagem ; encaminhamento de porta e cadeias de proxy.

A ideia que tive foi configurar um túnel para o servidor web e apenas encaminhar as informações para iniciar o mapeamento da rede interna. Eu tropecei em proxychains, que é tão simples quanto configurar a porta, digamos 8080 em seu arquivo conf, em seguida, executando comandos: proxychains ifconfig e, em seguida, proxychains nmap --script=discovery $ip

Parece haver alguma configuração que precisa ser feita antes que você possa usar as cadeias de proxy e é aqui que eu penso por quê? . Eu adicionarei abaixo.

Então, primeiramente como acesso root no servidor, eu abro a porta 22 e faço um usuário com permissões de administrador, digamos jakefromstatefarm .

Então eu vou da minha máquina atacante fazer o seguinte:

ssh -f -N -R 2222:127.0.0.1:22 [email protected]
# Enter password for jakefromstatefarm
ssh -f -N -D 127.0.0.1:8080 -p 2222 [email protected]
# Enter password for atkMachineUser

Agora eu usaria proxychains na porta 8080 editando o arquivo conf

proxychains ifconfig

Minha pergunta que me confunde é por que precisamos configurar esses conjuntos de túneis antes? É por causa das credenciais de usuário necessárias para falar com as diferentes máquinas? Dessa forma, a máquina irá manter as credenciais e, a partir daí, os proxychains não precisam manter nada?

Eu estava confuso porque eu não sabia por que não podia, em teoria, configurar proxychains para usar a porta 22 para falar diretamente com o servidor web em 1.1.1.1 e executar seus respectivos comandos.

Estou tentando entender corretamente o encapsulamento SSH.

Eu li um monte de informações, páginas wiki e livros, e enquanto eu vagamente entendo alguns conceitos, eu não tenho um caloroso e fuzzy ainda. Dito isto, eu adoraria se alguém pudesse explicar isso para mim como se eu tivesse 5 ou bem, com menos bobagens.

    
por Fallenreaper 01.11.2017 / 20:38

1 resposta

0

Explicação SSH

Talvez alguém possa entrar em contato se eu entendi errado, mas foi assim que entendi que isso funcionava.

Você está criando uma porta de escuta no host remoto e a redirecionou localmente. Isso remove sua máquina da equação de decidir onde o tráfego precisa ser roteado, e é por isso que você não precisa configurar rotas depois. Assim, o host remoto toma a decisão com base no tráfego que recebe para onde enviá-lo.

proxychains envia tráfego para 8080 - > Envio de tráfego para a porta de escuta 2222 na vítima remota que reverte para o loopback 22 nesse host. Agora esse host está no controle de determinar para onde o tráfego vai. É por isso que você precisa girar dessa maneira.

Usar esse método deixa a responsabilidade de roteamento cair no host da vítima, que é como o pivô funciona.

[ATTACKER] 8080 < - > 2222 [VICTIM] < - > 22 [VICTIM:]

Se você ignorar o primeiro passo, sua máquina terminará decidindo qual rota tomar e lhe dará resultados indesejados enviando tráfego para qualquer rota de rede que possa obter para isso ... geralmente roteando através de sua rede de ISPs ou algum servidor público da rede segmentada do outro lado do host.

[ATTACKER] 8080 < - > 22 [VICTIM:]

    
por 30.03.2018 / 04:33