RSS |

Blog de Omar

Just another WordPress weblog

Advertisement

Después de 09 meses de inactividad en el Blog, me he decidido volver a escribir. De hecho existen muchos motivos por los cuales no he escrito pero de eso no pienso escribir – al menos no en este POST – pero hoy domingo de resurrección resucitamos el Blog también. 

Hace poco más de dos (02) meses empecé a investigar un nuevo tema de seguridad, lo inicié ya que me encontré con la vulnerabilidad realizando un servicio de Ethical Hacking que me contrataron y me pareció muy interesante; interesante para postearlo, interesante para explicarlo detalladamente y más interesante aún, explicar como automatizar un ataque de este tipo. ¿Y qué fue lo que me encontré? me encontré con una Inyección SQL a través de un Captcha, así que de eso va tratar este POST.

Antecedentes

  • Sería buena idea que revises los POST de inyecciones que he publicado antes: Clase 1, Clase 2, Clase 3, Clase 4
  • Vamos a utilizar MySQL como motor de Base de Datos pero como ya saben, las inyecciones de código SQL nada tiene que ver con el motor de BD.
  • Vamos a utilizar Python para automatizar el ataque

 

1. Identificando la vulnerabilidad

Primero vamos a situarnos en el escenario, he replicado el escenario vulnerable y sobre este nos vamos a situar. Es un formulario de envío de comentarios, el formulario cuenta con un código CAPTCHA de seis (06) caracteres que obviamente varia cada vez que se accede a la página que contiene el formulario.

1

A) No funcionan las herramientas de Vulnerabilidades

Repito, no funcionan las herramientas de búsquedas de vulnerabilidades, EXACTO no funcionan ni van a funcionar.

¿Por qué no funciona?

  • El formulario envía el comentario y genera en background un query SQL sólo si se ingresa adecuadamente el código Captcha.
  • Si se ingresa o se envía por el método POST cualquier otro caracter que no coincida con lo que muestra la página, no se genera el INSERT y por consecuencia no hay forma de interactuar con la BD.
  • Si no interactuamos con la base de datos  no se puede identificar INYECCIONES SQL (eso debería estar claro si estas leyendo este post)

A continuación les pongo los resultados del análisis de vulnerabilidades que realicé con dos herramientas conocidas: Acunetix y W3AF, como verán no detectan ningún tipo de inyección SQL.

2

3

 

B) Pruebas Manuales de Identificación

Gran parte de las pruebas que se realizan en un proceso de Ethical Hacking son pruebas manuales. No se puede pretender o menos creer que las herramientas van hacer nuestro trabajo e identificar todas las vulnerabilidades que pueden haber en una página web.

Las herramientas sólo nos ayudan a identificar vulnerabilidades, lean bien por favor, “AYUDAN” y este post es un buen ejemplo para hacerlo notar.

En este caso vamos a realizar una inyección del tipo BLIND SQLi (inyección sql a ciegas) a través del método POST en la variable “nombre” del formulario, para identificar un BLIND SQLi se hace uso de sentencias condicionales del tipo OR, AND, IF u otra palabra reservada y observar el comportamiento de la página web, además, BLIND SQLi no arroja errores de sentencia en el query.

Nuestro PAYLOAD a colocar en la variable “nombre” es el siguiente: [ omar'|| (if(2>1, sleep(10),0)) ||' ], lo que debe ocurrir si es que el query se ejecuta es que la página demora más de 10 segundos en volver a cargar, debido a que la función SLEEP hará que la base de datos tarde 10 segundos en ejecutar el query.

Es importante remarcar que el PAYLOAD correcto no sirve si es que no se ingresa el Captcha correcto, si no me creen inténtelo.

 

4

 

Aquí dejo los HEADERs de la petición que se envía, en la cuadro inferior se muestran las variables en formato urlencoded.

5

 

2. Realizando y explicando el ataque

Ahora que ya sabemos a los que nos enfrentamos -  un formulario con Captcha – y que sabemos que es vulnerable con un Blind SQLi, debemos automatizar el ataque y extraer información de la(s) base(s) de dato(s), tablas y registros del servidor web a los que tengamos permisos.

A) ¿Por qué no podemos utilizar SQLMap?

Muy bien, entonces utilizaremos la herramienta por excelencia verdad? SQLMap es la solución para las inyecciones. Si pensaste que SQLMap sería la solución debes dejar este blog de inmediato – no mentira es broma – pero toca analizar un poco porque no se podría utilizar SQLMap ni ninguna herramienta que automatiza las inyecciones de código SQL. Vamos a analizarlo paso por paso para que se entienda.

