Vulnerabilidad en A2BILLING ELASTIX 2.5 2.4 thanku-outcall iridium_threed.php

Por experiencia algunas vulnerabilidades toman un tiempo en “madurar” o hacerse masivas, esto ha pasado con está específicamente. En estas ultimas semanas he recibido muchas noticias y comentarios de hackeos a plantas, PBX, Centrales basadas en Elastix 2.4 y 2.5 en donde se crean un contexto llamado thanku-outcall esto por lo general, nombre del contexto puede cambiar evidentemente,  el objetivo es que se crea un contexto que permite sacar llamadas o en algunos casos mas creativos permiten originar llamadas solo para abrir un canal hacia un 0800 por ejemplo.

Como ingresan ? Cual es el punto de acceso?
Pues para variar el punto de acceso es vía Web ( Puerto 80, 443)  se trata de un archivo vulnerable en A2billing específicamente el archivo “iridium_threed.php” el cual permite una inyeccion SQL el cual inserta un registro en el servidor de base de datos de esta forma:

Luego de ello se crea un contexto en el archivo extensions_custom.conf alguna variante puede hasta crear un archivo en el directorio de publicación de apache.

La vulnerabilidad es clasificada como crítica. El punto de acceso es una función desconocida del archivo a2billing/customer/iridium_threed.php del componente Billing es afectada por esta vulnerabilidad. Mediante la manipulación del parámetro transactionID de un input desconocido se causa una vulnerabilidad de tipo sql injection.

La vulnerabilidad fue publicada el 2015-03-07 en exploitdb  la cual pueden verificar en https://www.exploit-db.com/exploits/36305/. La vulnerabilidad es identificada como CVE-2015-1875. La explotación se considera fácil. El ataque se puede efectuar a través de la red. La explotación no necesita ninguna autenticación específica.

Como parcho , Como lo corrijo o mitigo?
Si necesitas A2billing , es migrar a la versión superior, ya que la que trae Elastix es una version bastante antigua,  sin embargo sabemos que en las PBX no necesitas este software, lo recomiendo personalmente  es eliminarlo sacar del directorio de publicación de apache la carpeta A2billing.

Y si no tengo publicado mi Elastix no me interesa ?
Pues si te debería interesar ya que los hackeos no necesariamente vienen desde afuera, ahora con las vulnerabilidades como wanacry no te puedes fiar de tu red interna.

Y si tengo Issabel PBX o FreePBX ?
Pues para tranquilidad Issabel o FreePbx no trae A2billing fue un gran acierto eliminar aplicaciones “extra”

Espero les sirva la info.
Juan Oliva
@jroliva

 

 

 

 

Hacking Fortinet – WAF TEST

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

waf

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.

fortiweb

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.

fortiweb

Escenario

escenario-waf

fortiweb

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)

fortiwebVemos 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

fortiwebVemos que el WAF reacciona y bloquea la ejecución del XSS reflejado

fortiweb

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

fortiwebTambién vemos que el WAF reacciona y bloquea la ejecución del XSS

fortiweb

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

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 :

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

fortiwebAsí mismo el evento queda registrado como se muestra a continuación:

fortiwebEs 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)

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

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

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

fortiweb

Scenario:

 

escenario-waffortiweb

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.

A. Without the WAF protects web application
Xss tested the following string: alert (document.cookie)
fortiwebsee that reflected XSS is complete
B. With the WAF protects web application
Retest the same test but now with the WAF protects web application
fortiwebsee that the WAF reacts and blocks the execution of reflected XSS
fortiwebAlso 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

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

fortiwebWe also see that the WAF reacts and blocks the execution of XSS

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

Selection_222

A. Without the WAF protects web application
Without the WAF protecting , may save the file and complete the defacement as follows:

fortiweb

B. With the WAF protects web application
Retest trying to save the index.php file with the WAF protecting and it reacts like this:

fortiwebLikewise, the event is recorded as shown below:

fortiwebWAF 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