Hacking Fortinet – SQLI test

fortinetPara los que me siguen en Facebook y en Twitter,  saben que últimamente he tenido una especial curiosidad en los equipos Fortinet,  ya que por un lado, es uno de los equipos que tienen mayor posicionamiento de instalaciones en la región y por otro lado en mis proyectos de pentest a pesar de estar presentes, nunca tuve inconveniente de bloqueos en los ataques que realizaba.

Debido a ello, la semana pasada junto a mi amigo Alexis Torres un colega del área de pentest y que también es especialista en soluciones Fortinet , realizamos algunas pruebas de seguridad ofensiva para validar si realmente el equipo bloqueaba ataques cuando protege una aplicaciones Web, en este caso usando un Appliance FortiGate 60D el cual fue configurado adecuadamente por el , ya que la idea era hacer las pruebas como dios manda.

Fortinet
El test consistió en poner una aplicación web vulnerable como DVWA la cual estaba protegida por un Appliance Fortinet D60 específicamente.

fortinet

Entrando a los Ataques:

Como saben las vulnerabilidades de SQL Inyection ( SQLI) son las mas comunes en las aplicaciones web, esto lo pueden validar ya que están en el primer lugar del Owasp top 10.

Entonces nos valimos de la aplicación vulnerable para primero realizar ataques de SQLI muy sencillos.

‘ union select 1 —

Para mi sorpresa el Fortinet detectaba el patrón de SQL , y lo bloqueaba.

Fortinet

La regla que detectaba el ataque fue “http.uri.sql.injection” evidentemente no dice mucho sobre su funcionamiento interno ya que debe ser un secreto bien guardado por la marca.

fortinet

Es así, que no nos dimos por vencidos y decidimos ir un poco más allá y desarrollar ataques un poco más elaborados con SQLMAP , herramienta por excelencia hará desarrollar SQLI.

Sin embargo era obvio que si enviaba el ataque con sqlmap sin ajustar sería presa fácil del Fortinet.

Así que le agregamos un par de modificaciones:

Velocidad:

–threads=1 , Ajustamos el máximo numero de solicitudes a 1
–delay=60 , Retrasar en 60 segundo cada envío de sqli

Ofuscación

–technique U, especificamos la tecnica basado en UNION QUERY
–batch ,  obviar el ingreso de Y/N
–tamper, especificamos el tipo script que usará como payload para ofuscar las cadenas sqli

en el caso de sqlmap tenemos una amplia variedad como en botica:

space2hash.py
space2morehash.py
space2mssqlblank.py
space2mysqlblank.pycharencode.py
chardoubleencode.py
charunicodeencode.py

De tal forma que el ataque quedó de está forma :

python sqlmap.py –url=”http://192.168.19.253/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” –cookie=”security=low; PHPSESSID=d0fa0f05f0b714c18b3ba3ebace3f450″ -v 3 –dbms “MySQL” –technique U -p id –batch –threads=1 –delay=60 –tamper “space2mysqldash.py”

Después de algún tiempo de espera ya que como indicamos bajamos la velocidad del ataque, oh sorpresa el equipo detecto y bloqueo el ataque para cada uno de los payloads existentes con sqlmap.

fortinet-sqlmap

fortinet-sqlmap

Bueno, es evidente que fue un buen resultado para Alexis pero no para mi en mi posición de atacante, sin embargo bajo la perspectiva de protección, es bueno saber que el equipo cumple con su trabajo, aunque es necesario tener en cuenta estos dos factores:

1.-  Configuración adecuada
Como indique desarrollé las pruebas con un especialista en la marca, pero no solo activando o desactivando reglas o configuraciones, como la mayoría de empresas/implementadores lo hacen,  es importante también que un especialista en ataques haga la otra de parte, de tal forma que es posible tener los dos lados del escenario desarrollando test de seguridad ofensiva así como defensiva y de está forma garantizar que la configuración es la adecuada.

2.- Respecto a las pruebas
Desde la perspectiva del pentester no es posible asumir una posición que el equipo tiene la seguridad perfecta, por lo menos hablando de SQLI, teniendo en cuenta que se usó una aplicación web muy conocida en temas de inseguridad, sin embargo es correcto precisar que bajo este escenario fue efectivo, habría que realizar mas pruebas y en otros escenarios web para sentirse mas conforme.

