Normalmente, cuando auditamos una aplicación web mal programada en su backend, es habitual encontrarnos con vulnerabilidades de inyección SQL. Principalmente inyecciones ciegas basadas en error o, si tenemos mucha suerte, basadas en unión de tablas. Sin embargo, lo que no es muy habitual es encontrarnos con una inyección sql fuera de banda.
Éstas no solo dependen de que la aplicación sea vulnerable sino de que el servidor tenga habilitados mecanismos que nos permitan exfiltrar la información por una banda distinta a la propia aplicación web.
El propio hecho de que los resultados sean devueltos por una vía completamente diferente, unido a que éstas pueden ser muy variadas, hace que sea muy difícil utilizar herramientas automatizadas para explotar este tipo de vulnerabilidades. Aún así, en ciertos casos donde los tiempos de respuesta de un servidor sean muy lentos o irregulares, puede merecer la pena tratar de exfiltrar la información de dicha forma.
Como ejemplo vamos a echar un vistazo a una inyección que me he encontrado recientemente en una auditoría web.
En este caso, la vulnerabilidad resultaba muy extraña puesto que el parámetro se llamaba sql***, pidiendo a gritos una inyección, pero la web no devolvía errores y no parecía ser afectada por técnicas basadas en tiempo. Sin embargo, nuestro mejor amigo Burp active scan parecía convencido de que existía una inyección en dicho parámetro.
Analizándolo con calma, descubrimos que la aplicación puede ser comprometida utilizando una vulnerabilidad de Oracle, ¡fechada en 2014! Esta vulnerabilidad proviene de un error en los mecanismos de seguridad del parser XML de Oracle, el cual previene la interpretación de entidades externas, pero no filtra la petición para obtenerlas. En resumen, tenemos una vulnerabilidad de pseudo-XXE autenticado, que en una situación normal sería muy difícil de explotar, pero que puede ser un método de exfiltración curioso para auditores oportunistas como nosotros.
El payload que se utiliza es el siguiente:
Esto forzará a la base de datos a realizar una petición GET a http://IP/test para solicitar la entidad xml, pero podemos modificar esta url para concatenarle consultas a la base de datos y exfiltrar su resultado de la siguiente forma:
Con lo que recibiremos en nuestro servidor una petición GET como la siguiente:
Los únicos inconvenientes que tiene esta técnica de exfiltración es que solo puede devolver el contenido de una celda con lo que tendremos que ser muy específicos en nuestras consultas, y que necesitamos disponer de un servidor accesible desde Internet. Esto sería un problema si lo hacemos a mano cada vez que nos encontráramos con esta vulnerabilidad, pero a quién le gusta hacer estas cosas a mano, ¿verdad?
Automatizando
Para automatizar el proceso de explotación, he creado un script que automatiza el proceso de generar los payloads, enviarlos e inicializar el servidor web para recibir las respuestas.
Por el momento solo soporta peticiones GET con headers y url personalizables. También permite no lanzar el servidor por si queremos recibir las peticiones en otro distinto. El programa tiene 4 niveles de output (o logging, para los entendidos): Info, Ok, Warning y Error.
La salida es tal que así:
Utiliza un listado externo de payloads, payloads.lst que podemos modificar a nuestro gusto o incluso indicar un archivo propio.
Conclusión
Lo de siempre, mantén actualizados tus sistemas, incluyendo la base de datos. ¡Puede marcar la diferencia!
Podéis encontrar el código fuente aquí.
(Las salidas de este post están simplificadas para no mostrar información sensible)
Bibliografia:
