La entrada de hoy es una colaboración enviada por el equipo del CSIRT-CV, el Centro de Seguridad TIC de la Comunitat Valenciana, en relación a la detección de una vulnerabilidad en el CMS Tiki-Wiki durante el pasado diciembre.
Hace ya unos meses, concretamente en diciembre de 2019, en el CSIRT-CV descubrimos una vulnerabilidad en el CMS Tiki-Wiki, un sistema de gestión de contenidos del estilo de WordPress, Joomla o Drupal.
Esta vulnerabilidad se publicó meses más tarde, en abril de 2020, con el código CVE-2020-8966, como se puede comprobar en nuestra página de alertas, dando el suficiente margen de tiempo a los desarrolladores para corregir el problema detectado en la aplicación. Todo esto se canalizó a través de INCIBE-CERT, que intermedió con la empresa desarrolladora. Una vez corregida, publicada y tras los problemas derivados de la Covid-19 hemos sacado un rato para contaros los detalles de la misma.
Durante un test de intrusión realizado a una página web interna que usaba este CMS, se detectaron varios fallos de seguridad Cross-Site Scripting (XSS) Reflected sobre la versión 18.3, pero cuya explotación seguía siendo efectiva en la última versión disponible, la v.20.0 por aquel entonces.
La vulnerabilidad XSS permite la inyección de código sobre algún campo de entrada de datos de la página web: un buscador, un campo de participación en un foro o un formulario de recogida de datos. La intención es que el código inyectado se ejecute en el navegador de la víctima tras su acceso al recurso. Esta vulnerabilidad puede ser de dos tipos: persistente cuando el código inyectado se almacena en la web y se ejecuta en el navegador de cada usuario que accede a la página, o reflejado, cuando no se almacena sino que va embebido dentro de la URL, y que se hace llegar de algún modo a la víctima para que pinche en él, como por ejemplo un correo electrónico, un enlace por redes sociales, etc.
En este caso, se identificaron varios recursos vulnerables a XSS reflejado, que podían (y pueden, en sistemas vulnerables) aprovechados por cualquier usuario malintencionado para realizar distintos tipos de ataque: robo de sesión, ataques contra el navegador, descarga de software malicioso, keyloggers u otros ataques del lado del cliente.
Recurso tiki-index.php
Después de esta breve introducción, vamos con el primer problema de seguridad, detectado en el parámetro msg del recurso tiki-index.php (URL: http://servidor/recurso/tiki-index.php).
Como se puede observar en la prueba de concepto (PoC), aprovechando que el parámetro msg no impide el uso de caracteres especiales y por lo tanto permite la ejecución de la función alert, se consiguió inyectar en la petición el siguiente código JavaScript, mostrando por pantalla el texto XSS y confirmando que es vulnerable.
Recurso tiki-contact.php
Otro parámetro vulnerable a XSS fue subject del recurso tiki-contact.php (URL: http://servidor/recurso/tiki-contact.php), formulario utilizado para enviar un correo al administrador del CMS. Al igual que en el anterior caso, este tampoco filtraba correctamente la entrada de texto permitiendo la inyección del código, tal y como se muestra en la imagen:
En esta ocasión se utilizó el siguiente código con la función alert(), para que se ejecutara al pasar el ratón por encima del campo subject (Tema) del formulario de contacto:
Historial del CMS tiki-pagehistory.php
Los tres siguientes parámetros vulnerables se detectaron sobre el recurso del historial del CMS tiki-pagehistory.php (URL: http://servidor/recurso/tiki-pagehistory.php).
El primer parámetro vulnerable se detectó al observar que era posible habilitar la paginación y establecer un número máximo de resultados por página.
El parámetro history_pagesize, igual que en los anteriores casos, no filtraba los datos de entrada y permitió ejecutar de nuevo código JavaScript.
Para esta PoC se modificó la petición que realiza el recurso en el lado del cliente contra el servidor, para habilitar y seleccionar el valor máximo de paginación, que al no estar correctamente sanitizado permitió inyectar el siguiente código:
Con el segundo parámetro vulnerable nos encontramos con una situación similar a la anterior cuando se cambia de página en el historial.
Para ello, se estableció el parámetro history_offset con el valor previamente indicado como valor máximo de resultados por página y sobre la misma URL (http://servidor/recurso/tiki-pagehistory.php?page=Inici&history_offset=25), y se comprobó que se podía ejecutar el siguiente código:
El tercer parámetro vulnerable sobre el recurso tiki-pagehistory.php se identificó al presionar el botón “Collapse Into Edit Sessions”.
Este realizaba una petición GET (http://servidor/recurso//tiki-pagehistory.php?page=Inici&clear_versions=1&show_all_versions=n) que contiene el parámetro show_all_versions, que tampoco era validado correctamente, permitiendo la inyección del código siguiente sobre la propia URL:
Recurso tiki-browse_freetags.php
Por último y cambiando de recurso, se detectó otro fallo de seguridad en tiki-browse_freetags.php (URL:http://servidor/recurso/tiki-browse_freetags.php). Este caso es más especial pues el código a inyectar va justo después del nombre del archivo, antes de la definición de los parámetros con los que se llama al recurso, por lo que no hay ningún parámetro involucrado.
Al acceder a este recurso, uno de los enlaces generado por la propia web, encargado de mostrar más contenido, toma como URL destino parte de la URL actual. Al no filtrarse adecuadamente, insertando el carácter “/” fue posible inyectar código JavaScript , tal y como se puede observar en las siguientes ilustraciones:
Con esto concluimos esta entrada sobre los fallos de seguridad XSS descubiertos por CSIRT-CV en el CMS Tiki-Wiki, destacando la importancia de desarrollar aplicaciones siguiendo las guías existentes de desarrollo seguro, mejorando de esa forma la seguridad de nuestros usuarios.
Fuente obtenida de: https://www.securityartwork.es/2020/09/23/que-ha-pasado-tiki-wiki-vulnerabilidades-xss-no-gracias/
