A finales de marzo de 2023, investigadores de seguridad expusieron la identidad de un actor de amenazas. Ataque complejo a la cadena de suministro de software en el software de comunicación empresarial de 3CX, principalmente la aplicación de escritorio de llamadas de voz y video de la compañía. Los investigadores advirtieron que la aplicación estaba de alguna manera troyanizada y que su uso podría exponer a la organización a un posible plan de exfiltración por parte de un actor de amenazas. El ataque fue denominado "Operador Suave" y hay evidencia que sugiere que ha estado ocurriendo durante meses.
Entonces, ¿qué sucedió exactamente? ¿Por qué el uso de esta versión troyanizada lo pone en riesgo y cómo se podría haber evitado empleando la firma y verificación de software?
Lo primero es lo primero: ¿Qué es 3CX?
3CX es un IP PBX (Private Branch Exchange) basado en software y de estándares abiertos que reemplaza un PBX de hardware tradicional. Está diseñado para permitir a las empresas realizar y recibir llamadas utilizando la tecnología VoIP (Voice over Internet Protocol), que transmite comunicaciones de voz a través de Internet. 3CX también incluye funciones avanzadas como videoconferencia, presencia, mensajería instantánea y más, y puede implementarse en las instalaciones o en la nube. Windows, macOS y Linux son sólo algunos de los sistemas operativos populares en los que está disponible la aplicación. Además, se puede acceder al cliente a través de navegadores gracias a una extensión de Chrome e incluso el cliente tiene una versión PWA, además de estar disponible como aplicación móvil para dispositivos Android e iOS.
Puede hacerse una idea de los efectos potenciales de un ataque a la cadena de suministro de software en el sitio web de 3CX, que cuenta con 600,000 empresas que utilizan su aplicación con más de 12 millones de usuarios diarios.
Un adelanto del ataque: lo que necesita saber
Esto es un poco complejo así que lo dividiremos en pasos:
- Descargas un versión troyanizada de la aplicación de escritorio o ya la tiene instalada y simplemente actualícela con una versión troyanizada.
- El ejecutable 3CXDesktopApp.exe carga una biblioteca de vínculos dinámicos (DLL) maliciosa llamada ffmpeg.dll.
- ffmpeg.dll se utiliza para extraer una carga útil cifrada de d3dcompiler_47.dll y ejecutarla.
- Luego, el malware descarga archivos de íconos de apariencia inocente alojados en GitHub que contienen cadenas codificadas en Base64 adjuntas al final de las imágenes.
- Luego, esos datos codificados se decodifican y se utilizan para descargar otra etapa, que contiene el servidor C&C cifrado al que se conecta la puerta trasera para recuperar la posible carga útil final.
- En la fase final, se pone en práctica la funcionalidad de robo de información, incluida la recopilación de datos del sistema y de los navegadores Chrome, Edge, Brave y Firefox. Esto puede incluir consultar el historial de navegación y la información de la tabla Lugares, así como también consultar potencialmente la tabla Historial.
Inicialmente, 3CX minimizó el ataque, pero luego admitió que era una amenaza real y sugirió desinstalar y reinstalar la aplicación con sus instrucciones específicas, así como usar la versión PWA mientras tanto hasta que la compañía logre desenredar el incidente y mitigarlo.
Otro factor muy importante a tener en cuenta es que el compromiso incluye un certificado de firma de código utilizado para firmar los archivos binarios troyanizados. Bueno, no exactamente; en realidad está utilizando una vulnerabilidad conocida llamada CVE-2013-3900 (publicado originalmente en 2013 pero actualizado en 2022 y nuevamente esta semana) para que sea Aparecer firmado legítimamente.
Déjà Vu: esto ha sucedido antes
Si esta historia de un La versión troyanizada de 3CX te suena familiar porque ya ha sucedido antes.
En este caso eres túNo está claro si una biblioteca de código abierto que utiliza la empresa se infectó o si un ataque real violó el entorno de desarrollo de la empresa.
En otros ataques famosos, desde 'Kingslayer' (2016) hasta 'CCleaner' (2017), 'VestaCP' (2018), 'WIZVERA VeraPort' (2020) y hasta 'SolarWinds' (2020), es un práctica común de los actores de amenazas para intentar comprometer los servidores de una empresa, el entorno de compilación o su ejecutable descargable real. Después de todo, disfrazar algo malo y peligroso como algo en quien puedes confiar es una excelente manera de lograr que la gente confíe y descargue tu carga útil.
Eso es parte de la definición de ataque a la cadena de suministro de software – los atacantes comprometieron la cadena de suministro de software para distribuir software malicioso a un gran número de víctimas. En cada uno de estos casos famosos, los atacantes pudieron inyectar código malicioso en paquetes de software legítimos, que luego fueron distribuidos a los usuarios. Los atacantes a menudo podían hacer esto comprometiendo a un vendedor o proveedor de software confiable, como un servidor de actualización de software o un certificado de firma de código.
Al lograr que clientes desprevenidos descarguen una versión modificada de una aplicación legítima, los atacantes básicamente pueden ocultar casi cualquier cosa que contenga.
Y aquí está el principal problema: "desprevenidos". Después de todo, el ejecutable, binario o imagen proviene de la empresa creadora, aparentemente aprobado por ella, e incluso contiene un certificado firmado. ¿Qué más puede hacer un cliente? ¿Deberían llamar a la empresa para verificar cada actualización? ¿Escanear el código (si está disponible) para comprobar la existencia de puertas traseras? Esto es absurdo y poco realista. Pero hay is algo que se puede hacer.
¿Cómo se puede agregar una capa de confianza más allá de un certificado?
El modelo propuesto Es bastante simple y se basa en la misma idea que la de los certificados de firma de código. Un certificado de firma de código es un certificado digital emitido por un tercero que se utiliza para firmar digitalmente software o código. Cuando el software se firma con un certificado de firma de código, permite a los usuarios verificar la autenticidad e integridad del software antes de instalarlo o ejecutarlo.
Los certificados de firma son emitidos por un tercero de confianza. autoridades de certificación (CA), quienes verifican la identidad del editor del software y la integridad del código del software. La autoridad certificadora utiliza algoritmos criptográficos para crear una firma digital del software, que luego se incluye en el código firmado. Cuando un usuario intenta instalar o ejecutar el software, su sistema verificará la firma digital para asegurarse de que coincida con la firma generada por la autoridad certificadora. Si las firmas coinciden, el software se considera auténtico y no ha sido manipulado desde que se firmó.
Este sistema se basa en criptografía de clave pública, también conocida como criptografía asimétrica, un método de criptografía que utiliza dos claves diferentes, una clave pública y una clave privada, para cifrar y descifrar datos. En el contexto de la firma de código, se utiliza un par de claves públicas y privadas para firmar software y código.
En este proceso, el editor de software genera un par de claves pública y privada, donde la clave privada se mantiene en secreto y la clave pública se pone a disposición de otros. Luego, el editor del software utiliza su clave privada para crear una firma digital del software o código que desea firmar. Esta firma digital es un valor hash generado al ejecutar el software o código a través de un algoritmo matemático y luego cifrar el valor hash resultante con la clave privada del editor.
Cuando un usuario descarga el software o código firmado, su sistema utiliza la clave pública del editor del software para descifrar la firma digital y verificar que coincida con el valor hash del software o código descargado. Si la firma digital es válida, entonces el usuario puede estar seguro de que el software o el código no ha sido manipulado desde que fue firmado por el editor del software.
Con base en este concepto simple, la solución propuesta es firmar cada nueva versión, binario e imagen directamente con la clave de la empresa o la clave de la canalización de compilación y simplemente pedir que el usuario verifique la firma cuando descargue o actualice el software.
Por supuesto, las cosas no siempre son tan simples. Si los malos actores se han infiltrado en el servidor de compilación, entonces firmar la compilación allí ya no tiene sentido. Si la infraestructura clave se ha visto comprometida, todo el ejercicio tampoco tiene sentido.
Pero pedir a los usuarios que verifiquen una firma, algo rápido y fácil que se puede hacer automáticamente, es un pequeño precio a pagar para ayudar a prevenir el próximo ataque a la cadena de suministro de software.
Pero espere, podría estarse preguntando, ¿qué pasa si en realidad es una biblioteca de código abierto la fuente de contaminación? En tal caso, firmar una compilación es, nuevamente, inútil ya que el código comprometedor está "integrado".
Aquí es donde debemos empezar a considerar un ecosistema de confianza basado en firmar y verificar estas firmas. Si estos paquetes de código abierto estuvieran firmados y las firmas se verificaran cuando se incorporaran al código de la empresa, podría reducirse la probabilidad de una infracción.
Donde entra el escriba
Escriba ha implementado una herramienta llamada valent Entonces, para firmar y verificar archivos, carpetas e imágenes. Sin la necesidad de mantener sistemas PKI complicados, la herramienta implementa un enfoque novedoso que consiste en utilizar su identidad verificada ya establecida (como su identidad de Google, Microsoft, GitHub o AWS, por ejemplo) para firmar el artefacto deseado. Posteriormente podrá utilizar la misma herramienta para verificar que el artefacto haya sido firmado y cuál fue la identidad utilizada para firmarlo.
Digamos que su canal de compilación produce una imagen de contenedor como artefacto final. Inmediatamente después de crear esa imagen, debe firmarla y cargar esa versión firmada en el repositorio donde sus clientes pueden descargarla. Una vez firmada, esa imagen ya no se puede modificar: está bloqueada. Cualquiera que quiera puede comprobar que está firmado y que la identidad del firmante coincide con lo publicado por la empresa.
Esta herramienta es sólo una parte de las capacidades que otorga la implementación del Scribe solución SaaS para su organización. Con el objetivo de mejorar tanto la seguridad de su cadena de suministro de software como su transparencia general, existen muchas razones para comprobar lo que Scribe puede ofrecerle.
Este contenido es presentado por Scribe Security, un proveedor líder de soluciones de seguridad de la cadena de suministro de software de extremo a extremo, que ofrece seguridad de última generación para artefactos de código y procesos de desarrollo y entrega de código en todas las cadenas de suministro de software. Más información.
Artículos relacionados con
