The Brazilian financial world was shaken by one of the largest hacker attacks against financial organizations in the country, resulting in an estimated diversion of more than R$1 billion, with the potential to reach R$3 billion. The investigation conducted by ASPER, a Brazilian security consultancy, revealed a series of alarming failures, highlighting the primary vulnerability that allowed such a scale of loss. This technical article details the origin of the problem, the vulnerabilities exploited, and crucial lessons for the sector.

Context: FinTechs, BaaS, and the Single Point of Failure

The incident occurred in the fintech ecosystem, a segment that has grown exponentially in recent years. Many of these companies, to avoid bureaucracy and the complex requirements of dealing directly with the Central Bank, opt for a "Bank as a Service" (BaaS) model. In this scenario, companies like CM act as brokers, offering a simplified API so that multiple fintechs can access and interact with the Central Bank.

The convenience of this model, however, revealed a critical fragility: by centralizing access for several fintechs, CM became a single point of failure. If CM's security were compromised, the interruption and risk would extend to all fintechs that depend on it. And that's exactly what happened.

The Root Vulnerability: CVE-2023-46604 in Apache ActiveMQ

The origin of the problem was identified as CVE-2023-46604, a critical vulnerability in a widely used Java component, Apache ActiveMQ.

Understanding Apache ActiveMQ and Message Queues

ActiveMQ is a popular implementation of a message queue system. This software design pattern is crucial for asynchronous communication between systems and processes. Instead of a system waiting for an immediate response (synchronous communication), it sends a message to a queue, receiving a confirmation protocol. The destination system processes the message in its own time, allowing the original system to continue its operations without blocking.

ActiveMQ has two main components:

• Broker: The server that manages all messages.
• Client: The part of the system that sends and receives messages, interacting with the broker.

The Deserialization Flaw (CVE-2023-46604)

CVE-2023-46604 is classified as a data deserialization flaw. When a system sends an object (a variable, a class) to another system via ActiveMQ, this object is first serialized (turned into a sequence of bytes, like a large data string). Upon reaching the broker, this string is deserialized (converted back to the original object).

The vulnerability lies in the deserialization process. An attacker can send maliciously crafted serialized data that, when deserialized by the broker in an old and vulnerable version of ActiveMQ, forces arbitrary code execution (shell execution) on the server.

This flaw is of maximum criticality:

• According to the NIST (National Institute of Standards and Technology), the vulnerability has a score of 9.8.
• According to the Apache Software Foundation, the score is 10, which means the highest possible criticality.

The solution for this vulnerability is trivial: just update ActiveMQ. The fixed versions are 5.15.16, 5.16.7, 5.17.6, or 5.18.3. However, CM's system had not been updated.

The Attack Chain: Privilege Escalation and Credential Theft

After gaining shell access to the server via the deserialization flaw, the attacker managed to escalate privileges and steal credentials. The most alarming post-exploitation failure was how the private communication keys of clients were stored.

Instead of using an HSM (Hardware Security Module), which is a specific and highly secure hardware for storing cryptographic keys, the private keys were kept in PFX files directly on the server. An HSM prevents keys from being extracted, allowing only data to be encrypted by them within the module itself, with extreme physical protections.

With access to the server, the attacker could simply locate and steal these PFX files, which contained the private communication keys of CM's clients.

The Impact of Stolen Private Keys

Private keys are used to digitally sign requests, ensuring their authenticity in the system. With the clients' private keys in hand, the attacker could forge payment messages and digitally sign them, making them indistinguishable from legitimate transactions sent by the clients themselves.

This ability to forge legitimate transactions is why CM, BMP, and the Central Bank initially did not detect the theft. The exact amount diverted is still uncertain, as those responsible need to analyze the logs of the issuing banks to differentiate what was real from what was forged.

The Discovery: The Unexpected Role of Cryptocurrencies

Most notably and worryingly for traditional financial institutions was how the attack was discovered: not by internal monitoring systems or Central Bank alerts, but by a Bitcoin exchange, SmartPay.

When the attackers tried to use R$1 billion of the stolen funds to buy Bitcoin at SmartPay, the exchange noticed the suspicious transaction. SmartPay froze the funds and directly alerted the Central Bank: "You have been robbed!". This episode raises questions about the security of some fintechs compared to the robust security that cryptocurrency exchanges are forced to maintain due to the constant volume of attacks.

Lessons Learned and Critical Recommendations

The incident at CM exposed fundamental failures in security and software development practices:

1. Vulnerability and Update Management:

   • Not updating a component with a critical and public vulnerability is unacceptable.
   • Modern configuration management systems (present in most Git repositories) can automatically alert about components with known vulnerabilities, even preventing deployment.
   • It is imperative to have periodic vulnerability scanning routines, as new flaws can arise in already used components.

   • Secure Storage of Cryptographic Keys:

   • Immediately migrate PFX keys to an HSM is a priority security measure. Although expensive and complex, the cost of an HSM is negligible compared to the billions of reais at risk.

   • Reinforced Authentication:

   • Implementing Multi-Factor Authentication (MFA) for access to banking APIs and critical systems is essential.

   • Active Monitoring and Anomaly Detection:

   • The absence of monitoring routines for large volume transactions is a serious failure. It is inconceivable that R$1 billion was moved without generating automated alerts or human verification.

   • Continuous monitoring is vital to detect suspicious activities in real time.

This attack serves as a severe warning to the entire fintech ecosystem in Brazil. The expectation is that, with the publicity of this vulnerability, hackers will intensify attempts to exploit similar flaws in other systems. Companies urgently need to review their development, deployment, security verification, and monitoring processes to ensure the protection of the billions of reais that pass through their platforms. The amateurism revealed by this investigation is an existential threat in a sector that deals with the money of millions of people.