Liberando algunas vulnerabilidades - Ultimate Product Cataloge v2.1.2 (II de II)

Hace ya un tiempo que escribí la primera parte de de este artículo, en él os hablaba de unas vulnerabilidades del plugin de Wordpress llamado Ultimate Product Catalogue en una versión menor o igual a la 3.1.4.
En su momento publiqué un par de SQL Injections sin autenticar [1][2]y hoy toca hablar de una especie de combo XSS + CSRF + File Upload descrito en el POC de de exploit-db [3] y el vídeo de youtube [4].

La utilidad básica de este plugin es publicar un catálogo de productos para vender y presentar en tu blog wordpress.

Ninguno de los formularios de este plugin cuenta con protección contra CSRF, es decir, que en el momento que un administrador o colaborador de la web visite un enlace a una web especialmente creada para esto, podría provocar, entre otras cosas, acciones en la parte de administración de este plugin, como podría ser cambiar los detalles de un producto como precio, título, descripción, o lo que es peor, inyectar código javascript en estos campos, ya que estos no se filtran en ningún momento. Por lo tanto, se podría conseguir mediante una visita del administrador a una web de perros gansta que modificara atributos de un producto a la venta para servir código HTML o javascript a todos los visitantes del blog que visitaran este catálogo de productos (1º combo: CSRF + XSS).

Por otro lado, contamos con la funcionalidad de subida de excels o CSV sin protección CSRF ni comprobación del tipo de fichero que se sube, dando como resultado la la posibilidad de que un administrador visitara una web de perros molones terminara subiendo un backdoor PHP en el servidor (2º combo: CSRF + File Upload).

En el siguiente vídeo se observa un POC de lo anterior, está editado regular, así que es posible que para pillar los detalles tengas que pararlo de vez en cuando:



La empresa está notificada desde hace tiempo y ambas vulnerabilidades solucionadas.

[1] https://www.exploit-db.com/exploits/36823/
[2] https://www.exploit-db.com/exploits/36824/
[3] https://www.exploit-db.com/exploits/36907/
[4] https://www.youtube.com/watch?v=roB_ken6U4o

WP-BackitUp: Arbitrary File Deletion vulnerability (o porqué no subestimar un CSRF)

¡Saludos!

   Escribo esta entrada para dar un toque de atención a todos aquellos desarrolladores de plugins para WordPress: por favor, la API de WordPress permite crear directamente tokens (o "nonces") y después comprobar su validez. ¡NO QUIERO VER UN CSRF MÁS!

   En este mes y dos semanas que he pasado buscando vulnerabilidades en plugins de WordPress lo que más me he encontrado son CSRF que permiten cosas tan dispares como que puedas recibir un atacante pueda recibir por correo electrónico un backup de la base de datos (¡Toma ya!, en un plugin con más de un millón de descargas y que bastantes webs gordas lo tenían instalado), realizar un DoS al servidor , o como en este caso, poder eliminar cualquier archivo. Voy a usar el plugin "WP-BackItUp" como ejemplo porque fue reportado hace un mes (tal y como se indicó en Quantika14 ) y no han parcheado este grave fallo de seguridad pese ha que han sacado diversas actualizaciones desde entonces.

  Cuando comprobamos las cabeceras HTTP que se mandan cuando realizamos alguna acción, por ejemplo crear un backup, vemos que en ningún momento se manda ningún token que proteja esa petición y por tanto no se comprueba si realmente ha sido el administrador quien ha querido hacerla y no ha sido "forzado" por un atacante:

   Por lo pronto podemos forzar a que realice un backup de la base de datos y de los archivos de ese WordPress. En otros casos de plugins que realizan backups y también son vulnerables a CSRF se ha podido usar esa caracterísitica para que se inicien 10.000 full backups practicamente al unísono, produciendose un denial of service del servidor. Por desgracia este no es el caso :(


    Cuando observamos la petición de borrado de un archivo vemos que tampoco lleva un token que la proteja:

  Lo primero que pensé cuando lo ví es que bueno, pode borrar backups puede ser un fallo de seguridad, pero tampoco nada transcendental. Lo segundo fue: ¿porqué diablos pone el nombre del archivo? ¿no serán capaces de cometer tal atrocidad....?

    Efectivamente, la hacen. Contemplad este trozo de código, obelisco que simboliza la candidez de ese desarrollador. Un minuto de silencio por la inocencia de quien hizo esto:

function deletefile()

{

$fileToDel = str_replace('deleteRow', '', $_POST['filed']);

$restore_path =  WPBACKITUP_CONTENT_PATH .WPBACKITUP_BACKUP_FOLDER .'/' . $fileToDel;

_log('(functions.deletefile) Delete File:' . $restore_path);

if (unlink($restore_path))

echo 'deleted';

else

echo 'problem';

exit(0);

}

   En vez de guardar en la base de datos el nombre del archivo y después pedirlo para borrarlo, se lo pasa directamente a través de una petición POST. Sin filtrar. A pelo. Un "unlink()" a lo que le pases. Eso es confiar en el usuario.


    Procedamos a hacer la petición de rigor para ver si podemos aprovechar esto, sabiendo que la carpeta de la que parte es /wp-content/wpbackitup_backups:

Premio para el niño, el archivo ha sido borrado:

  Para poder hacer el PoC rápidamente y probarlo podeis usar el script que hice, CSRFtoPOST, que podeis descargar haciendo click AQUI.

No es dificil usar tokens en WordPress, de hecho hay un artículo donde lo explica dentro de la propia documentación de la API (http://codex.wordpress.org/WordPress_Nonces )  por lo que este tipo de fallos pueden ser subsanados agregando apenas 3 líneas más a tu código. No seas vago y hazlo ;)


Byt3z!

@TheXC3LL