Análisis de ataques a la cadena de suministro de software
3CX es una conocida empresa que ofrece productos de VoIP y comunicaciones unificadas. Afirma tener más de 600,000 instalaciones y 12 millones de usuarios diarios. Sin duda, un objetivo tentador para los actores maliciosos.
A finales de marzo, 3CX sufrió el 3CX Supply Chain Attack, un sofisticado ataque a la cadena de suministro de software que logró inyectar malware en su software de escritorio. El malware tiene como objetivo robar información, pero también instala una puerta trasera.
En este artículo, analizaremos este ataque a la cadena de suministro, siguiendo la secuencia de eventos desde diferentes puntos de vista. En el proceso, podemos Aprenda cómo se podría bloquear o mitigar el ataque..
Índice del Contenido
Cómo se realizó el ataque
Los delincuentes primero comprometieron un paquete de software, X_TRADER, de una empresa llamada Tecnologías comerciales con sede en Chicago, Illinois. El software tenía malware ( SEÑAL VELADA puerta trasera) inyectado. El instalador fue firmado digitalmente con un certificado de firma de código válido. Posiblemente malos actores irrumpieron en la construcción. pipeline para 2021 y modificó el software antes de empaquetarlo y firmarlo. Este fue el primer salto en el ataque a la cadena de suministro encadenada. En marzo de 2022 esto era reportaron en el contexto de las operaciones DreamJob también conocido como BLINDINGCAN y ManzanaJeus, dirigido a organizaciones con sede en EE. UU. en las industrias de medios de comunicación, TI, criptomonedas y tecnología financiera.
Este software se retiró en 2020 (!), pero estuvo disponible para descargar a partir de 2022. Un empleado de 3CX lo instaló en una computadora personal. Los malos robaron las credenciales corporativas del empleado de la computadora comprometida. Curiosamente, el SEÑAL VELADA utilizó una URL en el sitio web de Trading Technologies para comando y control (una táctica que se usa a menudo para evitar la detección).
Dos días después del compromiso inicial, los malos actores utilizaron la VPN corporativa para acceder a los sistemas internos de 3CX. Usaron el proxy inverso FRP, una herramienta pública que podía usarse para bien y para mal, para moverse lateralmente. Sabían qué hacer con el punto de apoyo ganado: comprometieron los sistemas de compilación Windows y macOS. Cada entorno con diferentes herramientas. Por ejemplo, utilizaron la herramienta SigFlip para inyectar el código shell cifrado con RC4 en el apéndice de firma del d3dcompiler_47.dll.
Se infectaron las actualizaciones de software para la aplicación de escritorio 3CX para Windows y macOS. Este fue el segundo salto en este (¿primero?) ataque a la cadena de suministro de varios pasos. La actualización de software para Windows, también firmada correctamente con un certificado de firma de código 3CX, elimina dos archivos maliciosos, ffmpeg.dll y d3dcompiler_47.dll (con equivalente .dylib bibliotecas para macOS), que fueron cargadas y ejecutadas por el benigno Aplicación de Escritorio 3CX ejecutable (a través de la técnica de carga lateral de DLL). El código shell cifrado en la segunda DLL carga otra DLL que se descarga desde Almacenamiento de iconos Repositorio de GitHub: un archivo .ico que contiene el servidor de comando y control (C2) cifrado.
Se habían previsto más de 20 dominios para esto, lo que nos habla de cómo se planificó cuidadosamente el ataque a la cadena de suministro de software.
Las conexiones desde las PC de las víctimas a los dominios C2 comenzaron el 06 de marzo de 2023 y finalizaron el 29 de marzo.
Tenga en cuenta que (1) no se modificó ningún código fuente en un repositorio de código, sino que se inyectó la carga útil de malware durante la compilación, (2) un código legítimo ffmpeg DDL fue reemplazado por uno malicioso y cargado mediante carga lateral de DLL, y (3) una popular aplicación VoIP se convirtió en un arma con malware de varias etapas.
Cómo se manejó el incidente
Parece que el 29 de marzo 3CX recibió informes de terceros de un actor malicioso "explotando una vulnerabilidad en su producto". Las plataformas antimalware hicieron (parcialmente) su trabajo.
El 30 de marzo de 2023, 3CX CISO, Pierre Jourdan, publicó una alerta de seguridad informar a los clientes y socios que su aplicación Electron (cliente de escritorio) se envió después de una actualización con malware. La publicación enumera las versiones afectadas (para Windows y Mac), una breve declaración sobre las medidas de contención iniciales tomadas y una recomendación rápida para continuar trabajando con el cliente web en lugar del cliente de escritorio contaminado.
En mi opinión, la comunicación inicial, aunque un poco concisa, fue al grano. No es fácil para ningún proveedor reconocer que existe un problema de seguridad grave que podría afectar a muchos clientes. La empresa reconoció el problema e inmediatamente señaló a un posible culpable:
"Vale la pena mencionarlo: esto parece haber sido un ataque dirigido de una amenaza persistente avanzada, tal vez incluso patrocinada por el estado, que ejecutó un complejo ataque a la cadena de suministro y eligió quién descargaría las siguientes etapas de su malware".
La empresa ofreció una alternativa para mantener el producto funcionando: utilizar el Aplicación web progresiva o PWA, en lugar de la aplicación de escritorio, según la Electrón marco de referencia.
“Le recomendamos encarecidamente que utilice nuestra aplicación PWA. La aplicación PWA está completamente basada en web y hace el 95% de lo que hace la aplicación electron. La ventaja es que no requiere ninguna instalación ni actualización y la seguridad web de Chrome se aplica automáticamente.
La razón por la que tenemos dos aplicaciones es que cuando iniciamos la aplicación Electron, la tecnología PWA aún no estaba disponible. Ahora está maduro y funciona muy bien”.
Bueno, la aplicación web también podría estar infectada y, por definición, una PWA puede ejecutar código en los trabajadores del servicio (código JavaScript) con acceso (restringido) a los recursos locales. La publicación afirmaba que la PWA no estaba infectada en ese momento. Podemos entender por qué, en muchos de los más de 277 comentarios de la publicación, algunos preguntaron si la alternativa PWA mencionada o el propio software del servidor PBX estaban comprometidos.
El mismo día, 3CX nombró a Mandiant para investigación, con más instrucciones. Básicamente, instala la actualización para
Aplicación de escritorio Win/Mac en la instalación local, desinstale la aplicación electron para las versiones afectadas y vaya a la alternativa PWA. Esto no es necesariamente suficiente, ya que el malware puede tener acceso a los sistemas afectados, persistir en el malware o incluso moverse lateralmente. La eliminación completa del malware no es tan fácil. Podemos entender que, dada la urgencia, no siempre se encuentre la mejor manera de abordar un incidente… a menos que el escenario haya sido imaginado previamente y se hayan identificado las medidas de remediación adecuadas.
El siguiente publicación, ahora por el CEO de la compañía, intenta tranquilizar a los clientes con el anuncio de una actualización solo de seguridad para DesktopApp. Se implementaron algunas técnicas de protección básicas, como el hash de contraseñas (“Más vale que nunca es tarde; nunca tener éxito sería un período demasiado largo”, Chaucer Dixit en 1386.) Las protecciones específicas implementadas son mejores que las buenas intenciones y los planes proyectados... Pero, ¿cómo se almacenaban las contraseñas anteriormente?
De todos modos, Google invalidó el certificado de firma de código 3CX existente y los proveedores de antivirus también bloquearon cualquier software firmado con ese certificado. Los instaladores MSI para la actualización de DesktopApp tuvieron que regenerarse con un nuevo certificado de firma de código, lo que llevó algunas horas. ¡Esto podría esperarse!
3CX implementó preventivamente un servidor de nueva construcción. Esto es razonable: sin análisis, se desconocía cómo se inyectó el malware.
El mismo 1 de abril, el CEO publicó un Actualización de incidentes de seguridad. La publicación explica lo que estaba haciendo la empresa (realizar una investigación completa y validar todo el código fuente del software del lado del cliente). La seguridad no puede esperar ni siquiera los sábados.
Cuando se analizó el incidente y se conoció la infraestructura del atacante, se eliminaron el repositorio de GitHub y los dominios de los servidores C2 utilizados por la APT, eliminando efectivamente el malware.
En abril 11th, el CISO publicó el Resultados iniciales del análisis del incidente.. La APT UNC4736, vinculada a Corea del Norte, fue citada por primera vez.
El viernes 20 de abril, Mandiant publicó el análisis inicial del incidente. Se publicaron las reglas de detección de YARA y Snort.
El mismo día, el CEO de 3CX publicó una nueva publicación, con el sugerente nombre “Acciones, no palabras: ¡nuestro plan de acción de seguridad de 7 pasos!”. El subtítulo es bastante interesante: “Asegurando el futuro de 3CX después de una conexión en cascada, la primera en su tipo ataque a la cadena de suministro de software en software.” Los pasos del borrador de la carta de seguridad son:
- Fortalecimiento de múltiples capas de seguridad de la red.
-
La renovación genera seguridad.
-
Revisión continua de seguridad del producto.
-
Mejora de las funciones de seguridad del producto.
-
Realización de pruebas de penetración continuas.
-
Perfeccionar el plan de gestión de crisis y manejo de alertas.
-
Establecimiento de un nuevo departamento para operaciones y seguridad de redes..
Los analistas estarán atentos a este loable programa, en efecto…
Consecuencias: cómo reaccionó la industria
Pasaron apenas unas semanas desde que se publicó el incidente. Pero la industria está reaccionando.
CVE-2023-29059 Se le asignó un nivel de riesgo CVSSv7.8 de 3 (ALTO) a partir de hoy. Los productos 3CX tienen solo 16 CVE enumerados, lo que parece bueno en comparación con proveedores con niveles de implementación similares. Pero este incidente no es la vulnerabilidad habitual De hecho. Se trata de un ataque dirigido activo por una amenaza persistente activa (APT), como el CISO's más reconocido.
El CWE-506 El término “código malicioso incrustado” que clasifica este incidente no nos ayuda mucho a entender cómo prevenir este tipo de ataques a la cadena de suministro de software. Desafortunadamente, los cibercriminales tienen muchas vías para distribuir malware, y los ataques a la cadena de suministro son la nueva joya de la corona de su arsenal. Se debería mejorar el CWE-506 para reflejar los escenarios actuales, incluidos aquellos basados en la violación del sistema de compilación.
La APT, denominada UNC4736 por Mandiant, utiliza tácticas y técnicas similares a las del conocido Grupo Lazarus (APT38), creado por el Estado norcoreano y autor de la campaña de ransomware WannaCry de 2017. Estos vínculos entre malos actores en estados estalinistas con horarios laborales regulares son difíciles de establecer, pero investigadores de CrowdStrike y ESET descubrió que las tácticas, técnicas y procedimientos (TTP) utilizados se parecen a los de uso común de Lazarus APT38. Comprender cómo operan es esencial para la detección, prevención y erradicación.
Conocer sus objetivos, envueltos en un velo de misterio, es aún más difícil.
Este ataque es lo suficientemente importante como para que CISA, la Agencia de Ciberseguridad de Estados Unidos, emitió un asesor con publicaciones de proveedores y enlaces a múltiples análisis sobre el ataque a la cadena de suministro. Su lectura es relevante para los profesionales de la ciberseguridad.
El incidente nos recuerda el ataque de SolarWinds. Dado el enorme impacto, muchos proveedores se apresuraron a analizar los instaladores de productos de escritorio VoIP infectados. Pero este es el último paso. Se necesitan más detalles para comprender qué falló con la seguridad de los sistemas de compilación de las dos organizaciones afectadas y qué medidas tomaron los malos actores para afectar esos sistemas de compilación y lograron que se insertara el malware durante la compilación. De lo contrario, este incidente se repetirá una y otra vez.
Y ahora, ¡lecciones aprendidas!
Jugar un deporte de equipo y escuchar a alguien de tu equipo explicar cada minuto de falla en el juego después destroza el espíritu más templado. ¡Pero aquí en España todo el mundo es seleccionador nacional de fútbol! Así que déjenme actuar como Pep Guardiola, José Mourinho, Alex Ferguson y Arrigo Sacchi todos juntos.
Actúa como si tu sistema de construcción estuviera bajo fuego de artillería intensa.. Quizás no pueda evitar que un empleado instale software no autorizado en las PC del trabajo. Probablemente, los equipos de ingeniería requieran políticas más estrictas. Pero esté atento a la construcción e implementación pipeline. Si entrega software a los clientes, la seguridad sobre cómo construye el software debería ser tan importante como la seguridad del producto de software.
Preparación para incidentesEs difícil, quizás estéril, anticipar los escenarios más probables de incidentes de seguridad. ¿Debería aprender a usar un desfibrilador? No, a menos que viva con una propensión a usar tarjetas.iac ¡Arresto! ¡Pero por Dios! Prepárense para "reconstruir su sistema" desde cero, con revocación y renovación de claves, tokens de acceso, pares de claves públicas y certificados.
Los sistemas de construcción deben tener ciertas características.: La tendencia actual hacia construcciones en entornos efímeros, aislados/sin parámetros/herméticos e incluso reproducibles podría ser el marco para evitar Ataques como el de 3CX Supply Chain Attack cuando se complementan con requisitos adicionales en otros sistemas en la compilación y la implementación pipeline. Vea Requisitos de compilación de Google SLSA para referencia.
La comunicación adecuada es clave. La transparencia es obligatoria. Minimizar el problema u ocultarlo debajo de la alfombra es lo peor que puede hacer cualquier organización. Los incidentes de seguridad a menudo afectan más a la reputación que a otros activos, y una mala comunicación después de la infracción podría ser catastrófica.
Convertir los problemas en oportunidades. Un buen incidente puede desencadenar mejoras en los controles de seguridad que nunca llegaron al estricto plan del producto. Incluso cosas esenciales como el hash de contraseña adecuado y la documentación de configuración/refuerzo de seguridad podrían programarse a corto plazo. Pero para los ataques a la cadena de suministro, reforzar los sistemas de construcción y agregar certificaciones y controles de integridad en cada paso de la construcción e implementación. pipelines son esenciales. No debería ser tan fácil para un atacante implantar tales cambios en el sistema de compilación.
Esté preparado. De lo contrario, su organización podría enfrentarse a una amenaza existencial, como el ataque a la cadena de suministro del software 3CX.





