Recently, there have been a number of attacks on high-profile centralized exchanges (CEXs) in the digital asset space. We feel it is critical to highlight some of the most common attack vectors in this area so that, in the future, CEXs can adequately protect themselves, their institutional trading partners, and their retail customers.

To start, we wanted to clear up a common misconception – that the most common attack vector is a private key compromise. In post-hack coverage, this is often cited as the attack vector, especially in the absence of detail on the attack itself; this is often categorically false. An actual private key compromise is typically rare, and it’s worth noting that an attacker can execute many malicious activities without having access to the private key itself, including stealing funds.

In general, CEXs should have a full understanding of the entire exchange workflow as well as consistent internal ledger audits. It’s also important that they use only secure and battle-tested third-party applications with appropriate monitoring, set up strong access and approval policies, and utilize cold storage.

In this piece, we will outline the most common attack vectors and how Fireblocks can help mitigate these risks

Top attack vectors for CEX hacks

Let’s explore some of the most relevant vectors for attacks on centralized exchanges.

1. People-based attacks

People-based attacks are where an actual person is the source of compromise, either through human error or a malicious insider. There are two major groupings to people-based attacks: phishing/social engineering and malicious insiders.

Phishing/social engineering

Phishing and social engineering attacks look to gain access to internal systems by compromising a specific person or group of people. Strong hacking groups, like Lazarus, can spend a large amount of time learning their targets, gaining a deep understanding of a targeted organization or company and developing techniques to mislead employees.

How to prevent this type of attack:

• Develop a strong SecOps system
• Rigorous training for personnel to recognize and combat phishing and social engineering attacks
• Split responsibility for transaction approvals, wallet creation, and admin amongst multiple independent parties, with strong governance policies in play to enforce this

How Fireblocks can help:

• The Fireblocks Policy Engine can easily help create customizable and automated policies to ensure there is a split amongst roles and responsibilities and the appropriate approvals are put in place to manage them
• Provide technology to require biometric and passphrase for all approvals, which can be done via mobile devices
• Implement admin quorum requirement to remove or add new users after detecting an employee might’ve been compromised

Malicious insider

Many people have access to mission-critical systems within a centralized exchange, as well as user funds. While no one wants to believe their employees could engineer an attack, this is absolutely a risk. For investors and board members of CEXs, it’s highly important to ask executive management how they are accounting for these possibilities.

How to prevent this type of attack:

• Implement a risk-based approach in distributing controls of transaction approvals, wallet creations, and administrative activities

How Fireblocks can help:

• The Fireblocks Policy Engine can easily help create customizable and automated policies to create a split amongst roles and responsibilities. The Policy Engine ensures the appropriate approvals are put in place to manage them based on different risk profiles (asset sizing, type, destinations, transaction type, etc.)

2. Network-based attacks

One of the most common attack vectors for CEXs is infiltrating an internal network and abusing this position for gain. Often, the assumption is that this is a private key compromise. However, this is typically not the case, as there are many other ways to abuse network access.

Non-cryptocurrency based secret compromise

There are other types of private keys an organization owns which, when stolen, can also lead to significant or total loss of funds. These keys include API and session keys, cookies, or login data that provide access to different parts of the exchange’s wallet operations.

How to prevent this type of attack:

• Secure network, storage, and limited permissions to databases
• IP whitelisting for API keys
• Limits on API keys

How Fireblocks can help:

• Fireblocks provides IP whitelisting for APIs, enabling CEXs to only recognize IPs that are fully approved and have approval policies that can be created to whitelist new IP addresses
• The Fireblocks Policy Engine can easily help create customizable and automated policies to govern approvals for IP whitelisting for APIs
• Specifically for deposit addresses, Fireblocks secures deposit addresses using the same hardware protection as your private keys – meaning it is very difficult for someone to spoof deposit addresses stored using the Fireblocks platform

Signing procedure compromise/UI attack

An attacker can intervene in many parts of transaction signing, from the physical machines of the signer, to the wallet’s server, to the network between.

How to prevent this type of attack:

• Split signing into many parts that form a coherent single and understandable signature flow to reduce the chance of blind signing
• Build a secure network and devices, limiting use of signing machines while creating secure and efficient approval policies
• Use an end-to-end wallet solution where transaction creation is secured similarly to transaction signing

How Fireblocks can help:

• Fireblocks can provide a direct view of the transaction in the signing device (even if it’s in cold storage), creating a single secure signature flow
• Fireblocks can also split transaction approvals into many parts, allowing for multiple approval flows to be enforced to stop malicious activities
• The Fireblocks system is designed in such a way that an attacker cannot compromise a transaction by solely taking control of customer signing devices (even if they take control over all customer’s network), because the MPC algorithm will fail by the Fireblocks co-signers. This is a core property of the MPC-CMP algorithm that is designed to handle dishonest majority attacks

Sim swapping

One of the more common paths hackers use to get into a network is swapping an insider’s phone’s SIM to a malicious SIM. This swap allows access to the network which then provides multiple avenues of attack to occur.

How to prevent this type of attack:

• CEXs should use cold storage whenever possible
• Limit usage of signing machines
• Develop strong SecOps
• Develop transaction approval policies to help prevent malicious fund transfers

How Fireblocks can help:

• Fireblocks offers cold storage solutions for customers, and allows them to use the same transaction signing process (including policy management and enforcement) that they use for hot wallets
• Fireblocks Policy Engine can easily help create customizable and automated transaction policies to prevent malicious fund movements

3. Accounting/internal ledger-based attack

Attacks can happen because of a mistake in how the exchange accounts for user funds. We have seen many cases of dApps affected by this attack vector as well.

Fake inputs and double spending

Using any kind of inconsistency in the input or output logic, a hacker can make an exchange believe it received money which never entered the exchange’s wallet, or convince them no money was sent out when it actually did. In both cases, the attacker will appear to have more money than they actually have, which they can then extract from the exchange, removing money they never actually had.

How to prevent this type of attack:

• Make sure all nodes are updated and ideally use more than one source or technique
• Check if there are any internal ledger inconsistencies, even if no money was lost
• Develop transaction approval and access policies to help prevent malicious fund transfers

How Fireblocks can help:

• The Fireblocks Policy Engine can easily help create customizable and automated transaction policies to prevent malicious fund movements which can also connect to the exchange’s own verification system. No transaction will be signed until it is doubly verified

4. Infrastructure and supply chain attacks

When utilizing external infrastructure systems, such as smart contracts, oracles, or even external vendors and Web2 front ends, it’s important to keep close track of what your dependencies and vulnerabilities are – both on- and off-chain. Supply chain attacks are quite common outside of the blockchain space.

Oracle and token value manipulation

A hacker can manipulate how an exchange values different tokens (this is more common in DEXs) through the oracles they use.

How to prevent this type of attack:

• Ideally use more than one oracle for price discovery
• Check if there are any internal ledger inconsistencies, even if no money was lost
• Develop transaction approval and access policies to help prevent malicious fund transfers, even for smart contract access and usage

How Fireblocks can help:

• The Fireblocks Policy Engine can easily help create customizable and automated transaction policies to prevent malicious fund movements as well as access and usage to smart contracts

Supply chain attack/malicious dependency

Using other external infrastructure resources can be useful, but it creates a risk that these external parties can be attacked and gain access to your systems via the supply chain.

How to prevent this type of attack:

• Limit usage to known and safe packages/imports/devices
• Be careful when updating third party products

How Fireblocks can help:

• Fireblocks only uses secure packages and devices and constantly monitors for any changes