Reviewing 100 attack incidents, in-depth study of encryption attack types, tools, prevention methods, and future predictions

Original Title: "DAOrayaki ｜Analyzing Crypto Attack Types, Tools, Prevention Methods, and Future Predictions from 100 Attack Incidents" ( The State of Crypto Security)

Written by: Kofi Kufuor

Compiled by: DAOctor

Crypto Security Revelation

Hackers have stolen over $2 billion from crypto applications this year. As the DAOrayaki decentralized editorial committee wrote this article, two more hacking incidents occurred: Rabby wallet and the Solana ecosystem decentralized finance platform Mango. As the crypto ecosystem evolves and attracts more malicious actors, the situation will only worsen. Some things must change. It is time to take a step back, reflect on past mistakes, and change the way we handle security in this industry.

In this article, we will:

• Propose a framework for classifying cryptocurrency hackers
• Outline the methods used by the most profitable hackers to date
• Review the strengths and weaknesses of current tools used to prevent hacking
• Discuss the future of cryptocurrency security

1. Cryptocurrency Hacking Classification Framework

The crypto application ecosystem consists of interoperable protocols supported by smart contracts, relying on the underlying infrastructure of blockchains and the internet.

Since each layer of the stack has its unique vulnerabilities, we can classify crypto hackers based on the stack layer exploited and the methods used.

Infrastructure

Attacks on the infrastructure layer exploit weaknesses in the underlying systems that support crypto applications: it relies on consensus blockchains, internet services for the front end, and tools for private key management.

Smart Contract Languages

Hackers at this layer exploit vulnerabilities in smart contract languages like Solidity. Well-known vulnerabilities in smart contract languages, such as reentrancy and the dangers of incorrectly implemented delegate calls, can be mitigated by following best practices.

Interesting Fact: The vulnerability used to execute the $60 million The DAO hack was actually discovered by Least Authority during a security audit of Ethereum. It is interesting to consider how different things might have been if it had been fixed before release.

Protocol Logic

Such attacks exploit errors in the business logic of a single application. If hackers discover a flaw, they can use it to trigger unintended behavior from the application developers.

For example, if a new decentralized exchange has an error in the mathematical equation determining how much a user receives from the exchange, that error can be exploited to withdraw more funds than should be possible.

Protocol logic-level attacks can also exploit existing governance systems to control parameters of the application.

Ecosystem

Many of the most influential crypto hackers exploit interactions between multiple applications. The most common variant is hackers leveraging funds borrowed from another protocol to exploit a logic error in one protocol to scale the attack.

Typically, the funds used for ecosystem attacks are borrowed through flash loans. When executing a flash loan, as long as the funds are returned in the same transaction, you can borrow as much as possible from liquidity pools of protocols like Aave and dYdX without providing collateral.

2. Data Analysis

Since 2020, we have collected data from the 100 largest crypto hacks, with stolen funds totaling $5 billion.

Ecosystem attacks occur most frequently, accounting for 41% of the sample group. Losses due to protocol logic vulnerabilities are the largest.

The three largest attacks in the dataset, namely the Ronin bridge attack ($624 million), the Poly Network hack ($611 million), and the Binance bridge hack ($570 million), had a significant impact on the results.

Excluding the top three attacks, infrastructure hacks are the category with the most significant impact on lost funds.

3. How Hackers Execute Attacks

Infrastructure Attacks

In 61% of infrastructure exploitations in the sample group, private keys were compromised in unknown ways. Hackers may have gained access to these private keys through social attacks such as phishing emails and fake job postings.

Smart Contract Language Attacks

Reentrancy attacks are the most common type of attack at the smart contract language level.

In a reentrancy attack, a function call in the vulnerable smart contract calls a function in a malicious contact. Alternatively, when the vulnerable contract sends tokens to the malicious contract, a function in the malicious contract can be triggered. Then, before the contract updates its balance, the malicious function can recursively call the vulnerable function.

For example, in the Siren Protocol hack, the function for withdrawing collateral tokens was easily reentered and called repeatedly (each time the malicious contract received tokens) until all collateral was drained.

Protocol Logic Attacks

Most vulnerabilities at the protocol layer are unique to specific applications, as each application has its unique logic (unless it is a pure fork).

Access control errors are the most common issue in the sample group. For example, in the Poly Network hack, the "EthCrossChainManager" contract had a function that anyone could call to execute cross-chain transactions.

The contract owns the "EthCrossChainData" contract, so if you set "EthCrossChainData" as the target for the cross-chain transaction, you can bypass the onlyOwner() check.

All that remains is to craft the correct message to change which public key is defined as the protocol's "custodian," seize control, and drain the funds. Ordinary users would never have access to the functions on the "EthCrossChainData" contract.

Note: In many cases, multiple protocols are hacked using the same technique because teams forked a vulnerable codebase.

For example, many Compound forks like CREAM, Hundred Finance, and Voltage Finance became victims of reentrancy attacks because Compound's code did not check the effects of interactions before allowing them. This worked well for Compound because they reviewed the vulnerabilities of every new token they supported, but the fork teams did not make such efforts.

Ecosystem Attacks

98% of ecosystem attacks utilized flash loans.

Flashloan attacks typically follow this formula: use the loan for large-scale swaps, thereby inflating the token price on the AMM, which uses it as a price feed. Then, in the same transaction, use the inflated tokens as collateral to obtain a loan far exceeding their real value.

4. When Attacks Occur

The dataset is not large enough to draw meaningful trends from the time distribution. However, we can see that different types of attacks occur more frequently at different times.

