stealth/pscCrittografia end-to-end per sessioni tty multi-hop o portshell + forwarding di porte TCP/UDP
Questo progetto - così come il suo progetto gemello crash - fa parte della mia suite di strumenti anti-censura che permette di configurare shell crittografate funzionanti e inoltri TCP/UDP in ambienti ostili alla censura. È utile anche per la computer forensics per estrarre dati da dispositivi tramite UART o adb quando non sono disponibili altri mezzi.
Ricerca DNS e sessione SSH inoltrate attraverso una connessione UART verso un Pi
PSC permette di crittografare end-to-end sessioni di shell, con singolo o multipli salti, essendo
indipendente dal trasporto sottostante, purché sia affidabile e possa inviare/ricevere
dati codificati in Base64 senza modificarli/filtrarli. Oltre alla pty e2e che
ricevi (ad esempio all'interno di una port-shell), puoi inoltrare connessioni TCP e UDP,
similmente al parametro -L di OpenSSH. Questo funziona in modo trasparente
e senza la necessità di un indirizzo IP assegnato localmente al punto di partenza.
Ciò consente a forenser e pen-tester di creare connessioni di rete, ad esempio tramite:
adb shell, se l'adbd OEM non supporta l'inoltro TCPImmagina di avere una sessione ppp invisibile all'interno della tua sessione shell, senza che il peer remoto supporti effettivamente ppp.
Funziona su Linux, Android, OSX, Windows, FreeBSD, NetBSD e (possibilmente) OpenBSD.
PSC include anche il supporto proxy SOCKS4 e SOCKS5 per avere sessioni di navigazione web reali tramite port-shell o modem dial-up in remoto.
Modifica il Makefile per impostare le tue chiavi pre-condivise, come definite all'inizio del Makefile.
Poi esegui semplicemente make su Linux e OSX.
Su BSD devi installare GNU make e invocare gmake invece.
Su Windows devi installare cygwin e selezionare
i pacchetti appropriati gcc, gcc-g++, make e git.
Su Linux, PSC userà pseudo terminali Unix98, su altri sistemi userà pty POSIX, ma questo dovrebbe essere trasparente per te. Ho aggiunto una volta il supporto per pty 4.4BSD e SunOS ai tempi della pietra per un motivo particolare, quindi potrebbe compilarsi anche con Solaris.
orgogliosamente sponsorizzato da:
Semplice e diretto. Sulla tua macchina locale, esegui pscl e passa qualsiasi
porta TCP o UDP che desideri inoltrare dal sito remoto a un indirizzo
particolare. Ad esempio:
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: impostata porta TCP locale 1234 per proxy verso 192.168.0.254:22 @ remoto.
pscl: impostata porta UDP locale 1234 per proxy verso 8.8.8.8:53 @ remoto.
pscl: In attesa che appaia la sessione [pscr] ...
linux:~ >
[ UART / SSH / ... login al lato remoto ... ]
Sul sito remoto (l'ultimo salto) con la sessione shell, indipendentemente dal fatto che sia in
una port-shell, SSH, login console, ecc., esegui pscr:
linux:~ > ./pscr
PortShellCrypter [pscr] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: Vista sequenza STARTTLS, abilito la crittografia.
linux:~ >
Una volta eseguito pscr, entrambi i lati stabiliscono un handshake crittografico e posano un ulteriore
protocollo sulla tua sessione esistente che è trasparente per te. Puoi quindi connetterti
a 127.0.0.1:1234 sulla tua macchina locale per raggiungere 192.168.0.254:22 tramite
TCP o il resolver 8.8.8.8 tramite UDP. Questo funziona anche con indirizzi [IPv6],
se il sito remoto ha connettività IPv6. In realtà, puoi anche usarlo per tradurre
software IPv4 in IPv6, poiché ti connetti sempre a 127.0.0.1 sul lato locale.
Puoi passare più parametri -T e -U. Se perdi traccia del fatto che la tua sessione
sia già crittografata e2e, puoi inviare un SIGUSR1 al processo pscl locale, e ti
dirà lo stato.
PSC è utile anche se vuoi usare tor da una shell SSH remota, dove puoi
inoltrare la porta socks5 e la porta DNS all'indirizzo 127.0.0.1 dell'host remoto.
Poiché SSH non inoltra pacchetti UDP, normalmente useresti due connettori socat
o simili per risolvere tramite il nodo tor. PSC ha il vantaggio di mantenere i confini
dei datagrammi UDP, mentre socat su SSH -L può rompere i confini dei datagrammi
e creare richieste DNS malformate.
La sessione sarà crittografata con aes_256_ctr di una PSK che scegli nel
Makefile. Questo schema crittografico è malleabile, ma aggiungere dati AAD o OAD
aumenta la dimensione del pacchetto, dove ogni byte conta poiché nelle sessioni interattive
e a causa della codifica Base64, ogni carattere digitato causa già molti più dati da inviare.
Le sessioni UART possono essere utilizzate tramite screen ma ad esempio non tramite minicom poiché
minicom crea finestre invisibili con righe di stato e agisce come un filtro
che distrugge il protocollo di PSC. PSC cerca di rilevare il filtraggio e può convivere con
una certa quantità di danneggiamento dei dati, ma in alcune situazioni non è possibile recuperare.
Simile con tmux. Dovresti evitare di impilare gestori di pty con PSC che
alterano/gestiscono troppo i dati in arrivo.
La variabile d'ambiente SHELL deve essere impostata sia per pscl che per pscr affinché
PSC sappia quale shell eseguire sulla pty. SHELL è impostata di default nella maggior parte degli
ambienti, ma in caso contrario, PSC deve essere eseguito come SHELL=/bin/bash pscl
ecc.
pscl supporta anche l'inoltro di connessioni TCP tramite SOCKS4 (-4 porta) e SOCKS5
(-5 porta). Questo imposta porta come porta SOCKS per le connessioni TCP, così ad esempio puoi
navigare reti remote da una sessione port-shell senza la necessità di aprire nessun'altra
connessione durante un pen-test. Se passi -N a pscl, abilita la risoluzione dei nomi DNS
sul lato remoto, quindi puoi usare anche Chrome con esso. Ma attenzione: C'è un problema di privacy
con i browser che cercano di risolvere una sequenza di nomi DNS all'avvio che
non è sotto il tuo controllo. Inoltre, se il tuo lato remoto ha una configurazione DNS danneggiata, la tua
shell di digitazione potrebbe bloccarsi per diversi secondi se i pacchetti di risposta DNS mancano. Non esistono
buone funzioni di risoluzione asincrona incorporabili e portabili, quindi ho dovuto fare affidamento su
getaddrinfo() in un unico thread al prezzo di possibili blocchi di diversi secondi
se esistono problemi DNS. Ecco perché la risoluzione dei nomi deve essere abilitata esplicitamente. pscr
cerca comunque di minimizzare questo potenziale problema con cache di ricerca DNS, quindi nella maggior parte
delle situazioni dovrebbe funzionare senza problemi.
Se passi -X indirizzo-IP (deve essere il primo argomento), puoi associare il tuo proxy locale
a un indirizzo diverso da 127.0.0.1, così puoi condividere il proxy nella tua rete locale.