Yuzi download

En varios artículos hemos hablado de cómo hacer ataques de Network Packet Manipulation a entornos de bases de datos. Hablamos de cómo ownear MySQL colocándonos en medio de la comunicación del cliente y el servidor. En otro artículo comentamos cómo hackear Wordpress con la misma técnica. Al final todo se basa en que el tráfico entre las aplicaciones web y el motor de base de datos puede ir sin cifrar, así es por defecto en la instalación de los motores de base de datos y es labor de los administradores configurar las protecciones y el cifrado.

Figura 1: Fortificación de comunicación entre WordPress y MySQL

En el artículo de hoy nos pondremos del lado del Blue Team y hablaremos de cómo fortificar tu Wordpress cifrando las comunicaciones entre éste y el  motor de MySQL.

Punto 0. Mi Wordpress por defecto

Partimos del siguiente esquema:

- Máquina A con dirección IP 192.168.56.103 tiene instalada un Wordpress.
- Máquina B con dirección IP 192.168.56.106 tiene instalado y configurado MySQL por defecto.

Si analizamos las peticiones se puede ver como accediendo al WordPress, entre la máquina 192.168.56.103 y 192.168.56.106 se realizan una serie de consultas a la base de datos. Estos paquetes son susceptibles de ser manipulados.

Figura 2: Trafico de WordPress a MySQL sin cifrar

Punto 1. Fortificando la conexión a MySQL con SSL

En este punto lo que vamos a hacer es preparar los tres componentes necesarios para que MySQL acepte conexiones bajo SSL. En primer lugar hay que consultar si la compilación de MySQL que se está utilizando permite utilizar SSL, si no fuera así habría que instalar una versión más nueva o compilarla con soporte a SSL.

Para verificar esto accedemos a MySQL con un cliente y ejecutamos la siguiente consulta “show variables like ‘%ssl%’;”. Si las variables have_openssl y have_ssl tienen como valor DISABLED significa que está soportado pero no activo. Si por el contrario encontramos el valor NO, significa que la compilación de MySQL no soporta SSL. Si aparece el valor YES, significa que está correctamente configurado y el servidor permite conexión bajo este mecanismo. Además, hay que ver las rutas de las variables ssl_ca, ssl_cert y ssl_key que indican la ruta de la CA, del certificado del servidor y de la clave de éste.

Figura 3: variables de MySQL para configurar SSL

En este punto vamos a utilizar OpenSSL para generar la CA, el certificado y la clave. Para ello ejecutamos las siguientes instrucciones:

- openssl genrsa 2048 > ca-key.pem
- openssl req –sha1 –new –x509 –nodes –days 3600 –key ca-key.pem > ca-cert.pem

Con esto tenemos creado el certificado y la clave privada de la CA. Nos pedirán que rellenemos varios datos como país, ciudad, dominio, e-mail, etcétera.

- openssl req –sha1 –newkey rsa:2048 -days 730 -nodes -keyout server-key.pem > server-req.pem

Con esto generamos la clave privada para el servidor. A continuación, exportamos la clave privada del servidor a tipo RSA con la ejecución del siguiente comando:

- openssl rsa -in server-key.pem -out server-key.pem

Por último, generamos un certificado de servidor utilizado el certificado de la CA.

- openssl x509 -sha1 -req -in server-req.pem -days 730 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

Los ficheros cacert.pem, server-cert.pem y server-key.pem deben estar en la ruta /etc/mysql. Aunque esto puede ser configurado en el fichero de configuración de MySQL /etc/mysql/my.cnf. Editando dicho fichero y buscando a partir del campo “[mysqld]” debemos descomentar la parte de SSL y asegurarnos de que las variables tienen la configuración adecuada, tal y como puede verse en la siguiente imagen.

Figura 4: Configuración del fichero my.cnf

Ahora, reiniciamos el servicio de MySQL. Una vez el motor arranque y lea la configuración del fichero sabrá de dónde leer la información del certificado, la CA y la clave privada. Ahora, podremos conectarnos con un cliente MySQL a través de SSL. Como ejemplo rápido utilizamos el propio MySQL. La instrucción es la siguiente:

-  mysql –u [user] –p –ssl-ca=[ruta cacert]. 

Para comprobar que la conexión se ha realizado a través de SSL podemos consultar la variable Ssl_Cipher.

Figura 5: Configuración de la conexión

Si abrimos ahora WireShark y aplicamos el filtro de MySQL para ver el tráfico observaremos que ya no vemos nada. Sin embargo, si utilizamos un filtro “tcp.dstport == 3306” veremos que hay conexión con dicho puerto de la máquina 192.168.56.106.

Figura 6: Tráfico cifrado entre WordPress y MySQL

