WPScan a fondo para webmaster

Este artículo tiene dos propósitos: el primero es mostrarle a los administradores de aplicaciones web basadas en WordPress como pueden utilizar WPScan para realizar evaluaciones de seguridad.

El segundo objetivo es adentrarnos en la comprensión del funcionamiento de WPScan porque hay muchos tutoriales que dan explicaciones superficiales que no abarcan todos los elementos necesarios para hacer una prueba de seguridad efectiva.

Para hacer un escaneo rápido y superficial puedes encontrar muchos tutoriales más breves y simples que este. Si quieres realmente comprender como utilizar WPScan y cómo interpretar correctamente sus resultados, entonces sigue leyendo que este tutorial es para ti.

Conceptos Iniciales

WPScan 2.9.1 es un escáner de vulnerabilidades para WordPress.  Está desarrollado por el WPScan Team y patrocinado por la reconocida empresa de seguridad Sucuri. Su enlace principal es https://wpscan.org/.

Tienen una licencia dual, lo que se traduce en que si vas a utilizarlo como una herramienta para escanear aplicaciones web propias o en pruebas de penetración no tienes que pagar nada. Ahora, si vas a comercializar un producto o servicio que integra a WPScan como un componente interno o algo similar entonces necesitarías una licencia comercial (Ej. Vendes un servicio de hosting y como valor añadido incorporas escaneos periódicos con WPScan).

Las pruebas de seguridad que realiza se basan en un enfoque de caja negra, lo que significa que todo el análisis se ejecutará únicamente sobre las peticiones y respuestas HTTP intercambiadas con la aplicación web.

Primeros pasos

Recomiendo utilizar WPScan desde Kali Linux u otra distribución que esté instalada por defecto. En la página principal pueden encontrar información sobre esto y también que debes hacer para instalarlo desde cero.

Hay que actualizar la base de datos de WPScan para usarlo por vez primera. La base de datos está compuesta por un conjunto de archivos que contienen firmas hash de componentes  de WordPress, de plugins, descripciones de vulnerabilidades, referencias de exploits, entre otros datos que pueden consultarse en línea en  https://wpvulndb.com/. Gracias a esto vas a recibir un reporte con un conjunto de referencias muy completo sobre las vulnerabilidades que sean detectadas.

En la figura 1 podemos ver los archivos que conforman la base de datos y se incluye un segmento del contenido de archivo wp-versions.xml, mostrando algunas firmas hash.

1

Figura 1. Archivos que componen la base de datos de WPScan.

Para actualizar los archivos se utiliza la opción  –update:

  • wpscan –update

El proceso de actualización es muy rápido y ya estamos en capacidad de hacer nuestro primer escaneo.

Otra opción importante es –help, pues brinda información de todas las opciones disponibles. En algunos casos pienso que podían haber sido más explícitos en las descripciones pero en sentido general orienta con suficiente claridad al usuario novel.

Importante: Todas las opciones principales comienzan con dos signos menos (–) delante.

Escaneo básico

El escaneo básico no intrusivo es el modo más simple en que podemos revisar nuestro sitio de WordPress. Solo hay que escribir la opción –url y teclear enter:

wpscan – -url http://URL-de-la-aplicación-web

Es importante saber que este modo solo se encarga de revisar las referencias de la página principal y otras rutas por defecto. Si hay un plugin que no tiene una referencia directa en la página principal del portal o está de algún modo ofuscado, no va a ser detectado ni revisado con este modo.

Interpretando los resultados

El informe emitido por WPScan usa colores y símbolos para alertar sobre los elementos que va mostrando de la aplicación web. Es necesario destacar algo y debes tenerlo siempre presente para que no te confundas:

Cuando WPScan no es capaz de detectar la versión exacta de WordPress o de un plugin, reporta las últimas vulnerabilidades conocidas para esos elementos pero esto no quiere decir que tu aplicación web sea vulnerable.

En teoría, si haces todo como debe ser, WPScan debe ser incapaz de detectar incluso que está tratando con una aplicación web basado en WordPress pero es algo que veremos más adelante.

La primera parte del reporte (figura 2) contiene la hora de inicio del escaneo, informa de los fingerprint o firma digital dejados por defecto por los webmasters y enviados por el servidor de aplicaciones.

2.png

Figura 2. Ejemplo de la primera parte de un reporte emitido por WPScan.

Toda la información que aparece allí tiene algún tipo de implicación con la seguridad de la aplicación web. En la figura 2 se aprecia cómo nos alerta que el archivo readme.html existe y expone el número de versión de WordPress, que el admin-ajax.php está habilitado, que hay un error que expone rutas de directorios (Full Path Disclosure), que la funcionalidad de registro puede usarse y que está disponible el XML-RPC.

Por último nos dice que pudo determinar el número de la versión de WordPress por el metadato meta generator que aparece en la página principal del sitio y que para esa versión existen 8 vulnerabilidades identificadas (figura 3).

3

Figura 3. Sección del reporte generado por WPScan que informa de las vulnerabilidades presenten en la versión de WordPress 4.5.2.

Opción –enumerate

La opción —enumerate es una de las principales funcionalidades de WPScan y nos va a permitir inspeccionar los plugin, temas (themes) y cuentas de usuarios en la aplicación web, informándonos en los casos correspondientes de las vulnerabilidades y versiones actuales disponibles. El 99.9% de la información que podremos descubrir con esta funcionalidad, nunca va a ser mostrada durante un escaneo básico, de ahí la importancia de su utilización:

