RSS |

Blog de Omar

Just another WordPress weblog

Advertisement

Posts Tagged ‘ analisis ’

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: 15% [?]

Nessus ha sido, al menos para mi, la primera herramienta de análisis de vulnerabilidades que he usado, además,  no sólo fue la primera sino también la herramienta más fácil y práctica que he conocido. Como todo y como todos nosotros durante el tiempo Nessus ha pasado por un proceso evolutivo y  ha ido cambiando de interfaces, de licenciamiento y sobre todo de versiones; la última versión de Nessus fue lanzada en los primeros meses de este año y trajo consigo nuevas características y también nuevas restricciones. Mientras escribo este post seré victima de un flashback mortal para comparar la nueva versión Nessus contra las anteriores y además poner sobre la mesa alternativas al que hasta ahora fue (para mi todavía lo es) la mejor herramienta de análisis de vulnerabilidades.

Nessus v4 – Nessus v5

Comparativo:

  • La última versión, Nessus v5, mantiene el mismo espíritu para la interfaz de cliente, es decir, utilizar cualquier browser para lanzar un análisis de vulnerabilidad.
  • Nessus v5, trae consigo una nueva escala de categorías para las vulnerabilidades encontradas, atrás quedo la sencilla clasificación: ALTA, MEDIA y BAJA; ahora las clasificaciones de vulnerabilidades son: CRÍTICA, ALTA, MEDIA, BAJA e INFORMATIVA. Esta clasificación me parece mucho más justa e idónea, por ejemplo, abajo podemos ver que han sido clasificados como CRÍTICAS aquellas vulnerabilidades que tienen un exploit altamente conocido y que otorgan privilegios de usuario tipo SYSTEM, mientras que las vulnerabilidades tipificadas como ALTAS muestran vulnerabilidades que no necesariamente te podrían permitir tomar el control total del servidor.

nessusv5

  • No todo es color rosa, todo cambio no siempre trae consigo algo bueno. Todos saben que Nessus tiene dos versiones: Professional (de pago) y Home (gratis), en esta nueva versión la versión Home trae consigo una limitante sobresaliente y que a mi opinión es un cambio que incita o da motivos para preocuparnos sobre el futuro de la versión Home que ofrece Tenable. En la versión 5 de Nessus, la versión Home sólo puede hacer un escaneo de máximo 16 direcciones IP de manera concurrente, es decir, si ustedes están apurados y quieren hacer un análisis sobre 20 direcciones IP no podrán hacerlo.

nessusv5limi

OPENVAS vs NESSUS v5

OPENVAS es una interesante alternativa pero vamos a ser imparciales y analizarla de manera objetiva.

  • La primera diferencia entre NESSUS y OPENVAS es la cantidad de plugins con los que cuentan, NESSUS tiene hasta hoy, 13 de Mayo de 2012, 48268 plugins para el análisis de vulnerabilidades mientras que OPENVAS por el momento tiene 25505. Hay una diferencia de casi el doble de plugins, esto le da una mayúscula ventaja a NESSUS.
  • La segunda diferencia es que OPENVAS es más complejo en cuanto a instalación y configuración inicial, esto debido a que tiene una arquitectura de funcionamiento distinta la cual puede complicar la instalación y configuración inicial.

openvasarch

 

  • El tiempo es otra variable importante en esta comparación, para efectos de esta prueba se realizó un escaneo a un servidor Windows 2003 SP1, los tiempos fueron:
    • NESSUS: 10 minutos aproximadamente
    • OPENVAS: 18 minutos aproximadamente
  • OPENVAS sólo tiene una versión, la cual es libre y gratis para usarse; este es el principal motorcito que debe impulsar el apoyo hacia esta herramienta; además por ser gratuito esta herramienta no tiene un limitante de direcciones IP que pueden ser escaneados.
  • La principal diferencia y por la cual aún OPENVAS no es altamente usado está relacionado a la cantidad de plugins, OPENVAS aun no detecta vulnerabilidades CRITICAS y que ya deberían estar implementadas sobre la misma. A continuación les muestro una imagen que habla por si sola.

