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”
Muchas gracias por la info!
ResponderEliminarSaludos!
Entiendo que eso solo ocurre si no se usa TLS (o en su defecto, HTTPS), ¿cierto?
ResponderEliminarentre la db y el php no hay https aunque si pueden existir consultas cifradas
EliminarBuena pregunta Jimmy, ¿será así?
ResponderEliminarY 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 ....
Este comentario ha sido eliminado por el autor.
Eliminar1. Equipo del usuario -> 2. Servidor WordPress -> 3. Servidor Base de datos
ResponderEliminarEl 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.
Como siempre Chema eres el mejor
ResponderEliminarAnónimo de las 24/2/16 1:38 p. m.
ResponderEliminarEl autor fué Pablo González, aunque claro Chema es un Crack!
Un ataque de este tio no es un juego...ni para el dueño de site, al que implantado el ataque puedo acceder a datos sensibles de los usuarios (recordemos que wordpress se utiliza como simple pagina web en la mayoria de empresas con pasarelas de pago) y para el hackeador, que si es localizado (una cosa es «entrar» y otra «irse»)...se enfrenta a una «ristra chorizera» de delitos, que podrian sumar 15 años de prisión...mas que si robas, vestido de politico, en las arcas públicas. Bien dicho esto, solo queda agradecer a Pablo González, sus divulgaciones, aunque el sabe, que la menor problematica, es instalar un ssl en la web...la mayor problematica y hablo de EX-paña (Una grande, que nunca fue libre) es la burrologia, y analfabetismo tecnológico, al cual hace referencia. Jugar a admin, instalando un ubuntu server en la empresa y gestionar este «en mis ratos libres» es por desgracia, el dia a dia de muchas pymes españolas, que desean y necesitan ahorrar, y optimizar el capital al máximo. Esto lleva a «ver» por la Red, verdaderas burradas configurativad, debido a la conjunción de todos estos factores...y es que no todo es SSL...Un saludo y repito, gracias por tu tiempo y conocimientos...tu legado debería ser materia obligatoria desde 1 de la ESO...Salud a toda la comunidad de habla hispana.
ResponderEliminar