image

 

La imagen superior resume el motivo por el cual no podemos utilizar SQLMap para realizar el ataque, si es que no se entendió la imagen superior aquí lo vuelvo a resumir:

  • SQLMap realiza múltiples envíos consecutivos con las variables que le indiquemos a través de la opción  “- – data”.
  • En cada envío que hace SQLMap debería enviar el código Captcha para realizar la inyección SQL.
  • SQLMap no tiene como saber cual es el código Captcha, ya que este varía después de cada envío realizado previamente
  • Además, algunos formularios realizan un cierre de sesión después de cada envío (creando uno nuevo) y eso dificulta la inyección porque cada sesión esta asociada al código captcha.

Listo!!! con eso queda totalmente explicado el motivo porque el cual no podemos utilizar SQLMap.

 

B) Realizando el ataque de Inyección

Después de lo explicado, nos toca analizar como realizar el ataque si es que hasta ahora ninguna herramienta parece que nos va servir. De pronto, alguien se puede estar preguntando que no es necesario automatizar el ataque ya que con el siguiente PAYLOAD [ omar'|| (if(2>1, sleep(10),0)) ||' ] queda totalmente evidenciado que la página web es vulnerable pero aquí les dejos algunos motivos por los cuales debemos buscar la forma de automatizar el ataque:

  • Evidenciar y mostrar evidencia clara de que la página es vulnerable, de hecho me pagan por eso y toca hacerlo. No es lo mismo decir: “la página es vulnerable y hemos identificado N cantidad de usuarios” versus “la página es vulnerable pero no hemos podido obtener información”. El riesgo de seguridad queda explicado mejor en el primer caso.
  • Automatizar el ataque es el único camino, hacerlo manualmente tardaría tanto como tardaría la selección peruana de futbol en llegar a un Mundial. Además no me pagan por horas, sino por resultados.
  • Y el motivo más importante, porque me da la gana y es un buen reto. En especial cuando toca analizar diversas imágenes Captcha con diferentes tipos de complejidad.

Entonces lo que vamos a realizar para resolver este problema es un script en Python que realice lo siguiente:

  • Realizar una solicitud a la página web del formulario para obtener la imagen que contiene el Captcha y descifrarlo.
  • Obtener la cookie de la petición de la página web, la cookie se asocia con la imagen Captcha obtenida.
  • Enviar las  variables obtenidas por el método post, las variables enviadas incluyen: la cookie, el captcha descifrado y el PAYLOAD identificado.
  • Realizar la inyección Blind SQLi para obtener caracter por caracter.
  • El script debe ser interactivo y realizar todos los pasos previos en cada solicitud, es decir, lo que SQLMap no hace.

6

 

Hasta el próximo post!!! y saludos a todos.

Popularity: 14% [?]

Si te gusto este post, asegurate de suscribirte a mi RSS feed!

Omar Palomino

Hola mi nombre es Omar Palomino. Si te gustan las noticias de mi blog, no olvides suscribirte a la página. Puedes leer más en Acerca de MI, o bien ponerte en contacto conmigo al correo: omarc320@gmail.com

More Posts - Website

Post Relacionados

SI TE GUSTO ESTE ARTICULO, COMPARTELO!


Comments

There are 3 comments for this post.

  1. marcos on Reply to this comment Abril 25, 2014 7:18 am

    Me gustaria saber si vas a publicar el codigo fuente vulnerable en tu blog como en post anteriores.

    Gracias.

  2. oscar on Reply to this comment Mayo 7, 2014 9:53 pm

    Buenas Omar
    buenos tutoriales de tu pagina me gusta mucho la seguridad informatica aunque no se demasiado, por eso mi inquetud, no entendi lo del script en pyton, cual es? o hay que hacerlo y donde se inyectaría? , te felicito por tu pagina. Atte. Saludos.

  3. ANÁLISIS CAPTCHA: INYECCIÓN DE CÓDIGO SQL–PARTE III | Blog de Omar on Reply to this comment Junio 16, 2014 12:33 am

    […] ANÁLISIS CAPTCHA: INYECCIÓN DE CÓDIGO SQL–PARTE I [AQUÍ] […]

Write a Comment

*

Spam Protection by WP-SpamFree