nessus_openvas

Lo que llama la atención de sobremanera es que OPENVAS encuentra menos vulnerabilidades que NESSUS pero lo que preocupa es que no haya encontrado la vulnerabilidad altamente conocido MS08-067, la misma que es clasificada por NESSUS como CRÍTICA y que inclusive hemos explotado en el videotutorial que realicé: CREACIÓN DE BACKDOORS CON METASPLOIT.

Además, NESSUS encontró en total 08 vulnerabilidades entre críticas y altas, mientras que OPENVAS sólo encontró sólo 05 vulnerabilidades altas. Finalmente, y a favor de OPENVAS, es que encontró una vulnerabilidad que NESSUS no lo hizo, sólo deben comparar las imágenes.

 

RETINA vs NESSUS

RETINA es la alternativa más interesante de esta comparación, vamos a realizar la comparación con los mismos vectores que OPENVAS:

  • Número de plugins: Lamentablemente no he encontrado cuantos plugins o pruebas de vulnerabilidades utiliza OPENVAS durante su escaneo. Sin embargo, NESSUS y OPENVAS realizan escaneo de vulnerabilidades a aplicaciones web, mientras que RETINA en su versión COMMUNITY (gratuita) no ofrece esta característica.
  • Su instalación es extremadamente sencilla, basta dar unos clicks y la tendremos instalada, por el momento sólo hay una versión para Windows de esta herramienta y es una aplicación de ESCRITORIO, es decir, no se puede instalar en un servidor y usar a través de red.

retinaclient

  • Tiempo de escaneo al mismo servidor que fue escaneado con NESSUS y OPENVAS:
    • NESSUS: 10 minutos aproximadamente
    • OPENVAS: 18 minutos aproximadamente
    • RETINA: 12 minutos aproximadamente
  • Respecto a las versiones, RETINA tiene sus respectivas versiones de pago y versión gratuita (COMMUNITY), aquí pueden leer más sobre todas las versiones que tiene: AQUÍ, la versión COMMUNITY que es gratuita no tiene un limitante de numero de escaneo para direcciones IP.
  • Lo más importante de esta comparación es el resultado final del escaneo, a continuación el resumen del resultado comparado contra NESSUS:

nessus_retina

La imagen superior muestra en la parte lateral izquierda, el resultado de NESSUS y en la parte lateral derecha el resultado de RETINA, como notaran RETINA ha encontrado 04 vulnerabilidades ALTAS que también encontró NESSUS, RETINA no encontró la misma cantidad que NESSUS pero si encontró las que tienen exploits conocidos en METASPLOIT: MS08-067, MS09-001, MS06-035 y MS12-020. Sin embargo ninguna vulnerabilidad en Microsoft SQL SERVER ni siquiera el uso de credenciales por defecto que si encontró OPENVAS.

 

CONCLUSIONES

  • Nessus encontró la mayor cantidad de vulnerabilidades en comparación de OPENVAS y RETINA.
  • RETINA sólo encontró aquellas vulnerabilidades que tienen un exploit público conocido.
  • OPENVAS es una alternativa interesante que es totalmente OPEN SOURCE pero aún carece de un número importante de plugins pero esperamos prontas mejoras.
  • NINGUNA de las 03 herramientas es mejor que otra, por lo menos dos de las tres herramientas arriba descritas deben ser usadas en el proceso de descubrimiento y análisis de vulnerabilidades para garantizar un adecuado análisis libre de falsos positivos.

Popularity: 11% [?]

androidpirateComo cuando mi abuelita me traía nuevas canicas para jugar, como cuando orquestaba y armaba todo un campo de batalla en mi habitación y como cuando me sumergía en una historia imaginaria con los soldaditos de plástico que colocaba estratégicamente en la ventana y muebles de mi cuarto, así me encuentro, tocando y haciendo clicks a discreción sobre mi nuevo Google Nexus.