May 2021 saw a historical peak in ecosystem attacks. July 2021 had the most protocol logic attacks. December 2021 experienced the highest number of infrastructure attacks. It is difficult to determine whether these clusters are coincidental or if they represent a successful case that incentivizes the same actors or others to focus on a specific category.

Exploits at the smart contract language level are the rarest. The dataset began in 2020, when most vulnerabilities in this category were already well-known and likely discovered early on.

Over time, the distribution of stolen funds shows four major peaks. There was a peak in August 2021 driven by the Poly Network hack. Another peak occurred in December 2021 due to a large number of infrastructure hacks that compromised private keys, such as 8ight Finance, Ascendex, and Vulcan Forged. Then, due to the Ronin hack, we saw a historical peak in March 2022. The final peak was caused by the attack on the BNB bridge.

5. Where Attacks Occur

The dataset is segmented based on the chain of the contract or wallet from which the stolen funds were taken. Ethereum has the highest number of hacks, accounting for 45% of the sample group. Binance Smart Chain (BSC) ranks second at 20%.

There are many factors contributing to this:

• Ethereum and BSC have the highest total value locked (the funds deposited in applications), making the scale of the bounty larger for hackers on these chains.
• Most crypto developers are familiar with Solidity, the chosen smart contract language on Ethereum and BSC, and there are more complex tools supporting that language.

The amount of stolen funds on Ethereum is the largest ($2 billion), with BSC in second place ($878 million). Hacks involving stolen funds on Ethereum, BSC, and Polygon rank third in a single event ($689 million). This is primarily due to the Poly Network attack.

Hacks involving cross-chain bridges or multi-chain applications (such as multi-chain exchanges or multi-chain lending) have a significant impact on the dataset. Although they only account for 10% of the incidents, these hacks account for $2.52 billion in stolen funds.

6. How We Prevent Hacks

For each layer of the threat stack, we can use some tools to identify potential attack vectors early and prevent attacks from occurring.

Infrastructure

Most large infrastructure hacks involve hackers obtaining sensitive information, such as private keys. Following good operational security (OPSEC) practices and conducting regular threat modeling can reduce the likelihood of this happening. Development teams with good OPSEC processes will:

• Identify sensitive data (private keys, employee information, API keys, etc.)
• Identify potential threats (social attacks, technical vulnerabilities, insider threats, etc.)
• Identify vulnerabilities and weaknesses in existing security defenses
• Determine the threat level of each vulnerability
• Create and implement plans to mitigate threats
• Smart Contract Languages and Protocol Logic

Fuzz Testing

Fuzz testing tools like Echidna can test how smart contracts respond to a large number of randomly generated transactions. This is a good way to detect edge cases where specific inputs produce unexpected results.

Static Analysis

Static analysis tools, such as Slither and Mythril, automatically detect vulnerabilities in smart contracts. These tools are great for quickly identifying common vulnerabilities, but they can only catch a predefined set of issues. If a smart contract has a problem not covered by the tool's specifications, it will go unnoticed.

Formal Verification

Formal verification tools, such as Certora, compare smart contracts against specifications written by developers. The specifications detail what the code should do and the properties it requires. For example, developers of a lending application would specify that each loan must have sufficient collateral backing.

If any possible behavior of the smart contract does not conform to the specifications, the formal verifier will identify that violation.

The weakness of formal verification is that the testing is only as good as the specifications. If the provided specifications do not account for certain behaviors or are too lenient, the verification process will fail to capture all errors.

Audits and Peer Reviews

In an audit or peer review, a trusted group of developers will test and review the project's code. Auditors will write a report detailing the vulnerabilities they find and recommendations for fixing those issues.

Having third-party experts review contracts is a good way to identify vulnerabilities missed by the original team. However, auditors are also human and cannot catch everything. Additionally, there must be trust in this process; if auditors find issues, they will inform you rather than exploit them themselves.

Ecosystem Attacks

Frustratingly, despite ecosystem attacks being the most common and destructive variant, there are not many tools in the toolbox suitable for preventing these types of attacks.

Automated security tools focus on discovering errors in a single contact at a time. Audits often fail to address how to exploit interactions between multiple protocols in the ecosystem.

Monitoring tools like Forta and Tenderly Alerts can issue warnings when composability attacks occur, allowing teams to take action. However, during flash loan attacks, funds are often stolen in a single transaction, so any alerts come too late to prevent significant losses.

Threat detection models can be used to look for malicious transactions in the memory pool, where transactions are before being processed by nodes, but hackers can bypass these checks by using services like flashbots to send transactions directly to miners.

7. Predictions for the Future of Crypto Security

1) I believe the best teams will shift from viewing security as an event-based practice (testing -> peer review -> audit) to a continuous practice process. They will:

• Run static analysis and fuzz testing on every addition to the main codebase.
• Run formal verification with every major upgrade.
• Set up monitoring and alert systems using responsive actions (pausing the entire application or specific affected modules).
• Designate some team members specifically responsible for developing and maintaining security automation and attack response plans.
• Security is not a checklist to be filled out and set aside. Security work should not end after an audit. In many cases, such as the Nomad bridge hack, exploits are based on errors introduced in upgrades after audits.

2) The process by which the crypto security community responds to hacks will become more organized and streamlined. Whenever a hack occurs, contributors flood into crypto security group chats eager to help, but the lack of organization means important details can get lost in the chaos. I see a future where some of these group chats evolve into more structured organizations:

• Using on-chain monitoring and social media monitoring tools to quickly detect active attacks.
• Using security information and event management tools to coordinate efforts.
• Independent workflows with different channels to communicate white hat work, data analysis, root cause theories, and other tasks.