martes, febrero 23, 2016

Hackear un WordPress con Network Packet Manipulation

La semana pasada hablaba de la técnica Network Packet Manipulation con la que podíamos modificar consultas MySQL al vuelo en aquellas conexiones a bases de datos no cifradas. Hablando con Chema Alonso sobre ello llegamos a la conclusión de que podríamos modificar fácilmente las consultas que un WordPress realiza sobre la base de datos. Echando una pensada, podríamos crearnos con un filtro un usuario en el sistema y poder entrar a través del panel de administración en WP-Admin o, incluso, actualizar el campo contraseña de un usuario y robar directamente dicha cuenta. ¿Te imaginas haciendo esto al usuario admin de tu Wordpress?

Figura 1: Hackear un WordPress con Network Packet Manipulation

La primera traba que muchos pueden pensar es: la mayoría de los servidores WordPress instalan en la misma máquina la base de datos y la aplicación web. Esto es cierto, puede que en un alto porcentaje de usuarios este hecho sea así, pero en muchas ocasiones, en entornos empresariales estas dos capas se separan. Es decir, encontraríamos la aplicación web por un lado, y la base de datos por otro.

Figura 2: Escenario de un pentesting interno con servidores independientes

En un escenario de auditoría interna podremos encontrar una oportunidad para realizar este tipo de manipulaciones y poder llegar a tomar el control del gestor de contenidos. Por defecto, la aplicación web de WordPress no va cifrada, y las consultas contra el motor MySQL tampoco, y son tareas de fortificación que deben hacerse para evitar los ataques de red.

Preliminares: Analizando las consultas de WordPress

En primer lugar hay que estudiar qué tipo de peticiones realiza WordPress contra el servidor MySQL. Como se puede ver en la siguiente imagen, las consultas van en plano, por lo que basándonos en el ataque de Network Packet Manipulation podemos modificar las consultas y tomar el control de la máquina.

Figura 3: Consulta SQL en texto plano capturada por la red

El siguiente paso es acudir al panel de control de un WordPress y ver qué tipo de peticiones realiza cuando accedemos a la gestión de usuarios. El objetivo es claro, entender qué consulta SQL o conjunto de consultas SQL realiza la aplicación de WordPress a MySQL cuando damos de alta un nuevo usuario o modificamos algún parámetro.

Figura 4: Forzando la creación de un usuario de WordPress para capturar las consultas

Analizando las peticiones podemos encontrar que la inserción o alta de usuarios se realiza a través de una instrucción SQL de tipo INSERT INTO en la tabla wp_users y se pasan una serie de parámetros. En la imagen inferior se puede visualizar parte de dicha sentencia.

Figura 5: Consulta SQL lanzada para la creación de un usuario de WordPress

La idea será capturar un paquete que encaje con un patrón y modificar la consulta por la que nosotros queramos, por ejemplo una consulta UPDATE que permita modificar la contraseña de un usuario existente con el fin de robar una cuenta, o una inserción que nos permita crear un nuevo usuario en la base de datos.

Ataque 1: Cambiando las passwords a los usuarios

Ahora llega el momento de crear los filtros con Etterfilter. El primer filtro que crearemos será el que nos posibilite cambiar las contraseñas del WordPress. Para ello la sentencia que debemos tener en mente será “UPDATE wp_users SET user_pass = [contraseña hasheada]". Antes de mostrar el filtro debemos tener en cuenta una cosa. En los paquetes de MySQL hay un campo denominado Packet_Length. Este valor le indica al motor de  MySQL cuantos bytes debe leer y ejecutar en la base de datos. Debemos localizar una consulta común de WordPress y utilizarla modificando el Packet_Length.

El primer filtro detecta si el paquete está destinado al puerto 3306, que es el que utilizar MySQL por defecto, y decodifica el mensaje filtrando por la palabra “SELECT”. En primer lugar reemplazaremos el Packet_Length, que en el caso del paquete seleccionado es \x49\x00\x00, por el tamaño que estipulemos que será la longitud de nuestra consulta en hexadecimal. En el caso del valor del user_pass pondremos una que queramos, hasheada con el mismo algoritmo que utiliza WordPress.

Figura 6: Filtro para cambiar las passwords a los usuarios de WordPress

Una vez creado el filtro se debe compilar con la herramienta Etterfilter mediante la instrucción etterfilter –o wp.ef wp.filter, siendo wp.filter el nombre del fichero dónde escribimos el filtro. Una vez compilado se debe ejecutar Ettercap para realizar el ataque de MiTM entre el servidor web donde corre WordPress y el servidor donde corre el motor de bases de datos MySQL mediante la instrucción ettercap –T –q –i [interfaz de red] –F wp.ef –M ARP. Si hiciéramos una consulta antes de envenenar con ARP Spoofing veríamos lo siguiente:

