Transaction Screening & Threat Oracles: A New Approach to Exploit Prevention

Forta is the largest network of security intel in Web3. The decentralized Forta Network leverages machine learning and a community of security researchers to detect exploits, scams and other threats.   

This blog dives into transaction screening as a promising approach to prevent smart contract exploits, addresses some common criticisms, and providing a first look at a concept the Forta Foundation team is calling “Threat Oracles”, an on-chain blocklist DeFi protocols can leverage to screen for and block malicious activity. 

Why the team is excited about Transaction Screening

As you know, for some time Forta has been focused on real-time monitoring and threat detection. When the Forta Network detects a threat on-chain, it emits an alert essentially saying “hey, this address is malicious” or “this protocol was just attacked”.

Alerts are useful information, but the team recognized early on the real value is in being able to prevent the exploit entirely. And prevention is a much harder problem to solve than detection - for both cultural and technical reasons.

There is a lot of experimentation around prevention today, and one of the approaches Forta researchers are most excited about is transaction screening. This is pretty self explanatory, transaction screening refers to pre-chain transactions are “screened” against one or more lists/sets of rules where the transaction is reverted if it violates the rules. 

Transaction screening is particularly exciting for a few reasons.

1. It focuses the security effort on malicious activity. The only preventative action most protocols have at their disposal today is pausing one or more of its contracts. This is a blunt approach that destroys the experience for one malicious user and all your legitimate users. It can also have serious consequences for asset prices and liquidations. Screening for malicious activity focuses the security effort on the highest risk users and transactions 

2. It gives protocols control over their risk management. Dapps should have complete control over the transactions they allow and disallow, because ultimately they are the only ones responsible for their risk management.

3. It offers flexibility. There are various forms of transaction screening, and each protocol can implement it the way they want. Some may choose a negative reputation-based approach, others may choose an anomaly-based or positive reputation-based approach, and there are different security vendors across the spectrum ready to support these approaches. 

Some criticisms of transaction screening are that it can result in censorship, attract regulatory scrutiny due to a perception of control, and is susceptible to circumvention. These are valid concerns, but in the context of an exploit the Foundation believes these risks are acceptable or at least addressable.

With respect to censorship, every protocol should have the ability to manage their risk the way they want, including disallowing a subset of transactions they deem to be dangerous. This could impact composability, but just because another protocol lets a hacker take out a flashloan doesn’t mean you have to accept their exploit transaction. 

With respect to attracting regulatory scrutiny, there is a way to implement screening such that protocols maintain their decentralized governance. For example, tokenholders can vote on the rules they want to apply, and a third-party network like Forta could be used to perform the screening.

With respect to circumvention, the Forta Foundation team is working on mechanisms that would make it harder to circumvent screening. One example is RIP-7614, which would introduce a new precompile contract into L2 EVMs that provides better visibility into addresses deeper in the transaction call stack. If adopted, this precompile would make it more difficult for attackers to hide behind proxy contracts and delegate calls. In parallel, the Foundation is also exploring solutions that would allow Forta to screen for contract age. This would make it difficult for attackers to use contracts deployed in the attack transaction.

“Threat Oracles” 

The first iteration of a screening mechanism is what Forta is calling “Threat Oracles”,  a dynamically updated, on-chain list of malicious addresses. The list can include both EOAs and contracts. During internal testing, the team used Forta’s Attack Detector 2.0 as the source of the suspicious addresses as the Attack Detector is actively flagging attacker contracts, but in practice an oracle can have a variety of sources. 

As mentioned above, this oracle also doesn’t have to focus on bad actors, it can screen for positive reputation factors as well. A simple example of this would be screening for and only approving transactions involving contracts with an age of greater than or equal to 20 blocks. This would help prevent atomic attacks where a new malicious smart contract is deployed and invoked in a single exploit transaction.  

The Foundation received feedback that the list of addresses should be crowdsourced so as to avoid a single entity having too much control over the transaction approval process. This is a reasonable concern, and ideally protocols could choose the specific sources they want to trust, crowdsourced from a variety of teams, and perhaps feature some form of consensus mechanism.
DeFi protocols will be able to integrate with a Threat Oracle by adding modifiers to their smart contracts that force addresses in a pending transaction to be checked against the oracle. In the case of a negative reputation check, if an address appears on the list, the protocol has the ability to revert the transaction. In the case of a positive reputation check, if an address is off the list, the protocol can revert. Modifiers can be added to one or more smart contract functions depending on the risk profile of the protocol.

The Road Ahead

One shortcoming of transaction screening lies in the limited visibility smart contracts currently have into the transaction call stack. A DeFi protocol being called by an attacker contract, for example, can only see the addresses in the msg.sender and tx.origin fields of incoming transactions. A clever hacker could simply “hide” using various proxies and techniques to avoid showing up in either field, thereby obfuscating detection by the oracle. To address this limitation, the Foundation, along with members of OpenZeppelin, SphereX, Ironblocks, Neurablock and Collider Ventures have proposed RIP-7614 - a new precompile that exposes the full call stack to called smart contracts. Getting an RIP adopted by L2s is a long process (6-12 months), but the authors are optimistic that L2 communities will see the value. This RIP is simply “leveling the playing field”, giving DeFi protocols equivalent visibility into incoming transactions that attackers already have. If you have any thoughts on RIP-7614, everyone is encouraged to engage with the proposal in the Magicians Forum.  

Transaction screening at scale is still largely conceptual, but the Forta Foundation is committed to pushing this initiative forward. As this concept evolves and garners support, it could very well be a game-changer in the ongoing battle against smart contract exploits.