Owneando MySQL con Network Packet Manipulation

Hace unos días leí un artículo en el que Rick Osgood hablaba de un detalle el cual, en muchas ocasiones, pasamos por alto. Rick se encontraba haciendo un trabajo de pentesting cuando se dio cuenta que en Microsoft SQL Server, por defecto, los paquetes de autenticación van cifrados, pero no las consultas. Esto, a priori, puede dar mucho juego, ya que cómo ocurría tiempo atrás con redes sociales que cifraban la autenticación y dejaban la sesión por HTTP, aquí nos encontraríamos con un escenario similar.

Figura 1: Owneando MySQL con Network Packet Manipulation

Para los expertos en bases de datos, esto es algo conocido y hasta en algún examen del Master de Seguridad de la UEM con los que Chema Alonso "martiriza" a sus alumnos puede caer - pregunta 2 -. En los SGBD MS SQL Server, el protocolo TDS (Tabular Data Stream) puede cifrarse instalando un certificado digital en el servidor y seleccionando en los parámetros de la cadena de conexión la opción de Encrypt. En este artículo se explica paso a paso: How to encrypt SQL TDS connections

Figura 2: Configuración de una conexión al SGBD MS SQL Server cifrada

Se me ocurrió llevar esta misma prueba de concepto al mundo MySQL con el objetivo de comprobar si podemos modificar al vuelo una consulta SQL enviada por un cliente legítimo para hacer un ataque de SQL Injection, pero directamente desde la red. El objetivo es sencillo, modificar tráfico de la consulta MySQL y conseguir ganar acceso sobre el sistema estando en la misma red que el cliente - que puede ser un servidor web - y el SGBD MySQL. En primer lugar, comprobé que el tráfico, por defecto, va sin cifrar y como se puede ver, en el caso de MySQL, tanto el proceso de login como las consultas SQL van sin cifrado. Eso sí, la contraseña utilizada en el proceso de login va hasheada.

Figura 3: Hash de contraseña en paquete de autenticación en MySQL

Estando en la misma red LAN o colocándonos en medio de la comunicación, por ejemplo entre dos redes, podríamos obtener el usuario y la contraseña hasheada. La configuración por defecto no es la más segura, eso queda reflejado, y claro, a partir de este momento podríamos hacer lo que quisiéramos. Estando en el medio de la comunicación vamos a ver algunas consultas que la víctima realiza. De primeras se puede ver una consulta del tipo “Select * from cookie;”.

Figura 3: Paquete de consulta a MySQL capturado por la red

La víctima puede esperar resultados sobre cookies, fechas de expiración y otros datos que pueda contener dicha tabla. ¿Cómo podemos modificar la consulta y conseguir devolverle otros datos? Este sería el paso en el que cambiaremos al vuelto la consulta “select * from cookie;” por “select * from stolen;”. Para ello creamos un filtro con EtterFilter.

Modificando un paquete de consulta MySQL con EtterFilter

Crear filtros con esta herramienta es sencillo e intuitivo, y proporciona un gran potencial en la edición de paquetes al vuelo. La sintaxis del filtro puede ser representada mediante este pseudocódigo:

Si tcp port es 3306 Y paquete contiene “Selec” Entonces
Reemplazar “Selec” por “Select * from stolen;#”
Fin Si

¿Por qué ponemos la almohadilla? Vamos a reemplazar sólo la palabra “Selec”, aunque podríamos reemplazar todo, por la consulta “Select * from stolen”, por lo que la almohadilla nos ayuda a comentar todo lo que venga después. El filtro podría realizarse a través de datos en hexadecimal o decodificar y sacar las cadenas de caracteres. Para esta prueba de concepto lo haremos a través del DECODED que estos filtros aportan.

Figura 4: Filtro para modificar una consulta MySQL

Para compilar el filtro hay que ejecutar el comando etterfilter –o [mysql.ef] [mysql.filter]. Esto generará un fichero con extensión ef, el cual es el filtro compilado. Ahora tenemos la opción de utilizar Ettercap para lanzar un ARP Spoofing en la red y cargar nuestro filtro creado para la ocasión. Realmente es un ataque man in the middle que modifica un paquete de red, así que un ataque similar podría hacerse con cualquier otra herramienta de ataques en redes IPv4 & IPv6.

Para realizar el envenenamiento se ejecuta la siguiente instrucción ettercap –T –q –i [interfaz red] –F [mysql.ef] –M ARP. El parámetro –T indica que ejecutaremos Ettercap a través de la línea de comandos. Por último, indicar que el módulo ARP permite indicar un target o toda la red, por lo que si queremos envenenar a un target concreto sería –M ARP /t1/ /t2/. En la siguiente imagen se puede ver cómo queda el lanzamiento de Ettercap.

Figura 5: Arranque de Ettercap para hacer el ataque mitm de ARP Spoofing

En este instante la víctima se encuentra con caché ARP envenenada y sus consultas pasarán por la máquina del atacante. Desde el analizador de tráfico de Wireshark podemos visualizar las peticiones y observamos que llega la consulta SQL original con el típico aspecto. Esta consulta será modificada al vuelo por nuestro filtro, por lo que en Wireshark veremos la nueva petición que sale de nuestra tarjeta dirección al servidor MySQL.

A continuación se muestra la petición legítima que llega y la modificada que sale de nuestra máquina. Hay que tener en cuenta que la legítima nunca llegará al servidor MySQL.

Figura 6: Consulta SQL a MySQL antes y después de ser alterada

También podemos ver la respuesta que obtenemos a través de Wireshark y observaremos cómo, lógicamente, no se obtiene el contenido de la tabla cookie y sí el contenido de la tabla stolen. En la siguiente imagen se puede ver una comparativa de una consulta con resultado legítimo, a la derecha, y una con la inyección/modificación en la consulta, a la izquierda.

Figura 7: Resultados de las tablas antes y después de ser modificadas al vuelo

También quedan abierto la creación de un filtro para el tráfico de vuelta por si hay algo que no queremos que se muestre a la víctima e intentar ser lo más transparentes posible.

Owneando MySQL con la creación de un usuario

La no fortificación de la base de datos nos proporciona la posibilidad de añadir a la consulta una instrucción del tipo “Create User” con el que podamos crearnos un usuario en la base de datos MySQL y abrirnos nuestra propia cuenta si el usuario con que se hace la conexión tiene dichos permisos. El filtro que habría que crear sería el que se ve a continuación.

Figura 8: Filtro para crear un usuario en MySQL reemplazando la Select

Claro, si han aplicado el concepto de mínima superficie de exposición a las cadenas de conexión tal vez sea complicado, pero en ese caso puede que también hubieran cifrado la cadena de conexión.

Figura 9: Ejecución de la consulta de creación de un usuario en MySQL

Las conexiones a los servidores SGBD desde los servidores de aplicaciones web deberían estar cifradas y autenticadas. Configurar un túnel IPSec o configurar una cadena de conexión cifrada con SSL a MySQL debe ser algo obligatorio en todas tus implantaciones de servidores.

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