¿ TU SEGURIDAD AL 100%? – PARTE3 – A

Entre apuros y temas profesionales, recién me desocupo.

Como les comente les el anterior post ¿ TU SEGURIDAD AL 100%? – PARTE2 continuaremos con el pequeño manual  básico del UTM sophos para posteriormente realizar las pruebas de rendimiento a nivel de seguridad, haciéndole focus en el parte de UTM:

Este es el esquema que trabajaremos para las primeras configuraciones:

graf1

  1. ingresamos al portal(de preferencia firefox) https://192.168.20.1:4444

1

  • Aceptamos el certificado inseguro

2

2. En el siguiente panel agregaremos nuestros datos de la empresa, includido empresa, ciudad, pais y un password:

username:admin

password: elquemasteguste

3

aceptamos las condiciones de uso

4

3. esperamos unos 40 segundos e ingramos con nuestro user y password, ojo que el user sera  “admin”

5

4. solo ponemos continuar:

6

5. habrá una licencia de activación por 30 dias, que servirá para realizar las pruebas que deseen:

7

6.  Listo, hasta cada todo bien, ahora cargaremos configuraciones mediante el wizzard, podremos configurar tanto las internfaces como el FW y el UTM(filtro web, antispam, antivirus, antispam etc)

  • interfaz lan:

8

  • interfaz wan(ponemos configurar despues, esto ya depende de uds)

9

  • Con el wizzard podemos crear una regla de salida para ciertos servicios

**** red lan(192.168.20.0/24) permit http,https,dns —> internet

  • Y también permitir realizar pruebas de conectividad hacia el utm:

10

7. En el wizzar también podremos realizar activaciones y configuraciones del IPS, filtro web, antispam (ojo por 30 dias)

  • Activación del ips

11

  • Activación del filtro web y antivirus

12

antispam

14

8) bueno ya esta casi listo para comenzar, aca aparecera un resumen de lo que hemos hecho.

15

9) Este sera nuestro primer panel, las caracteristicas del panel son como la de la mayoria de equipos UTM, apareceran licencias, versiones de sistemas operativo, consumo de CPU, tambien podemos añadirles widgets, para verficar alincion por ejemplo las reglas FW y  del UTM escritas asi como logs del sistemas y de seguridad

16

  • Como nota importante es las secciones de configuracion:

Donde estara el managment, interfaz routing, definition user etc

secciones

El el panel de control verificamos:

  • Interfaces activas:

17

  • Consumo de cpu

cpu

  • Registro de log de amenazas

AMENAZAZ

  • Así como también podemos agregar mas widgets.

widget

20

10.Bien ahora iremos en la parte izquierda a la sección de interface y routing, en esta sección podemos verificar el estado de las interfaz, con cuadros referenciales al consumo de ancho de banda, estado de la interfaz etc

21

  • Aca existen varias subsecciones:

subseccion1

11. En la subseccion  interfaces

por ejemplo podemos observar o re configurar la interface managment:

22

  • Crear una interfaz wan:

interfacewan

  • Dando en up a la interfaz creada:

23

12. También podemos crear rutas estáticas, en el menú izquierdo en la subseccion de routing static:

24

  • podemos configurar rutas como las siguientes:

25

13. Ahora para crear objetos tanto a nivel de redes como de servicios iremos a la seccion Definition & users

  • Dentro de esta sección tendremos muchas subsecciones

subseccion2

  • Creamos un network definitions

networkdef

  • También podemos crear un service definition

27

14. listo, despues de crear el service y el network definition podemos crear reglas en el FW:

En network protection / firewall

28

30

activar la regla

31

15. Y podemos verificar los logs:

32

En la próximo post (parteB) hablaremos un poco de el UTM, para posteriormente crear el siguiente esquema muy similar a hacking fortinet , donde tendremos un servidor expuesto a la nube con un software vulnerable(pentesterlab)

esquemavitima

Saludos

continuara:

Alexis Torres  @dUn_h4t

post anterior

require_once(/var/www/html/common/lib/../../vendor/autoload.php) en A2BILLING

Es claro que este tema de tecnología cambia mucho y uno tiene que estar preparado para las actualizaciones y los colaterales que puede traer, es así que durante el curso de Vicidial que vengo impartiendo, se presentó un problema al instalar A2billing desde los repositorios es Github, es decir la última versión del software.

El problema es que después de realizar todo los procedimientos de instalación, no era posible ver la interfase de administración de a2billing, metiéndonos en el log de error de apache vemos el siguiente error.

a2billing