Las consultas están siendo cifradas, y por eso WireShark no reconoce contenido de los datos que se envían al motor de MySQL.

Punto 2. Configurar Wordpress para que cifre con SSL la conexión con MySQL

Ahora, hay que indicar en el fichero wp-config.php de WordPress que éste debe entender los flags de MySQL para SSL. Para ello, añadimos al fichero la instrucción “define(‘MYSQL_CLIENT_FLAGS’, MYSQL_CLIENT_SSL);”, tal y como se puede ver en la imagen siguiente.

Figura 7: Configuración de WordPress

Ahora accedemos al sitio web de nuestro WordPress y las consultas a MySQL irán por un canal cifrado, tal y como puede verse en la imagen. En este momento los ataques de NPM (Network Packet Manipulation) ya no es válido, ya que no podemos detectar y manipular las cadenas de MySQL. Si probamos con WireShark veremos que solo accedemos a la conexión al MySQL, pero nada de las consultas, si que veríamos la conexión al puerto 3306, pero todo cifrado.

Figura 8:Conexión a MySQL desde WordPress

De esta forma estamos fortificando el intercambio de información entre el WordPress y la base de datos MySQL. También se puede forzar a que usuarios concretos sólo puedan hacer conexiones bajo SSL, lo cual es interesante para fortificar.

Más artículos sobre seguridad y fortificación en WordPress:

- Hackear WordPress con ataques de Network Packet Manipulation
- Fortificar WordPress frente ataques de fuerza bruta
- WordPress: Ten cuidado con el cacheo de borradores
- WPHardening: Automatizar la fortifación de WordPress
- Listar los plugins de WordPress
- Configurar Latch en WordPress

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

El siguiente ejercicio trata de explicar cómo se puede hackear un servidor Moodle mediante la utilizacio?n de la te?cnica de ataque de Network Packet Manipulation, tal y como ya se ha visto con WordPress, con la que se pueden modificar las consultas a MySQL al vuelo cuando las conexiones a la base de datos no esta?n cifradas. Es bastante comu?n que la aplicacio?n web y la base de datos que utiliza dicha aplicacio?n web este?n instaladas en la misma ma?quina, sí, pero en muchos caso - sobre todo en entornos corporativos - estas dos capas están separadas.

Figura 1: Hackear Moodle con ataques de Network Packet Manipulation

Lo primero que se debe hacer es analizar las consultas de Moodle y conocer un poco como gestiona e?ste su base de datos. En este caso el proverbio “ten cerca a tus amigos para cerca au?n a tus enemigos” recobra un poco valor a la inversa, es decir, tenemos que estar lo mas cerca posible de nuestra víctima en el sentido de que debemos conocerla a la perfeccio?n para poder llevar a cabo el ataque de forma sencilla y con e?xito. En el escenario para las pruebas de concepto esta?n como sigue el esquema siguiente:

Figura 2: El servidor Moodle y la motor SGBDR de MySQL se conectan vía red

Para ello se ha estudiado qué tablas hay en la base de datos que utiliza una aplicacio?n Moodle y cuáles nos podri?an interesar. Como en este caso queremos hacernos con el control del Moodle, lo que necesitaremos es saber dónde se aloja la informacio?n de los usuarios registrados en el sistema y de qué manera. Investigando un poco nos encontramos con que los usuarios se guardan en la tabla siguiente:

Figura 3: Tabla de usuarios en Moodle

Una vez que se sabe qué tabla queremos adulterar debemos saber qué tipo de datos se guardan en ella, es decir, debemos conocer su esquema y qué columnas son las que nos interesan y cuáles no.  Se hacen resaltar los datos que quiza?s nos puedan interesar ma?s, aunque podemos ver la cantidad de columnas que tienen la tabla que gestiona los usuarios en Moodle.

Figura 4: Columnas de la tabla mdl_user

La tabla sigue a continuacio?n con el resto de columnas menos relevantes a la hora de llevar a cabo el objetivo fijado. Se observa la cantidad de datos que puede llegar a guardar Moodle sobre los usuarios de su sistema, hasta 53 columnas que, en un ataque similar podrían modificar cualquier situación, dato personal o privilegio de un usuario.

Figura 5: Hasta 53  columnas en la tabla mdl_user

Ahora que ya sabemos todo lo necesario sobre la tabla que queremos atacar, debemos analizar las consultas que realiza Moodle sobre su base de datos MySQL. Como podemos observar con el analizador de tramas de red Wireshark, el tráfico va en texto plano porque no estamos utilizando una conexión cifrada, por lo si utilizamos la te?cnica Network Packet Manipulation podremos modificar las consultas y tomar el control de la ma?quina.

Figura 6: Consultas de Moodle a MySQL en texto plano

