Técnicas Avanzadas en ataquesBlind SQL Injection (Parte III de III)

***************************************************************************************
Artículo publicado en PCWorld Noviembre 2007:
- Técnicas Avanzadas en ataques Blind SQL Injection (I de III)
- Técnicas Avanzadas en ataques Blind SQL Injection (II de III)
- Técnicas Avanzadas en ataques Blind SQL Injection (III de III)
***************************************************************************************

Extracción de ficheros mediante técnicas de Blind SQL Injection

Hasta el momento hemos visto que mediante las técnicas de Blind SQL Injection es posible consultar todos los objetos del motor de la base de datos a los que los privilegios de la cuenta que se utiliza en la aplicación web permita. Esto, como hemos visto a lo largo de los anteriores artículos y en este mismo se puede realizar comprobando las páginas de resultados ante inyecciones o midiendo el tiempo. Sin embargo, esto es aún más peligroso. Con la herramienta mysqlget se vio como era posible traerse un fichero del sistema operativo mediante un ataque Blind SQL Injection. Esta herramienta permitía realizarlo utilizando bases de datos MySQL pero hoy vamos a verlo también funcionando con Microsoft SQL Server 2005.

¿Cómo extraer un fichero del sistema operativo? En primer lugar es absolutamente necesario que el usuario que identifica al motor de bases de datos dentro del servidor tenga acceso a ese fichero. Una buena fortificación del sistema debería impedir que ese usuario accediese a ficheros de otra parte del sistema. En segundo lugar para hacerlo el sistema debe proporcionar una herramienta para cargar el fichero en memoria y a partir de ahí utilizarlo como elemento de comparación de una claúsula where.

MySQL

En motores MySQL se utiliza la función LOAD_FILE que recibe como parámetro la ruta de un fichero en hexadecimal. Una vez cargado funcionará como una cadena de caracteres a la que podremos realizar funciones de comparación con valores ASCII. Supongamos en el ejemplo que un atacante desea obtener el fichero c:\boot.ini de un sistema MySQL sobre Windows con una vulnerabilidad de Blind SQL Injection. El ataque que realizaría sería el siguiente:

Se convierte c:\boot.ini a su representación hexadecimal: 0x633A5C626F6F742E696E69 y se realiza la inyección. La condición será True, si la primera letra del fichero corresponde con el carácter ASCII 1.

- http://www.servidor.com/prog.php?id=1 and mid(Load_File(0x633A5C626F6F742E696E69),1,1)=CHAR(1)

A partir de este momento se realizaría un recorrido por todos los valores posibles del alfabeto hasta que se llegue al final de fichero. Esta técnica es muy lenta, hay que tener en cuenta que por cada petición se está obligando al servidor a cargar un fichero en memoria y componer una consulta con él. Sin embargo, ha resultado ser funcional y la herramienta mysqlget de las SQLbfTools implementa este método.

Microsoft SQL Server 2005

Un método similar se puede implementar en las versiones de Microsoft SQL Server 2005. Para ello se utilizan la función OpenRowset en combinación con la función BULK.

Esto permite cargar el fichero en memoria como una secuencia de caracteres (SINGLE_CLOB) en un único registro con un único campo. Esto permitiría al atacante realizar un proceso de inyección como el que se muestra en el siguiente ejemplo:

- http://www.servidor.com/prog.php?id=1 and ASCII(Substring((Select * From OpenRowset(BULK 'c:\boot.ini', SINGLE_CLOB) As Datos), $numCaracter, 1)) > $numAscii

Dónde las variables $numCaracter y $numAscii son las que indicarían el carácter que se está intentando averiguar y el valor ASCII que se está probando.
Realizada una prueba de concepto con un pequeño Script en C# se obtiene el fichero deseado como se puede ver en la siguiente captura:

Imagen: c:\boot.ini descargado a través de un ataque Blind SQL Injection en base a errores
Contramedidas

Para que se pueda realizar este ataque el usuario con el que la aplicación se conecta al motor de base de datos tiene que tener permisos de bulkadmin. Estos permisos no se conceden a los usuarios por defecto, pero sí que lo tienen los usuarios administradores. Hay que evitar el uso de este permiso si en caso de no ser absolutamente necesario. Además, los ficheros a los que se van a poder acceder mediante este ataque dependerán de los privilegios con los que se ejecute el motor de bases de datos Microsoft SQL Server 2005.

Conclusiones finales

Las técnicas de Blind SQL Injection, vistas en este artículo y los artículos anteriores siguen sustentándose en fallos de validación de los parámetros que recoge la aplicación. Todas las amenazas, todos los ataques y todos los riesgos son evitables simplemente realizando un filtrado de los parámetros recibidos que van a ser utilizados en las consultas SQL. Quiero resaltar el hecho de que hasta el momento nos hemos centrado en fallos de validación de datos que vienen desde el cliente, pero las comprobaciones deben realizarse hasta de los datos que se reciben de la base de datos, si estos van a ser utilizados en nuevas consultas a bases de datos. De este hecho hizo una demostración muy interesante Alexander Kornbrust en la que demostraba como era posible inyectar código malicioso en los nombres de los objetos creados en bases de datos Oracle en una presentación titulada “Hacking hardened Oracle Databases”.

Herramientas de Análisis de Código Estático

Me gustaría hacer énfasis en la necesidad de utilizar herramientas de análisis de vulnerabilidades automáticas, pues aunque se cuente con un equipo de desarrolladores bien formados siempre son de ayuda. FxCop que es una herramienta gratuita para .NET o Code Analysis que viene incorporada en Visual Studio Team System son soluciones que detectan este tipo de vulnerabilidades en códigos fuente para desarrollos .NET y muchas otras, pero existen soluciones para todos o casi todos los lenguajes de desarrollo de similares prestaciones. Tienes una lista de las herramientas disponibles en la siguiente URL: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Imagen: Fxcop
Como dice Michael Howard de Microsoft, “All input is evil, until it proven otherwise”.

Referencias

- Time-Based Blind SQL Injection with heavy queries
- Importing Data using Bulk Insert or Openrowset(bulk)
- SQLBfTools (mysqlget)
- FxCop
- Hacking Hardened Databases

***************************************************************************************
Artículo publicado en PCWorld Noviembre 2007:
- Técnicas Avanzadas en ataques Blind SQL Injection (I de III)
- Técnicas Avanzadas en ataques Blind SQL Injection (II de III)
- Técnicas Avanzadas en ataques Blind SQL Injection (III de III)
***************************************************************************************