Issabel ISO (Latest): Download Here
Cloud Services: User Portal - Quick Guide
News: Telegram channel
Become a Patron!
  • General
  • Beware: New Elastix 2.5 / 4.0 FreePBX 2.11.0.26 exploit..

Lo raro si ya tienes bloqueado con htaccess el acceso es que pueda volver a hacerlo mediante get o post por web, imagino que tendrias algun script o fichero metido todavia. En teoria una vez elimines todo lo infectado con el htaccess no te debe volver a pasar al menos si el ataque es por web ( por ejemplo intentan hacer un get o post a cualquier pagina no podran si no tienen usuario y clave del htaccess.

En cuanto elimines todo lo problemático dentro del servidor no se te deberia volver a infectar.

Otra solucion para buscar posibles ficheros sospechosos es buscar cualquier fichero cuayo ultimo acceso fuera por ejemplo hoy o ayer o el dia x que sepas que te han entrado igual te salen muchos pero te limitara la busqueda

    navaismo Gracias! Eso mismo estoy haciendo ahora aunque es esa IP en cuestión y otras más.. En realidad acabo de darme cuenta que ponerle password al http como sugirió hgmnetwork si está funcionando, lo que pasa es que me olvidé de un paso en uno de los servidores afectados ya que este es el ssl_access log de un servidor al que trrataron de entrar pero no pudieron:

    89.249.67.50 - - [13/Jun/2017:05:31:39 -0400] "GET / HTTP/1.1" 401 381
    213.202.233.77 - - [13/Jun/2017:05:31:39 -0400] "GET /recordings/misc/salem.php HTTP/1.1" 403 227
    89.249.67.50 - - [13/Jun/2017:05:44:35 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:05:58:07 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:06:11:47 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:06:23:10 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:06:34:36 -0400] "GET / HTTP/1.1" 401 381
    163.172.68.183 - - [13/Jun/2017:06:34:41 -0400] "GET /a2billing/customer/templates/default/footer.tpl HTTP/1.1" 401 381
    216.218.206.68 - - [13/Jun/2017:06:45:01 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:06:45:38 -0400] "GET / HTTP/1.1" 401 381
    216.218.206.68 - - [13/Jun/2017:06:45:46 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:06:56:28 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:07:08:26 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:07:19:34 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:07:31:06 -0400] "GET / HTTP/1.1" 401 381
    89.249.67.50 - - [13/Jun/2017:07:55:53 -0400] "GET / HTTP/1.1" 401 381

    Como ves error los intrusos obtienen el error 401 que es UNAUTHORIZED y 403 (FORBIDDEN) no pueden hacer nada. Es una molestia tener que ingresar doble clave (La del servidor Apache y la propia de Elastix / issabel) pero algo que los clientes sabrán entender cuando se les dice que es para evitar intrusos en el sistema.

    Adicionalmente todo parece indicar que es a través de los scripts de recordings por donde están vulnerando a Elastix como indicaste.

    striderec En realidad no deberias tener abierto los puertos hacia la WAN. Desde ahí comienza el problema, Tu diseño debe seguir estas preguntas:
    -- ¿Realmente necesitas abrir puertos?
    -- Si tienes que abrir puertos, solo se hace a IP conocidas.
    -- Si las IPs son dinamicas una VPN soluciona el problema.

    Es regla básica jamás abrir puertos a la WAN sin un filtro o sin VPN precisamente por lo que te ha pasado. Lo mejor es reinstalar el PBX ya que no has podido identificar si hay script en el server.

      navaismo Generalmente sólo abro el PBX a las IPs mías (oficina, casa, IPs fijas del cliente si las tuviera), tengo el módulo anti hacker y el firewall activo para evitar esto pero como sabemos todos los hackers siempre se las ingenian para ver cómo entran.

      La VPN es buena idea pero desafortunadamente sirve sólo para instalaciones "en el sitio" (locales) las cuales en el caso particular de mi negocio casi no tengo ya que a la mayoría de mis clientes les gusta la idea de tener algo hosted fuera de su oficina o en la nube y el 95% de mi clientela tiene Elastix virtualizados con VMWare ESXi 6.5 desde mi centro de datos por lo cual la VPN no es solución adecuada debido a una razón simple: Todos mis clientes son extensiones remotas y salvo honrosas excepciones no todos los teléfonos IP tienen cliente VPN incorporado en su firmware para poder conectarlos de esa forma a la red de mi centro de datos..

      striderec Fijate que por los logs te están haciendo un básico ataque de diccionario para ingresar (todos los POST a / ). Poniendo .htaccess se les hará más complicado (quizas los script kiddies no usan basic http auth y solo automatizan los posts)... o bien tendrán dos claves que adivinar.

      ARI es un conocido vector de ataque, no estoy seguro de que en la version incluída en Issabel 4 existan las vulnerabilidades en callme.php y similares que parecen haber sido los vectores de ataque en tu caso... es posible que eso esté resuelto, pero no puedo garantizarlo.

      ARI es uno de los primeros candidatos a ser removido, luego de a2billing que ya fue removido del ISO. A menos que existan usuarios que puedan aportar los parches de seguridad adecuados, lo que posiblemente decidamos sea retirar la funcionalidad (desarrollada por terceros), o forzar capas de autenticación .htaccess. Pero lo ideal a mediano plazo sería reemplazarlo por herramientas propias y más modernas, al igual que FreePBX.

      Sería bueno armar un equipo de "seguridad" que pueda hacer pruebas y pen testing , o que pueda intentar usar todos los exploits conocidos sobre una instalación fresca.

      Saludos,

      asternic Nicolás, apliqué lo indicado por hgmnetwork y por lo menos hasta ahora los potenciales atacantes están recibiendo los errores HTTP 401 y 403 lo cual es positivo hasta el momento. Igual estaré monitoreando mis servidores afectados durante todo el día para saber si así se ven finalmente truncados en sus intentos de ingresar y dañar el acceso GUI de FreePBX.

      Lo que me preocupa es que http y https están bloqueados en el firewall para IPs que no sean la mía y las fijas de los clientes pero aún sigo viendo intentos de accesar a la central por esos puertos lo cual me deja pensando si algo del firewall de Elastix no está funcionando bien o si no está aplicando las reglas en el orden correcto.

      Yo entiendo que la prioridad es de número mayor a número menor lo cual significa por ejemplo que la regla #12 se aplica primero que la regla #8 y por ende lo que la regla #8 "libere" viene después de lo que yo haya "bloqueado" en la regla #12. Ejemplo: En la regla #12 de acuerdo al firewall de Elastix he bloqueado http a todo el mundo y en la regla #8 desbloqueo http para 127.0.0.1 y en la #9 desbloqueo http para la IP fija de mi oficina. Si entiendo esta lógica correctamente esta acción debería permitir el paso al puerto http a las IPs de la regla #8 y #9 pero a nadie más. Corríjanme si me equivoco?

      A mi siempre me ha gustado aportar con reportes de bugs del sistema o con problemas de cualquier índole. Ayuda mucho que yo comercializo elastix virtualizado junto con DIDs y minutos de llamadas locales o internacionales para oficinas y call centers. Estoy día a día monitoreando mis servdores para estar pendiente de cualquier ataque o problema que pueda haber y reportarlo.

        asternic y por cierto, estos ataques fueron realizados también a instalaciones limpias, nuevecitas de paquete de Elastix 4.0 que se supone tiene CentOS 7 y no el 5.11 que ya está descontinuado. Es decir que el exploit del script está presente incluso en la versión "mas reciente" del antiguo Elastix.

        striderec Todo lo que puedas reportar es más que bienvenido. Con respecto a las reglas de firewall, lo único que puedo sugerir es que las veas en consola, no por web:

        iptables -vnL

        Y ahí podrás verificar el orden de las mismas. Elastix 4 tiene muchos bugs debido a la intriducción de Centos 7, incluído el que NO INICIALIZA el firewall aunque en el GUI diga que si. Y el GUI no comprueba nunca si el firewall (iptables), está corriendo o no.

        El comando de arriba te va a mostrar si hay reglas o no creadas.

        Issabel 4 ha cambiado mucho de lo que fue Elastix 4:

        FreePBX fue forkeado a IssabelPBX en su version 2.11.43 (esa versión corrige muchos de los exploits de freePBX).
        Hemos corregido el bug anteriormente mencionado con el firewall y además muestra en GUI el estado real.

        Hemos comprobado que hay exploits no reportados/conocidos en A2Billing, por lo que lo hemos removido del .iso y próximamente de los repositorios de modo preventivo.

        Es posible que existan otros exploits in freePBX (IssabelPBX ahora), o en el código que era de Elastix, y estamos trabajando proactivamente para resolver/minimizar incidencias.

        En la próxima semana anunciaremos la versión estable de Issabel 4, y te pediremos entonces que puedas al menos migrar uno de tus sistemas (si tienes tiempo y ganas, puedes hacerlo con nuestra versión de desarrollo esta misma semana), para luego monitorear este nuevo sistema y veas si es atacado y exploiteado.

        Si quieres experimentar con la iso de Issabel 4, dime por privado y te hago llegar un link para que lo pruebes.

        Saludos,

        Estuve sufriendo el mismo ataque, todos los días a las 00:22 se elminaban varios archivos, lo mitigue con un script que recupera desde un backup anterior los archivos afectados. También bloqueé todo el tráfico https que por error había quedado expuesto a la pública y eliminé el file magnito.php que sólo se encontraba en el directorio _asterisk, curiosamente con fecha de Octubre de 2015 que es la de instalación de la central. Por ahora desde hace una semana que no tengo inconvenientes y por si acaso también eliminé el directorio /usr/src/a2billing.

          alvbosch Hola AlvBosch,

          Estaba pensando en un script también pero pensé que el dañar la interfaz pudiera ser sólo la punta del iceberg para este ataque y que quizá el transfondo sea usar tu servidor para hacer ataques DDoS a otras redes o la tuya propia a parte de tratar de robarse minutos. Por ahora con los cambios que apliqué hoy gracias a hgmnetwork puedo decir que 10 horas después aún no me han tumbado el FreePBX en ninguno de los 3 servidores que me estaban atacando (3 con Elastix 4.0 y 1 con Elastix 2.5)

          asternic Nicolás,

          Gracias por toda la información que me has proporcionado sobre el Issabel 4.0 oficial.

          Uno de mis clientes está de acuerdo en hacer el upgrade a Issabel 4.0 y usarlo como lo hace con Elastix 4.0.

          ¿Cómo te contacto para el Link y realizar la prueba? Este servidor de este cliente en particular también estaba siendo blanco del ataque LORD MAGNITO V 1.0

          Con mucho placer haré pruebas de todo tipo y reportar anormalidades que encuentre tanto en funcionalidad como en algún agujero de seguridad de ser el caso.

            striderec Actualización: Ya fastidiaron a uno de los servidores con Elastix 4.0... YO creo que las reglas del firewall no es están ejecutando correctamente.......

              Me alegra saber que la ayuda del htaccess ha mitigado los ataques aunque efectivamente es algo mas molesto para los clientes, lo bueno que se puede almacenar la clave y solo es darle aceptar. y para ataques via http/https ayuda mucho ya que deben vulnerar primero una y posterior la otra y con el htaccess y el fail2ban el que entre o conoce las claves o algo ha pasado :D

              asternic, Seria bueno en el modulo antihacker poner esa opcion el poder mediante htaccess crear 1 o x usuarios y asi quien desee activarlo pueda mediante el modulo y de forma facil añadir, modificar o quitar usuarios autorizados o eso creo yo :D.

              Basicamente yo suelo instalar el CSF Firewall junto con el webmin para poder controlar el servidor y bloqueando en el CFS y permitiendo solo el pais al que dedican o bloqueando por ejemplo rusia, china y algun pais raro con eso el fail2ban y el htaccess hasta la fecha ( y por suerte :D ) de momento no hemos tenido incidencites grabes.

              Me parece una idea estupenda el poder hacer pruebas. Actualmente tengo un servidor vacio reservado para cuando saquen el estable de issabel 4 poder instalarlo , en cuanto lo instale probare todas las opciones

              Saludos!

              asternic Podríamos considerar agregar por defecto en Issabel 4 el mod_evasive en apache? Este ayudará a mitigar ataques de fuerza bruta.

              striderec Podrías compartir con nosotros los log referentes al ataque realizado a Issabel 4? Sería interesante identificar y mitigar posibles vulnerabilidades.

              hgmnetwork Hola hgmnetwork,

              Gracias por toda tu ayuda. Desafortunadamente para mí creo que la misma llegó muy tarde puesto que todos mis PBX Elastix afectados con el problema amanecieron hoy nuevamente con el freePBX dañado y el famoso magnito.php presente. Tal parece que ya es un script que se ha metido y que desde adentro está fastidiando porque revisando ssl_access.log potenciales atacantes sólo reciben error 401 y 403 de HTTP

              Me va a tocar exhaustivamente buscar scripts PHP con fechas recientes y borrarlos ya que esto para mí prueba de que es algo que ya está metido y no importa lo que haga, me van a seguir fastidiando la vida.

              Otra Consulta: Pueden cohexistir el módulo de firewall de Elastix / Issabel con CSF Firewall y con el anti-hacker? No quisiera tener una ensalada de productos para proteger al sistema contra intrusos y luego entre ellos se fastidien y resulte en problemas en el PBX o resultados no deseados en la protección.

              Gracias de nuevo por todo,

              Paul

                markmarco16 Hola Mark,

                Los ataques que he reportado no han sido contra Issabel 4 sino Elastix 2.5 y Elastix 4.0. Déjame saber si igual te interesa ver los logs o no por favor.

                Nicolás indicó que el fork del FreePBX con el que Issabel viene es el 2.11.0.43 que ya no tiene esta vulnerabilidad y Elastix como has de saber llegó sólo hasta el 2.11.0.26

                Estoy considerando migrar dos de estos servidores a Issabel 4 pero quisiera saber si con sólo cambiar los repositorios y correr "yum update" el Elastix 2.5 y 4.0 se convierten en Issabel 2.5 y 4.0 respectivamente..

                asternic Nicolás,

                Definitivamente creo que las reglas no se están aplicando bien porque en /var/log/messages veo intentos de conexión al servidor TFTP que está bloqueado para todos menos mis IPs así como el mismísimo http o https.

                EL resultado de correr iptables -vnL en uno de mis Elastix atacados es:

                Chain INPUT (policy ACCEPT 148K packets, 107M bytes)
                pkts bytes target prot opt in out source destination

                18 840 f2b-vsftpd tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 21
                11378 885K f2b-ssh tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 45622
                26353 2717K f2b-https tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 80,443
                6060 3205K f2b-asterisk udp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 5060

                Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
                pkts bytes target prot opt in out source destination

                Chain OUTPUT (policy ACCEPT 112K packets, 21M bytes)
                pkts bytes target prot opt in out source destination

                Chain f2b-asterisk (1 references)
                pkts bytes target prot opt in out source destination

                12 8924 REJECT all -- 146.0.32.94 0.0.0.0/0 reject-with icmp-port-unreachable
                1229 786K REJECT all -- 154.16.126.40 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 95.154.217.168 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 95.110.232.224 0.0.0.0/0 reject-with icmp-port-unreachable
                28 21757 REJECT all -- 92.114.32.74 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 89.163.146.72 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 89.163.146.243 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 89.163.144.189 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 87.106.16.49 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 82.165.97.126 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 62.210.181.99 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 62.210.181.161 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 62.210.143.74 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 51.15.71.197 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 51.15.146.174 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 5.152.215.58 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 5.104.111.244 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 5.104.105.102 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 45.61.34.247 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 45.243.58.167 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 37.8.37.27 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 35.184.220.231 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 31.6.23.109 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 23.239.70.162 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 23.239.69.227 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 23.239.66.123 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 213.202.233.77 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 213.202.233.200 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 212.83.168.81 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 212.47.247.54 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 212.129.47.132 0.0.0.0/0 reject-with icmp-port-unreachable
                29 16511 REJECT all -- 209.126.117.58 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 209.126.116.166 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 195.154.214.162 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 185.111.228.246 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 185.111.228.158 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 163.172.4.70 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 163.172.121.136 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 139.196.15.87 0.0.0.0/0 reject-with icmp-port-unreachable
                0 0 REJECT all -- 104.143.31.104 0.0.0.0/0 reject-with icmp-port-unreachable
                4762 2371K RETURN all -- 0.0.0.0/0 0.0.0.0/0

                Chain f2b-https (1 references)
                pkts bytes target prot opt in out source destination

                0 0 REJECT all -- 95.141.35.112 0.0.0.0/0 reject-with icmp-port-unreachable
                26353 2717K RETURN all -- 0.0.0.0/0 0.0.0.0/0

                Chain f2b-ssh (1 references)
                pkts bytes target prot opt in out source destination

                11378 885K RETURN all -- 0.0.0.0/0 0.0.0.0/0

                Chain f2b-vsftpd (1 references)
                pkts bytes target prot opt in out source destination

                18 840 RETURN all -- 0.0.0.0/0 0.0.0.0/0

                striderec Te recomendaria instalar el webmin + modulo csf (Firewall) y hay bloqueas cualquier ip que no sea del pais xx asi pones solo las que sepas que son mas viables.

                Aparte puedes bloquear si hacen x intentos o peticiones

                Suele ser muy efectivo yo lo tengo instalado en los elastix 2.5 ( no llegue a poner ningun 4 en producción)

                Es bastante facil de instalar.

                yum install webmin

                una vez instalado te debe ir a la ip_servidor:10000

                el user y pass es el root
                y luego el modulo de csf puedes ver como implementarlo aqui https://www.bitronictech.net/knowledgebase/10088/Installing-CSF-on-Webmin.html

                espero te ayude.

                  hgmnetwork Hola hgmNetwork,

                  Entiendo tus sugerencias a la perfección pero aún quisiera saber si esto no va a inteferir con anti hacker y el firewall de Elastix (reglas de iptables) que ya existen en el sistema.. no quisiera que se pisen la manguera entre bomberos como decimos en mi país...

                  Ya tengo instalado webmin pero antes de proceder con CSF quisiera me pudieras contestar esa pregunta sobre "conflicto de intereses" entre estos módulos de seguridad.

                  Se me ocurre a mi desactivar el firewall de Elastix, inactivar anti-hacker (o eliminar el módulo) y de allí instalar CSF y configurarlo.

                  Gracias de antemano!

                    Lo primero es que añadas tu ip a la lista blanca para que sea como sea no te bloquees a ti mismo :D eso es muy importante, esto tanto en el de elastix como en el csf y en el fail2ban.

                    Yo suelo mantener el propio de elastix activado y a la vez el csf lo uso para bloquear ips de rusia, china y no recuerdo cual mas, y tambien para determinados puertos y flood

                    lo que si me despiste de indicarte que debes en el firewall de elastix activar y permitir el acceso al puerto 10.000 si no no te dejara entrar al webmin :D porque el firewall del propio elastix te bloqueara ese puerto.

                    con el CFS incluso tiene opciones que te ayudaran a mejorar la seguridad con muy pocos pasos, por ejemplo yo suelo cambiar el puerto ssh tambien y poner en el ssh 1 solo intento si se falla cierra conexion si yo pongo mal la clave de root tengo que probar de nuevo pero si es un ataque lo complica bastante mas. si lo cambias tambien recuerda abrir el puerto que uses en el firewall de elastix y poner tu ip en la lista blanca para que a ti nunca te bloquee.