No es difícil imaginar que lo primero que haría es evaluar las herramientas que me servirían para realizar Ethical Hacking, así que decidí realizar un videotutorial sobre el “Análisis de vulnerabilidades” desde un celular con el sistema operativo Android. En el video podrán ver el uso de dos herramientas:

  • NETAUDIT TCP PORT.- Herramienta lo más parecido a NMAP (aunque aún muy lejos de parecérsele)
  • NESSSUS.- Herramienta para realizar y encontrar vulnerabilidades

Espero les guste el video y puedan realizar las mismas pruebas.

 

Popularity: 9% [?]

Sin duda este año nos deja sin sabores que no son fáciles de asimilar, uno de ellos tuvo lugar en Abril de este 2009 y fue la inesperada compra de SUN por parte de Oracle. Son esas noticias que uno no espera leer un día común por la mañana cuando se revisan los feeds y que cuando lo lees debes de verificarlo en otro blog para ver si es cierto o solo es parte de una broma pesada.

Lo ciesakila_switchboardrto es que Oracle compro Sun y con ello Java, Solaris y MySQL que es la primera base de datos Open Source y el tercer sistema gestor de base de datos mas popular del mundo… nada mas y nada menos.
Aquí un breve pero muy breve resumen:

  • Inicios 2009 y desde antes: Había una guerra fría entre IBM y Oracle por adquirir Sun.
  • Abril 2009: Oracle da el golpe liquidador y Compra Sun.
  • Desde Abril 2009 hasta Diciembre 2009: Todos analizan el impacto que esto tendrá en el mercado y en especial sobre MySQL ya que este podría ser el mas afectado.
  • Diciembre 2009: Michael “Monty” Widenius (uno de los creadores de MySQL) hace un llamado para “Salvar a MySQL”, aquí el [POST] de su blog.
  • Diciembre 2009 y solo días después: Oracle da una conferencia pública comprometiéndose a mantener MySQL debido a que los usuarios de Oracle y MySQL son totalmente distintos. Aquí el [POST] con mas detalles.

Hace unos meses conversaba con un miembro del soporte de MySQL Enterprise que me estaba ayudando con un tema de licencias que ha adquirido la empresa donde trabajo y en donde administro MySQL Enterprise 5 y me comentaba que el futuro es totalmente incierto que no se sabe aun los cambios que Oracle impondrá sobre MySQL y especular sobre el futuro en estos mundos de TI puede convertirse en algo tan similar como jugar a la ruleta rusa y obviamente sobre lo que convenga a Oracle.

¿Que le conviene a Oracle?

En mi opinión, abandonar MySQL y desaparecerlo podría resultarle a Oracle un “tiro por la culata” porque podría ocasionar levantar otra competencia como PostGres, seria para PostGres la oportunidad que esperaba (imagínense todas las aplicaciones Web del mundo migrando a PostGres: WordPress, Joomla, Nuke, Typo, software de investigación, etc. etc.).
Otros piensan que Oracle jamás cometería semejante y tamaño error y que por el contrario que esta es la gran oportunidad de Oracle para liquidar a IBM en el mundo de software, ofreciendo 2 tipos de servicios: Uno propietario (bien caro por cierto) y uno Open Source, ambos totalmente integrales. Imagínense una plataforma con Solaris, Oracle (para aplicaciones empresariales) o MySQL Enterprise (para aplicaciones de investigación) y con programas desarrollados en JAVA y por otro lado podrías usar Open Solaris, MySQL Community y Aplicaciones Java, definitivamente un golpe duro para IBM y Microsoft.

Pero el tiempo solo el tiempo dirá que pasará (como dice mi padre y señores que vivieron “La Nueva Ola” con mucho furor), mientras esperamos las novedades para el 2010 les dejo un video muy gracioso y que vale la pena de ver. ¿Se imaginan a Hitler enterándose de la compra de Sun por parte de Oracle? y a todo esto…. ¿Ustedes que creen que hara Oracle con MySQL?

Popularity: 2% [?]