Securing Web3 Through Proactive Threat Prevention

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.

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.

Original hack tx: https://etherscan.io/tx/0xd9bc83688e8eddde39bd9073c363665b1419d475dd4498e81b52cce41d7c76b3
Our rescue tx: https://etherscan.io/tx/0x9549c0cb48ec5a5a2c4703cbbbbea5638028b2d8c8adc103220ef1c7fe5e99a3

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.