psc
1.0.0
Este projeto - assim como seu projeto irmão crash - pertence ao meu conjunto de ferramentas anticensura que permite configurar shells criptografados totalmente funcionais e encaminhamento TCP/UDP em ambientes de censura hostis. Também é útil para a análise forense despejar dados de dispositivos via UART ou adb quando nenhum outro meio estiver disponível.
Pesquisa de DNS e sessão SSH encaminhadas através de uma conexão UART para um Pi
O PSC permite criptografar sessões de shell e2e, single ou multip-hop, sendo independente do transporte subjacente, desde que seja confiável e possa enviar/receber dados codificados em Base64 sem modificação/filtragem. Junto com o e2e pty 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. Isto 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 pen-testers criem conexões de rede, por exemplo, por meio de:
adb shell , se o OEM adbd não suportar encaminhamento de TCPImagine que você teria uma sessão ppp invisível dentro de sua sessão shell, sem que o peer remoto realmente suportasse o ppp.
Ele roda em Linux, Android, OSX, Windows, FreeBSD, NetBSD e (possivelmente) OpenBSD .
O PSC também inclui suporte a proxy SOCKS4 e SOCKS5 para ter sessões reais de navegação na web por meio de shells de porta ou dial-ups de modem remotamente.
Edite o Makefile para refletir suas chaves pré-compartilhadas, conforme definido na parte superior do Makefile .
Depois é só digitar make no Linux e OSX .
No BSD você precisa instalar o GNU make e invocar gmake .
No Windows você precisa instalar o cygwin e selecionar os pacotes gcc, gcc-g++, make e git apropriados.
No Linux , o PSC usará pseudoterminais Unix98 , em outros sistemas usará pty's POSIX , mas isso deve ser transparente para você. Certa vez, adicionei suporte ao 4.4BSD pty e ao SunOS na idade da pedra por um motivo específico, portanto, ele pode ou não ser construído mesmo com o Solaris .
orgulhosamente patrocinado por:
Puro e simples. Na sua caixa 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 do shell, não importa se está em um port-shell, SSH, login do 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:~ >
Depois de executar pscr , ambas as extremidades estabelecem um handshake criptográfico e estabelecem um protocolo adicional sobre sua sessão existente que é transparente para você. Você pode então conectar-se a 127.0.0.1:1234 em sua caixa local para acessar 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 ao 127.0.0.1 no lado local.
Você pode passar vários parâmetros -T e -U . Se você perdeu o controle se sua sessão já está criptografada com e2e, você pode enviar um SIGUSR1 para o processo pscl local e ele lhe dirá.
O PSC também é útil se você quiser usar o tor a partir de um shell SSH remoto, onde você pode encaminhar o Socks5 e a porta DNS para o endereço 127.0.0.1 dos hosts remotos. Como o SSH não encaminha pacotes UDP, você normalmente usaria dois conectores socat ou similares para resolver através do nó tor. O PSC tem a vantagem de manter os limites do datagrama UDP, enquanto socat sobre SSH -L pode quebrar os limites do datagrama e criar solicitações DNS malformadas.
A sessão será criptografada com aes_256_ctr de um PSK que você escolher no Makefile . Esse esquema de criptografia é 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á faz com que muito mais dados sejam enviados.
As sessões UART podem ser usadas via screen , mas por exemplo não via minicom , pois o minicom criará janelas invisíveis com linhas de status e atuará como um filtro que destrói o protocolo do PSC. O PSC tenta detectar a filtragem e pode conviver com certa quantidade de confusão de dados, mas em algumas situações não é possível recuperar. Coisa semelhante com tmux . Você deve evitar empilhar manipuladores pty com PSC que bagunçam/manipulam demais os dados recebidos.
A variável de ambiente SHELL precisa ser definida para pscl e pscr para que o PSC saiba qual shell executar no pty. SHELL é definido na maioria dos ambientes por padrão, mas caso não seja, o PSC precisa ser executado como SHELL=/bin/bash pscl etc.
pscl também suporta encaminhamento de conexões TCP via SOCKS4 ( -4 port ) e SOCKS5 ( -5 port ). Isso configura a 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 pen-test. Se você passar -N para pscl , ele ativará a resolução de nomes DNS no lado remoto, para que você também possa usar o 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 de DNS corrompida, seu shell de digitação poderá bloquear por vários segundos se os pacotes de resposta de DNS estiverem faltando. Não existem boas funções de resolução assíncrona que sejam incorporáveis e portáteis, então tive que confiar em getaddrinfo() no thread único 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 habilitada explicitamente. pscr tenta minimizar esse problema potencial com caches de pesquisa de DNS, portanto, na maioria das situações, ele deve funcionar sem problemas. Se você passar -X IP-address (deve ser o primeiro argumento), você pode vincular seu proxy local a um endereço diferente de 127.0.0.1 , para poder compartilhar o proxy em sua rede local.
Os recursos psc permitem que conexões TCP ou blobs de dados binários sejam encaminhados de/para dispositivos remotos em vários saltos, mesmo que não seja possível instalar o binário pscr no site remoto. Isso é muito útil para fins forenses se você não tiver nenhum meio de baixar artefatos do dispositivo (que pode ser um telefone conectado ao UART, por exemplo) ou precisar encaminhar conexões sem tocar no FS para não destruir evidências no sistema ou quando o root-FS está montado e você não pode carregar seu conjunto de ferramentas.
Este é um recurso muito legal, pois você pode ver sua conexão TCP passar do tty local para uma caixa remota sem a necessidade de instalar nada remotamente.
Isso funciona apenas com o pty punkrock local e entregando um comando de rejeição ao pscl que será colocado no shell remoto (sem pscr em execução) e alguma mágica do mecanismo de estado que filtra e manipula os dados no lado local. Normalmente, isso requer definir o pty remoto para o modo bruto antes de emitir o comando real e alguns outros detalhes que são passados para -B . O argumento está dividido nas seguintes partes:
: , por exemplo, 1234: .stty -echo raw ou python -c "import tty;tty.setraw(0)" (tome cuidado para acertar as aspas, pois -B também precisa ser citado) ou qualquer coisa semelhante.pscl para começar a enviar dados para evitar que uma corrida entre stty realmente aconteça e o início do cmd, por exemplo, um echo GO é perfeito.nc 127.0.0.1 22 para devolver a porta local 1234 para o servidor SSH remotopscl redefina seu estado tty. echo FIN fará isso. Recomendado, caso contrário você poderá ter problemas para reconhecer o final do seu comando.; e entre colchetes.Exemplos:
Se você deseja encaminhar uma conexão TCP, este exemplo requer stty e nc instalados no dispositivo, mas teoricamente poderia ser qualquer outra coisa equivalente.
Inicie uma sessão local:
./pscl -B '1234:[stty -echo raw;echo GO;nc example.com 22;echo FIN]'
Isso emitirá o comando stty -echo raw;echo GO;nc example.com 22;echo FIN para o dispositivo remoto se você se conectar localmente à porta 1234 e, em seguida, apenas encaminhar quaisquer dados que ele vê para frente e para trás e limitar a taxa de tráfego para que não excederá a velocidade tty dos dispositivos (115200 é o padrão).
Quando a sessão pscl for iniciada, conecte-se ao dispositivo remoto por UART, ssh -e none ... ou o que quer que seja e assim que tiver o shell remoto, digite também localmente:
ssh [email protected] -p 1234 para devolver a conexão SSH de sua caixa local através do dispositivo remoto para o destino example.com . É claro que a variante pscr é preferida, pois -B só pode devolver uma única conexão por vez (embora você possa passar vários comandos -B para vários encaminhamentos) e há uma chance de travar o shell após a sessão TCP, já que o pty está em raw -echo e dependendo se o ponto remoto final também fecha a conexão, pode ser que o shell trave depois disso. Se acontecer de você encontrar uma notificação pscl de que a conexão foi concluída e ver um prompt, você deve reset la para que uma nova conexão possa ser iniciada. Enquanto os dados estão sendo encaminhados, você verá notificações ASCII < e > de 7 bits em pscl que são apenas locais para facilitar a depuração e detecção de progresso.
Observe que a conexão com o site remoto deve ser limpa de 8 bits, ou seja, o canal ssh, telnet, UART ou qualquer outro canal não deve lidar com sequências de escape (ao contrário do uso de pscr ). Para conexões ssh, isso significa que você deve usar ssh -e none na sessão pscl .
A seguir, seguem alguns exemplos para lidar com o arquivo binário xfer, onde rfile denota o arquivo remoto e lfile o arquivo local.
Para iniciar uma sessão para descartar arquivos remotos, localmente:
./pscl -B '1234:[stty -echo raw;echo GO;dd of=rfile.bin bs=1 count=7350;echo FIN]'
Onde você precisa especificar a quantidade de dados que o lado remoto está esperando. Também funcionaria sem (por exemplo, cat>... ), mas a sessão será interrompida após o término da transmissão, pois cat espera incessantemente a entrada. Usando dd count=... , você obterá uma saída limpa e será notificado sobre isso pelo marcador FIN.
Então, ssh ou o que for necessário para obter um shell no dispositivo remoto a partir da sessão pscl recém-iniciada. Em um segundo terminal localmente:
dd if=lfile.bin|nc 127.0.0.1 1234
que se conectará à porta local 1234 do pscl e acionará o comando dump no lado remoto, encaminhando os dados binários do lfile.bin local para os controles remotos rfile.bin . Devido à limitação de taxa, isso pode demorar um pouco e você só confiará na tela de progresso do psc se a transferência for concluída. O comando local dd ...|nc ... mostrará apenas o status local que pode consumir arquivos inteiros em mseg devido aos buffers TCP locais enquanto o arquivo ainda está sendo transferido através do pty. Portanto, certifique-se de pressionar Ctrl-C apenas quando a tela pscl informar que terminou ou você ver o marcador final FIN sendo ecoado de volta para você na sessão dd ...|nc ...
Da mesma forma, comandos semelhantes poderiam ser usados para transferir dados binários de um dispositivo remoto para a caixa local para fins forenses. Novamente, inicie a sessão localmente:
./pscl -B '1234:[stty -echo raw;echo GO;dd if=rfile.bin]' ou
./pscl -B '1234:[stty -echo raw;echo GO;cat rfile.bin]'
Em seguida, faça ssh para o dispositivo remoto para obter o shell e novamente localmente:
nc 127.0.0.1 1234|dd of=lfile.bin bs=1 count=7350
Para obter rfile.bin de tamanho 7350, copie para o arquivo local lfile.bin
Se stty -echo raw não estiver disponível no dispositivo, algo como python -c "import tty;tty.setraw(0)" também funciona. Observe que no dispositivo remoto você precisa ter um tty (não apenas um port-shell) ao usar comandos bounce, já que o comando stty para definir o modo bruto requer um tty real.
Se o psc for executado em uma conexão serial, os bits perdidos podem acabar com toda a sua diversão. Se você executar sem HW FC, eventualmente experimentará perda de bits e conexões travadas, principalmente porque não há limitação quando o dispositivo está enviando dados em sua direção ao usar comandos de rejeição . O despejo de dados no dispositivo funciona melhor à medida que esses dados passam pelos limites de taxa pscl .
No entanto, aqui estão algumas dicas que funcionaram para mim em circunstâncias em que não é possível usar pscr no dispositivo e no HW FC. Isto só se aplica ao usar UARTs, pois este é um canal de transporte potencialmente não confiável.
pscr no dispositivo para definir o limite de taxa para os dados enviados em sua direção. Como a direção em direção ao dispositivo é sempre limitada por taxa, você pode usar comandos de rejeição para despejar um binário pscr compilado de forma cruzada no dispositivo e iniciar uma sessão bidirecional com taxa limitada com ele.tio -o 1 ou -o 2 para adicionar atrasos entre os bytes de saída enviados38400 , embora a linha serial tenha definido 115200 )psc com -DRESPECT_UART_BUFSIZE=4096 , porém isso tornará a sessão muito lenta Dentro da pasta contrib você também encontrará um patch tio-noprefix para desabilitar o processamento de caracteres de escape, mas este patch só é necessário para versões mais antigas, pois o upstream já aceitou e integrou este patch. Eu realmente recomendo usar tio ao usar UARTs.
Ao usar comandos bounce em tio , você deve adicionar ao seu arquivo ~/.tioconfig :
[default]
prefix-ctrl-key = none
que desativa o manuseio do ESC e fornece um canal limpo de 8 bits.
Você pode enviar SIGUSR1 para pscl para que ele informe se a sessão está criptografada. Se o pscr remoto morrer ou sair sem possibilidade de sinalizar isso para a parte local, pscl permanecerá no modo de criptografia e, portanto, travará. Neste caso você pode forçar um reset para modo texto simples enviando SIGUSR2 , para que uma nova sessão possa ser iniciada.
A partir da versão 0.64, o psc suporta soquetes de script, então você não precisa mais screen para obter/colocar arquivos ou despejar buffers de colagem no console remoto. Em vez disso, você inicia sua sessão local assim:
~ > ./pscl -S ~/psc.script_sock
Você pode então prosseguir e usá-lo como antes. Se você precisar 'colar' algo que você gosta:
~ > ./pscsh -S ~/psc.script_sock -f script_/helloworld
Isso irá 'digitar' o conteúdo de script_/helloworld no console. Durante o script, o stdin do pscl é bloqueado para que a entrada injetada não se misture com nenhuma digitação. Se -S for omitido em pscsh , ~/psc.script_sock será usado automaticamente. Por motivos de segurança, os scripts devem começar com o prefixo script_ .
Como bônus, pscr agora contém a capacidade de decodificar/decodificar arquivos em base64, mesmo com caracteres CR incorporados por conveniência. É compatível com uuencode -m .
