cerrar-sesion editar-perfil marker video calendario monitor periodico fax rss twitter facebook google-plus linkedin alarma circulo-derecha abajo derecha izquierda mover-vertical candado usuario email lupa exito mapa email2 telefono etiqueta

RFD (Remote File Downlading) en aplicaciones web Parte I de II

Escrito por Redacción en Programación
no hay comentarios Haz tu comentario
Imagen de logotipo de facebook Imagen de logotipo de Twitter Imagen de Logotipo de Google+ Imagen de logotipo de Linkedin

El presente artA�culo es sA?lo eso, una pequeA�a vuelta de tuerca mA?s a las tA�cnicas de SQL Inyection para extraer, en este caso, ficheros del servidor dA?nde estA? instalado el motor de las bases de datos. Para que entendamos de que trata el trabajo tomemos el siguiente ejemplo: Supongamos un cliente A que se conecta a una aplicaciA?n web vulnerable a Blind SQL Injection B. Supongamos que esta aplicaciA?n vulnerable se conecta a un motor de base de datos que se ejecuta sobre el servidor C. Una vez entendido quien es A, quiA�n es B y quiA�n es C, la idea es tan sencilla como que ficheros de C sean descargados a A. Estos ficheros pueden ser tan famosos como boot.ini, la sam, /etc/passwd o tan anodinos como datos.dat.

En las dos partes que ocuparA? este trabajo se analizarA? en detalle cA?mo se puede perpetrar un RFD, es decir, una descarga remota de un fichero, utilizando Blind SQL Injection. Para ello se analizarA? la metodologA�a de trabajo, las caracterA�sticas de cada uno de los motores que se van a tratar, a saber: Microsoft SQL Server 2000, 2005 y 2008, Oracle versiones i y MySQL. AdemA?s, finalizaremos con un recorrido de las herramientas existentes y las opciones de fortificaciA?n y securizaciA?n del entorno. AsA� que, si te apetece descubrir cA?mo se hace, comencemos por el principio.

BooleanizaciA?n de datos

Para poder extraer informaciA?n de una base de datos mediante un ataque Blind SQL Injection es necesario ser capaz de evaluar las respuestas del sistema y definir una clasificaciA?n entre respuestas Verdaderas o Falsas. Las respuestas Verdaderas serA?n aquellas que corresponden al comportamiento de la aplicaciA?n web tras la ejecuciA?n de una consulta en la que se ha inyectado una condiciA?n lA?gica verdadera, por ejemplo: a�?and 1=1a�? y las respuestas Falsas corresponderA?n al comportamiento de la aplicaciA?n ante la ejecuciA?n de una consulta en la que se inyecta una lA?gica falsa, por ejemplo: a�?and 1=2a�?. Al proceso de formular el criterio de decisiA?n se le llama booleanizaciA?n, con independencia de cuA?l sea el aspecto del comportamiento de la aplicaciA?n a considerar para construir dicho criterio. Por tanto se llama booleanizaciA?n en referencia al hecho de interpretar de forma binaria las respuestas del sistema ante inyecciones de cA?digo (Ver Figuras 1, 2, 3).

Teniendo en cuenta el tipo de dato que se defina para cada parA?metro de la base de datos, la booleanizaciA?n de un dato de tipo numA�rico se realiza mediante el uso de comparaciones de tipo a�?mayor quea�? o a�?menor quea�? entre el dato que se intenta inferir y unos A�ndices de referencia. Implementando un algoritmo de bA?squeda binaria entre los lA�mites del tipo de datos se puede llegar a inferir el resultado sA?lo obteniendo respuestas Verdadero o Falso (Ver Figura 4).

