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 pentest cuando se dio cuenta que en SQL Server, por defecto, la autenticación va cifrada, 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.
Se me ocurrió llevar esta prueba de concepto al mundo MySQL con el objetivo de comprobar si podemos modificar on the fly una query enviada por un cliente legítimo. El objetivo es sencillo, modificar tráfico de la consulta MySQL y conseguir ganar acceso sobre el sistema. En primer lugar, comprobé que el tráfico, por defecto, va sin cifrar. En el caso de MySQL, tanto el login como las querys van sin cifrado. La contraseña del login va hasheada.
Estando en la misma red LAN o colocándonos en medio de la comunicación, por ejemplo entre 2 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. Ahora, 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;”.
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 paso podría ser denominado el paso Troll, en el que cambieramos on the fly la consulta “select * from cookie;” por “select * from stolen;”. Para ello creamos un filtro con EtterFilter. Crear filtros con esta herramienta es sencillo e intuitivo y proporciona un gran potencial en la edición de paquetes on the fly.
La sintaxis del filtro será sencilla y 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 strings. Para esta prueba de concepto lo haremos a través del DECODED que estos filtros aportan.
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.
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.
En este instante la víctima se encuentra con caché ARP envenenada y sus querys pasarán por nosotros. Desde Wireshark podemos visualizar las peticiones y observamos que llega la query original con el típico aspecto. Esta consulta será modificada on the fly 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.
También podemos ver la respuesta que obtenemos a través de Wireshark y veremos 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 query con resultado legítimo, a la derecha, y una con la inyección/modificación en la query, a la izquierda.
¿Qué nos ofrece este mecanismo? 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. También queda 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.