Archivo
Ciberseguridad en tiempos de Coronavirus (Parte 3)
Recomendaciones para todos, Zoom y el acceso a redes empresariales.
En los post anteriores vimos Ciberataques en el mundo luego Ciberataques en Perú para cerrar este tópico aquí veremos una serie de recomendaciones que todos deberíamos considerar hasta recomendaciones mas especificas para entornos empresariales.
1.- Recomendaciones de uso General
- Hacer respaldos de información
- Use una contraseña segura.
- Use contraseñas diferentes para email personal, email corporativos,
redes sociales, etc. - Bloquee manualmente la pantalla o configurar la pantalla.
- del dispositivo para que se bloquee automáticamente al alejarse o al dejar de usarlo.
- Instalar las últimas actualizaciones de software y aplicaciones todos los dispositivos, Celulares, Tablets, PC, Laptop.
- Uso de software antivirus / anti malware comercial y licenciado.
- Verificar correos electrónicos, SMS o mensajes de redes sociales, si son de contactos conocidos.
- No hacer clic en direcciones de internet sin estar 100% seguro.
- No abrir archivos adjuntos si no esta 100% de su origen.
Aquí un estudio reciente donde se muestra las contraseñas mas comunes encontradas durante análisis de vulnerabilidades a nivel global :
Fuente : Raconteur: https://www.linkedin.com/posts/edgescan_raconteur-cybersecurity-report-activity-6648188015975899136-on2J/
2.- Recomendaciones para Zoom.
Como todos sabemos las plataformas de vídeo conferencia se han intensificados y Zoom se ha vuelto una de las principales, como si bien es cierto a la fecha de este post Zoom ha publicado una nueva versión con muchas mejoras de seguridad ademas de comprar una empresa de ciberseguridad para mejorar el cifrado de las comunicaciones los ciberdelincuentes siguen encontrando problemas de seguridad.
Basado en ello, aquí algunas recomendaciones para «mejorar» la seguridad en las conferencias.
- Agregar una contraseña de reunión.
- Establecer el uso compartido de pantalla en «solo host».
- Deshabilitar transferencia de archivos.
- Deshabilitar «unirse antes del host».
- Deshabilite «Permitir que los participantes eliminados vuelvan a unirse» Habilitar la sala de espera.
- No hacer clic en enlaces sospechosos o aceptar archivos en la sala de chat.
3.- Habilitar autenticación multifactor (2FA)
Adicionar un mecanismo para autentificar el acceso es altamente recomendable, teniendo en cuenta que tarde o temprano la contraseña termina siendo guarda en un archivo de texto ( algo que sabes) y puede ser robada fácilmente, contar con una contraseña dinámica (algo que tienes) es decir que cambia cada momento o es enviado por sms es sumantante importante.
Algunos servicios donde se puede activar :
- Correo electrónico personal, los printicales servicios de email como gmail, outlook, hotmail lo soportan.
- Correo electrónico corporativo ( si esto lo soporta).
- Redes Sociales : Facebook por ejemplo.
- Conexiones VPN (Acceso remoto a la red corporativa).
- Inicio de sesión en computadoras corporativas.
Aquí un ejemplo de como activarlo para Facebook :
4.- Acceso a redes empresariales
Debido al teletrabajo ha hecho que muchas empresas textualmente «corran» para implementar soluciones que permitan a sus empleados trabajar desde casa, sin embargo se estan perdiendo de vista ciertas cosas que exponemos a continuación.
4.1.- Acceso cifrado a la red empresarial
sea cual sea la solución para ingresar a la red empresarial, esta debe ser cifrada, como por ejemplo el uso de «servicio de escritorio remoto» o RDP en su configuración por defecto hace uso de cifrado, así mismo cuenta con vulnerabilidades como BlueKeep.
4.2.- Permitir el acceso solo a dispositivos de trabajo
Hoy todos están conectados desde casa, pero se esta viendo que el mismo computador/Laptop que venia siendo usado para el hogar, también esta siendo usado para conectarse a la red empresarial, por tanto si ese computador se encuentra comprometido de algun tipo de virus, también esta comprometiendo la red empresaria.
4.3.- Uso de software VPN sin vulnerabilidades.
Ningún software en ningun sistema operativo se «salva» de tener vulnerabilidaes, es importante que a la hora de implementar los servidores VPN el software a usar siempre sea la ultima version y este libre de vulnerabilidades, al menos en ese momento. Por ejemplo este es el reporte de vulnerabilidades OPENVPN a la fecha, el cual es uno de los software mas usados para implementar este tipo de acceso.
4.4.- Uso de protocolos seguros en VPN
Muchas implementaciones de Servidor VPN no tienen en cuenta que de nada sirve los accesos remotos sin hacer uso de un protocolo que brinde el correcto cifrado en la comunicación, es asi que hacer uso de PPTP sobre SSL o L2TP/IPsec SSTP y IKEv2/IPsec. solo por citar algunos es muy importante.
4.5.- De ser posible uso de 2FA.
Adicionar un mecanismo para autentificar el acceso es altamente recomendable, teniendo en cuenta que una contraseña normalmente se copia fisicamente en algún lado ( algo que sabes) contar con una contraseña dinámica es decir que cambia cada momento o es enviado por sms (algo que tienes) es importante.
A continuación una lista de soluciones basadas en software libre enfocadas a controles de seguridad.
Fuente : http://www.eventid.net/docs/open_source_security_controls.asp
5.- Evaluación de aplicaciones Web y visibilidad en la red empresarial
- Análisis de vulnerabilidades de Aplicaciones web y móviles.
- Revisión de visibilidad del perímetro de la red, ejemplo servicios expuestos.
- Actualización de software en servicios.
- Tratar de no usar servicios que no cifren la comunicación, ejemplo Telnet, FTP, RDP por defecto.
Un estudio de la empresa Edgescan revela las vulnerabilidades mas comunes en evaluaciones sin credenciales sobre sistemas expuestos por internet.
Fuente : https://cdn2.hubspot.net/hubfs/4118561/BCC030%20Vulnerability%20Stats%20Report%20(2020)_WEB.pdf
43% en vulnerabilidades en criptografia, implementaciones de servidor, clientes y APIs/Endpoints en el uso de algoritmos debiles.
20% en Aplicaciones Web, vulnerabilidades que comprometen la seguridad en Aplicaciones web, como XSS, CSRF, SQLI,etc.
15% Relacionado a falta de parches de seguridad, en diversas implementaciones como Apache, Cisco, Citrix, Vmware,etc.
Espero les sirva.
@jroliva
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
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
Juan Oliva 