stealth/pscCriptografia E2E para sessões tty multi-hop ou portshells + encaminhamento de portas TCP/UDP
Este projeto – assim como seu projeto irmão crash – pertence ao meu conjunto de ferramentas anti-censura que permite configurar shells criptografadas totalmente funcionais e encaminhamento TCP/UDP em ambientes censores hostis. Também é útil para perícia forense para despejar dados de dispositivos via UART ou adb quando nenhum outro meio estiver disponível.
Consulta DNS e sessão SSH encaminhadas por uma conexão UART para um Pi
PSC permite criptografar de ponta a ponta sessões de shell, com um ou múltiplos saltos, sendo
agnóstico em relação ao transporte subjacente, desde que seja confiável e possa enviar/receber
dados codificados em Base64 sem modificar/filtrar. Junto com o pty de ponta a ponta que
você recebe (por exemplo, dentro de um port-shell), você pode encaminhar conexões TCP e UDP,
semelhante ao parâmetro -L do OpenSSH. Isso funciona de forma transparente
e sem a necessidade de um endereço IP atribuído localmente no ponto de partida.
Isso permite que peritos forenses e testadores de penetração criem conexões de rede,
por exemplo, via:
adb shell, se o adbd OEM não suportar encaminhamento TCPImagine que você teria uma sessão ppp invisível dentro da sua sessão de shell, sem que o peer remoto realmente suporte ppp.
Funciona em Linux, Android, OSX, Windows, FreeBSD, NetBSD e (possivelmente) OpenBSD.
PSC também inclui suporte a proxy SOCKS4 e SOCKS5 para ter sessões reais de navegação web via port-shells ou conexões discadas remotamente.
Edite o Makefile para refletir suas chaves pré-compartilhadas, conforme definido no topo do Makefile.
Depois basta digitar make no Linux e OSX.
No BSD você precisa instalar o GNU make e invocar gmake em seu lugar.
No Windows você precisa instalar cygwin e selecionar
os pacotes apropriados gcc, gcc-g++, make e git.
No Linux, o PSC usará terminais pseudo Unix98, em outros sistemas usará POSIX pty, mas isso deve ser transparente para você. Uma vez adicionei suporte a pty 4.4BSD e SunOS na idade da pedra por uma razão específica, então pode ou não compilar até com Solaris.
orgulhosamente patrocinado por:
Simples e direto. Na sua máquina local, execute pscl, e passe quaisquer
portas TCP ou UDP que você deseja encaminhar do site remoto para um endereço
específico. Por exemplo:
linux:~ > ./pscl -T 1234:[192.168.0.254]:22 -U 1234:[8.8.8.8]:53
PortShellCrypter [pscl] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: set up local TCP port 1234 to proxy to 192.168.0.254:22 @ remote.
pscl: set up local UDP port 1234 to proxy to 8.8.8.8:53 @ remote.
pscl: Waiting for [pscr] session to appear ...
linux:~ >
[ UART / SSH / ... login to remote side ... ]
No site remoto (o último salto) com a sessão de shell, não importa se está em
um port-shell, SSH, login de console etc, você executa pscr:
linux:~ > ./pscr
PortShellCrypter [pscr] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: Seen STARTTLS sequence, enabling crypto.
linux:~ >
Assim que você executa pscr, ambas as extremidades estabelecem um handshake criptográfico e sobrepõem um protocolo
adicional sobre sua sessão existente, que é transparente para você. Você pode então
conectar-se a 127.0.0.1:1234 na sua máquina local para alcançar 192.168.0.254:22 via
TCP ou o resolvedor 8.8.8.8 via UDP. Isso também funciona com endereços [IPv6],
se o site remoto tiver conectividade IPv6. Na verdade, você pode até usá-lo para traduzir
software IPv4 para IPv6, já que você sempre se conecta a 127.0.0.1 no lado local.
Você pode passar múltiplos parâmetros -T e -U. Se você perder o controle se sua sessão
já está criptografada de ponta a ponta, pode enviar um SIGUSR1 para o processo local pscl, e ele
informará.
PSC também é útil se você quiser usar tor a partir de um shell SSH remoto, onde você
pode encaminhar a porta socks5 e a porta DNS para o endereço 127.0.0.1 do host remoto.
Como o SSH não encaminha pacotes UDP, você normalmente usaria dois conectores socat
ou similar para resolver via nó tor. PSC tem a vantagem de manter os limites dos datagramas UDP,
enquanto socat sobre SSH -L pode quebrar os limites dos datagramas e criar requisições DNS malformadas.
A sessão será criptografada com aes_256_ctr de uma PSK que você escolhe no
Makefile. Esse esquema criptográfico é maleável, mas adicionar dados AAD ou OAD aumenta o
tamanho do pacote, onde cada byte conta, pois em sessões interativas e devido à codificação
Base64, cada caractere digitado já causa muito mais dados a serem enviados.
Sessões UART podem ser usadas via screen, mas por exemplo não via minicom, pois
minicom cria janelas invisíveis com linhas de status e age como um filtro
que destrói o protocolo do PSC. PSC tenta detectar filtragem e pode conviver com
certa quantidade de adulteração de dados, mas em algumas situações não é possível recuperar.
Algo semelhante com tmux. Você deve evitar empilhar manipuladores pty com PSC que
adulteram/processam demais os dados de entrada.
A variável de ambiente SHELL precisa estar definida tanto para pscl quanto para pscr para que
o PSC saiba qual shell executar no pty. SHELL está definida na maioria dos ambientes
por padrão, mas caso não esteja, o PSC precisa ser executado como SHELL=/bin/bash pscl
etc.
pscl também suporta encaminhamento de conexões TCP via SOCKS4 (-4 porta) e SOCKS5
(-5 porta). Isso configura porta como porta SOCKS para conexões TCP, então por exemplo você
pode navegar em redes remotas a partir de uma sessão port-shell sem a necessidade de abrir qualquer outra
conexão durante um teste de penetração. Se você passar -N para pscl, ele ativa a resolução de nomes DNS
no lado remoto, então você também pode usar chrome com ele. Mas esteja avisado: Há um problema de
privacidade com navegadores que tentam resolver uma sequência de nomes DNS na inicialização que
não está sob seu controle. Além disso, se o seu lado remoto tiver uma configuração DNS quebrada, seu shell
de digitação pode travar por vários segundos se pacotes de resposta DNS estiverem faltando. Não existem
boas funções de resolvedor assíncronas que sejam incorporáveis e portáveis, então tive que usar
getaddrinfo() em uma única thread ao preço de possíveis bloqueios por vários segundos
se existirem problemas de DNS. É por isso que a resolução de nomes deve ser ativada explicitamente. pscr
tenta minimizar esse problema potencial com caches de consulta DNS, então na maioria das
situações deve funcionar sem dor.
Se você passar -X endereço-IP (deve ser o primeiro argumento), você pode vincular seu proxy local
a um endereço diferente de 127.0.0.1, assim você pode compartilhar o proxy na sua rede local.