Queridos lectores bienvenidos a la DMZ, esta es nuestra primera publicación pronto tendremos muchas más.
Esta es una prueba de concepto acerca una vulnerabilidad de tipo Arbitrary file deletion que se encuentra en el plugins MW WP Form <=5.0.3
En esta demostración estamos utilizando la última versión de WordPress disponible con el Plugins MW WP 5.0.3 con técnicas de reconocimiento manual.
………………………………………………………………………………………………………………………………………………………………
Proof Of Concept (P.O.C) –> CVE-2023-6559 – Arbitrary file deletion.
Reconocimiento
Buscaremos algún dato que indique presencia de este plugins dentro del sitio revisando el código fuente desde el navegador, sobre todo enfocándonos en las partes donde se sospeche que pudo ser construida con este plugins, concentrémonos en algún formulario. Recuerda que intencionalmente esta demostración es sobre cómo hacer reconocimiento manual sin utilizar herramientas automatizadas como WPScan, Wappalyzer, Etc…
Bien, este es nuestra DMZ-MAchineWP
Un recorrido rápido por el sitio encontramos que en la sección JOBS hay un formulario para subir CV.
Inspeccionar código fuente encontramos una referencia hacia un plugins MW-WP-Form.
Ahora necesitamos confirmar que la versión encontrada sea vulnerable. Para identificar la versión podemos leer el archivo readme.txt que se instala junto con el plugins en la carpeta raíz del mismo (example.com/wp-content/plugins/mw-wp-forms/readme.txt).
El Stable Tag:5.0.3 indica la versión instalada del plugin, Buscando información acerca del plugins encontraremos diferentes avisos de vulnerabilidades identificadas. En esta prueba nos basamos en la de tipo Arbitrary File Deletion.
https://wpscan.com/plugin/mw-wp-form
Pasamos a la explotación
Cargamos un pdf simulando un CV
Con BurpSuite interceptamos la petición que se genera al darle clic al boton Send.
La vulnerabilidad dice que se puede borrar cualquier archivo, ya que no tiene límites definidos sobre los directorios que puede borrar archivos. Esto quiere decir que si modificamos el nombre del archivo que estamos enviando en el Request y colocamos otra ruta lo va a borrar.
Probaremos primero borrando un archivo que sabemos que existe, el readme.txt dentro de la carpeta de plugin de mw-wp-forms.
Al enviar obtenemos esta respuesta –> Archivo encontrado y borrado!!
Verificamos tratando de abrir otra vez el readme.txt –> example.com/wp-content/plugins/mw-wp-form/readme.txt/
Ahora otro mas importante el index.php en la raiz del sitio.
Respuesta encontrado y borrado!!
Confirmando abrimos el sitio otra vez.
Hasta aquí la demostración. ¿Pero como es que un simple formulario se puede manipular para borrar archivos?
¿Por qué se da esta vulnerabilidad?
El archivo se almacena en el servidor y se guarda en la base de datos si se selecciona la opción «Guardar datos de la consulta en la base de datos» en la configuración del formulario. Si el archivo no se guarda en la base de datos, elimina inmediatamente el archivo cargado después de enviar el correo electrónico. En este escenario y en muchos no se configura para guardar los adjuntos en una base de datos ya que los vas a recibir por correo. Justo cuando se invoca la función de borrado de archivos no se valida correctamente la ruta permitiendo la vulnerabilidad.
Revisando el codigo fuente
Si descargamos el plugins y revisamos el código encontraremos lo siguiente:
Revisando las classes encontramos el archivo que contiene la función de borrado de archivos –> /mw-wp-form/classes/services/class.mail.php
Dentro del archivo existe una condicional que invoca la función _delete_files()
// If not usedb, remove files after sending admin mail
if ( ! $this->Setting->get( 'usedb' ) ) {
$this->_delete_files();
}Si revisamos que hace la función
/**
* Delete attachment files.
*/
protected function _delete_files() {
foreach ( $this->attachments as $file ) {
if ( file_exists( $file ) ) {
unlink( $file );
}
}Donde esta el error?
El unlink() es una función nativa de PHP que se utiliza para borrar archivos del sistema, pero si vemos se le está diciendo bórrame este archivo, pero como no existe validación de la ruta también borrara si se le indica otro archivo de otra ruta.
Una forma muy básica de remediar esto es agregar la validación de la ruta:
Por ejemplo, __DIR__ es una constante de PHP que devuelve la ruta absoluta del directorio que contiene el archivo actual. Si tienes un archivo file.php en el directorio c:/vscode/myproject/, entonces __DIR__ devuelve la ruta c:/vscode/myproject/
Luego, se utiliza la concatenación de strings para agregar el directorio /static a la ruta actual, lo que resulta en la ruta relativa c:/vscode/myproject/static/
$directory = realpath(__DIR__ . '/adjuntos');
$filename = 'archivo.pdf';
$filePath = $directory . '/' . $filename;
if (file_exists($filePath)) {
unlink($filePath);
} else {
echo 'El archivo no existe';
}Ahora un ejemplo integrado al código del formulario suponiendo que los archivos se cargan en el mismo directorio del archivo class.mail.php
protected function _delete_files() {
$directory = realpath(__DIR__ . '/adjuntos');
$filename = 'archivo.pdf';
foreach ( $this->attachments as $file ) {
$filePath = $directory . '/' . basename($file);
if ( file_exists($filePath) ) {
unlink($filePath);
}
}
}Son ejemplos básicos de remediación, pero con validaciones mas fuerte se puede hacer mejor.
FIN!!