Luego investigar un poco, se indagó que se tenia que hacer dos cosas , por un lado actualizar la versión de PHP que viene en mi caso en Centos 6.6 que es la 2.3.0 y luego instalar un componente llamado Composer en PHP , entonces el procedimiento fue el siguiente :

1.- Actualizar la versión de PHP en Centos 6.6

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
yum –enablerepo=remi update php-\*

Una vez actualizado la versión de PHP es la 5.4.3 como se muestra a continuación:

a2billing

2.- Instalar Composer
Ingresamos primero donde hemos descargado las fuentes de a2billing.

cd /usr/local/src/a2billing
curl -sS https://getcomposer.org/installer | php
php composer.phar update
php composer.phar install

3.- Finalizar la instalación de a2billing
Si ya hemos copiado las carpetas, es necesario eliminarlas de apache.

ln -s /usr/local/src/a2billing/common /var/www/html/common
ln -s /usr/local/src/a2billing/admin /var/www/html/admin
ln -s /usr/local/src/a2billing/agent /var/www/html/agent
ln -s /usr/local/src/a2billing/customer /var/www/html/customer

chmod 755 /var/www/html/admin/templates_c
chmod 755 /var/www/html/customer/templates_c
chmod 755 /var/www/html/agent/templates_c
chown -Rf apache:apache /var/www/html/admin/templates_c
chown -Rf apache:apache /var/www/html/customer/templates_c
chown -Rf apache:apache /var/www/html/agent/templates_c
service httpd restart

Ahora ingresamos nuevamente : http://TUIP/admin y veremos la pagina con la ultima versión de a2billing:

a2billingEspero les sirva
Saludos
Juan Oliva

 

 

 

¿ TU SEGURIDAD AL 100%? – PARTE2

Bueno continuando con el anterior post PARTE 1, ahora vamos a preparar el entorno virtual para instalar nuestro UTM – SOPHOS.

Detallo los topics a tocar:

SOPHOS UTM – PARTE2: PRIMEROS PASOS

  • Preparando el ambiente
  • Instalación de UTM sophos

A)PREPARANDO AMBIENTE

1) Preparamos nuestro vmware con nuestro .iso descargado asg-9.304-9.1.iso

File/New virtual Machine

Captura

2) En la parte inferior seleccionamos el iso a usar despues de descargarlo, dependiendo el directorio donde lo hallas descargado,

Installer disc image file(iso):

Luego next

captura2

 

3) Aca sellecionamos el sistema operativo base a usar, en mi caso puse other, pueden usar Linux o algun otro distro:

 

sophos2

 

Next>

 

4) Luego le damos un nombre y ubicamos donde se guardara nuestra maquina virtual:

sophos3

 

Next>

 

5) Aca seleccionaremos el espacio virtual de disco, lo dejamos por defecto:

sophos4

 

Next>

6) Seleccionamos cuztomizar hardware,la función principal es agregar al menos 3 adaptadores lan virtual, para simular:

Wan –> Network Adapter

Lan –>  Network Adapter2

Dmz –>  Network Adapter 3

sophos5

 

Captura3

 

 

Captura4

 

Next >

Y asi creamos 3 interfaces.

 

7) Algún muy importante despues de crear las interfaces es poner las 3 interfaces en modo bridge (paso2)
sophos6

B)INSTALACION DE SOPHOS

Después de preparar el ambiente comenzaremos con la instalación de sophos UTM:

1) seleccionamos Power on this virtual machine

Captura5

2) nos aparecerá la pantalla de arranque, simplemente presionamos enter:

Captura6

3) Nos aparecerá la pantalla de “introducción”, ponemos start

sophos8

 

 

<Start>

** La maquinar virtual SOPHOS, detectara las características de HW:

sophos9

 

<OK>

4) Acá pueden seleccionar el idioma a preferencia en mi caso cuando instale por primera vez use Spanish, en las posteriores POST veran una imagen actual en version English:

 

sophos10

 

5) seleccionamos ubicación y país:

America/Peru

sophos11

 

<next>

Captura7

<next>

Captura8

<next>

6) ahora seleccionamos por cual interfaz podremos levantar la administracion via web,  escojemos eth0

 

 

Captura9

 

<Next>

7) ahora configuramos la IP DE ADMINISTRACION en mi caso sera, 192.168.20.1/24

Captura10

<Next>

 

8) seleccionamos el kernel a instalar, 64bits:

Captura11

 

<Yes>

9) podemos instalación de todas sus capacidades ya que estaran en un tiempo de prueba de 30 dias:

Captura12

 

<Yes>

10) Ahora solo aparecer un banner con los features del appliance , solo aceptamos.

11) Seleccionamos la partición por defecto a instalar,el cual borrara para realizar una instalación limpia:

Captura13

 

<yes>

13) luego comenzara a realizar su proceso de instalación y a continuación les aparecerá la ip de administración, el equipo rebooteara:

IP MGMT: https://192.168.20.1:4444

Captura14

 

 

 

<Reboot>

**en el proceso de reinicio se mostrara nuevamente el la ip de administración:

Captura15

 

 

Listo en la siguiente entrada “SOPHOS UTM – PARTE3: REGLAS BASICAS”

hablaremos del procedimiento para administracion, dasboard y jugaremos con algunas reglas.

No se olviden de revisar el Post anterior

 

SOPHOS UTM – PARTE1: CONCIENDO AL UTM

Salud0s

@dUn_h4t

 

 

¿TU SEGURIDAD AL 100%?

 

Saludos otra vez, bueno aprovechando el trabajo con Juan Oliva decidí realizar un conjunto de pruebas sobre dispositivos de seguridad denominados UTM(Unified Threat Management) con el fin de probar sus capacidades reales de reacción ante un eventual ataque, todo esto quizás sirva para realizar una estadística de cuan seguro estamos si depositamos nuestra confianza en este variopinto de equipos, que como di mi opinión en BYPASSING FORTINET debería ser solo nuestra primera línea de defensa.

 

ADVERTENCIAS

  • En las pruebas subsiguientes vamos a usar un ambiente virtual, con el firmware lo más actualizado posible.
  • El TARGET es vulnerable y está en una DMZ, el blanco va a ser la DMZ por obvias razones, la exposición hacia internet, para luego realizar pruebas desde el lado del cliente.
  • Las pruebas a las firmas del UTM son de concepto es decir básicas, por ahí quizás podamos tratar de usar otros mecanismos de evasión como encoders o ofuscadores.
  • No se empleara ataques de DOS porque cualquier equipo puede ser vulnerable al mismo, este es otro tema de discusión.
  • No se analizara la estructura informática de la plataforma UTM por el momento, trabajo futuro.
  • Como parte final y mas importante: este conjunto de pruebas no tienen como fin desprestigiar a alguna marca, sino concientizar a los administradores de red o expertos en seguridad de la información que no basta con comprar equipos sino que es un trabajo en conjunto y que va desde capa1 a capa7 (siguiendo modelo OSI) donde está en juego la reputación de la empresa.

 

 

SOPHOS FIREWALL

Este solo es un manual de configuración básico dirigido a pruebas de pentesting de un potente UTM – SOPHOS, no es muy conocido al menos en el mercado Peruano, me gustaría saber cómo va en el mercado internacional, porque he leído buenos comentarios al respecto.

el topic va a constar de 4 partes:

SOPHOS UTM – PARTE1: CONCIENDO AL UTM

SOPHOS UTM – PARTE2: PRIMEROS PASOS

  • Preparando el ambiente
  • Instalación de UTM sophos

SOPHOS UTM – PARTE3: REGLAS BASICAS

  • DASHBOARD
  • RUTAS
  • FIREWALL
  • UTM

SOPHOS UTM – PARTE4: PENTESTING

  • PENTESTING SOBRE FIRMAS UTM
  • PENTESTING CLIENT SITE ATTACK
  • PENTESTING SOBRE FW

 

SOPHOS UTM – PARTE1: CONOCIENDO AL UTM

Lo que dice el autor:

“La gestión unificada de las amenazas simplifica la seguridad Sophos UTM proporciona seguridad completa, desde cortafuegos de red

a antivirus para estaciones de trabajo, en un solo dispositivo por módulos.

Simplifica la seguridad informática y elimina las complicaciones de utilizar soluciones diferentes en varios puntos. La interfaz intuitiva ayuda a crear políticas rápidamente para controlar los riesgos para la seguridad, mientras que los informes claros y detallados le ofrecerán toda la información que necesita para  mejorar la protección y el rendimiento de la red.”

Aspectos destacados

  • Todas las funciones están disponibles en todos los dispositivos Cortafuegos, VPN, ATP,
  • IPS, email, filtrado web y control de aplicaciones
  • Dispositivos de hardware, virtuales, software o en la nube
  • Interfaz web intuitiva
  • Informes incorporados en todos los modelos
  • Autenticación de doble factor y contraseñas de un solo uso en muchas áreas
  • Controlador inalámbrico integrado

 