Figura 7: Contraseñas cambiadas (no se ha utilizado un hash válido)

El valor de user_pass está preparado para cambiar, aunque en este caso no es un hash real y se ha puesto esa cadena solo para que se vea más claro. Una vez el filtro es ejecutado y un usuario refresca la página principal de control de WordPress se interceptará un paquete MySQL que coincide con lo que nuestro filtro busca y se llevará a cabo el proceso de actualización. Con la ejecución del mismo, todas las contraseñas de las cuentas de WordPress serán modificadas y actualizadas a la contraseña que nosotros queramos, eso sí hasheada.

Figura 8: Nueva contraseña configurada para los usuarios de WordPress

En esta imagen se puede ver el cambio gracias al filtro ejecutado y el ataque de ARP Spoofing. Ahora mismo ya tenemos acceso al WordPress, simplemente conociendo uno de los usuarios, por ejemplo el usuario wordpress o root habrán sido afectados por esta actualización.

Ataque 2: Creando un usuario de WordPress

A continuación os muestro el segundo filtro. Este filtro crea un usuario para que el administrador del WordPress no detecte tanto el robo. La consulta SQL para crear un usuario es INSERT INTO, tal y como hemos visto antes, sobre la tabla wp_users con, al menos, los atributos de contraseña, usuario e id. Hay que tener en cuenta de nuevo el tamaño correcto del paquete.

Figura 9: Filtro para crear un usuario de WordPress

De nuevo elegimos la consulta SQL de tipo SELECT option_val para generar el filtro y reemplazamos el tamaño del paquete por el hexadecimal 0x71, ya que nuestra consulta tiene dicho tamaño.

Figura 10: Ejecución del ataque de Network Packet Manipulation con EtterFilter

De nuevo hay que compilar el filtro con Etterfilter y ejecutar un ataque de spoofing de ARP con la herramienta Ettercap. El resultado es el que se puede ver en la imagen, donde obtenemos un nuevo usuario denominado pablo con un id alto, para no colisionar con otros posibles usuarios, y con la contraseña hasheada que queramos, en ese instante el pentester tendrá acceso al panel de WordPress con este usuario recién creado.

Figura 11: Usuario de WordPress creado correctamente

En conclusión, además de todas las opciones de fortificación de WordPress para evitar ataques a las cuentas de usuario, hay que cifrar las consultas SQL que se realicen entre los frontales web y los motores MySQL. Si un atacante puede colocarse en medio de la comunicación todo el servidor WordPress podría quedar a merced de éste por no haber fortificado la cadena de conexión.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell

7 comentarios:

Inseguro y Navegando dijo...

Muchas gracias por la info!
Saludos!

Jimmy dijo...

Entiendo que eso solo ocurre si no se usa TLS (o en su defecto, HTTPS), ¿cierto?

crv dijo...

Buena pregunta Jimmy, ¿será así?
Y en este punto, me pregunto: ¿quién vela por estos y otros temas relacionados con la seguridad en la mayoría de los blogs o webs que están montados sobre la plataforma WordPress y cuyos propietarios, en la mayoría de los casos, ni tienen un perfil tecnológico ni son conscientes de los riesgos (de seguridad) a los que están expuestos sus blogs/webs? .... uhmmmmm!, me da la impresión de que nadie ....

Anónimo dijo...

1. Equipo del usuario -> 2. Servidor WordPress -> 3. Servidor Base de datos

El artículo habla de un ataque a la comunicación entre un Wordpress y la base de datos donde se almacenan los contenidos que presenta (servidores 2 y 3). Como dice el artículo, en entornos pequeños el servidor de Wordpress es el mismo que el de la base de datos que lo alimenta (servidores 2 y 3 son la misma máquina), por lo que el ataque descrito no es posible.

No tiene nada que ver con la comunicación entre el usuario y Wordpress (equipos 1 y 2). Esta puede ser cifrada o no, pero eso no influye en el ataque descrito en el artículo.

Anónimo dijo...

Como siempre Chema eres el mejor

Anónimo dijo...

Anónimo de las 24/2/16 1:38 p. m.
El autor fué Pablo González, aunque claro Chema es un Crack!

Anónimo dijo...

entre la db y el php no hay https aunque si pueden existir consultas cifradas

Entradas populares