Hace un tiempo ya que he querido terminar de escribir estas líneas. A raíz un un mensaje recibido en Twitter el año pasado se me ocurrió generar una entrada para recopilar aquellos tips o consideraciones que suelo tener muy al corriente a la hora de identificar vulnerabilidades de forma automatizada y sin apenas intercesiones manuales por mi parte para cada activo, es decir, intentar conseguir “sentarte a esperar” todo tipo de alertas con notificaciones de vulnerabilidades que me pueden llegar en cualquier momento.
En la actualidad son 2 las plataformas en donde me encuentro especialmente activo y en donde cada X tiempo suelo reportar vulnerabilidades que me advierten los automatismos que tengo desplegados y de los que hablaremos el día de hoy. En primer lugar y por tener un contexto, tenemos a OpenBugBounty, una plataforma abierta en donde reportar fallas de seguridad identificadas en cualquier tipo de activo web de Internet, si bien y como su nombre indica, por un lado OBB (OpenBugBounty) se puede considerar una plataforma de Bug Bounty al uso, ya que dispone de una serie de programas a los cuales cualquier persona puede apuntarse, focalizarse y buscar fallas, también se trata de una plataforma peculiar a mi entender, principalmente lo digo por que según sus normas de divulgación responsable (acorde a la ISO 29147) solo se permite reportar vulnerabilidades de las siguientes tipologías:
- Cross-Site Scripting (XSS)
- Open Redirect
- Cross Site Request Forgery (CSRF)
- Improper Access Control (IAC)
Como se refleja, vulnerabilidades poco intrusivas y que no atenten severamente contra la confidencialidad, integridad y disponibilidad de los activos afectados.
La otra plataforma en la que suelo reportar vulnerabilidades es una de mi país de origen. Se trata de la plataforma gestionada por el Centro de Gestión de Incidentes Informáticos (CGII) que depende de la AGETIC (Agencia de Gobierno Electrónico y Tecnologías de Información y Comunicación), en donde como objetivo (alcance) tienen prácticamente todo tipo de instituciones y organizaciones gubernamentales.
Pues bien, volviendo al inicio de este post, considero que en el Hacking como en la vida misma, contar con una metodología o un conjunto de pasos de actuación nos conducirá a tener potenciales resultados eficientes, tal vez con el menor grado de “desgaste” o dedicación posible, esto viéndolo como un valor que se precia cuando apenas disponemos de tiempo para invertir. Por tanto, he aquí algunas lógicas que suelo seguir de cara a identificar vulnerabilidades en activos de Internet.
Identificaciones de vulnerabildad de XSS en activos con Moodle
Durante la semana pasada recuerdo haber leído el siguiente Tweet:
Inmediatamente me puse “manos a la obra” para revisar activos que tengan disponible plataformas Moodle que se vean potencialmente afectadas por esta vulnerabilidad. Por ello lo primero es revisar la vista estándar de la plataforma y buscar patrones generales que nos permitan modelar el rastreo a través de buscadores (crawling).
En este caso tomaré el siguiente texto genérico que sé que en la mayoría de las plataformas Moodle encontraré (es lo que tienen las plantillas).
Cabe destacar que la alternativa al texto: «Usted no se ha identificado» en inglés es: «You are not logged in«.
Por tanto y con la ayuda de las Google Dorks, lo primero será obtener toda la cantidad posible de resultados proporcionados por el buscador.
En donde:
- «Usted+no+se+ha+identificado»: Será el mensaje que buscaré en cada web resultante de Google.
- inurl%3A%2Fmod%2F: Le indicará a Google que las web resultantes además cuente con el directorio /mod/ que básicamente es donde buscaré el recurso afectado (lti/auth.php). Alternativamente también me puede interesar buscar el directorio /course/, que básicamente lo presentará cualquier plataforma Moodle.
- site%3Aedu: Por ahora únicamente tomaré los sitios web con TLD .edu.
- num=10000: Me permitirá no paginar los resultados de Google, por ahora me interesa tener como salida una única página de resultados.
- > Google.tmp: Me guardará todos los resultados en un fichero que tendré que procesar en adelante.
Una vista parcial de ejemplo con los resultados de Google empleando estas Dorks, es la siguiente:
Llegados a este punto los resultados de Google estarán guardados en un fichero de salida (Google.tmp). Toca ahora procesar la salida en bruto (raw) y quedarnos únicamente con las URLs objetivo, para ello me apoyaré en los siguientes comandos:
En donde:
- El primer sed lo emplearé para ubicar rápidamente la etiqueta “a href”. Al resultado le añadiré un salto de línea y una string temporal (ñapa time), que posteriormente eliminaré.
- El segundo sed básicamente quitará de las URLs resultantes, todos los caracteres que estén después del directorio /mod/.
- Después de quitarme lineas sobrantes del fichero inicial (Google.tmp), paso a generar un listado ordenado y sin activos repetidos. Esto lo guardaré en un segundo fichero llamado URLs.tmp.
Destacar que en este punto pasamos de tener un fichero de salida en bruto con las búsquedas de Google de más de 220 líneas, a un resultado filtrado que presenta finalmente las URLs de los objetivos.
Bien, ahora llega el momento de validar si los activos filtrados en el fichero URLs.tmp se ven afectados por la vulnerabilidad de XSS en cuestión, para ello nos valdremos del siguiente bucle for:
En donde:
- Lo primero que haremos es generar un bucle for que nos permita recorrer por cada uno de los objetivos contenidos en el fichero URLs.tmp.
- Para cada caso lo primero que haremos es validar a través de las cabeceras HTTP que el recurso “/mod/lti/auth.php” existe y es accesible, por ello tan solo nos quedaremos con aquellos resultados que nos arrojen un código de estado HTTP “200 OK”.
- Posteriormente y condicionado al resultado anterior (valiéndonos de la condición if), si resulta que el objetivo si que nos arroja el código de estado HTTP 200, validaremos ya a través del payload y el parámetro afectado: “redirect_uri=javascript:alert(854588)«, que el objetivo sea o no vulnerable a XSS.
Después de toda la secuencia de comandos obtendremos como resultado un listado de este tipo:
Al llevar al navegador web cualquiera de estas URLs obtendremos un resultado similar a:
Como datos adicional observemos como queda conformado el body de la respuesta del activo web afectado por esta vulnerabilidad de XSS.
Nota: Ayer miércoles 9 de Junio he visto que esta vulnerabilidad en Moodle está representada por el CVE-2021-32478, actualmente en estado de reservado y sin aparente información pública. Suele ser algo habitual en las vulnerabilidades nuevas. Esto lo he visto en una publicación reciente del CGII, que también referencian a una publicación del foro de Moodle. Les dejo ambos enlaces de información:
- https://cgii.gob.bo/es/alertas-de-seguridad/multiples-vulnerabilidades-en-moodle
- https://moodle.org/mod/forum/discuss.php?d=422314
Identificación “masiva” de parametros vulnerables a XSS
Por último y ya aprovechando la ocasión os presento y os dejo un pequeño script que escribí en su momento para identificar sitios web que tenga un determinado parámetro en sus URLs, en donde existe una probabilidad de identificar vulnerabilidades de XSS si dichos parámetros no tienen sanitizadas las inserciones. En este caso el parámetro que busco es: “lang=”, presente en muchos sitios web. Por tanto el script tiene una función básica, basta con indicarle el TLD con el que quieras trabajar, y el se va a encargar de consultar con Google los sitios web que tengan dicho parámetro y posteriormente procederá a validar si es vulnerable. Las URLs con los resultados validados te llegará por Telegram, a través de un bot. Bien, pues como mejor es verlo que contarlo, aquí una demo:
Podréis descargaros el script desde mi GitHub y personalizarlo ya a vuestra necesidad.
Volviendo a la vulnerabilidad de Moodle, ya simplemente para dejarles los “dientes largos”, les dejo esta ilustración:
