O mundo financeiro brasileiro foi abalado por um dos maiores ataques hackers contra organizações financeiras do país, resultando em um desvio estimado em mais de R$ 1 bilhão, com potencial de atingir R$ 3 bilhões. A investigação conduzida pela ASPER, uma consultoria de segurança brasileira, revelou uma série de falhas assustadoras, destacando a vulnerabilidade primária que permitiu tal escala de prejuízo. Este artigo técnico detalha a origem do problema, as vulnerabilidades exploradas e as lições cruciais para o setor.

O Contexto: FinTechs, BaaS e o Ponto Único de Falha

O incidente ocorreu no ecossistema das fintechs, um segmento que cresceu exponencialmente nos últimos anos. Muitas dessas empresas, para evitar a burocracia e os requisitos complexos de lidar diretamente com o Banco Central, optam por um modelo de "Bank as a Service" (BaaS). Neste cenário, empresas como a CM atuam como brokers, oferecendo uma API simplificada para que múltiplas fintechs possam acessar e interagir com o Banco Central.

A conveniência desse modelo, contudo, revelou uma fragilidade crítica: ao centralizar o acesso para diversas fintechs, a CM tornou-se um ponto único de falha. Se a segurança da CM fosse comprometida, a interrupção e o risco se estenderiam a todas as fintechs que dependem dela. E foi exatamente isso que aconteceu.

A Vulnerabilidade Raiz: CVE-2023-46604 no Apache ActiveMQ

A origem do problema foi identificada como a CVE-2023-46604, uma vulnerabilidade crítica em um componente Java amplamente utilizado, o Apache ActiveMQ.

Entendendo o Apache ActiveMQ e Filas de Mensagens

ActiveMQ é uma implementação popular de um sistema de fila de mensagens (Message Queue). Este padrão de design de software é crucial para a comunicação assíncrona entre sistemas e processos. Em vez de um sistema esperar uma resposta imediata (comunicação síncrona), ele envia uma mensagem para uma fila, recebendo um protocolo de confirmação. O sistema destinatário processa a mensagem em seu próprio tempo, permitindo que o sistema original continue suas operações sem bloqueio.

O ActiveMQ possui dois componentes principais:

• Broker: O servidor que gerencia todas as mensagens.
• Cliente: A parte do sistema que envia e recebe mensagens, interagindo com o broker.

A Falha de Desserialização (CVE-2023-46604)

A CVE-2023-46604 é classificada como uma falha de desserialização de dados. Quando um sistema envia um objeto (uma variável, uma classe) para outro sistema via ActiveMQ, este objeto é primeiro serializado (transformado em uma sequência de bytes, como uma grande string de dados). Ao chegar no broker, essa string é desserializada (convertida de volta para o objeto original).

A vulnerabilidade reside no processo de desserialização. Um atacante pode enviar dados serializados maliciosamente elaborados que, ao serem desserializados pelo broker em uma versão antiga e vulnerável do ActiveMQ, forçam a execução de código arbitrário (shell execution) no servidor.

Esta falha é de criticidade máxima:

• Segundo o NIST (National Institute of Standards and Technology), a vulnerabilidade tem uma pontuação de 9.8.
• De acordo com a Apache Software Foundation, a pontuação é 10, o que significa a maior criticidade possível.

A solução para essa vulnerabilidade é trivial: basta atualizar o ActiveMQ. As versões corrigidas são 5.15.16, 5.16.7, 5.17.6 ou 5.18.3. No entanto, o sistema da CM não havia sido atualizado.

A Cadeia de Ataque: Escalada de Privilégios e Roubo de Credenciais

Após obter acesso ao shell do servidor via a falha de desserialização, o atacante conseguiu escalar privilégios e furtar credenciais. A falha mais alarmante pós-exploração foi a forma como as chaves privadas de comunicação dos clientes eram armazenadas.

