Fortinet reveló públicamente hoy una vulnerabilidad crítica de la API FortiManager. Identificada como CVE-2024-47575 (CVSS 9.0), está siendo explotada en ataques Zero-Day para robar archivos confidenciales que contienen configuraciones, direcciones IP y credenciales para dispositivos administrados.

La compañía advirtió en privado a los clientes de FortiManager sobre la falla a partir del 13 de octubre, en correos electrónicos que contenían pasos para mitigar la falla hasta que se publicara una actualización de seguridad.

Sin embargo, las noticias sobre la vulnerabilidad comenzaron a filtrarse en línea a lo largo de la semana por parte de clientes de Reddit y por el investigador de ciberseguridad Kevin Beaumont de Mastodon, quien llama a esta falla «FortiJump».

Los administradores de dispositivos Fortinet también han compartido que esta falla ha sido explotada por un tiempo, y un informe de un cliente fue atacado semanas antes de que se enviaran las notificaciones a los clientes. «Fuimos atacados una semana antes de que llegara a las ‘notificaciones avanzadas'».

Divulgación Zero-Day de FortiManager

«La falta de autenticación en una función crítica [CWE-306] en el demonio fgfmd de FortiManager permite que un atacante remoto no autenticado ejecute código o comandos arbitrarios a través de solicitudes especialmente diseñadas», se lee en el aviso de seguridad FG-IR-24-423 de Fortinet. «Los informes han demostrado que esta vulnerabilidad se está explotando en la naturaleza».

Una fuente familiarizada con los ataques le dijo a BleepingComputer que al aviso le falta información crítica para explotar el error: los actores de amenazas primero deben extraer un certificado válido de cualquier dispositivo Fortinet de propiedad o comprometido, incluido FortiManager VM. Los clientes de Fortinet han expresado su frustración por cómo se reveló la vulnerabilidad, ya que algunos clientes de FortiManager no recibieron el aviso previo y tuvieron que confiar en la información filtrada para conocer la vulnerabilidad de día cero

La falla afecta a las versiones 7.6.0, 7.4.0 – 7.4.4, 7.2.0 – 7.2.7, 7.0.0 – 7.0.12, 6.4.0 – 6.4.14 y 6.2.0 a 6.2.12.
La falla se solucionó en FortiManager 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15 y 6.2.13 o posteriores. 

Los clientes también informaron en Reddit que el centro de asistencia técnica (TAC) de Fortinet dice que la falla también afecta a FortiManager Cloud (FMG Cloud), aunque eso no se comparte en el aviso.

En este momento, solo se han lanzado las versiones 7.2.8 y 7.4.5 de FortiManager, y el resto se lanzará en los próximos días.

Fortinet creó el «Protocolo FortiGate a FortiManager» (FGFM) para permitir a las empresas implementar fácilmente dispositivos de firewall FortiGate y registrarlos en un servidor FortiManager remoto para que puedan administrarse desde una ubicación central.

Estos escenarios incluyen el FortiManager en Internet público mientras la unidad FortiGate está detrás de NAT, la unidad FortiGate está en Internet público mientras FortiManager está detrás de NAT, o tanto FortiManager como FortiGate tienen direcciones IP enrutables.

Como señala el investigador de ciberseguridad Kevin Beaumont, no es difícil para un atacante registrar un dispositivo FortiGate en un servidor FortiManager expuesto siempre que haya obtenido un certificado válido.

Este certificado se utiliza para configurar un túnel SSL entre FortiGate y el servidor FortiManager para autenticar ambos dispositivos. Sin embargo, una fuente familiarizada con la vulnerabilidad dijo que no es ahí donde reside la vulnerabilidad. En cambio, se requiere un nivel adicional de autorización para ejecutar comandos a través de la API FortiManager FGFM, que se puede evitar utilizando la falla CVE-2024-47575.

