lunes, diciembre 17, 2007

Técnicas Avanzadas en ataques
Blind 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)
***************************************************************************************

14 comentarios:

  1. Seguramente ya te hayas dado cuenta, pero no nos permite entrar en la web del reto, "Error en tiempo de ejecución" :(

    ResponderEliminar
  2. Sí, Thesur, en unos minutos estará... disculpen las molestias ;)

    ResponderEliminar
  3. Estaba yo que adivinaba todo esto para la segunda parte sí :P

    Cuando esté el solucionario poned también los scripts ;)

    Fdo: analfabeto en programación :))

    ResponderEliminar
  4. Ahora la web me carga sin problemas, pero me da "error en tiempo de ejecucion" al logearme en mi cuenta, además de que me envia a nivel1.aspx.

    ¿Me pasa solo a mi?

    /Thesur

    ResponderEliminar
  5. Está en ello Alex, esta noche se había ido la luz. 1 sg y estará.

    Saludos!

    ResponderEliminar
  6. Maligno, muy interesante el tercer y ultimo articulo de la serie.

    Estoy jugando con un juguete de OSWAP llamado WebGoat para enseñar a los taruguetes.

    Aunque estoy intentando digerir el RFC2616 ,en inglés :-( que creo que me valdrá, estoy buscando información a poder ser en castellano sobre 'HTTP Splitting', Como sería su traducción a nuestra lengua: 'Inyecciones HTML'???.

    Por cierto, has oído hablar de cursohacker.com que lo imparten unos chavales de Uruguay? Que tal?

    Gracias y enhorabuena!!

    ResponderEliminar
  7. A mi también me envía otra vez al nivel1, yo que estaba intentando traducir al castellano la inscripción del diente del mono... XD. Cuando este solucionado avisar.

    ResponderEliminar
  8. Perdonad por los problemas que hemos tenido esta mañana, SealTeam ya estas colocado en el nivel adecuado

    Si alguno mas habeis tenido problemas indicarmelo, no me hagais trampas que me reviso los logs ;)

    Gracias y animo que todavia quedan regalos

    Alex

    ResponderEliminar
  9. Que rapidez, así da gusto.
    Bueno, ya que estamos...me presento. Me acabo de pasar "al lado del mal" gracias a Chema y la exposición que hizo en Valladolid (Ya conocía ciertos métodos, pero no que hacíais retos), así que aquí estoy dispuesto a dar guerra.

    P.D. Me he atrancado en el nivel 2 :(

    ResponderEliminar
  10. SealTeam eres de Valladolid?
    Sólo estaba yo (o eso creo) de esta provincia, un abrazo!

    ResponderEliminar
  11. Ya van estando todos...

    1 Kachakil 15/12/2007 18:55:45
    2 romansoft 16/12/2007 20:33:49
    3 palako 17/12/2007 8:34:03
    4 bambu 17/12/2007 9:04:50
    5 m4nd1ng0 17/12/2007 14:11:39

    Pedro Laguna está currando en Valladolid... pobre... me voy a hinchar a cervezas!!

    ResponderEliminar
  12. Es agradable conocer a alguien de mi ciudad, pero ¿eres de aqui o solo estas currando aqui?.
    Ya se a quien invitar a cervezas para conseguir ayuda cuando me atranque en los retos :P

    ResponderEliminar
  13. A mi también me había vuelto a dejar en el nivel1, pero no te preocupes, ya lo tengo de nuevo en el 2.

    enhorabuena por el reto... está super currao... enhorabuena a los merecidos pájaros ganadores... Y sobre todo, enhorabuena al Rodol que se ha pegado una currada de diseño impresionante!!!

    ResponderEliminar
  14. @anónimo,

    el http splitting se aprovecha de los servicios de redirección inyectando dos redirecciones en la URL a redireccionar. LA gente de Securiteam lo cuenta muy bien.

    HTTP Redirect Splitting

    Saludos!!

    ResponderEliminar