psc
1.0.0
Este proyecto, así como su proyecto hermano crash, pertenece a mi conjunto de herramientas anticensura que permite configurar shells cifrados completamente funcionales y reenvío TCP/UDP en entornos de censura hostiles. También es útil para los científicos forenses 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 reenviada a través de una conexión UART a un Pi
PSC permite cifrar e2e sesiones de shell, de un solo salto o de múltiples saltos, siendo independiente del transporte subyacente, siempre que sea confiable y pueda enviar/recibir datos codificados en Base64 sin modificar/filtrar. Junto con el pty e2e que recibe (por ejemplo, dentro de un port-shell), puede reenviar conexiones TCP y UDP, similar al parámetro -L de OpenSSH. Esto funciona de forma transparente y sin necesidad de una dirección IP asignada localmente en el punto de partida. Esto permite a los forenses y probadores crear conexiones de red, por ejemplo, a través de:
adb shell , si el adbd OEM no admite el reenvío TCPImagínese que tendría una sesión ppp invisible dentro de su sesión de shell, sin que el par remoto realmente admita ppp.
Se ejecuta en Linux, Android, OSX, Windows, FreeBSD, NetBSD y (posiblemente) OpenBSD .
PSC también incluye compatibilidad con proxy SOCKS4 y SOCKS5 para tener sesiones reales de navegación web a través de puertos shell o accesos telefónicos por módem de forma remota.
Edite el Makefile para reflejar sus claves previamente compartidas, tal como se define en la parte superior del Makefile .
Luego simplemente escriba make en Linux y OSX .
En BSD necesitas instalar GNU make e invocar gmake en su lugar.
En Windows, debe instalar cygwin y seleccionar los paquetes gcc, gcc-g++, make y git apropiados.
En Linux , PSC usará pseudo terminales Unix98 , en otros sistemas usará POSIX pty, pero eso debería ser transparente para usted. Una vez agregué soporte para 4.4BSD pty y SunOS en la edad de piedra por una razón particular, por lo que puede o no compilarse incluso con Solaris .
orgullosamente patrocinado por:
Simple y llanamente. En su cuadro local, ejecute pscl y pase cualquier puerto TCP o UDP que desee 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, no importa si está en un port-shell, SSH, inicio de sesión de consola, etc., ejecuta 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 ejecuta pscr , ambos extremos establecen un protocolo de enlace criptográfico y establecen un protocolo adicional sobre su sesión existente que sea transparente para usted. Luego puede conectarse a 127.0.0.1:1234 en su caja local para llegar a 192.168.0.254:22 a través de TCP o al solucionador 8.8.8.8 a través de 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.
Puede pasar varios parámetros -T y -U . Si perdió la pista si su sesión ya está cifrada con e2e, puede enviar un SIGUSR1 al proceso pscl local y este se lo informará.
PSC también es útil si desea utilizar Tor desde un shell SSH remoto, donde puede reenviar los calcetines5 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 los datagramas y crear solicitudes DNS con formato incorrecto.
La sesión se cifrará con aes_256_ctr de un PSK que elijas en el Makefile . Este esquema criptográfico es maleable, pero agregar datos AAD u OAD aumenta el tamaño del paquete, donde cada byte cuenta, ya que en las sesiones interactivas y debido a la codificación Base64, cada carácter escrito ya hace que se envíen muchos más datos.
Las sesiones UART se pueden usar 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 vivir con cierta cantidad de datos alterados, pero en algunas situaciones no es posible recuperarlos. Algo similar ocurre con tmux . Debe evitar apilar controladores pty con PSC que ensucien o manejen demasiado sus datos entrantes.
La variable de entorno SHELL debe configurarse tanto para pscl como para pscr para que PSC sepa qué shell ejecutar en pty. SHELL está configurado en la mayoría de los entornos de forma predeterminada, pero en caso de que no lo esté, PSC debe ejecutarse como SHELL=/bin/bash pscl etc.
pscl también admite el reenvío de conexiones TCP a través de SOCKS4 ( -4 port ) y SOCKS5 ( -5 port ). Esto configura el puerto como puerto SOCKS para conexiones TCP, de modo que, por ejemplo, puede explorar redes remotas desde una sesión de port-shell sin la necesidad de abrir ninguna otra conexión durante una prueba de penetración. Si pasa -N a pscl , habilita la resolución de nombres DNS en el lado remoto, por lo que también puede usar Chrome con él. Pero tenga cuidado: existe un problema de privacidad con los navegadores que intentan resolver una secuencia de nombres DNS al iniciarse que no está bajo su control. Además, si su lado remoto tiene una configuración DNS defectuosa, su 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 integrables y portátiles, por lo que tuve que confiar en getaddrinfo() en el hilo único al precio de posibles bloqueos durante varios segundos si existen problemas de DNS. Es por eso que la resolución de nombres debe habilitarse explícitamente. pscr intenta minimizar este problema potencial con las cachés de búsqueda de DNS, por lo que en la mayoría de las situaciones debería funcionar sin problemas. Si pasa -X IP-address (debe ser el primer argumento), puede vincular su proxy local a una dirección diferente de 127.0.0.1 , para poder compartir el proxy en su red local.
Las características de psc permiten que conexiones TCP o blobs de datos binarios se reenvíen desde/hacia dispositivos remotos a través de múltiples saltos, incluso si no es posible instalar el binario pscr en el sitio remoto. Esto es muy útil para fines forenses si no tiene ningún medio para descargar artefactos del dispositivo (que puede ser un teléfono conectado UART, por ejemplo) o necesita reenviar conexiones sin tocar el FS para no destruir evidencia en el sistema o cuando el root-FS está montado en ro y no puede cargar su conjunto de herramientas.
Esta es una característica realmente interesante, ya que puede ver su conexión TCP saltar a través de su tty local a una caja remota sin la necesidad de instalar nada de forma remota.
Esto funciona únicamente mediante pty punkrock local y entregando un comando de rebote a pscl que se colocará en el shell remoto (sin que pscr se ejecute) y algo de magia del motor de estado que filtra y maneja los datos en el lado local. Por lo general, esto requiere configurar el pty remoto en modo sin formato al principio antes de emitir el comando real y algunos otros detalles que se pasan a -B . El argumento se divide en las siguientes partes:
: , por ejemplo 1234: .stty -echo raw o python -c "import tty;tty.setraw(0)" (tenga cuidado de escribir correctamente las comillas, ya que -B también debe estar entre comillas) o algo parecido.pscl que comience a enviar datos para evitar que ocurra una carrera entre stty y el inicio del cmd, por ejemplo, un echo GO es perfecto.nc 127.0.0.1 22 para rebotar el puerto local 1234 al servidor SSH remotopscl restablecer su estado tty. echo FIN lo hará. Recomendado, ya que de lo contrario puedes tener problemas para reconocer el final de tu comando.; y encerrado entre paréntesis.Ejemplos:
Si desea reenviar una conexión TCP, este ejemplo requiere que stty y nc estén instalados en el dispositivo, pero en teoría podría ser cualquier otra cosa que sea equivalente.
Iniciar una sesión local:
./pscl -B '1234:[stty -echo raw;echo GO;nc example.com 22;echo FIN]'
Esto emitirá el comando stty -echo raw;echo GO;nc example.com 22;echo FIN al dispositivo remoto si se conecta localmente al puerto 1234 y luego simplemente reenvía cualquier dato que ve de un lado a otro y limita la velocidad del tráfico para que no excederá la velocidad tty de los dispositivos (115200 es el valor predeterminado).
Cuando se inicia la sesión pscl conéctate al dispositivo remoto por UART, ssh -e none ... o lo que sea y una vez que tengas el shell remoto, escribe también localmente:
ssh [email protected] -p 1234 para rebotar la conexión SSH desde su caja local a través del dispositivo remoto hasta el destino example.com . Por supuesto, se prefiere la variante pscr ya que -B solo puede rebotar una conexión a la vez (aunque puede pasar múltiples comandos -B para varios reenvíos) y existe la posibilidad de bloquear el shell después de la sesión TCP ya que el pty está en raw -echo -modo raw -echo y dependiendo de si el par remoto final también cierra la conexión, es posible que el shell simplemente se cuelgue después de eso. Si encuentra una notificación pscl de que la conexión ha finalizado y ve un mensaje, debe reset para que se pueda iniciar una nueva conexión. Mientras se reenvían los datos, verá notificaciones ASCII < y > de 7 bits en pscl que son solo locales para facilitar la depuración y la detección del progreso.
Tenga en cuenta que la conexión al sitio remoto debe ser limpia de 8 bits, es decir, el canal ssh, telnet, UART o cualquier otro no debe manejar secuencias de escape (a diferencia de cuando se usa pscr ). Para conexiones ssh, esto significa que debe usar ssh -e none en la sesión pscl .
A continuación, sigamos algunos ejemplos para manejar archivos binarios xfer, donde rfile denota el archivo remoto y lfile el archivo local.
Para iniciar una sesión para descartar archivos remotos, localmente:
./pscl -B '1234:[stty -echo raw;echo GO;dd of=rfile.bin bs=1 count=7350;echo FIN]'
Donde debe especificar la cantidad de datos que espera el lado remoto. También funcionaría sin (por ejemplo, cat>... ) pero luego la sesión se bloqueará una vez finalizada la transmisión, ya que cat espera incesantemente una entrada. Al usar dd count=... , obtendrá una salida limpia y el marcador FIN le notificará al respecto.
Luego, ssh o lo que sea necesario para obtener un shell en el dispositivo remoto desde la sesión pscl recién iniciada. En una segunda terminal localmente:
dd if=lfile.bin|nc 127.0.0.1 1234
que se conectará al puerto local 1234 de pscl y activará el comando de volcado en el lado remoto, reenviando los datos binarios del lfile.bin local al rfile.bin remoto. Debido a la limitación de velocidad, esto puede llevar un tiempo y solo confías en la pantalla de progreso de tu psc si la transferencia ha finalizado. El comando local dd ...|nc ... solo le mostrará el estado local que puede consumir archivos completos en mseg debido a los buffers TCP locales mientras el archivo aún se está transfiriendo a través del pty. Así que asegúrese de presionar Ctrl-C solo cuando la pantalla pscl le indique que ha terminado o cuando vea que el marcador de fin FIN se repite en la sesión dd ...|nc ...
Asimismo, se podrían utilizar comandos similares para transferir datos binarios desde un dispositivo remoto a la caja local con fines forenses. Nuevamente, inicio de la sesión localmente:
./pscl -B '1234:[stty -echo raw;echo GO;dd if=rfile.bin]' o
./pscl -B '1234:[stty -echo raw;echo GO;cat rfile.bin]'
Luego, envíe ssh al dispositivo remoto para obtener el shell, luego nuevamente localmente:
nc 127.0.0.1 1234|dd of=lfile.bin bs=1 count=7350
Para obtener rfile.bin de tamaño 7350 copiado al archivo local lfile.bin
Si stty -echo raw no está disponible en el dispositivo, algo como python -c "import tty;tty.setraw(0)" también funciona. Tenga en cuenta que en el dispositivo remoto necesita tener un tty (no solo un port-shell) cuando usa comandos de rebote, ya que el comando stty para configurar el modo sin formato requiere un tty real.
Si psc se ejecuta a través de una conexión en serie, los bits perdidos pueden acabar con toda tu diversión. Si ejecuta sin HW FC, eventualmente experimentará pérdida de bits y conexiones bloqueadas, en particular porque no hay limitación cuando el dispositivo envía datos en su dirección cuando usa comandos de rebote . Volcar datos al dispositivo funciona mejor ya que estos datos superan los límites de velocidad pscl .
Sin embargo, aquí hay algunos consejos que me funcionaron en circunstancias en las que no es posible usar pscr en el dispositivo y HW FC. Esto solo se aplica cuando se utilizan UART, ya que es un canal de transporte potencialmente poco confiable.
pscr en el dispositivo para poder establecer un límite de velocidad para los datos que se envían en su dirección. Como la dirección hacia el dispositivo siempre tiene una velocidad limitada, puede usar comandos de rebote para volcar un binario pscr compilado de forma cruzada al dispositivo e iniciar una sesión bidireccional de velocidad limitada con él.tio -o 1 o -o 2 para agregar retrasos entre los bytes de salida enviados38400 aunque la línea serial haya configurado 115200 )psc con -DRESPECT_UART_BUFSIZE=4096 , sin embargo, esto hará que la sesión sea muy lenta Dentro de la carpeta contrib también encontrará un parche tio-noprefix para deshabilitar el procesamiento de caracteres de escape, pero este parche solo es necesario para versiones anteriores, ya que el desarrollador ya aceptó e integró este parche. Realmente recomiendo usar tio cuando use UART.
Cuando utilices comandos de rebote en tio , debes agregar a tu archivo ~/.tioconfig :
[default]
prefix-ctrl-key = none
que desactiva el manejo de ESC y le brinda un canal limpio de 8 bits.
Puede enviar SIGUSR1 a pscl para que le indique si la sesión está cifrada. Si el pscr remoto muere o sale sin posibilidad de señalarlo a la parte local, pscl permanecerá en modo de cifrado y, por lo tanto, se bloqueará. En este caso, puede forzar un reinicio al modo de texto sin formato enviando SIGUSR2 , para que se pueda iniciar una nueva sesión.
A partir de la versión 0.64, psc soporta scripting-sockets por lo que ya no necesita screen para obtener/poner archivos o volcar buffers de pegado a la consola remota. En su lugar, inicia su sesión local así:
~ > ./pscl -S ~/psc.script_sock
Luego puedes seguir adelante y usarlo como antes. Si necesitas 'pegar' algo que te guste:
~ > ./pscsh -S ~/psc.script_sock -f script_/helloworld
Esto 'escribirá' el contenido de script_/helloworld en la consola. Durante la creación de secuencias de comandos, la entrada estándar de pscl se bloquea para que la entrada inyectada no se mezcle con ninguna escritura. Si se omite -S en pscsh , ~/psc.script_sock se usa automáticamente. Por razones de seguridad, los scripts deben comenzar con el prefijo script_ .
Como beneficio adicional, pscr ahora contiene la capacidad de codificar/decodificar archivos en base64, incluso con caracteres CR incrustados para mayor comodidad. Es compatible con uuencode -m .
