Archivo
Desactivando SIP ALG en Fortinet
Mencionar 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.
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:
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:
Como vemos hemos identificado que el protocolo SIP se encuentra en el ID 13 , ahora procedemos a eliminarlo de la siguiente forma:
Una vez que hemos eliminado el ID simplemente cerramos la sesion en la consola.
Espero les sirva.
Saludos
Juan Oliva
Fortinet SSH Backdoor Exploit P.O.C.
Hace solo un par de semanas el mundo de uno de los mas famosos UTMs del mercado Fortinet, fue remecido por la divulgación de una puerta trasera de acceso a sus equipos.
Inicialmente se reveló un script que sacaba provecho a un método de «soporte» usado por el personal de firma para brindar ayuda, si bien es cierto este método tenia involucrado la generación de claves aleatorias, sin embargo usaba un algoritmo al parecer bastante sencillo.
Por supuesto luego de a ver sido revelado este «método» apareció un script en Python que explota y automatiza la apertura de un shell mediante SSH.
Cabe señalar que la firma emitió un comunicado (ver aquí) en donde aduce que lo revelado se trata de un problema de gestión y no de un puerta trasera, lo real es que ahora la vulnerabilidad afecta a las versiones 4.X hasta las 5.0.7 del sistema operativo.
Aquí el P.O.C. que realicé contra un Fortinet VM
Es claro que todos los equipos que tengan la versiones afectadas y que tengan SSH abierto, es altamente recomendable actualizar (pagar la licencia) para evitar ser comprometidos.
Espero les sirva
Juan Oliva
@jroliva
Hacking Fortinet – WAF TEST
Dentro de la amplia gama de soluciones de protección de seguridad informática, existen equipos muy especializados de acuerdo al propósito; Uno de ellos esos equipos es el denominado Web Application Firewall
Según OWASP es un firewall de aplicaciones Web o «WAF» el cual es es un aparato, plugin de servidor, o el filtro que se aplica un conjunto de reglas a una conversación HTTP. En general, estas reglas cubren ataques comunes tales como cross-site scripting (XSS) y SQL injection. Mediante la personalización de las reglas para su aplicación, muchos ataques pueden ser identificados y bloqueados.
Evidentemente un WAF no es un UTM , ya que el WAF como se cita en el párrafo anterior, es un equipo que se enfoque específicamente en la protección de aplicaciones o sistemas Web, es necesario precisar ello por que en el articulo anterior donde realizarnos pruebas contra un UTM la mayoría de los ataques hacia aplicaciones web, no fueron bloqueados por el equipo.
Es así , que gracias a Yishay Perry ( www.fil.org.il ) que es especialista en soluciones Fortinet y un colega en el área de seguridad perimetral, me dio la posibilidad de poder tener acceso al WAF de Fortinet denominado FORTIWEB, en donde implementamos un escenario de adecuado para realizar algunas pruebas de seguridad ofensiva y validar si el equipo podía bloquear algunos de los ataques hacia aplicaciones web mas representativos.
Escenario
Test 1 – Cross-site scripting XSS
La detección de ataques de XSS son bastante complicados de ser detectados por los UTM tradicionales en este caso vamos a ver como reacciona el WAF ante esta vulnerabilidad.
A.- Sin el WAF protegiendo la aplicación web
Probamos la siguiente cadena xss :
alert(document.cookie)
Vemos que el xss reflejado se completo
B.- Con el WAF protegiendo la aplicación web
Volvemos a probar la misma cadena pero ahora con el WAF protegiendo la aplicación web
Vemos que el WAF reacciona y bloquea la ejecución del XSS reflejado
Así mismo el WAF genera el registro del evento.
Test 2 – File Inclusion
Esta es otra vulnerabilidad bastante complicada de detectar, vamos a ver como reacciona.
A.- Sin el WAF protegiendo la aplicación web
Probamos la siguiente inclusion : /etc/passwd
Vemos que se completa el comando y devuelve el contenido del archivo /etc/passwd en la aplicación web
B.- Con el WAF protegiendo la aplicación web
Volvemos a probar la misma cadena pero ahora con el WAF protegiendo.
También vemos que el WAF reacciona y bloquea la ejecución del XSS
De la misma forma vemos que el WAF genera el registro del evento.
Test 3 – Website Defacement
El defacement o defaseo de paginas es un ataque bastante comun en estos tiempos, veamos como el WAF reacciona.
Escenario: En este caso hemos conseguido subir un webshell, mediante un formulario de upload, luego se ha detectado el archivo index.php que es la pagina principal del sitio web y estamos en el proceso de grabar nuestro defacement , como se muestra a continuación : 
A.- Sin el WAF protegiendo la aplicación web
Sin el WAF protegiendo es posible grabar el archivo y completar el defacement de la siguiente forma :
B.- Con el WAF protegiendo la aplicación web
Volvemos a probar tratando de grabar el archivo index.php con el WAF protegiendo y este reacciona de esta forma :
Así mismo el evento queda registrado como se muestra a continuación:
Es decir el WAF evita el defacement.
Conclusiones
- Contar con un equipo mucho mas especializado en ataques web permite reducir mucho las probabilidades de que se puedan explotar vulnerabilidades en las aplicaciones, como el caso de el FortiWEB
- Si bien es cierto todas las pruebas realizadas fueron positivas con respecto al WAF , ello es porque, se ha realizado configuración especifica de protección para la aplicación que se está defendiendo, es decir cualquiera que sea la solución WAF que se usen, es necesario realizar configuración personalizada en el equipo.
- Esta guía intenta mostrar, que para cualquier equipo o solución que proteja la seguridad, es altamente recomendable que se realicen pruebas de seguridad ofensiva para validar cada una de las reglas de protección que el equipo brinda.
- En el caso del FortiWeb puedo manifestar que es un equipo que protege bastante bien las vulnerabilidades evaluadas.
En otro articulo veremos como implementar un WAF basado en algunas soluciones de software libre existentes.
Espero les sirva.
Saludos
Juan Oliva
@jroliva
Hacking Fortinet – WAF TEST (English version)
Among the wide range of solutions to protect security, there are very specialized equipment according to purpose; One such equipment is called Web Application Firewall
According to OWASP is a Web application firewall or «WAF« which is a device, server plugin, or filter a set of rules that applies to an HTTP conversation. In general, these rules cover common attacks such as cross-site scripting (XSS) and SQL injection. By customizing the rules for its implementation, many attacks can be identified and blocked.
Evidently a WAF is not a UTM , the WAF it is a device or software that specifically focus on protecting applications or Web systems, it is necessary therefore that in the previous article where through testing against UTM most attacks on web applications, were not blocked by the team.
Thanks to Yishay Perry (www.fil.org.il) who specializes in Fortinet solutions and a colleague in the area of perimeter security, gave me the possibility to access the Fortinet WAF called FortiWeb, where we implemented a scenario suitable to perform some tests of the security offensive and validate if the team could block some of the attacks more representative on web applications.
Scenario:
Test 1 – Cross-site scripting XSS
The detection of XSS attacks are most complicated to be detected by traditional UTM in this case we see how the WAF reacts to this vulnerability.
Xss tested the following string: alert (document.cookie)
see that reflected XSS is completeRetest the same test but now with the WAF protects web application
see that the WAF reacts and blocks the execution of reflected XSS
Also the WAF generates the event log.Test 2 – File Inclusion
This is another vulnerability difficult to detect , let’s see how he reacts.
A. Without the WAF protects web application
We tested the following path inclusion: /etc/passwd
see that the command completes and returns the contents of /etc/ passwd file in the web application
B. With the WAF protects web application
Retest the same test but now with the WAF protecting.
We also see that the WAF reacts and blocks the execution of XSS
as in the previous test we see that the WAF generates the event log.
Test 3 – Website Defacement
The defacement or defaseo of pages is an attack fairly common these days, let’s see how the WAF reacts.
Scenario: In this case we managed to climb a webshell, upload through a form, then detected the file index.php is the main page of the website and are in the process of save our defacement in the file, as shown below:
A. Without the WAF protects web application
Without the WAF protecting , may save the file and complete the defacement as follows:
B. With the WAF protects web application
Retest trying to save the index.php file with the WAF protecting and it reacts like this:
Likewise, the event is recorded as shown below:
WAF prevents defacement.
Conclusions
- Have a much more specialized equipment allows web attacks greatly reduce the chances that can exploit vulnerabilities in applications, such as the case of the FortiWeb
- All tests were positive about the WAF, it is because, there has been specific configuration to protection for the application that is being defended, ie whatever the WAF solution is used, it is necessary to make custom settings on device .
- This guide is intended to show that for any equipment or solution to protect the security, it is highly recommended that offensive security testing to validate each of the security rules that the device offers are made.
- I can say that FortiWeb is a pretty good device that protects the assessed vulnerabilities.
In another article we will see how to implement a WAF some solutions based on existing free software.
Regards
Juan Oliva
@jroliva
Hacking fortinet – bypassing UTM (English version)
Spanish version :https://jroliva.wordpress.com/2015/07/31/hacking-fortinet-bypassing-utm/
Hello, in the previous post «Hacking FoAceptarrtinet – SQLI test» I made clear my position that I was unhappy with the results obtained. And do not misunderstand, beyond that we received very good feedback from the Fortinet brand which is important to us.
by showing a very good position and receptive to this type of study, however we needed perform another tests the offensive security because SQLI is not everything, Now the current attacks go far beyond, including combined attacks and techniques.
It is so a few days ago, again with my good friend Alexis Torres, developed the following test, detailed below:
Scenario:
The scenario is implemented as follows:
192.168.100.100 — IP WEB SERVER on LAN
192.168.100.120 — IP MS WINDOWS 7 on LAN
192.168.100.1 — IP UTM on LAN
192.168.13.100 — IP SERVIDOR WEB en WAN
192.168.13.200 — IP UTM en LAN
192.168.13.202-203 — ATTACKER 1 (KALI LINUX)
192.80.190.11X — ATTACKER 2 (VPS CENTOS 6.X)
Setup UTM
A Appliance Fortinet D60 with licenses of the IPS and Antivirus activated as you can see below:
Also, during the tests detailed below, several configuration profiles were tested as follows:
Profile «Default» activated in the IPS
Profile «High Security» activated in the IPS
Profile «protect_http_server» activated in the IPS
Profile «default» activated in the AV
Also set within this profile (AV), the proxy mode, which allows you to capture traffic on a cache, examine it and then send it to the client.
Then to validate that the IPS is configured correctly, we perform a basic test of SQLI to verify that blocks correctly.
trying to introduce a SQLI in the web application, we see that the IPS blocks attack:
All validated, we start with the tests.
Test 1 – Session Hijacking using XSS
The first attack we tested is the «session hijacking» using stored XSS, previously we had proven that XSS reflected were not detected by the IPS, so that when combined with other attack, the IPS had even less likely to be detected , as it’s shown in the following:
As shown, the XSS attack sent via the «document.cookie» object , current session to an external URL http: //192.80.190.1XX/b.php
Then the attacker 2 receives the string sent by the XSS stored in the web application, as follows:
As shown, the attack result is received in the VPS Linux (attacker 2) only opening a socket connection using netcat to port 80 and the session cookie is received.
After completing the attack, let the UTM web interfase and we do not have the «Security Log / Intrusion Protection» section, that is not registered and does not block it.
these attacks are maded in this scenario:
The attacker enters to intranet, who has an invited profile , he identifies that web application has XSS vulnerability and it stores on a common place in the web application then he deploys the malicious URL. The victim enters to intranet like whatever job day, he can review the balance of the day or some import information or maybe he could get an administrator profile.
When the victim gets to click to malicious url, the cookies are sent to attacker’s console.
the attacker can use that cookie in order to access to web application with the same victim’s profile and access all the information.
Test 2 – LFI
Including local files, allows viewing files that are not in the directory of your Web server publishing, as the following example:
In that case we are viewing the «passwd» file in the «etc» directory of the operating system.
The attack is complete and is never detected by the IPS.
Test 3 – Reverse Shell using File Upload
It is common in Web applications has forms to upload files, whether images, documents docx, xlsx or pdfs inclusive.
However, this represents a major vector for an attacker because it allows the physical write to the server, which is a very tempting opportunity.
We will not explain the many techniques to evade filters must have an upload form, however we will use a basic, is rename the extension to the flight, to upload your file, this file generates the reverse shell through the web application.
Start the the process of the attack
A. Download and set up reverse shell file.
Download PHP reverse shell file and configured as follows:
As we can see, in the variable $IP we are declaring the Linux VPS IP to which the shell is sent through the output port 1234, declared the variable $port
B. Rename to confuse evade the upload filter.
Then change the file extension to jpeg as shown below:
C. Upload and execute file
With our shell covered in a jpeg file, we will upload
Then using a proxy as «burp suite» we will rename the file extension on flight.
See a little more detail the change
Then, the file is uploaded, and execute in the URL where it is housed in the web server.
Later, the attack is complete, without being blocked by the UTM and the reverse shell is obtained, in the listening port 1234 of the VPS as shown below:
Test 4 – Avoiding the perimeter Antivirus and winning remote shell in Windows 7
Context: Some of the features of all UTM is to have an antivirus perimeter, your objetive to be the first defense against the entry of infected files, before they reach workstations of users, these attacks are best called «client side attacks».
The attack: In post past «Evading Antivirus with Shellter and Metasploit» showed how they could evade the local antivirus,
– Creating the infected file
Let’s create a Shellter infected file as follows:
As seen in the capture, it configures the IP 192.179.13.203 , will be receiving the reverse shell on port 5555, in the case that the infected file is execute in the victim.
– Execute the handler in Mestasploit
Now got one handler listening for the reverse shell
As shown, it is waiting for the reverse shell on port 5555
– Downloading the infected file on the client.
Now from the Windows, we will download the infected file, where the perimeter antivirus should react and do not allow downloading.
As you can see, it is possible to completely download the infected file.
– Gaining remote shell
Now what follows is run the file, and get the reverse shell.
I pause to explain the following.
Peculiar behavior
When executed the first time the infected file, the reverse shell was obtained, but after repeating the process several times, it was no longer possible, the UTM detect and block the reverse shell,but again, but I repeat, then gained 2 or 3 times the previously reverse shell.
Negative behavior – Obtain the shell
Positive behavior – block shell
As shown in previous screenshots, twice the attack could be completed (the shell was obtained) but then this was no longer possible.
As you can see, the handler can not get to complete the process of obtaining meterpreter session.
And obviously the reason was because the IPS detected the attack.
Abnormal behavior – Obtein the shell
We made the analysis of the packages, we could see that the shell was blocked, not at the time when Windows send the package handler, if not when, returned back to Windows (incoming packet) and at that moment, it was detected by IPS.
Because of this, we changed our configuration in file infected to send the shell to VPS Linux and this was the result :
As you can see after running the file, you may receive the connection in the VPS.
Conclusions
- The Tests in the side of pentester were of such Gray box, not known the type of configuration in the UTM but but yes , the IP address of targets.
- The tests are very used by computer criminals, especially when performing combinations of techniques may be more likely to succeed.
- My opinion It’s necessary implement additional systems to monitor attacks.
- Must be generated in the UTM custom rules for each type of situation, in the case of fortinet, this link is important.
- In the proof of AV engine in client side, only it was made with a type of payload, «meterpreter» that is denominated in the IPS signatures as «Shell reversing» , there isn’t unique payload kind, and the target in Windows(known signature).
- We don’t use any kind of sophisticated technique as crypter, encoder, reassemble however we use a dynamic code injector to PE, to create a malicious executable, after that in the pictures, we can see that originate a communicate channel between evilServer and the target.
- With my experience in security projects deployments for enterprises, there is a great dependability in UTMs about their security information because they can find “all defense in one” when the reality is the first line defense perimeter in some company.
- In addition, there aren’t enough to have firmware updated and licenses paid, in first point, we should assure that the configuration has a good practice because it can get a great impact without much effort to attacker 😀
Finally, tests have no intention to somehow discredit a particular brand, all the opposite, have the spirit carried out with other security appliance and other brands, and improve the security of bussines applications.
For example, personally pending testing by a product of the same brand, called FortiWeb, which is a much more specialized in web attacks protection.
Waiting the new tests !!
Saludos
Juan Oliva
@jroliva
Hacking fortinet – bypassing UTM
English version : https://jroliva.wordpress.com/2015/07/31/hacking-fortinet-bypassing-utm-english-version/
En las pruebas realizadas en el post anterior «Hacking Fortinet – SQLI test» dejé en claro mi posición respecto a que me sentía inconforme por los resultados obtenidos.
Y no lo mal interpreten, mas allá de que recibimos muy buenos comentarios de la marca Fortinet lo cual es importante, por que como lo indiqué, muestran una posición muy buena y receptiva ante este tipo de estudios, mas allá de eso, era necesario realizar pruebas de seguridad ofensiva un poco mas extendidas, ya que el SQLI no lo es todo y ahora los ataques actuales van mucho mas allá, inclusive combinándose entre si.
Es así que hace unos días, nuevamente en conjunto con mi buen amigo Alexis Torres , desarrollamos los siguientes test que a continuación detallo:
Escenario :
Como se muestra en el escenario implementado es el siguiente:
192.168.100.100 — IP SERVIDOR WEB en LAN
192.168.100.120 — IP MS WINDOWS 7 en LAN
192.168.100.1 — IP UTM en LAN
192.168.13.100 — IP SERVIDOR WEB en WAN
192.168.13.200 — IP UTM en LAN
192.168.13.202-203 — ATACANTE 1 (KALI LINUX)
192.80.190.11X — ATACANTE 2 (VPS CENTOS 6.X)
Setup del equipo
Un equipo Fortinet D60 con las licencias de IPS y Antivirus activado como se puede ver a continuación :
Así mismo, durante las pruebas que a continuación se detallarán, se probaron varios perfiles de configuración como los siguientes :
Perfil «default» activado en el IPS
Perfil «High Security» activado en el IPS
Perfil «protect_http_server» activado en el IPS
Perfil de AV en modo «default»
También se configuró dentro de este perfil, el modo proxy, que permite capturar el trafico en una cache, examinarlo y luego enviarlo al cliente.
Luego para validar que el IPS se encuentre correctamente configurado realizamos una prueba básica de SQLI para verificar que bloquee correctamente.
Luego tratar de introducir un SQLI vemos que el equipo lo bloquea:
Ahora con todo validado, empezamos con las pruebas.
Test 1 – Session Hijacking usando XSS
El primer ataque que probamos es el robo de sesiones (session hijacking) haciendo uso de XSS almacenado, previamente ya habíamos probado que los XSS reflejados no eran detectados por el IPS de tal forma que al combinarlo con otro tipo de ataque era menos probable aun que sea detectado, como se muestra a continuación :
Como se muestra, se envía vía el objeto «document.cookie» la sesión actual a una URL externa http://192.80.190.1XX/b.php
Luego el atacante 2, recibe la cadena disparada por el XSS almacenado de la siguiente forma :
Como se muestra el resultado del ataque se recibe en el VPS Linux ( ver gráfica) solo abriendo un socket de conexión median netcat al puerto 80 , y se recibe toda la cookie de sesión , que posteriormente servirá para autenticarse en la aplicación web donde estuvo logueada la víctima.
Si no la ven aun 😀 imagínense este escenario.
El atacante, ingresa a la intranet de la empresa, cuyo perfil es solo de invitado, identifica la vulnerabilidad de XSS almacenado sobre un lugar común en la aplicación web e implanta la URL maliciosa, La víctima, se loguea como todos los días en la intranet de la empresa a revisar digamos, los balances del día, en este caso tiene perfil de administrador de la empresa, hace clic sobre el lugar común donde está la URL maliciosa y envía su cookie de sesión al atacante, luego el atacante usa esa cookie para ingresar a la aplicación con el mismo perfil de la víctima y acceder a toda la información que le permite ese perfil.
Ojalá que ahora si la vean 😀
Una vez completado el ataque, vamos al equipo y vemos que no tenemos el apartado «Security Log/Intrusion Protection» es decir no registra y no lo bloquea.
Test 2 – LFI
La inclusión de archivos locales, permite la visualización de archivos que no están en el directorio de publicación del servidor web, como el siguiente ejemplo :
En ese caso estamos visualizando el archivo «passwd» en el directorio «etc» del sistema operativo.
El ataque se completa y nunca es detectado por el IPS.
Test 3 – Shell reverso usando File Upload
Es común dentro de las aplicaciones web tiene formularios para cargar o subir archivos, ya sea imágenes, documentos docx, xlsx o pdfs inclusive.
Sin embargo ello representa uno de los principales vectores para un atacante ya que permite la escritura física en el servidor, lo cual es una oportunidad muy apetitosa.
No vamos a ver las innumerables técnicas para como evadir los filtros que tiene que tener un formulario de upload, sin embargo vamos a usar uno básico que consiste en renombrar la extensión al vuelo para subir nuestro archivo que al final disparara el shell reverso.
Entonces iniciemos el proceso.
A.- Descargar y configurar el shell
Descargamos nuestro php reverse shell y lo configuramos de la siguiente forma :
Como podemos ver en la variable $IP estamos declarando la IP del VPS Linux a la cual se enviará el shell, mediante el puerto de salida 1234 declarado en la variable $port
B.- Renombrar para confundir evadir al upload
Luego cambiamos la extensión del archivo de a jpeg como vemos a continuación:
C.- Subir y ejecutar
Con nuestro shell encubierto en un archivo jpeg vamos a subirlo
Luego haciendo uso de un proxy como «burp suite» vamos a renombrar al vuelo la extensión del archivo.
Vemos un poco mas al detalle el cambio
Luego hemos conseguido que suba el archivo y lo ejecutamos en la URL donde se encuentra alojado:
El ataque se completa, sin ser bloqueado por el UTM y se obtiene el shell reverso en el puerto de escucha 1234 del VPS como se muestra a continuación:
Test 4 – Evadiendo el Antivirus de perímetro y ganando shell remota en Windows 7
Contexto: Parte de las características de todo UTM es contar con un antivirus de perímetro, es decir ser la primera defensa ante la entrada de archivos infectados, antes de que estos lleguen a las estaciones de trabajo de los usuarios y puedan comprometer de alguna forma sus estaciones de trabajo, estos ataques son mejor llamados «ataques del lado del cliente».
El ataque: En post pasado «Evadiendo Antivirus con Shellter y Metasploit» mostré como se podía evadir el antivirus local , sin embargo ahora, tenemos un antivirus de perímetro que no debería dejar descargar el archivo infectado.
– Creando el archivo infectado
Vamos a crear un archivo infectado con shellter de la siguiente forma:
Como se ve en la captura, se configura que la IP 192.179.13.203 será quien reciba el shell reverso en el puerto 5555 , en el caso de que se ejecute el archivo infectado.
– Levantando el handler en Mestasploit
ahora levantamos un handler de escucha para recibir el shell reverso
Como se muestra se está esperando el shell en el puerto 5555
– Descargando el archivo infectado en el cliente.
Ahora desde la estación Windows, vamos descargar el archivo infectado, en donde el antivirus de perímetro debería reaccionar.
Como se puede ver , es posible descargar completamente el archivo infectado.
– Ganando shell remota
Ahora lo que sigue es ejecutar el archivo para obtener la shell reversa, aquí quiero detenerme a explicar lo siguiente.
Comportamientos peculiares
Cuando se ejecutó las primeras veces el archivo se puedo completar su ejecución y se obtuvo la shell reversa, sin embargo luego de repetir algunas veces el proceso esto ya no se pudo , es decir el UTM detecto y bloqueo la shell reversa, pero repito después de amenos a ver obtenido 2 o 3 veces la shell reversa.
Comportamiento negativo – Obtención de la shell
Comportamiento positivo – bloqueo de la shell
Como se aprecia en las capturas anteriores al menos se pudo obtener en todos oportunidades se pudo completar el ataque (se obtuvo la shell) pero luego esto ya no fue posible, no se lograba obtener el shell
Como se puede ver, el handler no puede obtener completar el proceso de obtener la sesión de meterpreter .
Y evidentemente la razón fue por que el IPS detecto el ataque
Comportamiento anómalo – obtención de la shell
Como lo indicamos en un momento el IPS detecto la shell reversa , analizando un poco los paquetes pudimos ver que el shell era bloqueada, no en el momento cuando en Windows expulsa el paquete al handler, si no era cuando este, regresaba nuevamente al Windows ( paquete de entrada) y en ese momento era detectado por el IPS.
Debido a esto, cambiamos la configuración del nuestro archivo infectado para que envié la shell al VPS Linux y este fue el resultado.
Como se puede ver luego de ejecutar el archivo, se puede recibir la conexión en el VPS.
Conclusiones
- Las pruebas del lado del pentester fueron de tipo GrayBox, es decir no se tenia conocimiento del tipo de configuración que tenia el equipo UTM, pero si de las direcciones IP de los objetivos.
- Las pruebas realizadas son muy utilizadas por delincuentes informáticos, sobre todo al realizar combinaciones de técnicas es posible tener mayor probabilidad de éxito.
- Es necesario implementar sistemas complementarios para monitorear ataques.
- Es necesario generar reglas personalizadas en el UTM , para cada tipo de situación.
- En las pruebas de AV del lado del cliente, solo fueron realizadas con un tipo de payload, “meterpreter” que es mostrado en las firmas IPS como “Shell reversing” habría que tener en cuenta que no es el único tipo de payload y que el target es directo, es decir hacia Windows (firma conocida).
- No se usa ningún tipo de crypter, encoder, reassembler sino un injector de código dinámico al PE para crear el ejecutable malicioso, el cual como se muestra otorga un canal de comunicación, entre el evilVPS y el target.
- Con mi experiencia en despliegues de seguridad perimetral para empresas, he podido constatar la gran confianza que se tiene a los UTMs como un «all in one» debido a que son económicos y contienen diversas firmas de seguridad en contenidos, cuando realmente estos equipos son solo la primera línea de defensa.
- Además de la actualización de firmas y pago en licencias, se debe tener en cuenta las configuraciones realizadas por el consultor o experto que por mala praxis suelen proveer blancos directos sin necesidad de mucho esfuerzo para el atacante :D.
Finalmente, las pruebas realizadas no tienen la intensión de desprestigiar de alguna forma a una marca en particular, por el contrario, tienen el espíritu de que se realicen con otro tipo de equipos y por supuesto, mejorar la seguridad de las aplicaciones empresariales.
Por ejemplo personalmente esta pendiente realizar pruebas con un equipo de la misma marca que es FortiWeb , que es un equipo mucho mas especializado en protección de ataques web,
Esperen esas pruebas!!
Saludos
Juan Oliva
@jroliva
Hacking Fortinet – SQLI test
Para 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.
El test consistió en poner una aplicación web vulnerable como DVWA la cual estaba protegida por un Appliance Fortinet D60 específicamente.
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.
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.
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.
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
Juan Oliva 