Si el dato al que se desea acceder es de tipo alfanumA�rico, el proceso de booleanizaciA?n requiere que la inferencia se realice carA?cter a carA?cter, es decir, si el dato es de diez caracteres de longitud entonces el proceso consistirA? en repetir diez veces la inferencia de un carA?cter. Para realizar la inferencia de un carA?cter A�ste se transforma en su valor ASCII equivalente. Una vez convertido el carA?cter en un valor numA�rico su inferencia se realiza como se ha descrito en el proceso de booleanizaciA?n de datos numA�ricos. Por ejemplo, se supone que se desea extraer el valor del campo username de la vista all_users en un motor Oracle y este valor es a�?sysa�?. Teniendo en cuenta que el valor ASCII de la primera letra, es decir, la a�?sa�� es el 115, el proceso de booleanizaciA?n serA�a el siguiente:

255>(Select ASCII(Substr(username,1,1)) from all_users where rownum<=1 -> TRUE

128>(Select ASCII(Substr(username,1,1)) from all_users where rownum<=1 -> TRUE

64>(Select ASCII(Substr(username,1,1)) from all_users where rownum<=1 -> FALSE

96>(Select ASCII(Substr(username,1,1)) from all_users where rownum<=1 -> FALSE

112>(Select ASCII(Substr(username,1,1)) from all_users where rownum<=1 -> FALSE

120>(Select ASCII(Substr(username,1,1)) from all_users where rownum<=1 -> TRUE

116>(Select ASCII(Substr(username,1,1)) from all_users where rownum<=1 -> TRUE

114>(Select ASCII(Substr(username,1,1)) from all_users where rownum<=1 -> FALSE

115>(Select ASCII(Substr(username,1,1)) from all_users where rownum<=1 -> TRUE

En este punto se ha averiguado que el valor ASCII de la primera letra del nombre es 115 ya que no es mayor que 115 y es menor que 116. Y se pasarA�a a realizar el mismo proceso con la segunda letra. Se trata de un proceso iterativo, en ocasiones costoso, que finalmente permite obtener el resultado buscado.

Siempre y cuando no se haya habilitado un proceso de filtrado sobre los parA?metros que impida la inyecciA?n, la adaptaciA?n de estas tA�cnicas a los distintos tipos de datos es sA?lo una cuestiA?n de sintaxis. Ahora bien, si la inyecciA?n de cA?digo es posible cabe preguntarse hasta dA?nde es posible llegar en la extracciA?n de la informaciA?n del sistema que contiene la base de datos.

El tratamiento de ficheros en el servidor depende de cada motor de Bases de Datos que se estA� utilizando. Es necesario conocer el motor de base de datos y la versiA?n para intentar la descarga de ficheros mediante un proceso de booleanizaciA?n. Los motores de bases de datos modernos incorporan diferentes mecanismos para acceder a los ficheros del sistema operativo. Estos mecanismos, muy A?tiles en el desarrollo de aplicaciones, pueden volverse peligrosos si la configuraciA?n de seguridad en el motor de base de datos no es la adecuada.

En este artA�culo se verA? cA?mo explotar estos mecanismos en servidores de bases de datos Microsoft SQL Server, Oracle y MySQL indicando las posibilidades y pasos a seguir en cada uno de los motores, asA� como las restricciones de seguridad y permisos necesarios para que se pueda llevar a cabo.

Cualquiera que sea la tA�cnica utilizada para cargar el fichero al motor de base de datos, es al final, mediante la inferencia de los caracteres como se ha indicado anteriormente, la manera de leer el contenido completo del fichero. La posibilidad de leer ficheros binarios ademA?s de ficheros de texto dependerA? de las posibilidades que proporcione el motor de base de datos que se trata. Si el motor permite la carga de ficheros binarios, el proceso de booleanizaciA?n seguirA�a siendo el mismo, pues al final el valor de un byte puede ser comparado con a�?mayor quea�? o a�?menor quea�? y deducir el valor que almacena para pasar a grabarlo como un byte en un fichero, recuperando asA� el binario.

RFD (Remote File Downloading): MetodologA�a de Trabajo

Una vez que se han descrito los conceptos fundamentales para la extracciA?n de ficheros mediante la tA�cnica de booleanizaciA?n, es posible proponer una metodologA�a para la evaluaciA?n de la vulnerabilidad de una aplicaciA?n frente ataques de Blind SQL Injection para la extracciA?n de ficheros. La secuencia de pasos deberA�a ser la siguiente:

1. Comprobar que la aplicaciA?n es vulnerable a ataques de SQL injection. Para ello es preciso verificar que es posible realizar una inyecciA?n que no alterA� los resultados que devuelve la aplicaciA?n en su forma normal de trabajo, pero que demuestren la ejecuciA?n de los comandos. Un ejemplo serA�a sustituir un valor numA�rico por la llamada a la funciA?n ABS(). Si obtenemos el mismo resultado significa que se estA? ejecutando la funciA?n ABS, es decir, se puede inyectar cA?digo SQL.

2. Verificar si es posible realizar inyecciones que alteren el comportamiento durante la respuesta del sistema mediante inyecciones siempre verdaderas e inyecciones siempre falsas, como se ha visto en las imA?genes 1 a 3. Si es asA� entonces se concluye que la aplicaciA?n es vulnerable a ataques Blind SQL Injection.

3. Determinar una funciA?n error que permita distinguir cuA?ndo una inyecciA?n provoca una respuesta denominada verdadera y cuA?ndo provoca una respuesta falsa. En este punto las posibilidades dependen del tratamiento de errores que se haya realizado en la aplicaciA?n, siendo siempre posible reducir la formulaciA?n de la funciA?n error a una alternativa basada en tiempos de respuesta. Este paso determina como se van a reconocer las respuestas Verdaderas o Falsas. Puede hacerse por una cadena que aparezca en la respuesta positiva que no aparezca en las respuestas negativas, o viceversa, o mirando el tiempo respuesta, o la estructura HTML o el hash de la pA?gina, etca�� Es decir, reconocer las caracterA�sticas de las pA?ginas obtenidas en respuestas positivas y las caracterA�sticas de las pA?ginas obtenidas en respuestas negativas.

4. Seleccionar la estrategia a seguir para extraer ficheros del servidor. Existen dos posibilidades respecto a las fuentes de datos a utilizar: utilizar fuentes de datos externas, es decir, invocar directamente el fichero desde cada consulta o hacer uso de las opciones de carga masiva, es decir, volcar el fichero a una tabla y descargarlo de la tabla. En ambos casos se establece una fuerte dependencia con el motor de la base de datos que se estA� utilizando que hacen necesario la determinaciA?n de las funciones especA�ficas a usar.

5. Evaluar las limitaciones y entornos de permisos requeridos en cada caso. SerA? necesario determinar que privilegios son necesarios para poder utilizar en cada caso la fuente de datos seleccionada.

6. Implementar el proceso de extracciA?n del fichero mediante un proceso de booleanizaciA?n de datos.

Para el resto del artA�culo, vamos a suponer que se ha comprobado que la web es vulnerable y sabemos reconocer la respuesta positiva o True de la respuesta negativa o False. Vamos a analizar por tanto, como se realizarA�a la descarga remota de ficheros en los distintos motores de bases de datos.

RFD en Microsoft SQL Server 2000 y 2005 mediante fuentes de datos infrecuentes

Microsoft SQL Server permite utilizar fuentes de datos externas, o lo que es lo mismo, orA�genes de informaciA?n fuera del motor Microsoft SQL Server a los que se pueda acceder mediante cualquier OLE DB Data Provider. Un OLE DB Data Provider es un manejador de una fuente de informaciA?n que oferta un interfaz de acceso comA?n OLE DB a cualquier aplicaciA?n que lo utilice. Estas fuentes externas pueden ser servidores de bases de datos remotos del mismo o de distintos fabricantes o repositorios de informaciA?n que van desde ficheros Microsoft Excel, bases de datos Access, DBase, ficheros XML hasta ficheros de texto plano a�?txta�? o separados por comas a�?csva�?. De hecho, una fuente de datos externa podrA? ser cualquier fuente de informaciA?n accesible por un OLE DB Data Provider que el servidor tenga cargada y se convertirA? en un OLE DB Data Source, es decir, en una fuente de datos externa accesible mediante un OLE DB Data Provider.

El proceso de agregar fuentes de datos externas es una tarea de administraciA?n que se ejecuta mediante el enlazado de estos orA�genes. Este proceso se puede realizar utilizando la herramienta de administraciA?n o bien con el uso del procedimiento almacenado sp_addlinkedserver, sin embargo, Microsoft SQL Server permite realizar conexiones ad-hoc a fuentes de datos externas infrecuentes, es decir, a aquellos orA�genes de datos a los que se accede en contadas ocasiones. Para ello el lenguaje Transact-SQL de Microsoft SQL Server cuenta con dos comandos distintos. La funciA?n OpenRowSet que va a permitir acceder a cualquier fuente externa que devuelva un conjunto de registros y la funciA?n OpenDataSource, que permite lanzar una consulta sobre una fuente de datos externa enlazada ad-hoc.

En un entorno vulnerable a SQL Injection se permitirA�a acceder a ficheros del servidor que pudieran ser accesibles por un OLE DB Data Provider, y extraerlo mediante una tA�cnica de booleanizaciA?n. Por ejemplo, para extraer los datos de un fichero a�?c:\dir\target.txta�? en el servidor de bases de datos dA?nde se ejecuta el motor Microsoft SQL Server utilizado por una aplicaciA?n web vulnerable y explotable por Blind SQL Injection podrA�amos utilizar el un proceso de booleanizaciA?n sobre la siguiente inyecciA?n:

http://server/app.cod?param=1 and 256 > (ASCII(Substr(select * from OpenRowset(a�?MSDASQLa��, a�?Driver = Microsoft Text Driver (*.txt; *.csv);DefaultDir=C:\External;a��,a��select top 1 * from c:\dir\target.txta��),1,1))

En este ejemplo la inyecciA?n carga la primera fila del fichero target.txt, se queda con el valor ASCII de la primera letra y lo compara con el valor 256. Obviamente es una comparaciA?n que siempre darA? TRUE, pero ilustra cA?mo se debe realizar el proceso de booleanizaciA?n. Una vez descubierto el valor de la primera letra, el proceso se repetirA�a para las siguientes letras de la primera fila del fichero hasta que se llegarA? al final de la lA�nea dA?nde se deberA�a repetir el mismo proceso para las siguientes lA�neas del fichero hasta obtenerse el fichero completo.

En este caso, el driver Microsoft Text sA?lo permite acceder a ficheros con extensiones a�?txta�?, a�?csva�? o a�?taba�? por lo que nunca se podrA�a acceder con OpenRowSet u OpenDataSource a ficheros log, bak, old, o cualquier extensiA?n distinta. Sin embargo sA� es posible acceder a datos almacenados en ficheros Microsoft Office a�?mdba�?, a�?xlsa�?, o cualquier otro formato para el que el servidor tenga cargado un OLE DB Data Provider. Por ejemplo, para acceder a los datos de un fichero Microsoft Excel o a en un fichero Access almacenado en el servidor se podrA�a realizar consultas como las siguientes:

SELECT * FROM OPENROWSET (a�?Microsoft.Jet.OLEDB.4.0a��,a��Excel 8.0; DATABASE=c:\Excel.xlsa��,a��Select * from (Libro1$)a��)

SELECT * FROM OPENDATASOURCE (a�?Microsoft.Jet.OLEDB.4.0a��, a�?Data Source=a�?c:\Excel.xlsa�?; User ID=Admin; Password=;Extended properties=Excel 8.0a��)…Libro1

SELECT * FROM OPENDATASOURCE (a�?Microsoft.Jet.OLEDB.4.0a��,a��Data Source=a�?c:\ACCESS.mdba�?; User ID=Admin; Password=a��)…Tabla1

SELECT * FROM OPENROWSET (a�?Microsoft.Jet.OLEDB.4.0a��, a�?c:\Access.mdba��;a��admina��;a��a��, Tabla1)

En todos estos casos, como se puede apreciar en las consultas, no es un acceso directo al fichero sino a los datos almacenados en A�l y por tanto, es necesario conocer informaciA?n de la estructura de los datos. En los ejemplos se muestran datos de usuarios y contraseA�as, pero estos no serA�an necesarios si, como sucede en la gran mayorA�a de las ocasiones , los ficheros de Microsoft Access y Microsoft Excel no tiene habilitados explA�citamente un usuario y una contraseA�a.

Restricciones y permisos para uso de fuentes de datos infrecuentes

En los ejemplos de la secciA?n anterior, para poder trabajar con OPENDATASOURCE y OPENROWSET es necesario que la clave de registro DisallowAdhocAccess del proveedor que se va a utilizar estA� fijado a cero.

Las claves de registro donde se configuran los proveedores, entre ellos el proveedor Microsoft.Jet.OLEDB.4.0 visto en los ejemplos, se encuentran en la rama de registro, si se trata de una instancia sin nombre:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Providers

O en caso de que se trate de instancias con nombre en:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\\Providers

Si la clave de registro no existe, el comportamiento varA�a segA?n los privilegios del usuario que se conecta a la base de datos ya que si el usuario posee el rol a�?Server Administratorsa�? tendrA? permitido el acceso mientras que si por el contrario el usuario no posee este rol tendrA? denegado el acceso.

Por defecto el proveedor Microsoft.Jet.OLEDB.4.0 no establece la clave de registro DisallowAdhocAccess y por lo tanto impedirA? el acceso a fuentes de datos externas salvo que el usuario posea el rol a�?Server Administratorsa�?.

Estas son las A?nicas restricciones a la hora de utilizar OPENDATASOURCE y OPENROWSET, los permisos de acceso sobre los ficheros Microsoft Excel o Access vendrA?n determinados por los permisos del usuario que se le pase al proveedor OLE DB.

En Microsoft SQL Server 2005 ademA?s, el acceso a fuentes de datos externos esta desactivado por defecto como parte de la configuraciA?n de Seguridad, para modificar esta configuraciA?n una administrador puede utilizar el procedimiento almacenado sp_configure o la herramienta de administraciA?n Surface Area Configuration for Features y habilitar las consultas Ad hoc (Ver Figura 5).

ExtracciA?n de ficheros

Si se cumplen todos los requisitos necesarios del entorno bastarA�a aplicar un proceso de booleanizaciA?n como el descrito en el apartado 3 mediante la inyecciA?n de una llamada al fichero que se quiere acceder como si fuera una fuente de datos infrecuentes. AsA�, la inyecciA?n SQL quedarA�a de la siguiente forma:

http://server/app.cod?param=1 and 256 > (ASCII(Substr(select * from OpenRowset(a�?MSDASQLa��, a�?Driver = Microsoft Text Driver (*.txt; *.csv);DefaultDir=C:\;a��,a��select top 1 * from c:\dir\target.txta��),1,1))

Como se puede ver se estA? accediendo al fichero a�?c:\dir\target.txta�?. Este serA? cargado entero como una A?nica cadena alfanumA�rica que va a ser recorrida durante el proceso de booleanizaciA?n con la funciA?n substring. Cada carA?cter va a ser convertido a su valor ASCII y comparado con un A�ndice para averiguar el valor correcto. Una vez llegado al final del substring se habrA? terminado de acceder al fichero completo.

RFD en Microsoft SQL Server 2000 mediante opciones de carga masiva

En Microsoft SQL Server 2000 se permite la carga de ficheros registros de una o varias tablas mediante las operaciones de carga masiva. Existen tres formas distintas para realizar la carga masiva de datos desde ficheros. La primera opciA?n es utilizar el comando bcp a nivel del sistema operativo, la segunda opciA?n consiste en realizar un Insert desde una fuente de datos cargada con OpenRowSet como se ha visto en el apartado anterior y la tercera mediante el uso del comando Bulk Insert. Esta A?ltima opciA?n es la que un atacante puede utilizar para acceder a ficheros a los que no puede acceder mediante el uso de fuentes de datos externas infrecuentes por no existir un OLE DB Data Provider para ellos.

Restricciones y permisos

Para la creaciA?n de tablas es necesario tener como rol en la base de datos db_owner o db_ddladmin, es decir ser el propietario de la misma o tener permisos de administraciA?n.

Es cierto que es posible crear tablas temporales, visibles solo durante la sesiA?n en curso (#TablaTemporal) o tablas temporales globales, visibles desde todas las sesiones (##TablaTemporal), y que para la creaciA?n de estas tablas no es necesario poseer los roles de bases de datos db_owner y db_ddladmin.

Sin embargo, a la hora de realizar a�?bulk inserta�? es necesario que el usuario que ejecuta dicha sentencia, ademA?s de poseer el rol de Servidor bulkadmin, debe poseer el rol a nivel de base de datos db_owner o db_ddladmin para poder insertar sobre la tabla, y por lo tanto el uso de tablas temporales no tiene sentido.

En cuanto a la consideraciA?n de a que archivos se tiene acceso y a cuales no, esto dependen del perfil de seguridad del proceso SQL Server. Dado que el usuario es miembro de la funciA?n fija de Servidor bulkadmin, el usuario tiene acceso de lectura a todos aquellos archivos a los que el SQL Server puede acceder aunque A�l no tuviese concedidos esos permisos.

Proceso de la extracciA?n del fichero

En este caso son necesarias cinco fases para la extracciA?n del fichero del sistema operativo. La primera fase consistirA? en la creaciA?n de una tabla temporal para almacenar los datos del fichero. Una segunda fase en la que el fichero se carga dentro de la tabla temporal. La tercera implica la creaciA?n de una columna IDENTITY. Una cuarta fase de extracciA?n mediante la booleanizaciA?n de los datos almacenados en esa tabla. Una A?ltima fase para eliminar la tabla temporal creada dentro de la base de datos.

Fase 1.a�� CreaciA?n de una tabla temporal: En esta fase, se utiliza el parA?metro inyectable para lanzar una consulta de creaciA?n de la tabla temporal como sigue:

http://server/app.cod?param=1; Create Table TablaTemporal as (fila varchar(8000))a��

Fase 2.a�� Carga del fichero dentro de una tabla temporal:

Se debe poder ejecutar dentro del servidor un comando Bulk Insert. La inyecciA?n en un servidor vulnerable serA�a como sigue:

http://server/app.cod?param=1; Bulk Insert TablaTemporal From a�?c:\fichero.exta�� With (FIELDTERMINATOR = a�?\na��, ROWTERMINATOR = a�?\na��)a��

Como se puede apreciar en el ejemplo anterior el comando Bulk insert tiene una serie de parA?metros para indicar cuA?les son los caracteres separadores de campos y de fila. En este caso se ha utilizado el retorno de carro como carA?cter delimitador de campo y de fila.

Fase 3.a�� CreaciA?n de una columna IDENTITY: Una vez cargado el contenido del fichero sobre la tabla, se tiene una tabla con una sola columna y tantas filas como lA�neas tuviese el fichero, para poder leer correctamente esta tabla en un proceso de booleanizaciA?n serA�a necesario contar con un identificador A?nico para cada registro de la tabla.

Para crear los identificadores A?nicos lo que se hace es aA�adir una columna de tipo IDENTITY, configurada con valor de inicio 1 e incrementos unitarios, de modo que SQL Server 2000 se encarga de asignarle el valor numA�rico correspondiente a cada registro. La inyecciA?n en un servidor vulnerable serA�a:

http://server/app.cod?param=1; alter table TablaTemporal add num int IDENTITY(1,1) NOT NULLa��

Es muy importante destacar que este paso es necesario hacerlo aquA�, si se especifica esta columna durante la creaciA?n de la tabla en el paso 1, la carga del fichero sobre la misma no se realiza de forma correcta, por eso es necesario aA�adir la columna una vez cargada la tabla con la informaciA?n del fichero

Fase 4.a�� Proceso de BooleanizaciA?n: Como resultado de los pasos anteriores se tiene una tabla con dos columnas, cuyos registros se corresponden con las lA�neas del fichero que se ha leA�do, para poder descargar el fichero es necesario determinar cuA?ntas filas tiene la tabla. Para determinar el nA?mero de registros se utiliza Blind SQL Injection con un proceso de bA?squeda binaria, la sentencia tipo a inyectar en un servidor vulnerable serA�a:

http://server/app.cod?param =1 and (select COUNT(fila) from TablaTemporal) > 255 a��

Una vez fijado el nA?mero de registros que tiene la tabla, por cada uno de estos se calcularA�a el nA?mero de caracteres de la columna fila, que serA�an los que habrA�a que leer mediante un proceso de booleanizaciA?n. Siguiendo el ejemplo visto, la sentencia a inyectar en un servidor vulnerable para determinar el nA?mero de caracteres de la primera lA�nea del fichero serA�a:

http://server/app.cod?param=1 and (select top 1 len(fila) from TablaTemporal where num = 1) > 255 a��

De nuevo es necesario establecer un sistema de bA?squeda binaria, para inferir la longitud del campo fila del registro, obsA�rvese que en esta sentencia se hace uso de la columna IDENTITY creada anteriormente, y que sirve para identificar cada uno de los registros de la tabla y por tanto cada una de las filas del fichero.

Una vez determinados el nA?mero de filas y el nA?mero de caracteres, el siguiente paso es inferir los caracteres de la fila. Siguiendo los ejemplos anteriores la cadena a inyectar serA�a:

http://server/app.cod?param=1 and (select top 1 ASCII(SUBSTRING(fila,1,1)) from TablaTemporal where num = 1) > 255 a��

En esta cadena se estA? infiriendo el primer carA?cter de la primera fila de la tabla, como se ha averiguado el nA?mero de filas y para cada fila se averigua el nA?mero de caracteres es posible fijar los valores a utilizar para descargar el contenido completo del fichero.

Fase 5.a�� EliminaciA?n de la tabla Temporal: Por A?ltimo, se procederA? a eliminar la tabla temporal creada en la base de datos como sigue:

http://server/app.cod?param=1; Drop Table TablaTemporala��

RFD en Microsoft SQL Server 2005 mediante opciones de carga masiva

Una de las mejoras de transact-sql introducidas en Microsoft SQL Server 2005 es la posibilidad de realizar importaciones masivas llamando a OPENROWSET y especificando la opciA?n BULK. De este modo se puede conseguir lo mismo que se obtiene al utilizar bulk insert (tambiA�n disponible en SQL Server 2005), pero sin necesidad de utilizar tablas temporales donde almacenar el contenido de los ficheros. La sintaxis bA?sica de la instrucciA?n serA�a la siguiente:

INSERT … SELECT * FROM OPENROWSET(BULK…)

AsA�, si se quiere leer el contenido de un fichero se utilizarA�a una sentencia transact-sql como la siguiente:

SELECT * FROM OPENROWSET(BULK a�?c:\file.txta��, SINGLE_CLOB) As Datos

Al utilizar la opciA?n bulk se especifica el fichero a leer y opcionalmente se especifica el tipo de columna donde se va a colocar el dato leA�do, los posibles valores son:

a�� SINGLE_BLOB: Especifica que los datos se van a almacenar en una columna varbinary(max)

a��SINGLE_CLOB: Para especificar que los datos ASCII se almacenan en una columna varchar(max)

a��SINGLE_NCLOB: Para datos UNICODE que serA?n importados a una columna nvarchar(max)

La definiciA?n de tipos varbinay(max), varchar(max) y nvarchar(max) es una novedad de Microsoft SQL Server 2005, y se utiliza para permitir el almacenamiento de grandes cantidades de datos, la longitud de estos tipos de datos van desde 1 byte hasta los 2 GB

En SQL Server 2005 es posible descargar tanto ficheros de texto como ficheros binarios, para cargar ficheros binarios se utilizarA? la opciA?n bulk con el valor SINGLE_BLOB y para ficheros de texto se puede utilizar el valor SINGLE_CLOB

Restricciones y permisos

Al igual que sucede en Microsoft SQL Server 2000 para poder realizar importaciones masivas es necesario tener el rol de Servidor bulkadmin, como no es necesario crear tablas en la base de datos no es necesario tener ningA?n role especial a nivel de base de datos.

En cuanto a los ficheros a los cuales se puede tener acceso, Microsoft SQL Server 2005 soluciona los problemas que presentaba Microsoft SQL Server 2000 y versiones anteriores. En esta versiA?n el acceso depende de cA?mo se haya iniciado la sesiA?n en el Servidor Microsoft SQL Server.

a�� Si se ha utilizado un inicio de sesiA?n SQL Server, se utilizara el perfil de seguridad de la cuenta de proceso de SQL Server, y por lo tanto se tendrA? acceso a los ficheros que esta cuenta pueda leer.

a�� Si se ha utilizado un inicio de sesiA?n mediante la autenticaciA?n de Windows, el usuario solo tiene acceso para aquellos archivos para los que la cuenta del usuario tiene permiso, independientemente de los permisos que tenga la cuenta de proceso SQL Server. Para ello se utilizan las credenciales del usuario, a esto se le denomina suplantaciA?n o delegaciA?n.

Proceso de la extracciA?n del fichero

En primer paso lA?gico a seguir es calcular el tamaA�o en bytes del fichero. Para calcularlo es necesario cargar el contenido del fichero usando OPENROWSET(BULK a��) y utilizar la funciA?n DATALENGTH, para inferir mediante bA?squeda binaria el tamaA�o del mismo. Una posible sentencia a inyectar en un servidor vulnerable para calcular el tamaA�o serA�a:

http://server/app.cor?param=1 and DATALENGTH((SELECT * FROM OPENROWSET(BULK a�?c:\Helloworld.exea��, SINGLE_BLOB) As Datos)) > 255 a��

Una vez determinado el tamaA�o del fichero, el proceso de booleanizacion queda reducido a consultas que recuperan los diferentes bytes e infieren su valor, una posible sentencia a utilizar serA�a:

http://server/app.cod?param=1 AND 256 > ASCII(SUBSTRING ((SELECT * FROM OPENROWSET(BULK a�?c:\Helloworld.exea��, SINGLE_BLOB) As Datos), 1, 1))a��

Y en la prA?xima parte de este artA�culo

Hasta el momento se ha visto como es posible extraer ficheros de servidores utilizando aplicaciones web vulnerables a Blind SQL Injection en los entornos Microsoft SQL Server 2000 y Microsoft SQL Server 2005. En el prA?ximo artA�culo se verA? cA?mo funcionan las tA�cnicas RFD en Microsoft SQL Server 2008, en entornos Oracle y con motores de bases de datos MySQL. AdemA?s, le dedicaremos una parte fundamental a las herramientas de extracciA?n de ficheros de forma automatizada. A?Te lo quieres perder? i??

Chema Alonso, MVP Corporate Security. InformA?tica64.

http://elladodelmal.blogspot.com

Alejandro MartA�n BailA?n. InformA?tica64.

Antonio GuzmA?n SacristA?n. Universidad Rey Juan Carlos de Madrid. 

Etiquetas

Noticias relacionadas

Comentarios

No hay comentarios.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Debes haber iniciado sesión para comentar una noticia.