domingo, 16 de febrero de 2014

WordPress Backdoors III: JavaScript e infección de bases de datos

¡Saludos!

     Continúo trayendo pinceladas del PDF que estoy preparando sobre BackDoors en la plataforma WordPress.

     Cuando estuve en la WordCAMP Sevilla -con trágico resultado- en una de las conversaciones que se mantuvieron en la puerta mientras la gente fumaba hubo alguien, no recuerdo quien exactamente, que nos contó que cuando sufre un ataque en un WordPress lo que hace es hacer un backup de la base de datos, borrar todo el WordPress, instalarlo de nuevo y volver a poner el backup tal cual lo había sacado. Por lo que he podido preguntar me he dado cuenta de que al parecer esta es una práctica bastante habitual... y hace que me lleve las manos a la cabeza. ¿Por qué? Por la sencilla razón de que si el atacante tuvo acceso a la base de datos pudo colar cualquier bicho en ella.

    Si eliminas todos los archivos, y reinstalas en limpio por completo WordPress, te habrás cargado los posibles backdoors que se hubieran escondido en los archivos, pero no habrás erradicado aquellos que se encuentran autocontenidos en la DB. Cuando un usuario visita la web, en el HTML que recibe su navegador se envia texto procedente de campos dentro de la base de datos, véase por ejemplo el nombre del blog, la descripción, el usuario que ha escrito el post, etc. ¿Qué ocurriría si en ese contenido servido hubiera código JavaScript malicioso?

    Como PoC sencillo podemos utilizar WordPressa Lab. Procedemos a modificar en la tabla wp_options el valor de "home" (por poner un ejemplo, existen muchos otros campos susceptibles de ser usados), añadiendole

 "><script>alert(/0wned/)</script><a foo= 

    Para ocultar a los ojos el JS podemos añadir muchos espacios desde el final de la URL hasta que empiece el JS, de tal forma que pasará prácticamente desapercibido:





   Si únicamente queremos que afecte a los administradores (para quitar morralla) podemos editar la tabla wp_comments para añadir JS en el nombre del autor del post más reciente, de tal forma que al visitar el dashboard se le ejecute al admin el payload.

  Ahora que sabemos que cuando se vuelva a poner esa DB se va a ejecutar nuestro JS... ¿Qué hacer? Podemos contentarnos con robar las sesiones a los admins simplemente... o podemos hacerlo al estilo Max Power con BeEF




   Usando BeEF vamos a poder controlar totalmente el navegador de aquellos que visiten la web, abriendonos un abanico de posibilidades según nuestra imaginación: usar los visitantes como proxys, infectarlos con malware, escanear sus redes, extraer credenciales, geolocalizar, etc. Aetsu ya nos habló de BeEF en algun post, pero en proximas entregas entraremos más en profundidad.



Byt3z

5 0verl0ad Labs: WordPress Backdoors III: JavaScript e infección de bases de datos ¡Saludos!      Continúo trayendo pinceladas del PDF que estoy preparando sobre BackDoors en la plataforma WordPress.      Cuando estuve ...

2 comentarios:

Anónimo dijo...

Habra algo similar para infectar codigo php en bases de datos de wordpress ??? por ejemplo si se eliminan los archivos php y la db queda infectada al restaurarse, es posible que se genere un archivo o algo parecido???

The X-C3LL dijo...

Saludos Anónimo,

Inicialmente mi búsqueda se centró en intentar lograr eso, llegar a ejecutar código PHP (o alguna sentencia SQL) que se encontrara intrínseca en la DB, pero no he logrado nada. Estudiando la documentación de la comunidad de WordPress no he encontrado forma alguna más allá de inyectar JavaScript.

Una posible línea de investigación podría ser comprobar todas las funciones del core y ver si existe alguna vulnerabilidad que permita, usando valores establecidos en la DB, realizar un RCE o un PHP object injection. Pero eso requiere de mucho tiempo y cafeína (y es muy dificil dar con algo así de gordo).

< >