Requerimientos mínimos

  • Processor: Pentium 4 with 1.5 GHz (or compatible)
  • Memory: 1 GB RAM
  • HDD: 20 GB IDE or SCSI hard disk drive
  • CD-ROM Drive: Bootable IDE or SCSI CD-ROM drive
  • NIC: Two or more PCI Ethernet network interface cards
  • NIC (optional): One heart-beat capable PCI Ethernet network interface card. In a highavailability system, the primary and secondary system communicate with one another through so-called heart-beat requests. If you want to set up a high-availability system, both units need to be equipped with heart-beat capable network interface cards.
  • USB (optional): One USB port for communications with a UPS device
  • Switch (optional): A network device that connects (and selects between) network segments.
  • Note that this switch must have jumbo frame support enabled.

Modo de despliegue

Tiene 4 tipos de despliegue:

  • Los dispositivos de hardware
  • Los dispositivos de software
  • Los dispositivos virtuales
  • Los dispositivos basados en la nube

 

Donde lo descargo:

Descargamos  el modo software de evaluacion por 30 dias, para llevarlo a nuestro vmware:

https://secure2.sophos.com/en-us/products/unified-threat-management/free-utm-trial.aspx#start

sophos0

Esperemos la próxima entrada:

SOPHOS UTM – PARTE2: PRIMEROS PASOS

Saludos.

Alexis Torres

 

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:

fortinet-esenario

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

hackingfortinet

A Appliance Fortinet D60 with licenses of the IPS and Antivirus activated as you can see below:

fortinet

Also, during the tests detailed below, several configuration profiles were tested as follows:

Profile “Default” activated in the IPS

hacking-fortinet

Profile “High Security” activated in the IPS

hacking fortinet

Profile “protect_http_server” activated in the IPS

hacking fortinet
Profile “default” activated in the AV

hackingfortinet

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.

hackingfortinettrying to introduce a SQLI in the web application, we see that the IPS blocks attack:

hackingfortinetAll 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:XSS

As shown, the XSS attack sent via the document.cookie” object ,  current session to an external URL http: //192.80.190.1XX/b.php

XSSThen the attacker 2 receives the string sent by the XSS stored in the web application, as follows:

hijackingAs 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.

fortinet

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:

fortinetIn 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:

fortinetAs 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:

fortinet
C. Upload and execute file
With our shell covered in a jpeg file, we will upload
fortinetThen using a proxy as “burp suite” we will rename the file extension on flight.
fortinetSee a little more detail the change
fortinetThen, the file is uploaded, and execute in the URL where it is housed in the web server.
fortinetLater, 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:

fortinetfortinet

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 Metasploitshowed how they could evade the local antivirus,

– Creating the infected file
Let’s create a Shellter infected file as follows:

hackingfortinetAs 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
hackingfortinetAs 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.
hackingfortinethackingfortinet11830837_10153137243563160_817221665_n
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
hackingfortinethackingfortinethackingfortinethackingfortinet
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.

hackingfortinetAs 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.

hackingfortinet

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 :

hackingfortinetAs you can see after running the file, you may receive the connection in the VPS.

Conclusions

Juan Oliva

  • 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.

Alexis Torres

  • 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 :D

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 :

fortinet-esenario

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

hackingfortinet

Un equipo Fortinet D60 con las licencias de IPS y Antivirus activado como se puede ver a continuación :

fortinet

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

hacking-fortinet

Perfil “High Security”  activado en el IPS

hacking fortinet

Perfil “protect_http_server”  activado en el IPS

hacking fortinet

Perfil de AV en modo “default”

hackingfortinet
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.

hackingfortinetLuego tratar de introducir un SQLI vemos que el equipo lo bloquea:

hackingfortinet

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 :

XSS

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

XSSLuego el atacante 2, recibe la cadena disparada por el XSS almacenado de la siguiente forma :

hijackingComo 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 :D 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 :D

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.

fortinet

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 :

fortinetEn 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 :

fortinetComo 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:

fortinet
C.- Subir y ejecutar
Con nuestro shell encubierto en un archivo jpeg vamos a subirlo

fortinetLuego haciendo uso de un proxy como “burp suite” vamos a renombrar al vuelo la extensión del archivo.

fortinetVemos un poco mas al detalle el cambio

fortinet

Luego hemos conseguido que suba el archivo y lo ejecutamos en la URL donde se encuentra alojado:

fortinet

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:

fortinetfortinet

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:

hackingfortinetComo 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

hackingfortinetComo 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.

hackingfortinethackingfortinet11830837_10153137243563160_817221665_n

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

hackingfortinet

hackingfortinet

hackingfortinet

hackingfortinet

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

hackingfortinetComo 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

hackingfortinet

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.

hackingfortinet
Como se puede ver luego de ejecutar el archivo, se puede recibir la conexión en el VPS.

Conclusiones

Juan Oliva

  • 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.

Alexis Torres

  • 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

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 129 seguidores