Securing Web3 Through Proactive Threat Prevention
Jan 28 2023

Introduction

In the past three years, we have observed several security incidents in the DeFi ecosystem. To defend the threats, code-centric methods, e.g., static code auditing, smart contract scanning tool, or dynamic fuzzing, are adopted by the community. Though they have shown effectiveness, we argue that the code-centric approach cannot solely solve the security issues and project users’ assets. For instance, several cases exist where vulnerable contracts have been audited by multiple reputable code auditing companies.

We believe that besides existing code-centric approaches, a more proactive threat prevention solution should exist to defend against the threats. We internally deliberated this idea around the end of 2021 and developed a system called IronDome in early 2022. We have deployed the system internally in BlockSec since then. In 2022, IronDome successfully blocked multiple attacks and saved more than 5 million USD users’ assets, including the case that prevented the exploit to Saddle Fiance in April 2022 and rescued 3.8 Million USD.

In this blog, we will elaborate on the system architecture of IronDome and its success stories. We will also discuss our system's limitations and insights on the future direction of threat prevention.

High-level System Architecture

The basic idea of IronDome is listening to the pending pool of Ethereum, detecting the attack transaction through our transaction pre-execution system Mopsus, and blocking the attack by automatically synthesizing a rescue transaction that will move vulnerable assets into our secure account, and front-running the attack transaction by FlashBot. The following figure shows the architecture.

The overview of the system architecture

Mempool Monitoring

IronDome listens to the pending transactions in the memory pool through our customized Geth client. The critical point is that our system should listen to the transaction promptly and listen to as many transactions as possible.

Attack Detection

Each pending transaction will be fed to the attack detection module. Since these transactions are not on the chain yet, we will leverage our transaction pre-execution engine Mopsus to pre-execute these transactions and detect the attack (malicious) transactions based on the runtime states and outcomes of the transaction.

Rescue Tx Synthesizing

For the attack transaction, IronDome will automatically synthesize a rescue transaction and its auxiliary contracts. The rescue transaction will follow a similar method to the attack transaction to “exploit” the vulnerable contract but transfer the profit to our secure account (a multi-sig account) instead of the attacker-controlled account. For instance, we can automatically deploy auxiliary contracts similar to the attack contracts but replace the token transfer address to our secure account. Of course, more complicated approaches need to be used for some attack transactions.

For the rescue transaction, we need to make it on the chain before the attack transaction. In the current system, we are leveraging FlashBot for this purpose. First, we must ensure that others cannot listen to our rescue tx. Second, we can take some strategies to make our rescue transaction at the top of the block.

Representative Success Stories

We deployed IronDome in early 2022. The system has successfully detected and blocked multiple attacks. This table summarizes some of the success cases.

The following timeline shows how our system rescued 3.8 million USD for Saddle Finance at the end of April 2022. In particular, our system finished the whole process to detect the attack transaction and automatically synthesized the rescue tx in less than one second. We returned all the rescued funds to Saddle Finance. Click the link for the original hack tx and our rescue tx are in the following.

Ethics Consideration

We take security ethics seriously in our system. Though our system is “exploiting” the vulnerable contract to rescue users’ assets, we believe this action does not have an ethical issue.

  • First, our system is not actively exploiting the vulnerable contract. It only reacts when it detects a pending attack transaction and automatically synthesizes a similar one (to block the attack transaction). It never creates the attack transaction in the first place.
  • Second, we actively communicate with the affected protocol and return the saved funds.

Limitations

Although IronDome has shown its effectiveness, the system still has some limitations. In the following, we will illustrate these limitations and discuss further directions in proactive threat prevention.

  • First, our system listens to the pending tx in the mempool. If the attacker leverages some private transaction service, e.g., FlashBot, the attack transaction will not be in the mempool and thus cannot be detected. To solve this issue, we call for collaboration with the private transaction service provider to detect and block the attack transaction (taking a similar way to detect the malicious transaction as our system.) Besides, even if our system cannot block the attack tx in the pending tool, it can still detect the attack tx on the chain and send a rescuee tx to prevent further attack transactions. Note that, in many cases, there has more than one attack transaction.
  • Second, security is an arm-race. We have seen cases where attackers raise the bar for synthesizing the rescue transaction. For instance, they can split an attack transaction into multiple ones and obfuscate the profit address. Though these issues can be solved, we believe the arm-race will not stop. We are working on solutions to solve these issues.
  • Third, how to make the rescue transaction on the chain before the attack tx is still an open question. Though some bidding strategies can improve the chance that our rescue tx is packed into the block, we can not have a 100% guarantee.

References and Further Reading

[1] How to Make the BlockChain Attack “Blockable” | by BlockSec

[2] The Block: Stablecoin DEX Saddle Finance hacked for $10 million

[3] Lend Exploit Post-Mortem — HomeCoin (mirror.xyz)

[4] Equalizer Finance on Twitter: “We have recovered the funds from the vaults on Ethereum and BSC. Now the team is working on recovering the funds from the Polygon and Optimism chains. A big thank you to @BlockSecTeam who managed to block the attackers, protect and return the assets!” / Twitter

[5] FSWAP on Twitter: “The details of the attack on FSWAP liquidity progress” / Twitter

[6] https://forta.org/blog/blocksec-and-forta-work-to-secure-web3-beyond-audits/

[7] https://forta.org/blog/the-future-of-threat-prevention-in-web3/

Sign up for the latest updates
#10: ThirdWeb Incident: Incompatibility Between Trusted Modules Exposes Vulnerability
Security Insights

#10: ThirdWeb Incident: Incompatibility Between Trusted Modules Exposes Vulnerability

This blog shows the vulnerability and attack caused by Incompatibility of commonly used modules.

#9: MEV Bot 0xd61492: From Predator to Prey in an Ingenious Exploit
Security Insights

#9: MEV Bot 0xd61492: From Predator to Prey in an Ingenious Exploit

On August 3, 2023, an MEV Bot on Arbitrum was attacked, resulting in $800K in loss. The root cause of this attack was **Insufficient User Input Verification**.

#8: SushiSwap Incident: A Clumsy Rescue Attempt Leads to a Series of Copycat Attacks
Case Studies

#8: SushiSwap Incident: A Clumsy Rescue Attempt Leads to a Series of Copycat Attacks

On April 9, 2023, SushiSwap became the target of an exploit due to an Unverified External Parameter. The total loss is about $3.3 million.

BlockSec uses cookies and other identifiers to analyze our traffic in accordance. We also share information about your use of our site with our analytics partners. By remaining on this website, you consent to our use of cookies and the Privacy Policy.