El mundo financiero brasileño fue sacudido por uno de los mayores ataques de hackers contra organizaciones financieras del país, resultando en un desvío estimado de más de R$ 1 mil millones, con potencial de alcanzar R$ 3 mil millones. La investigación realizada por ASPER, una consultora de seguridad brasileña, reveló una serie de fallas alarmantes, destacando la vulnerabilidad principal que permitió tal escala de pérdida. Este artículo técnico detalla el origen del problema, las vulnerabilidades explotadas y lecciones cruciales para el sector.

Contexto: FinTechs, BaaS y el Punto Único de Falla

El incidente ocurrió en el ecosistema de fintechs, un segmento que ha crecido exponencialmente en los últimos años. Muchas de estas empresas, para evitar la burocracia y los requisitos complejos de tratar directamente con el Banco Central, optan por un modelo de "Bank as a Service" (BaaS). En este escenario, empresas como CM actúan como brokers, ofreciendo una API simplificada para que múltiples fintechs puedan acceder e interactuar con el Banco Central.

La conveniencia de este modelo, sin embargo, reveló una fragilidad crítica: al centralizar el acceso para varias fintechs, CM se convirtió en un punto único de falla. Si la seguridad de CM fuera comprometida, la interrupción y el riesgo se extenderían a todas las fintechs que dependen de ella. Y eso fue exactamente lo que sucedió.

La Vulnerabilidad Raíz: CVE-2023-46604 en Apache ActiveMQ

El origen del problema fue identificado como CVE-2023-46604, una vulnerabilidad crítica en un componente Java ampliamente utilizado, Apache ActiveMQ.

Entendiendo Apache ActiveMQ y las Colas de Mensajes

ActiveMQ es una implementación popular de un sistema de colas de mensajes. Este patrón de diseño de software es crucial para la comunicación asíncrona entre sistemas y procesos. En lugar de que un sistema espere una respuesta inmediata (comunicación síncrona), envía un mensaje a una cola, recibiendo un protocolo de confirmación. El sistema de destino procesa el mensaje en su propio tiempo, permitiendo que el sistema original continúe sus operaciones sin bloqueo.

ActiveMQ tiene dos componentes principales:

• Broker: El servidor que gestiona todos los mensajes.
• Cliente: La parte del sistema que envía y recibe mensajes, interactuando con el broker.

La Falla de Deserialización (CVE-2023-46604)

CVE-2023-46604 está clasificada como una falla de deserialización de datos. Cuando un sistema envía un objeto (una variable, una clase) a otro sistema vía ActiveMQ, este objeto es primero serializado (convertido en una secuencia de bytes, como una gran cadena de datos). Al llegar al broker, esta cadena es deserializada (convertida de nuevo al objeto original).

La vulnerabilidad reside en el proceso de deserialización. Un atacante puede enviar datos serializados maliciosamente elaborados que, al ser deserializados por el broker en una versión antigua y vulnerable de ActiveMQ, fuerzan la ejecución de código arbitrario (shell execution) en el servidor.

Esta falla es de criticidad máxima:

• Según el NIST (National Institute of Standards and Technology), la vulnerabilidad tiene una puntuación de 9.8.
• De acuerdo con la Apache Software Foundation, la puntuación es 10, lo que significa la mayor criticidad posible.

La solución para esta vulnerabilidad es trivial: basta con actualizar ActiveMQ. Las versiones corregidas son 5.15.16, 5.16.7, 5.17.6 o 5.18.3. Sin embargo, el sistema de CM no había sido actualizado.

La Cadena de Ataque: Escalada de Privilegios y Robo de Credenciales

Tras obtener acceso al shell del servidor mediante la falla de deserialización, el atacante logró escalar privilegios y robar credenciales. La falla más alarmante posterior a la explotación fue la forma en que se almacenaban las claves privadas de comunicación de los clientes.

