****************************************************************************************************
- Inverted SQL queries (I de II)
- Inverted SQL queries (II de II)
****************************************************************************************************
En el Reto Hacking X, en la primera fase, muchos sufrieron lo indecible con la jugada de poner la consulta SQL al revés, pero lo cierto es que tan válida es una como la otra. Que un programador decida poner primero el valor y luego la variable es tan correcto como poner primero la variable y luego el valor. Si hemos de ser justo, es tan correcto como estéticamente malo.
Tras ver como sufrían los pobres jugadores del reto, decidimos que era hora de hacer sufrir a los scanners de vulnerabilidades y enfrentamos a todos ellos antes un reto sencillo. Detectar una Blind SQL Injection invertido.
La idea es tener una consulta vulnerable a Blind SQL Injection como es la siguiente, a la que llamaremos “normal”:
Normal -> “Select * from noticias where id=”+get(ID)+”;”
Y convertirla en una consulta invertida como la siguiente, a la que, por razones obvias, llamaremos invertida.
Invertida -> “Select * from noticias where ”+get(ID)+”=id;”
Para hacer estas pruebas utilizamos una conexión con la cuenta “sa”, con password “sa” sobre un SQL Server y lanzamos varios de los más conocidos web vulnerability scanners contra la aplicación teniendo la consulta Normal y después con la consulta Invertida. Estos son los resultados.
Acunetix Web Vulnerability Scanner
Utilizamos una edición NFR (Nor For Resale) de la herramienta, que amablemente nos cedieron, de la última versión del producto. Con la consulta normal Acunetix Web Vulnerability Scanner, la detección es rápida y directa, pero la invertida no es detectada.
Consulta Normal detectada
Consulta Invertida NO detectada
IBM Rational APPScan
Para realizar esta prueba usamos una versión demo de la herramienta. Dicha versión demo sólo puede ser usada contra el sitio web demo.testfire.net, que se encuentra en la dirección IP 65.61.137.117, pero... suponiendo que los resultados de allí iban a ser muy buenos, decidimos hacer un entorno de pruebas y nos montamos nuestro propio demo.testfire.net en esa misma IP en un entorno de laboratorio al que calzamos la página de preubas con la consulta Normal y la consulta Invertida.
APPScan detectó bien la vulnerabilidad en la consulta normal, pero falló al enfrentarse con la consulta Invertida.
Consulta Normal detectada
Consulta Invertida NO detectada
Paros Web Application Security
Los resultados obtenidos con Paros Web Application Security fueron similares a los obtenidos con los otros dos scanners anteriores, es decir, detecta la vulnerabilidad Normal, pero falla al detectar la vulnerabilidad invertida.
Consulta Normal detectada
Consulta Invertida NO detectada
Saludos Malignos!
****************************************************************************************************
- Inverted SQL queries (I de II)
- Inverted SQL queries (II de II)
****************************************************************************************************
- Inverted SQL queries (I de II)
- Inverted SQL queries (II de II)
****************************************************************************************************
En el Reto Hacking X, en la primera fase, muchos sufrieron lo indecible con la jugada de poner la consulta SQL al revés, pero lo cierto es que tan válida es una como la otra. Que un programador decida poner primero el valor y luego la variable es tan correcto como poner primero la variable y luego el valor. Si hemos de ser justo, es tan correcto como estéticamente malo.
Tras ver como sufrían los pobres jugadores del reto, decidimos que era hora de hacer sufrir a los scanners de vulnerabilidades y enfrentamos a todos ellos antes un reto sencillo. Detectar una Blind SQL Injection invertido.
La idea es tener una consulta vulnerable a Blind SQL Injection como es la siguiente, a la que llamaremos “normal”:
Normal -> “Select * from noticias where id=”+get(ID)+”;”
Y convertirla en una consulta invertida como la siguiente, a la que, por razones obvias, llamaremos invertida.
Invertida -> “Select * from noticias where ”+get(ID)+”=id;”
Para hacer estas pruebas utilizamos una conexión con la cuenta “sa”, con password “sa” sobre un SQL Server y lanzamos varios de los más conocidos web vulnerability scanners contra la aplicación teniendo la consulta Normal y después con la consulta Invertida. Estos son los resultados.
Acunetix Web Vulnerability Scanner
Utilizamos una edición NFR (Nor For Resale) de la herramienta, que amablemente nos cedieron, de la última versión del producto. Con la consulta normal Acunetix Web Vulnerability Scanner, la detección es rápida y directa, pero la invertida no es detectada.
Consulta Normal detectada
Consulta Invertida NO detectada
IBM Rational APPScan
Para realizar esta prueba usamos una versión demo de la herramienta. Dicha versión demo sólo puede ser usada contra el sitio web demo.testfire.net, que se encuentra en la dirección IP 65.61.137.117, pero... suponiendo que los resultados de allí iban a ser muy buenos, decidimos hacer un entorno de pruebas y nos montamos nuestro propio demo.testfire.net en esa misma IP en un entorno de laboratorio al que calzamos la página de preubas con la consulta Normal y la consulta Invertida.
APPScan detectó bien la vulnerabilidad en la consulta normal, pero falló al enfrentarse con la consulta Invertida.
Consulta Normal detectada
Consulta Invertida NO detectada
Paros Web Application Security
Los resultados obtenidos con Paros Web Application Security fueron similares a los obtenidos con los otros dos scanners anteriores, es decir, detecta la vulnerabilidad Normal, pero falla al detectar la vulnerabilidad invertida.
Consulta Normal detectada
Consulta Invertida NO detectada
Saludos Malignos!
****************************************************************************************************
- Inverted SQL queries (I de II)
- Inverted SQL queries (II de II)
****************************************************************************************************
¿Me lo vas a contar a mi? Muchas pruebas enrevesadas para que después fuera algo tan sencillo como cambiar el orden de las proposiciones en la clausula.
ResponderEliminarYa comenté en la solución III mi idea... Que ni por asomo se parecía a la solución.
Muy interesante el resultado de las pruebas. Espero impaciente la parte II.
Nadie se podía imaginar que un programador fuera tan retorcido como para hacer la comparación "al revés"... El reto era irresoluble sin pistas (siendo en modo "blind"), e incluso con ellas, el método (poco ortodoxo) era acabar acertando medio de churro la inyección (a base de pruebas y pruebas) y luego buscar la explicación (lo cual es sencillo, una vez tienes lo primero).
ResponderEliminarPero el razonamiento lógico (primero analizar, luego inyectar) era imposible puesto que era todo en blind. De hecho, ni siquiera sabías si había inyección ahí, ni de qué tipo.
Para que esta prueba hubiera sido técnica de verdad deberíais haber dejado ver los errores de SQL. Parece un pequeño matiz pero le da totalmente la vuelta a la tortilla.
PD: ¿y ese libro de Howards?!!!! Ya tardas en mirar la "mvp-m$ store" :P
-r
Estoy totalmente de acuerdo con lo que comenta RoMaNSoFt sobre el reto, aunque también es cierto que para colar la clásica inyección de bypass (' or '1'='1) en general no necesitamos ningún feedback por parte de la aplicación y este caso es básicamente lo mismo, pero mucho más rebuscado.
ResponderEliminarDe todas formas, me parece interesante destacar que los escáneres de vulnerabilidades no detectan ese caso y supongo que no les costaría gran cosa incluirlo en sus respectivas baterías de pruebas.
Pensemos en un programador que no filtra el input en campos tan sensibles como los de contraseña, y pasa cualquier cosa directamente a la consulta.
ResponderEliminarIgual no es muy amigo de las buenas prácticas. Por lo tanto, tampoco sería de extrañar que escribiese una consulta SQL tan antiestética como la propuesta en el reto. Me imagino cómo podría ser el resto de la aplicación.
La ironía es que semejante aplicación, ante un pentesting poco riguroso, limitado a pasar los scans de alguna utilidad al uso, se iría de rositas.
Tengo una pregunta para Chema: ¿esto lo habéis visto en una auditoría real de algún cliente o simplemente ha sido una invención para el reto?
Saludos
No se si os referís a mi con lo de las aplicaciones...
ResponderEliminarAunque no se así, posiblemente sí que un test de intrusión se me coma vivo... Aunque sí pongo empeño en evitar que se pueda hacer una inyección, al menos ordinaria (una inyección a ciegas seguro que rompe algo).
Chema, a mi el Paros 3.2.13 y el SQLMap me detecta los dos tipos de injecciones...
ResponderEliminar@amperis, no estarás usando MySQL?? léete la parte II del artículo.
ResponderEliminarSaludos!