Em vez de utilizar um HSM (Hardware Security Module), que é um hardware específico e altamente seguro para armazenar chaves criptográficas, as chaves privadas estavam guardadas em arquivos PFX diretamente no servidor. Um HSM impede que as chaves sejam extraídas, permitindo apenas que dados sejam criptografados por elas dentro do próprio módulo, com proteções físicas extremas.

Com o acesso ao servidor, o atacante pôde simplesmente localizar e roubar esses arquivos PFX, que continham as chaves privadas de comunicação dos clientes da CM.

O Impacto das Chaves Privadas Roubadas

As chaves privadas são usadas para assinar digitalmente requisições, garantindo sua autenticidade no sistema. Com as chaves privadas dos clientes em mãos, o atacante pôde forjar mensagens de pagamento e assiná-las digitalmente, tornando-as indistinguíveis de transações legítimas enviadas pelos próprios clientes.

Essa capacidade de forjar transações legítimas é a razão pela qual a CM, a BMP e o Banco Central inicialmente não detectaram o roubo. A quantia exata desviada ainda é incerta, pois os responsáveis precisam analisar os logs dos bancos emissores para diferenciar o que foi verdadeiro do que foi forjado.

A Descoberta: O Papel Inesperado das Criptomoedas

O mais notável e preocupante para as instituições financeiras tradicionais foi a forma como o ataque foi descoberto: não por sistemas de monitoramento internos ou alertas do Banco Central, mas por uma exchange de Bitcoin, a SmartPay.

Quando os atacantes tentaram usar R$ 1 bilhão dos fundos roubados para comprar Bitcoin na SmartPay, a exchange notou a transação suspeita. A SmartPay congelou os fundos e alertou diretamente o Banco Central: "Vocês foram roubados!". Este episódio levanta questões sobre a segurança de algumas fintechs em comparação com a segurança robusta que as exchanges de criptomoedas são forçadas a manter devido ao constante volume de ataques.

Lições Aprendidas e Recomendações Críticas

O incidente na CM expôs falhas fundamentais nas práticas de segurança e desenvolvimento de software:

1. Gerenciamento de Vulnerabilidades e Atualizações:

   • A não atualização de um componente com uma vulnerabilidade crítica e pública é inaceitável.
   • Sistemas modernos de gerenciamento de configuração de código-fonte (presentes na maioria dos repositórios Git) podem automaticamente alertar sobre componentes com vulnerabilidades conhecidas, até mesmo impedindo o deploy.
   • É imperativo ter rotinas periódicas de varredura para vulnerabilidades, pois novas falhas podem surgir em componentes já utilizados.

   • Armazenamento Seguro de Chaves Criptográficas:

   • Migrar imediatamente as chaves PFX para um HSM é uma medida de segurança prioritária. Embora caro e complexo, o custo de um HSM é ínfimo comparado aos bilhões de reais em risco.

   • Autenticação Reforçada:

   • Implementação de Autenticação de Múltiplos Fatores (MFA) para acesso a APIs bancárias e sistemas críticos é essencial.

   • Monitoramento Ativo e Detecção de Anomalias:

   • A ausência de rotinas de monitoramento para transações de grande volume é uma falha grave. É inconcebível que R$ 1 bilhão fosse movimentado sem gerar alertas automatizados ou verificação humana.

   • Monitoramento contínuo é vital para detectar atividades suspeitas em tempo real.

Este ataque serve como um alerta severo para todo o ecossistema de fintechs no Brasil. A expectativa é que, com a publicidade desta vulnerabilidade, hackers intensifiquem as tentativas de explorar falhas semelhantes em outros sistemas. As empresas precisam urgentemente revisar seus processos de desenvolvimento, deploy, verificação de segurança e monitoramento para garantir a proteção dos bilhões de reais que transitam por suas plataformas. O amadorismo revelado por esta investigação é uma ameaça existencial em um setor que lida com o dinheiro de milhões de pessoas.