El primer grupo que veremos será el descubrimiento de los plugin instalados, para ello podemos usar diferentes opciones:

  • p (–enumerate p): Muestra un listado de todos los plugin instalados. Sin embargo, la opción p utiliza un algoritmo no exhaustivo por lo que hay plugin que no serán identificados por estar ofuscados de algún modo.
  • ap (–enumerate ap): Su ejecución toma tiempo, representa una sobrecarga para el CPU y envía un número considerable de peticiones al servidor web pero es la opción que más plugin descubre. Es la que recomiendo en primera instancia para hacer una labor realmente profesional.
  • vp (–enumerate vp): Muestra solamente los plugin que tienen vulnerabilidades. También muestra los plugin instalados, cuya versión WPScan no pudo determinar pero que tiene vulnerabilidades registradas. Es importante tener en cuenta esto pues podemos confundirnos y pensar que el plugin instalado es vulnerable cuando en realidad no es así (figura 4).
4

Figura 4. Ante la imposibilidad de detectar la versión de un plugin, WPScan informa de las vulnerabilidades presentes, si han sido publicadas, para este tipo de plugin.

Otra cuestión importante es analizar los temas presentes y sus vulnerabilidades, su utilización es muy similar a los plugin:

  • t (–enumerate t): Muestra un listado de todos los temas instalados. Sin embargo, utiliza un algoritmo no exahustivo por lo que hay temas que no se muestran con esta opción.
  • at (–enumerate at): Su ejecución toma tiempo, representa una sobrecarga para el CPU y envía un número considerable de peticiones al servidor web pero es la opción que más temas descubre. Es la que recomiendo en primera instancia para hacer una labor profesional.
  • vt (–enumerate vt): Muestra solamente los temas que tienen vulnerabilidades. También muestra los temas instalados, cuya versión WPScan no pudo determinar pero que tiene vulnerabilidades registradas.

Una tercera opción, de vital importancia, es la búsqueda del script TimThumb que ocasionó épicos problemas de seguridad en innumerables instalaciones de WordPress alrededor del mundo que ocasionaron el fin de su ciclo de vida en el 2014.

  • tt (–enumerate tt): Inspecciona la aplicación web basada en WordPress para detectar la presencia de scripts de TimThumb.

El último grupo de opciones está asociada al análisis de la enumeración de nombres de cuentas de usuarios en WordPress.

En un artículo anterior habíamos tratado este tema y cómo influye en la seguridad de nuestras aplicaciones web. WPScan nos permite analizar cómo se comporta esta cuestión del siguiente modo:

  • u (–enumerate u): Trata de enumerar las diez primeras cuentas de usuarios. No resulta inusual que sitios que hayan sido utilizado por un tiempo no tengan ningún usuario con id entre 1 y 10. Por tanto, si no obtenemos ningún resultado con esta opción no quiere decir nada y debemos aplicar otros intervalos de id.
  • u[inicio-fin] (–enumerate u[inicio-fin]): Trata de enumerar las cuentas de usuarios cuyos id se encuentran en el intervalo suministrado. Si esta opción no arroja una cuenta de usuario y el intervalo es razonable, por ejemplo u[11-50] entonces podemos concluir que la aplicación web tiene medidas básicas de protección contra la enumeración de cuentas de usuarios.

Hasta aquí, los cuatro grupos de opciones de descubrimiento que pueden utilizarse en un escaneo automático de vulnerabilidades con WPScan.

Estas opciones pueden separarse por coma para que se ejecuten en lote (Ej. –enumerate tt,u[11-50]). Algo que también utilizo casi siempre es el redireccionamiento >> de la shell de Bash para guardar el informe generado y no tener que volver a escanear varias veces la misma aplicación web, evitando de ese modo las sobrecargas de peticiones y respuestas HTTP.

Otras opciones

WPScan permite hacer otras pruebas de seguridad relacionadas con análisis de intrusión a través de ataques de diccionario, ofuscamiento de user-agent y control del tiempo entre peticiones, cuestiones que no trataremos en este artículo. No obstante quería comentarle de algunas otras opciones que resultan muy útiles:

  • –force: Si eres de los que cree y aplica la defensa en profundidad en tus aplicaciones web, de seguro ya ofuscas tus instalaciones de WordPress. Con esta funcionalidad le indicarás a WPScan que no se guíe por las apariencias y que escanee la aplicación web a pesar de que no haya podido encontrar las huellas digitales correspondientes.
  • –follow-redirection: En algunos casos la petición original a la aplicación web sufre un redireccionamiento. Normalmente esto ocurre cuando escribimos solamente http:// en sitios que utilizan HTTPS. En estos casos, WPScan generalmente nos pregunta si queremos seguir el redireccionamiento pero a veces queremos ejecutar de manera automática WPScan en momentos en que no estaremos para responder a esta pregunta. Por eso, la mejor opción es escribir correctamente https:// o adicionar a los parámetros  –follow-redirection.

Conclusiones

WPScan es una buena herramienta para que los webmaster de aplicaciones web basadas en WordPress, evalúen la seguridad de estas, entre una prueba de penetración y otra. Su utilización es bastante simple, no así su instalación, pero para esto tenemos a Kali Linux que nos resuelve este asunto.

Espero que hayas podido apreciar, con este artículo, que WPScan es más que el escaneo básico que aparece en decenas de tutoriales en Internet y lo más importante, que te haya servido para mejorar la seguridad en tus actuales y futuras aplicaciones web basadas en WordPress.

S4lud0s y h4st4 el próx1m0 p0st!!!

Anuncios

3 comentarios en “WPScan a fondo para webmaster

  1. Pingback: ¿Por qué el plugin RevSlider es culpable del 10% de las intrusiones en portales basados en WordPress en el 2016? | Behique Digital

  2. Pingback: Experiencias con Kali 2016.2 (I) | Behique Digital

  3. Pingback: Problemas del “pentesting real” según Marek Zmysłowski (III)- Mi Nessus es mejor que el tuyo | Behique Digital

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s