stealth/pscCifrado de extremo a extremo para sesiones tty de múltiples saltos o portshells + reenvío de puertos TCP/UDP
Este proyecto - así como su proyecto hermano crash - pertenece a mi conjunto de herramientas contra la censura que permite configurar shells encriptados y reenvío TCP/UDP completamente funcionales en entornos hostiles de censura. También es útil para forense para volcar datos de dispositivos a través de UART o adb cuando no hay otros medios disponibles.
Búsqueda de DNS y sesión SSH reenviadas a través de una conexión UART a una Pi
PSC permite encriptar de extremo a extremo sesiones de shell, de un solo salto o múltiples, siendo agnóstico del transporte subyacente, siempre que sea confiable y pueda enviar/recibir datos codificados en Base64 sin modificaciones/filtros. Junto con la pty e2e que recibes (por ejemplo dentro de un port-shell), puedes reenviar conexiones TCP y UDP, similar al parámetro -L de OpenSSH. Esto funciona de manera transparente y sin necesidad de una dirección IP asignada localmente en el punto de inicio. Esto permite a los forenses y testers de penetración crear conexiones de red, por ejemplo a través de:
adb shell, si el adbd del OEM no soporta reenvío TCPImagina que tuvieras una sesión ppp invisible dentro de tu sesión de shell, sin que el peer remoto soporte realmente ppp.
Se ejecuta en Linux, Android, OSX, Windows, FreeBSD, NetBSD y (posiblemente) OpenBSD.
PSC también incluye soporte de proxy SOCKS4 y SOCKS5 para tener sesiones de navegación web reales a través de port-shells o conexiones de módem de forma remota.
Edita el Makefile para reflejar tus claves precompartidas, según se define al inicio del Makefile.
Luego simplemente escribe make en Linux y OSX.
En BSD necesitas instalar GNU make e invocar gmake en su lugar.
En Windows necesitas instalar cygwin y seleccionar los paquetes apropiados gcc, gcc-g++, make y git.
En Linux, PSC usará pseudo terminales Unix98, en otros sistemas usará pty POSIX pero eso debería ser transparente para ti. Una vez añadí soporte para pty 4.4BSD y SunOS en la edad de piedra por una razón particular, por lo que puede o no compilar incluso con Solaris.
orgullosamente patrocinado por:
Simple y directo. En tu máquina local, ejecuta pscl, y pasa cualquier puerto TCP o UDP que quieras reenviar desde el sitio remoto a una dirección particular. Por ejemplo:
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 ... ]
En el sitio remoto (el último salto) con la sesión de shell, sin importar si está en un port-shell, SSH, inicio de sesión de consola, etc., ejecutas pscr:
linux:~ > ./pscr
PortShellCrypter [pscr] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: Seen STARTTLS sequence, enabling crypto.
linux:~ >
Una vez que ejecutas pscr, ambos extremos establecen un handshake criptográfico y colocan un protocolo adicional sobre tu sesión existente que es transparente para ti. Luego puedes conectarte a 127.0.0.1:1234 en tu máquina local para alcanzar 192.168.0.254:22 vía TCP o el resolver 8.8.8.8 vía UDP. Esto también funciona con direcciones [IPv6], si el sitio remoto tiene conectividad IPv6. De hecho, incluso puedes usarlo para traducir software IPv4 a IPv6, ya que siempre te conectas a 127.0.0.1 en el lado local.
Puedes pasar múltiples parámetros -T y -U. Si pierdes el rastro de si tu sesión ya está encriptada e2e, puedes enviar una SIGUSR1 al proceso pscl local, y te lo dirá.
PSC también es útil si quieres usar tor desde un shell SSH remoto, donde puedes reenviar el socks5 y el puerto DNS a la dirección 127.0.0.1 del host remoto. Dado que SSH no reenvía paquetes UDP, normalmente usarías dos conectores socat o similares para resolver a través del nodo tor. PSC tiene la ventaja de mantener los límites de los datagramas UDP, mientras que socat sobre SSH -L puede romper los límites de datagramas y crear solicitudes DNS malformadas.
La sesión se encriptará con aes_256_ctr de una PSK que elijas en el Makefile. Este esquema criptográfico es maleable, pero agregar datos AAD o OAD aumenta el tamaño del paquete, donde cada byte cuenta ya que en sesiones interactivas y debido a la codificación Base64, cada carácter escrito ya provoca que se envíen muchos más datos.
Las sesiones UART pueden usarse a través de screen pero, por ejemplo, no a través de minicom ya que minicom creará ventanas invisibles con líneas de estado y actúa como un filtro que destruye el protocolo de PSC. PSC intenta detectar el filtrado y puede soportar cierta cantidad de alteración de datos, pero en algunas situaciones no es posible recuperarse. Algo similar ocurre con tmux. Debes evitar apilar manejadores de pty con PSC que alteren/manipulen demasiado sus datos entrantes.
La variable de entorno SHELL debe estar configurada tanto para pscl como para pscr para que PSC sepa qué shell ejecutar en la pty. SHELL está configurada en la mayoría de entornos por defecto, pero en caso de que no lo esté, PSC debe ejecutarse como SHELL=/bin/bash pscl etc.
pscl también soporta el reenvío de conexiones TCP a través de SOCKS4 (-4 puerto) y SOCKS5 (-5 puerto). Esto configura puerto como puerto SOCKS para conexiones TCP, por lo que, por ejemplo, puedes navegar por redes remotas desde una sesión de port-shell sin necesidad de abrir ninguna otra conexión durante una prueba de penetración. Si pasas -N a pscl, habilita la resolución de nombres DNS en el lado remoto, por lo que también puedes usar chrome con él. Pero cuidado: Hay un problema de privacidad con los navegadores que intentan resolver una secuencia de nombres DNS al inicio que no está bajo tu control. Además, si tu lado remoto tiene una configuración DNS defectuosa, tu shell de escritura puede bloquearse durante varios segundos si faltan paquetes de respuesta DNS. No hay buenas funciones de resolución asíncrona que sean incrustables y portátiles, así que tuve que confiar en getaddrinfo() en un solo hilo al precio de posibles bloqueos de varios segundos si existen problemas de DNS. Por eso la resolución de nombres debe habilitarse explícitamente. pscr intenta minimizar este posible problema con cachés de búsqueda DNS, por lo que en la mayoría de las situaciones debería funcionar sin problemas. Si pasas -X dirección-IP (debe ser el primer argumento), puedes vincular tu proxy local a una dirección diferente de 127.0.0.1, para compartir el proxy en tu red local.