WordPress y el mundo de los CMS IV: ¡Por qué el hacking manual es más divertido!

Buenas compis,

Seguimos con la guía de pentesting de WordPress! Tras las primeras entregas de este famoso CMS:

Enumerando usuarios WordPress

Dork WordPress Hacking

Escaneando vulnerabilidades

Esta vez toca lo más divertido, olvidarnos de pasar scripts y demás herramientas (que son de gran ayuda por supuesto) y ponernos el gorro de pentester haciéndolo a mano y así de paso ponemos en evidencia los escáneres de vulnerabilidades de botón gordo 😉

Además recomiendo la lectura del compañero @_Metalex que hizo una prueba muy interesante al plugin revolution-slider.

Para ello, como ya sabéis somos chicos buenos y tal por lo que continuamos las pruebas en la máquina virtual que me monté de wordpress para divertirnos sin meternos en líos

Vamos al lío!Como ya se ha comentado anteriormente y ya deberías tener «grabado a fuego» es que si se desea comprometer un wordpress los vectores de entrada son los plugins, así que una buena manera es identificar los plugins que se encuentran instalados. Para ello, se va presentar dos maneras:

  • Códigos de respuesta del servidor web al acceder al directorio de wordpress.

La ruta por defecto en wordpress en la que se encuentran los plugins es DOMAIN/wp-content/plugins. De esta manera, se puede bien probar un par de plugins típicos o por defecto (por ejemplo akismet) o bien tirar pasar un diccionario con plugins empleando algún script o el propio intruder de burpsuite.

De esta manera, si el servidor devuelve un mensaje de 403 Forbidden significa que el plugin se encuentra instalado.

 

plugin_403-forbidden

 

Mientras que si el plugin no se encuentra instalado, el servidor web devuelve 404 Not Found mostrando la página personalizada de error.

 

404_plugin_no_valido

 

Sin embargo, si se pretende hacer poco ruido y no acabar haciendo fuerza bruta como al final y al cabo hacen por ejemplo las herramientas de enumeración.

  • Lo que esconde el código fuente

El código fuente siempre alberga «horrores» información muy interesante que es necesario inspeccionar. En el caso de WordPress suele contener las rutas de plugins, por lo que nos están «cantando» algunos de los plugins que tienen instalados.

 

codigo_fuente_plugins

 

Otro punto de entrada bastante interesante son los ficheros javascript que trae WordPress. Se encuentran localizados en la ruta: /wp-includes/js/ y «jugando» con los mensajes de error del servidor web se puede deducir si se encuentran instalados o no:

 

forbidden_js-png

 

Mientras si no se encuentra instalado:

 

404_not_found_js

 

De esta manera, wordpress cuenta con un js vulnerable que no valida correctamente la entrada de parámetros de tal manera que es vulnerable a un XSS reflejado.

La URL de compromiso es la siguiente:

http://DOMAIN/wp-includes/js/plupload/plupload.flash.swf?target%g=alert&uid%g=Upss&

En Upss es dónde se introduce la inyección del alert.

Hasta la versión 4.5.2 de WordPress no se encuentra resuelto. Por ello, un amigo me ha dejado su wordpress para hacer esta PoC (repito me ha dado permiso pues el wordpress que instalé es un 4.6.1 y tampoco es plan de hacernos N máquinas virtuales jajaja) de ahí que oculte cualquier identificador y además le ha servido para saber que la tiene y de esta manera, actualizar su wordpress y corregirla 😉

 

poc_js_xss

 

 

Existen un par más de vulnerabilidades pero ya no puedo seguir explicando más, creo que está bien dar unas pautas pero no dar todo el trabajo hecho, así os montáis vuestra máquina virtual de WordPress, practicáis y las buscáis =D

Pues esto es todo, espero que os haya sido útil.

La finalidad de esta entrada es con fines educativos y formativos. Las pruebas se han realizado en entornos controlados y/o virtuales. No nos hacemos responsables de uso para otro fin diferente. No seáis malos 😉

Saludos.

Naxhack5

La mejor defensa es un buen ataque.