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”
9 comentarios:
Muchas gracias por la info!
Saludos!
Entiendo que eso solo ocurre si no se usa TLS (o en su defecto, HTTPS), ¿cierto?
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 ....
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.
Como siempre Chema eres el mejor
Anónimo de las 24/2/16 1:38 p. m.
El autor fué Pablo González, aunque claro Chema es un Crack!
entre la db y el php no hay https aunque si pueden existir consultas cifradas
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.
Publicar un comentario