El siguiente paso a realizar seri?a acceder al panel de control de Moodle y ver qué tipo de peticiones realiza cuando accedemos a la gestio?n de usuarios. Es decir, debemos entender el conjunto de consultas que realiza Moodle al SGBDR MySQL cuando creamos un nuevo usuario o modificamos el valor de alguno ya existente.

Figura 7: Gestión de usuarios en Moodle

Se debe de analizar las peticiones minuciosamente para encontrar la consulta en la que se realiza la insercio?n del nuevo usuario ya que hay multitud de ellas en el intervalo de tiempo entre la conexio?n al servidor MySQL y la desconexio?n. La instruccio?n elegida para esta demo en cuestio?n es una query SQL del tipo INSERT INTO en la tabla mdl_user y se le pasan los para?metros correspondientes recogidos del formulario web rellenado. Podríamos haber utilizado cualquier otra y modificarla completamente, pero para este ejemplo vamos a usar directamente la de inserción de nuevos usuarios. Despue?s de analizar bien las consultas damos con ella, y es la siguiente:

Figura 8: Captura del INSERT INTO de un nuevo usuario

No cabe entera en la pantalla por lo que aquí se muestra en un editor de texto cualquiera para poder analizarla. Hay que recordar que son 53 columnas las que tiene la tabla y muchas de ellas están definidas como Not Null:

Figura 9: Consulta completa para dar de alta un nuevo usuario en Moodle

La idea principal es capturar un paquete, el cual sepamos que va a existir y modificar la consulta que lleva por la que nosotros queramos, por ejemplo una consulta UPDATE que permita modificar la contrasen?a o algu?n dato de un usuario existente con el fin de robar una cuenta.

Procedemos a ver como se podri?a cambiar cualquier dato de un usuario registrado en el sistema. Para realizarlo podemos crear filtros con Etterfilter. El primer filtro que se creara? sera? el que nos posibilite cambiar la ciudad de un usuario registrado en Moodle - de forma ana?loga se podrá hacer para cambiarle la contrasen?a -. Para ello la sentencia que debemos tener en mente sera?:

“UPDATE mdl_user set city = hack3d where username = zweig”

Antes de crear el filtro debemos hacer hincapie? en que los paquetes enviados a MySQL tienen el campo llamado Packet_Length, que le indica al motor de MySQL cuántos bytes debe leer y ejecutar en la base de datos. Por lo tanto, debemos localizar la consulta que sepamos que va a realizar Moodle, la cual sera? nuestro objetivo a adulterar, y deberemos modificar también su Packet_Length con el taman?o de nuestra consulta.

La consulta que se ha elegido como objetivo para inyectar nuestra propia consulta es la siguiente, aunque despue?s de un ana?lisis de las consultas podri?amos haber usado un monto?n más que se repiten cada vez que Moodle interactúa con su base de datos:

Figura 10: Consulta elegida con Packet Length de 43 bytes

Se puede ver que su Packet_Length es de 43, el cual en hexadecimal es 2b. La consulta que queremos inyectar en el paquete es la siguiente:

UPDATE mdl_user set city = hack3d where username = zweig

Esta consulta tiene un taman?o de 61, que en hexadecimal es 3d. Con toda esta informacio?n ya podemos pasar a elaborar el siguiente filtro:

Figura 11: Filtro creado para modificar la consulta original a Moodle

El filtro detecta si el paquete esta destinado al puerto 3306, que es el que esta utilizando MySQL por defecto, luego decodifica el mensaje filtrando por la palabra SET SESSION. Una vez se cumplan estas dos condiciones, lo primero que hace es reemplazar el Packet_length, en el caso del paquete seleccionado es x2bx00x00, por el taman?o de la que queremos inyectar, es decir x3dx00x00. Despue?s pasamos a modificar la ciudad de un usuario en concreto, al cual le pondremos como ciudad “hack3d”. De la misma forma que se puede hacer sobre ciudad lo podri?amos hacer sobre cualquiera de las columnas de la tabla mdl_user. Una vez que ya tenemos el filtro llega el momento de compilarlo mediante la instruccio?n:

etterfilter -o md.ef2 mdl.filter2

Antes de lanzarlo, podemos echar un ojo a la tabla en cuestión de la base de datos, para comprobar el valor que tiene la columna y poder verificar si el filtro ha tenido éxito o no en nuestra prueba:

Figura 12: Ciudad antes de ejecutar el ataque

Una vez que el filtro esta compilado llega el momento de usarlo con Ettercap para realizar el ataque de MiTM entre el servidor web donde corre Moodle y el servidor donde corre el SGBDR MySQL mediante la instruccio?n:

ettercap -T -q -i -F mdl.ef2 -M ARP