En lugar de utilizar un HSM (Hardware Security Module), que es un hardware específico y altamente seguro para almacenar claves criptográficas, las claves privadas estaban guardadas en archivos PFX directamente en el servidor. Un HSM impide que las claves sean extraídas, permitiendo solo que los datos sean cifrados por ellas dentro del propio módulo, con protecciones físicas extremas.

Con acceso al servidor, el atacante pudo simplemente localizar y robar estos archivos PFX, que contenían las claves privadas de comunicación de los clientes de CM.

El Impacto de las Claves Privadas Robadas

Las claves privadas se utilizan para firmar digitalmente solicitudes, garantizando su autenticidad en el sistema. Con las claves privadas de los clientes en mano, el atacante pudo forjar mensajes de pago y firmarlos digitalmente, haciéndolos indistinguibles de transacciones legítimas enviadas por los propios clientes.

Esta capacidad de forjar transacciones legítimas es la razón por la cual CM, BMP y el Banco Central inicialmente no detectaron el robo. La cantidad exacta desviada aún es incierta, ya que los responsables necesitan analizar los registros de los bancos emisores para diferenciar lo que fue real de lo que fue forjado.

El Descubrimiento: El Papel Inesperado de las Criptomonedas

Lo más notable y preocupante para las instituciones financieras tradicionales fue cómo se descubrió el ataque: no por sistemas de monitoreo internos o alertas del Banco Central, sino por un exchange de Bitcoin, SmartPay.

Cuando los atacantes intentaron usar R$ 1 mil millones de los fondos robados para comprar Bitcoin en SmartPay, el exchange notó la transacción sospechosa. SmartPay congeló los fondos y alertó directamente al Banco Central: "¡Han sido robados!". Este episodio plantea preguntas sobre la seguridad de algunas fintechs en comparación con la robusta seguridad que los exchanges de criptomonedas se ven obligados a mantener debido al constante volumen de ataques.

Lecciones Aprendidas y Recomendaciones Críticas

El incidente en CM expuso fallas fundamentales en las prácticas de seguridad y desarrollo de software:

1. Gestión de Vulnerabilidades y Actualizaciones:

   • No actualizar un componente con una vulnerabilidad crítica y pública es inaceptable.
   • Los sistemas modernos de gestión de configuración de código fuente (presentes en la mayoría de los repositorios Git) pueden alertar automáticamente sobre componentes con vulnerabilidades conocidas, incluso impidiendo el deploy.
   • Es imperativo tener rutinas periódicas de escaneo para vulnerabilidades, ya que pueden surgir nuevas fallas en componentes ya utilizados.

   • Almacenamiento Seguro de Claves Criptográficas:

   • Migrar inmediatamente las claves PFX a un HSM es una medida de seguridad prioritaria. Aunque costoso y complejo, el costo de un HSM es ínfimo comparado con los miles de millones de reales en riesgo.

   • Autenticación Reforzada:

   • La implementación de Autenticación Multifactor (MFA) para el acceso a APIs bancarias y sistemas críticos es esencial.

   • Monitoreo Activo y Detección de Anomalías:

   • La ausencia de rutinas de monitoreo para transacciones de gran volumen es una falla grave. Es inconcebible que R$ 1 mil millones fueran movidos sin generar alertas automatizadas o verificación humana.

   • El monitoreo continuo es vital para detectar actividades sospechosas en tiempo real.

Este ataque sirve como una severa advertencia para todo el ecosistema fintech en Brasil. Se espera que, con la publicidad de esta vulnerabilidad, los hackers intensifiquen los intentos de explotar fallas similares en otros sistemas. Las empresas necesitan urgentemente revisar sus procesos de desarrollo, deploy, verificación de seguridad y monitoreo para garantizar la protección de los miles de millones de reales que transitan por sus plataformas. El amateurismo revelado por esta investigación es una amenaza existencial en un sector que maneja el dinero de millones de personas.