Desactivando SIP ALG en Fortinet

SIPALGMencionar que el protocolos de Voz son los mas delicados que existen en el mundo de los servicios de infraestructura no es una novedad, debido primordial mente a que no pueden tener ningún tipo de retardo o falla durante su transmisión y en este caso protocolo SIP en este caso no es la excepción.

Bajo este contexto, algunos equipos perimetrales tipo Router, Firewall, UTM durante estos últimos años vienen implementando lo que llaman “Application Layer Gateway” o ALG evidentemente en favor de la protección ante fallas de seguridad,  ya que lo que hace es interceptar el trafico para administrarlo/gestionarlo antes de dejarlo pasar a su destino final.

SIPALG

Sin embargo este tipo de features no necesariamente surten en favor de uno cuando está desplegando una implementación de VoIP ya que ello va producir problemas durante las llamadas, causando entrecortes o caídas de llamada inesperados inclusive.

En este caso vamos a ver como desactivar SIP ALG de un equipo Fortinet 60D sin embargo puede ser aplicable para cualquier modelo.

1.-Desactivar sip-helper y sip-nat-trace

Ingresamos al CLI console mediante la interfase de administración y desactivamos las opciones de sip-helper y sip-nat-trace de la siguiente forma:

SIPALG

Una vez realizado esto es necesario reiniciar el equipo.

2.-Eliminar SIP dentro de session-helper

Luego ingresamos nuevamente, ahora es necesario identificar el ID del protocolo SIP dentro de la opción session-helper para luego eliminarla, esto se consigue de la siguiente forma:

SIPALGSIPALGComo vemos hemos identificado que el protocolo SIP se encuentra en el ID 13 , ahora procedemos a eliminarlo de la siguiente forma:

SIPALGUna vez que hemos eliminado el ID simplemente cerramos la sesion en la consola.

Espero les sirva.
Saludos
Juan Oliva

 

 

 

Anuncios

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