En el futuro espero desarrollar otro tipo de pruebas de seguridad ofensiva como XSS, Session Hijacking, entre otros y ver como nos va.

Como siempre espero les sirva la información.

Saludos
Juan Oliva
@jroliva

 

 

 

 

 

Anuncios
Esta entrada fue publicada en Hacking y etiquetada , , , por jroliva. Guarda enlace permanente.

Acerca de jroliva

Juan Oliva, es un consultor de seguridad informática y telefonía IP con 10 años de experiencia en el campo . Muy involucrado en proyectos de pruebas de penetración , análisis y explotación vulnerabilidades, pruebas de ingeniería social, seguridad física, revisión de código, entre otras tareas de seguridad informática. Así mismo, desarrolla proyectos de implementación y mantenimiento de VoIP, basadas en Asterisk y Elastix, proyectos de callcenter, soluciones en la nube y hosted PBX, Aseguramiento de plataformas Linux, Windows. Ha estado trabajando para una variedad de empresas en donde ha desarrollado proyectos para el estado peruano, así como para entidades privadas, nacionales y del extranjero, cuenta con certificaciones vigentes en Ethical hacking, Linux y telefonía IP. Es instructor de cursos de Ethical Hacking y certificaciónes como Linux Professional Institute y Elastix, donde ha tenido oportunidad de realizar capacitaciones en el Perú, así como en el extranjero. Es investigador de vulnerabilidades, y creador de contenidos, que son publicados en su blog personal jroliva.wordpress.com el cual mantiene desde hace mas de 6 años.

8 pensamientos en “Hacking Fortinet – SQLI test

  1. Excelente Juan, también me topé con un Fortinet al realizar una pruebas para unas aplicaciones web, y al menos para el sql injection con sqlmap el appliance cumplió su rol. Tu post me deja mas tranquilo, pensé que estaba haciendo mal las cosas.. 🙂

  2. Hola Juan,

    Este tipo de equipos también se comercializan en España y me sugieren una pregunta.
    ¿cual es la función a seguir puestos a proteger una infraestructura ya existente?
    Sistemas muy completos que protegen ante ataques de inyección SQL, ataques DoS y demás posibilidades, suelen provocar en los usuarios una “falsa tranquilidad” sobre el nivel de seguridad que deben practicar en sus sistemas interiores (servidores web, aplicacones, etc.) por lo que, en muchos casos, este sistema de defensa “de emergencia” pasa a ser (por el descuido y desinteres de los usuarios) en un firewall de primera línea defensiva.

    ¿está este equipo preparado para hacer frente a ese tipo de ataques que requieren de actualizaciones casi a diario para hacer frente a ataques nuevos o es mejor seguir vigilando el “backend”?

    Saludos y espero que nos veamos pronto! 😀

    • Hola Elio!!

      Un gusto recibir tus comentarios, a continuación respondo las interrogantes.

      ¿cual es la función a seguir puestos a proteger una infraestructura ya existente?

      Esta primera pregunta ya la respondiste y rescato lo de “falsa tranquilidad” sabemos que no existe la seguridad perfecta, por que al final los equipos, los configuran las personas y desde hay vienen los líos, cuando solo realizan configuraciones por defecto, sin saber como funcionan los ataques que en teoría protegen.

      ¿está este equipo preparado para hacer frente a ese tipo de ataques que requieren de actualizaciones casi a diario para hacer frente a ataques nuevos o es mejor seguir vigilando el “backend”?

      El tema de la seguridad web es un tema muy amplio, mis pruebas iniciales con SQLI han salido en favor del UTM, sin embargo aun necesito hacer otros test, teniendo en cuenta que la seguridad web no es solo SQLI , hay ataques mucho mas complejos que aun estoy por realizar.

      Hasta ello, los dejo con la siguiente analogía:

      Cuando alguien compra un arma, luego la prueba en un campo de tiro, para ver si dispara correctamente,

      De igual forma, cuando se compra un UTM, es necesario probarlo haciendo todos los tipos de ataques, como el realizado en este blog, es la única forma de validar que la configuración aplicada, fue la adecuada.

      Nos vemos en unos meses bro!!
      Juan Oliva
      @jroliva

  3. Pingback: Hacking fortinet – bypassing UTM | Juan Oliva

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s