Esta API permite a los atacantes ejecutar comandos, recuperar información y tomar control total sobre los dispositivos administrados y FortiManager para obtener mayor acceso a las redes corporativas.

Debido a la forma en que está diseñado FGFM (situaciones de cruce de NAT), también significa que si obtiene acceso a un firewall FortiGate administrado, puede atravesar hasta el dispositivo FortiManager de administración… y luego regresar a otros firewalls y redes.

Fortinet ha ofrecido diferentes formas de mitigar este ataque si no es posible instalar la última actualización de firmware en este momento:

  • Utilizar el comando set fgfm-deny-unknown enable para evitar que dispositivos con números de serie desconocidos se registren en FortiManager.
  • Crear un certificado personalizado para usarlo al crear el túnel SSL y autenticar dispositivos FortiGate con FortiManager. Sin embargo, Fortinet advierte que si un actor de amenazas puede obtener este certificado, aún podría usarse para conectar dispositivos FortiGate y explotar la falla.
  • Crear una lista permitida de direcciones IP para dispositivos FortiGate que pueden conectarse.

Las instrucciones sobre cómo realizar estas mitigaciones y restaurar servidores comprometidos se pueden encontrar en el aviso de Fortinet.

Explotado para robar datos

Fortinet dice que los ataques observados se utilizaron para robar varios archivos del servidor FortiManager que «contenía las IP, credenciales y configuraciones de los dispositivos administrados». Esta información robada se puede utilizar para conocer y apuntar a los dispositivos FortiGate para obtener acceso inicial a redes corporativas o clientes posteriores de MSP.

La compañía también confirma que no hay evidencia de malware instalado en servicios FortiManager comprometidos o cambios de configuración en dispositivos FortiGate administrados. «En este momento, no hemos recibido informes de ninguna instalación de sistema de bajo nivel de malware o puertas traseras en estos sistemas FortiManager comprometidos», dice Fortinet en el aviso de seguridad.

Fortinet ha compartido los siguientes IOC para ayudar a los profesionales de seguridad y administradores de red a detectar si sus servidores FortiManager fueron violados mediante esta vulnerabilidad.

Los ataques observados muestran que los actores de amenazas registran los dispositivos FortiGate controlados por los atacantes con el nombre «localhost». Las entradas del registro mostrarán que los actores de amenazas emitieron comandos API para agregar estos dispositivos «localhost» no registrados:

type=event,subtype=dvm,pri=information,desc="Device,manager,generic,information,log",
user="device,...",msg="Unregistered device localhost add succeeded" device="localhost" 
adom="FortiManager" session_id=0 operation="Add device" performed_on="localhost" 
changes="Unregistered device localhost add succeeded"
type=event,subtype=dvm,pri=notice,desc="Device,Manager,dvm,log,at,notice,level",
user="System",userfrom="",msg="" adom="root" session_id=0 opera,on="Modify device" performed_on="localhost" 
changes="Edited device settings (SN FMG-VMTM23017412)"

Fortinet dice que se detectaron dispositivos FortiGate fraudulentos utilizando el número de serie FMG-VMTM23017412, que parece ser el formato utilizado por las máquinas virtuales FortiGate-VM.

Otros IOC incluyen la creación de los archivos /tmp/.tm and /var/tmp/.tm files.

En los ataques se observaron las siguientes direcciones IP, todas ubicadas en la empresa de alojamiento en la nube, Vultr:

  • 45.32.41[.202
  • 104.238.141[.143 (visto recientemente alojando infraestructura SuperShell C2)
  • 158.247.199[.37
  • 45.32.63[.2
  • NOTA: no todos los IOC pueden estar presentes en los dispositivos explotados.

El framework SuperShell C2 se utilizó recientemente en ataques a F5 BIG-IP que se atribuyeron con moderada confianza a un actor de amenazas chino (RPC) conocido como UNC5174.

Fuente y redacción: segu-info.com.ar

Compartir