RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (I de VI)

*************************************************************************************************
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (I/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (II/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (III/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (IV/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (V/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (VI/VI)
*************************************************************************************************

El presente artículo es sólo una pequeña vuelta de tuerca más a las técnicas de SQL Inyection para extraer, en este caso, ficheros del servidor dónde está 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 aplicación web vulnerable a Blind SQL Injection B. Supongamos que esta aplicación vulnerable se conecta a un motor de base de datos que se ejecuta sobre el servidor C. Una vez entendido quién es A, quién es B y quié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 partes que ocupará este trabajo se analizará en detalle cómo se puede perpetrar un RFD, es decir, una descarga remota de un fichero, utilizando Blind SQL Injection. Para ello se analizará la metodología de trabajo, las caracterí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 "g" y MySQL. Además, finalizaremos con un recorrido de las herramientas existentes y algunas opciones de fortificación y securización del entorno. Así que, si te apetece descubrir cómo se hace, comencemos por el principio.

Booleanización de datos

Para poder extraer informació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 clasificación entre respuestas Verdaderas o Falsas. Las respuestas Verdaderas serán aquellas que corresponden al comportamiento de la aplicación web tras la ejecución de una consulta en la que se ha inyectado una condición lógica verdadera, por ejemplo: “and 1=1” y las respuestas Falsas corresponderán al comportamiento de la aplicación ante la ejecución de una consulta en la que se inyecta una lógica falsa, por ejemplo: “and 1=2”. Al proceso de formular el criterio de decisión se le llama booleanización, con independencia de cuál sea el aspecto del comportamiento de la aplicación a considerar para construir dicho criterio.

Teniendo en cuenta el tipo de dato que se defina para cada parámetro de la base de datos, la booleanización de un dato de tipo numérico se realiza mediante el uso de comparaciones de tipo “mayor que” o “menor que” entre el dato que se intenta inferir y unos índices de referencia. Implementando un algoritmo de búsqueda binaria entre los límites del tipo de datos se puede llegar a inferir el resultado sólo obteniendo respuestas Verdadero o Falso.

Si el dato al que se desea acceder es de tipo alfanumérico, el proceso de booleanización requiere que la inferencia se realice carácter a carácter, es decir, si el dato es de diez caracteres de longitud entonces el proceso consistirá en repetir diez veces la inferencia de un carácter. Para realizar la inferencia de un carácter éste se transforma en su valor ASCII equivalente. Una vez convertido el carácter en un valor numérico su inferencia se realiza como se ha descrito en el proceso de booleanización de datos numé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 “sys”. Teniendo en cuenta que el valor ASCII de la primera letra, es decir, la ‘s’ es el 115, el proceso de booleanización serí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 pasarí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.

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

RFD (Remote File Downloading): Metodología de Trabajo

Una vez que se han descrito los conceptos fundamentales para la extracción de datos mediante la técnica de booleanización es posible proponer una metodología para la evaluación de la vulnerabilidad de una aplicación frente ataques de Blind SQL Injection para la extracción de ficheros. La secuencia de pasos debería ser la siguiente:

1. Comprobar que la aplicación es vulnerable a ataques de SQL injection. Para ello es preciso verificar que es posible realizar una inyección que no alteré los resultados que devuelve la aplicación en su forma normal de trabajo, pero que demuestren la ejecución de los comandos. Un ejemplo sería sustituir un valor numérico por la llamada a la función ABS(). Si obtenemos el mismo resultado significa que se está ejecutando la función ABS, es decir, se puede inyectar có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 imágenes 1 a 3. Si es así entonces se concluye que la aplicación es vulnerable a ataques Blind SQL Injection.

3. Determinar una función error que permita distinguir cuándo una inyección provoca una respuesta denominada verdadera y cuándo provoca una respuesta falsa. En este punto las posibilidades dependen del tratamiento de errores que se haya realizado en la aplicación, siendo siempre posible reducir la formulación de la funció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 página, etc… Es decir, reconocer las características de las páginas obtenidas en respuestas positivas y las características de las pá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 esté utilizando que hacen necesario la determinación de las funciones específicas a usar.

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

6. Implementar el proceso de extracción del fichero mediante un proceso de booleanización de datos.

Para el resto del artí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 realizaría la descarga remota de ficheros en los distintos motores de bases de datos.

*************************************************************************************************
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (I/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (II/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (III/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (IV/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (V/VI)
RFD [Remote File Downloading] en aplicaciones web con Blind SQL Injection (VI/VI)
*************************************************************************************************