Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
Inverted SQL queries (II de II)
****************************************************************************************************
- Inverted SQL queries (I de II)
- Inverted SQL queries (II de II)
****************************************************************************************************
Para terminar las pruebas con los scanners de vulnerabilidades probamos w3af de Andrés Riancho y Wapiti.
w3af
Los resultados con w3af fueron como con el resto de los scanners, es decir, detectó la vulnerabilidad Normal y no detectó la vulnerabilidad invertida.
Vulnerabilidad Normal detectada
Vulnerabilidad Invertida NO detectada
Wapiti
Decidimos realizar una última prueba con Wapiti, que estaba a mano, y los resultados fueron los esperados, se comporta como el resto de scanners de vulnerabilidades.
Vulnerabilidad Normal detectada
Vulnerabilidad Invertida NO detectada
Reflexiones
Tras jugar con todo esto, lo que está claro es que utilizar un scanner de vulnerabilidades para auditar una web sigue sin ser la solución definitiva y hay que seguir teniendo el colmillo retorcido para encontrar este tipo de fallos.
Una de las cosas que vimos que puede detectar este tipo de vulnerabilidades, tanto si están normal o invertidas, es el uso de las técnicas de Arithmetic Blind SQL Injection en parámetros numéricos.
La idea sería probar el ID=valor, ID=valor+1-1 para comprobar si existe la vulnerabilidad, aunque también se puede hacer la prueba de la división por cero o el desbordamiento de tipos de datos.
He tenido la suerte de hablar con Andrés Riancho y él opina que esta sería una buena solución y la va a probar dentro de w3af, con lo que puede ser el primer scanner que detecte este tipo de bugs creados por programadores rarunos.
La paradoja de MySQL
Curiosamente, si se configura la vulnerabilidad invertida con un motor de MySQL todos los scanners detectaban la vulnerabilidad. ¿Cómo es esto posible? La explicación es tan curiosa como reveladora.
En MySQL se permiten comparaciones lógicas triples, cuádruples, quíntuples o séptuples, con lo que es posible hacer algo cómo:
Where 1 and 1=1=1 -> Lo que daría un True.
Where 1 and 1=1=2 -> Lo que daría un Fasle.
¿Es o no curioso todo este asunto? Como diría alguno en el SOCtano... "Esto es turbio....muy turbio."
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)
****************************************************************************************************
Para terminar las pruebas con los scanners de vulnerabilidades probamos w3af de Andrés Riancho y Wapiti.
w3af
Los resultados con w3af fueron como con el resto de los scanners, es decir, detectó la vulnerabilidad Normal y no detectó la vulnerabilidad invertida.
Vulnerabilidad Normal detectada
Vulnerabilidad Invertida NO detectada
Wapiti
Decidimos realizar una última prueba con Wapiti, que estaba a mano, y los resultados fueron los esperados, se comporta como el resto de scanners de vulnerabilidades.
Vulnerabilidad Normal detectada
Vulnerabilidad Invertida NO detectada
Reflexiones
Tras jugar con todo esto, lo que está claro es que utilizar un scanner de vulnerabilidades para auditar una web sigue sin ser la solución definitiva y hay que seguir teniendo el colmillo retorcido para encontrar este tipo de fallos.
Una de las cosas que vimos que puede detectar este tipo de vulnerabilidades, tanto si están normal o invertidas, es el uso de las técnicas de Arithmetic Blind SQL Injection en parámetros numéricos.
La idea sería probar el ID=valor, ID=valor+1-1 para comprobar si existe la vulnerabilidad, aunque también se puede hacer la prueba de la división por cero o el desbordamiento de tipos de datos.
He tenido la suerte de hablar con Andrés Riancho y él opina que esta sería una buena solución y la va a probar dentro de w3af, con lo que puede ser el primer scanner que detecte este tipo de bugs creados por programadores rarunos.
La paradoja de MySQL
Curiosamente, si se configura la vulnerabilidad invertida con un motor de MySQL todos los scanners detectaban la vulnerabilidad. ¿Cómo es esto posible? La explicación es tan curiosa como reveladora.
En MySQL se permiten comparaciones lógicas triples, cuádruples, quíntuples o séptuples, con lo que es posible hacer algo cómo:
Where 1 and 1=1=1 -> Lo que daría un True.
Where 1 and 1=1=2 -> Lo que daría un Fasle.
¿Es o no curioso todo este asunto? Como diría alguno en el SOCtano... "Esto es turbio....muy turbio."
Saludos Malignos!
****************************************************************************************************
- Inverted SQL queries (I de II)
- Inverted SQL queries (II de II)
****************************************************************************************************
5 comentarios:
Las capturas están cambiadas!!!
La 1ª debería de ser... ¿la 3ª?
@agux, cierto, arreglado.
gracias!
muy interesante esto de las consultas invertidas, de hecho creo que ayudaria a detener la mayoria de los intentos
estoy escuchando tu charla a 10 mts y la verdad sos el mas groso loco!!
que clase la tuya
gracias por postear nuestro deface
gracias por la foto ;)
ricota
Ey chema que pedazo de charla te mandaste, iba a ir a saludarte pero me perdi con una cerveza, felicitaciones!
Publicar un comentario