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';elseecho '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!
