NOTA: Esta entrada se trata de una recuperación de un post que realicé hace algunos años en el blog de una empresa en la que trabajaba por aquel entonces y que a día de hoy ya no se mantienen en vigencia ni el blog y la empresa. Me pareció oportuno rescatar estas líneas que hablaban de una herramienta o automatismo que realicé y que estoy queriendo desempolvar para hacerle algunas mejoras y tal vez dar añadirles nuevas características, por tanto ya me pongo en ese compromiso, que espero no tardar mucho en traerles novedades. Sin más, aquí les dejo la entrada original que realicé en su momento (Septiembre de 2018).
Desde hace algunas semanas el Tiger Team de Moebius Security viene trabajando con algunos de los CMSs existentes más populares, entre ellos WordPress. Algunas estadísticas hablan incluso de un posicionamiento de más del 50% a favor de este CMS. En cualquier caso, el hecho es que este popular CMS está siempre vinculado a distintas brechas de seguridad, incluso más de uno llega a pensar en que su utilización en producción, es un completo riesgo para mantener seguro los sitios web, pero nada más lejos de la realidad, sino que se lo pregunten a Daniel Maldonado (@elcodigok) autor del libro “Máxima Seguridad en WordPress”, altamente recomendable, todo sea dicho.
Bien en esta entrada vamos a presentar una pequeña herramienta que hemos desarrollado y que estamos felices de compartirla con toda la comunidad de seguridad. El nombre de la misma es: WPLchecker.
Primero, comentar que WPLchecker se trata de una herramienta centrada en evaluar sitios web que corran bajo WordPress (de ahí el nombre, es más). La función principal de la herramienta es identificar de forma automatizada y ágil todos aquellos plugins que cuenten con vulnerabilidades conocidas. Cabe destacar que un sitio web cualquiera puede no presentar vulnerabilidades aparentes en su estructura, sin embargo un plugin no deja de ser un pedazo de código que fue desarrollado por un tercero y que probablemente no haya sido concebido con mínimos de seguridad (o sí).
En portales como el archiconocido Exploit Database, se publican de manera constante una serie de exploit que permiten aprovechar y explotar diversas vulnerabilidades en algunos de los miles de plugins disponibles para WordPress. Por tanto, se pensó que usando esta gran base de datos, se podía preguntar si un determinado sitio web cuenta o no con uno o más plugins que sean potencialmente vulnerables. Esto es lo que conseguirás con WPLchecker, hacer la consulta automatizada concreta y a partir de los resultados, aprovechar si se cuenta con vulnerabilidades que puedan comprometer al sitio web objetivo.
La herramienta actualmente cuenta con la siguiente estructura:
En que cada fichero consiste y cumple con la siguiente función:
- paths.- Contiene un listado de nombres de plugins vulnerables. Actualmente se cuenta con un total de 57 nombres distintos. Esta lista la usará la herramienta para ir revisando uno a uno los potenciales plugins disponibles en un sitio web objetivo.
- plugins.- Contiene una tabla que muestra la totalidad de resultados que puede arrojar la herramienta. Actualmente hasta un total de 65 vulnerabilidades perfectamente explotables y aprovechables. El resultado mostrado en columnas identifica: Nombre del Plugins, Versión Vulnerable, Fabricante del Plugins, Nombre de la Vulnerabilidad y la ruta por defecto del fichero Readme.txt. Este fichero último lo encontrarás en cada plugin que se instale en un sitio web con WordPress, básicamente viene por defecto.
- WPLchecker.py.- Se trata de la herramienta propiamente. A continuación pasaremos a describir el código del mismo.
¿Cómo se compone WPLchecker?
Bien, WPLchecker actualmente se compone de menos de 70 líneas de código, es decir, su procesamiento es bastante ágil. Y su función principal es la de validar si tiene constancia de la existencia de un determinado directorio, o no? Tan simple, como útil.
Se compone de 3 funciones: “banner”, “usage” y “scanning”, esta última es la encargada de hacer la función principal de la herramienta, es decir, escanear.
Destripando esta última función, pasaremos a describir a nivel de código fuente como se comporta la herramienta con las interacciones del usuario.
./WPLchecker.py
La herramienta arroja los mensajes definidos en las funciones banner() y usage(). A modo de presentación.
./WPLchecker.py URL1 URL2 URL3
Si el usuario por error o de forma intencionada escribe más de 1 (una) URL como objetivo, la herramienta le indicará la advertencia de que quizás no la ha ejecutado como es debido. En este caso también nos remitirá al mensaje de la función usage().
./WPLchecker.py plugins
Cuando el usuario escriba la palabra “plugins” en la ejecución, la herramienta interpretará que lo que el usuario quiere es ver el listado completo de vulnerabilidades que es capaz de identificar, en este caso le mostrará toda la lista actualizada.
./WPLchecker.py paths
Cuando el usuario escriba la palabra “paths” en la ejecución, la herramienta se encargará de advertirnos que no estamos ejecutando la herramienta de la forma esperada y nuevamente nos remitirá al mensaje de la función usage().
./WPLchecker.py URL
En este último caso, la herramienta pasará a tomarse el valor de URL como el objetivo de escaneo y procederá a examinarlo. Cabe destacar que si aquí el usuario no escribe una URL válida, la herramienta poco resultado le podrá proporcionar.
Lo primero que hará la herramienta es identificar a través de 2 métodos, la versión de WordPress del objetivo. El primer método es a través de la etiqueta “<meta name=»generator» content=»VERSIÓN» />”, como mucho sabrán, si revisamos el código fuente de una página con WordPress, esta etiqueta normalmente nos revela la versión concreta del CMS.
VRS1 = os.popen("curl -s " + sys.argv[1] + " | grep 'content=\"WordPress' | cut -d '\"' -f4").read()
El otro método que usa y como alternativa para revisar la versión de WordPress es a través del fichero “wp-login.php”. Este fichero, si se tiene por defecto, nos llevará al panel de autenticación de administración. Si aquí nuevamente revisamos el código fuente resultante, y en las referencias vinculadas al campo “href=” siempre al final de la URL del objetivo aparecerá un apartado que nos dice “;ver=VERSIÓN’”, pues bien, resulta que esto se trata de la versión del CMS.
VRS2 = os.popen("curl -s " + sys.argv[1] + "/wp-login.php | grep ';ver=' | cut -d ';' -f4 | cut -d '=' -f2 | cut -d \"'\" -f1 | grep .").read()
Después de esto la herramienta ya pasará a realizar su inspección principal: descubrir plugins potencialmente vulnerables. Para ello se centrará en el directorio “URL/wp-content/plugins/”, que para los entendidos, comprenderán que éste directorio es donde se instalan y alojan todos los plugins que implementemos en un sitio web con WordPress. Al menos por defecto. Y concretamente la herramienta revisará la existencia del fichero “PLUGIN/readme.txt”, dentro de la estructura de directorios anterior.
Por lo tanto, a partir de la lista proporcionada por el fichero: “paths” irá preguntando al sitio web objetivo la existencia o no, de un plugin concreto, si la respuesta del sitio web objetivo es sí o lo que es lo mismo, da como respuesta un código de estado HTTP 200 OK, significará que el plugin existe en el sitio web objetivo y por tanto nos indicará una línea con el resultado. Si por el contrario, la respuesta es distinta de un código de estado HTTP 200 OK, significará que plugin no se encuentra en el sitio web objetivo y por tanto pasaremos al siguiente nombre de plugin disponible en la lista “paths”. Así, hasta barrerla toda.
Bueno, como se dice que es mejor verlo por si mismo, a que te lo cuenten. A continuación les dejo una pequeña demo de lo comentado en éstas líneas.
Por último aquí os dejo los pasos básicos para la instalación de WPLchecker en vuestra distribución de GNU/Linux favorita y desde el GitHub.
Instalación:
git clone https://github.com/Moebiusec/WPLchecker.git cd WPLchecker/ chmod +x WPLchecker.py ./WPLchecker.py
Espero que os sea de utilidad en vuestras labores. Sed buenos!