La semana pasada hablaba de la técnica Network Packet Manipulation con la que podíamos modificar consultas MySQL on the fly. Echando una pensada, podríamos crearnos un usuario en el sistema y poder entrar a través de WP-Admin o, incluso, actualizar el campo contraseña de un usuario y robar directamente dicho usuario, ¿Te imaginas haciendo esto al usuario root de tu Wordpress?
La primera traba que muchos pueden pensar es: la mayoría de 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 2 capas se separan. Es decir, encontraríamos la aplicación web por un lado, y la base de datos por otro. En un escenario de auditoría interna podremos encontrar una oportunidad para realizar este tipo de manipulaciones y poder llegar a tomar el control. Por defecto, la aplicación web de Wordpress no va cifrada, y las consultas con MySQL tampoco.
En primer lugar hay que estudiar qué tipo de peticiones realiza Wordpress contra el 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.
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é query o conjunto de queries realiza la aplicación cuando damos de alta un nuevo usuario o modificamos algún parámetro.
El primer filtro detecta si el paquete está destinado al puerto 3306, el cual es el de 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 algoritmo de Wordpress.
Una vez creado el filtro se debe compila con la herramienta etterfilter mediante la instrucción etterfilter –o wp.ef wp.filter, siendo wp.filter el nombre del fichero dónde escribí el filtro. Una vez compilado se debe ejecutar ettercap para realizar el MiTM 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:
El user_pass está preparado para cambiar, no es un hash real, pero es 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 matchea con lo que nuestro filtro busca y se llevará a cabo el proceso de actualización. Todas las contraseñas de las cuentas de Wordpress serán modificadas y actualizadas a la contraseña que nosotros queramos, eso sí hasheada.
En esta imagen se puede ver el cambio gracias al filtro ejecutado y el 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.
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 query para crear un usuario es INSERT INTO a la tabla wp_users con, al menos, los atributos de contraseña, usuario e id. Hay que tener en cuenta de nuevo lo del tamaño del paquete. De nuevo elegimos la query SELECT option_val y reemplazamos el tamaño del paquete por el hexadeciaml 0x71, ya que nuestra consulta tiene dicho tamaño.
De nuevo hay que compilar el filtro con etterfilter y ejecutar el spoofing de ARP con la herramienta Ettercap. El resultado es el que se puede ver en la imagen, obtenemos un nuevo usuario denominado pablo con un id alto, para no colisionar con otros usuarios y con la contraseña hasheada que queramos, en ese instante el auditor tendrá acceso al Wordpress.
En conclusión, hay que cifrar las consultar que se realicen entre las aplicaciones web, como puede ser Wordpress, y las bases de datos. Si un atacante puede colocarse en medio de la comunicación está podría quedar a merced de éste.
La primera traba que muchos pueden pensar es: la mayoría de 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 2 capas se separan. Es decir, encontraríamos la aplicación web por un lado, y la base de datos por otro. En un escenario de auditoría interna podremos encontrar una oportunidad para realizar este tipo de manipulaciones y poder llegar a tomar el control. Por defecto, la aplicación web de Wordpress no va cifrada, y las consultas con MySQL tampoco.
En primer lugar hay que estudiar qué tipo de peticiones realiza Wordpress contra el 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.
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é query o conjunto de queries realiza la aplicación cuando damos de alta un nuevo usuario o modificamos algún parámetro.
Analizando las peticiones podemos encontrar que la inserción o alta de usuarios se realiza a través de un INSERT INTO a la tabla wp_users y se pasan una serie de parámetros. En la imagen inferior se puede visualizar parte de dicha sentencia. La idea, entonces, será capturar un paquete que encaje con un patrón y modificar la consulta por la que nosotros queramos, por ejemplo un 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.
Ahora llega el momento de crear el filtro. 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 a MySQL cuantos bytes debe leer y ejecutar en el motor. 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, el cual es el de 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 algoritmo de Wordpress.
Una vez creado el filtro se debe compila con la herramienta etterfilter mediante la instrucción etterfilter –o wp.ef wp.filter, siendo wp.filter el nombre del fichero dónde escribí el filtro. Una vez compilado se debe ejecutar ettercap para realizar el MiTM 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:
El user_pass está preparado para cambiar, no es un hash real, pero es 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 matchea con lo que nuestro filtro busca y se llevará a cabo el proceso de actualización. Todas las contraseñas de las cuentas de Wordpress serán modificadas y actualizadas a la contraseña que nosotros queramos, eso sí hasheada.
En esta imagen se puede ver el cambio gracias al filtro ejecutado y el 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.
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 query para crear un usuario es INSERT INTO a la tabla wp_users con, al menos, los atributos de contraseña, usuario e id. Hay que tener en cuenta de nuevo lo del tamaño del paquete. De nuevo elegimos la query SELECT option_val y reemplazamos el tamaño del paquete por el hexadeciaml 0x71, ya que nuestra consulta tiene dicho tamaño.
De nuevo hay que compilar el filtro con etterfilter y ejecutar el spoofing de ARP con la herramienta Ettercap. El resultado es el que se puede ver en la imagen, obtenemos un nuevo usuario denominado pablo con un id alto, para no colisionar con otros usuarios y con la contraseña hasheada que queramos, en ese instante el auditor tendrá acceso al Wordpress.
En conclusión, hay que cifrar las consultar que se realicen entre las aplicaciones web, como puede ser Wordpress, y las bases de datos. Si un atacante puede colocarse en medio de la comunicación está podría quedar a merced de éste.