While both attackers and smart contract auditors are motivated to find vulnerabilities in code, according to Eyal Meron, the co-founder and CEO of Spherex, the former “is always more incentivized as the protocol’s total value locked (TVL) grows.” To overcome this challenge, Meron told Bitcoin.com News that decentralized protocols will need to put in place what he called “asymmetric countermeasures.”
Human Error and Smart Contract Vulnerabilities
The Spherex boss also suggested deploying an exploit prevention solution as another way protocols can prevent attackers from using errors in code to steal digital assets worth millions. Meron, a senior veteran of the elite Israeli 8200 cyber unit, nevertheless admits that most smart contract vulnerabilities are often the result of human error which in many cases is “inevitable.”
One common error, which according to Meron is almost impossible to detect, often occurs when developers “overlook how every code line affects the contract depending on the different states it might be in.” It is these errors that criminals often take advantage of before successfully siphoning digital assets worth millions of dollars. Many players in the Web3 space including Meron insist that when users lose funds through such incidents the entire industry suffers.
Meanwhile, in his written answers sent to Bitcoin.com News, Spherex’s chief product officer Ariel Tempelhof touched on how the collaboration between blockchains and onchain security providers can help turn the tide against code exploiters and other cyber criminals. He also offered his thoughts on some critics’ contention that an exploit prevention solution may eventually be used as a censorship tool.
Below are both Eyal Meron and Ariel Tempelhof‘s answers to all the questions sent to them via Telegram.
Bitcoin.com News (BCN): Smart contract vulnerabilities are often caused by human errors. What are some of the common mistakes developers make that give hackers an opportunity to look for and exploit weaknesses in smart contracts?
Eyal Meron (EM): There are a lot of common mistakes that, in our eyes, stem from the fact that a deployed smart contract is a state machine that grows exponentially with the code base and transaction volume. Due to this, human errors are inevitable, both on the developers’ part and the auditors’. The most common mistake is to overlook how every code line affects the contract depending on the different states it might be in (which is honestly impossible).
BCN: Once deployed, smart contracts become immutable and the vulnerabilities become a permanent part of the code. Therefore before they are deployed smart contracts are audited and in some cases, multiple times. However, it appears that has not helped to bring down the number of exploits. In what ways do the existing solutions for smart contract protection like auditing fall short?
EM: The fact that protocols are being audited multiple times proves that audits are best-effort and not enough. Audits are like playing on the attacker’s court. Both parties look for vulnerabilities in the code while the attacker is always more incentivized as the protocol total value locked (TVL) grows, while the auditors have limited resources. Protocols need to put asymmetric countermeasures in place to win this race.
BCN: Your company Spherex recently launched an exploit prevention solution for smart contracts called Spherex-Protect. Can you tell us how it works and whether blockchain protocols or applications have to compromise on decentralization to make it work for them?
EM: Sure, Spherex-Protect is essentially the missing piece in the Web3 security paradigm. Instead of looking at what’s wrong in your code, we look at how your protocol operates and make sure this line of operation stays the same. The protection is actually being done on-chain which has two important properties: The protection is verifiable – everyone (the protocol owners and customers) can look at the protection code and understand how it works.
The protection can be completely decentralized – The owners of the protection can be configured. It could be Spherex, the protocol owners, the assigned security council, the DAO, or completely revoked.
In that sense, Spherex-Protect is the most decentralized Web3 security a protocol can have. Moreover, this platform was planned with modularity and openness in mind. Everyone can write protection modules for the ecosystem to be audited and verified by the whole community.
BCN: How does Spherex differentiate between legitimate user transactions and suspicious ones and what happens to a suspicious transaction — including the false positive detections — once it is flagged?
Ariel Tempelhof (AT): This has been a year-long research by our research team. Finding the best way to distinguish between malicious and legitimate transactions, during transaction execution while maintaining a very low gas footprint.
We look at multiple data points, accessible from the contract itself, and gather them during the execution of the transaction. Those might be gas consumption, storage changes, input parameters, etc. When enough data is gathered, a decision is made whether to allow the transaction or revert it. The results were astonishing, we were able to prevent most of the hacks we’ve analyzed while maintaining a <0.1% false positive rate.
Once a transaction is reverted, it is further analyzed by our off-chain module to produce a recommendation of what to do with transactions sharing the same aspects in the future. Of course, it’s up to the protection manager to decide whether to accept the recommendation or disregard it.
BCN: How do you see smart contract security and threats evolving in an increasingly multi-chain future?
AT: A chain is not just a set of blocks, it’s a whole ecosystem of protocols that work together. As most blockchains would like to single themselves out as one of the most secure blockchains out there, they would have to implement a security baseline for the whole ecosystem to adopt. Spherex has already started collaborating with blockchains to incorporate chain-wide security countermeasures in place.
On another note, multi-chain means multiple bridges connecting them. Bridges, as we all know, are the most prone-to-be-hacked protocols out there. SphereX-Protect has already shown great success in preventing even the most sophisticated bridge hacks introduced in recent years.
BCN: Though they have their downsides including smart contract vulnerabilities, blockchain transactions are supposed to be irreversible by design. What’s the possibility of this ability to block or revert blockchain transactions being used as a censorship tool in the future?
AT: The exploit prevention solution is designed not to be used as a censorship tool. The data points we’re looking at are intrinsic to the protocol and are not affected by the entity sending the transaction. Applying such censorship, in our eyes, is futile since changing addresses is very easy on the blockchain.
What are your thoughts about this interview? Let us know what you think in the comments section below.