After successfully intercepting a hacker attack on Paraspace in March of this year, BlockSec, a security company focused on intercepting hacker attacks, has also gained recognition.
BlockSec was originally an academic project. Professor Zhou Yajin (Andy), who was engaged in blockchain security research at Zhejiang University, did not initially intend to start a business. He only wanted to explore the security issues and solutions in the world of blockchain from a purely academic perspective. However, after two or three years of in-depth research, Professor Andy's understanding of this field became deeper and he began to realize that there are still many practical security issues in the blockchain industry that have not been solved. Therefore, Andy decided to expand the scope of his research and focus on developing products and technologies that can truly serve users. That's how BlockSec was born under the drive of this idea.
This week, with the launch of EthCC in Paris, the atmosphere of the cryptocurrency industry's grand event has been ignited. As the founder and CEO of BlockSec, Andy was invited to speak at the 2023 DeFi Security Summit held in Paris, France. In his speech, Andy introduced how BlockSec's proactive defense system, Phalcon Block, works, and the basic principles of its core technology attack interception. The full text translated and compiled by BlockBeats is as follows:
I am Andy, the CEO of BlockSec. Today, I will talk about ways to protect the history of networks by proactively preventing threats.
BlockSec was founded in 2021 and has received support from top investors and clients. We have several products available for the community to use, such as Phalcon. I believe that most security researchers have already used our Phalcon Explorer to visualize transactions. We also have MetaDock and MetaSleuth, which are provided to the community for free.
Why is the security of Web3 so important? Even in this bull market, losses caused by DeFi hacks and scams continue to increase. Every day, we receive emails from victims who say they have been attacked and lost all their money, hoping we can help them. These are not just numbers, they represent individuals who face bankruptcy after being attacked. We must help them.
Why are DeFi hacks so common nowadays? I think there are several reasons. One reason is that we have attackers who have economic incentives to carry out DeFi hacks. By conducting DeFi hacks, they can obtain a large amount of money. However, we do not have enough qualified and secure developers. Some developers focus more on the functionality of the protocol, lacking sufficient security training and not having taken blockchain security courses in community and university. Additionally, some hacks are carried out by state-level organizations. We do not need to discuss this topic too much, as most people understand it.
"Only relying on code auditing is far from enough for protocol security."
When it comes to the security of protocols, most people think of code auditing. Code auditing is indeed the most common way to solve security issues in DeFi protocols. We believe that code auditing is helpful, but it is far from enough. Qualified auditing services are both expensive and time-consuming. You need to wait for two months or three months, or even half a year to be audited by a top auditing company. So some protocols do not have enough time to wait, and we do not have enough qualified auditors. If an auditing company only issues an audit certificate, this certificate will eventually no longer be trusted by the community. For these reasons, protocols must go live without some better threat prevention testing and attack prevention solutions. They can only go live without any security measures.
Therefore, we need a more proactive approach. A more proactive approach means that protocols need to know what is currently happening with their protocol. They cannot just put their protocol online and go to sleep. They need to know what is currently happening and who is interacting with the protocol. And when something bad happens, the protocol needs to know how to automatically respond to such attack transactions.
Why is the proactive approach more important in Web3? Why is it not needed in Web2 but necessary in Web3? This is because Web3 introduces more attack vectors, and the openness of blockchain makes attacks easier than in Web2. Everyone can view smart contracts on the blockchain. Most smart contracts on the blockchain are open source, so both good and bad actors can see the same source code. They can find vulnerabilities in the source code. If there are vulnerabilities, they can exploit them to gain huge profits. In addition, because the blockchain is anonymous, it is difficult to track the flow of funds of attackers. When an attacker launches an attack on a DeFi protocol, we always see the protocol asking who can help us contact Binance, who can help us contact some trading platforms. This is because tracking the flow of funds of attackers is very, very difficult.
Lightning loans make it easier for attackers to launch attacks. In Web2, if you find a vulnerability, you need $2 million to launch an attack, but most people don't have that much money to launch an attack. However, in blockchain, there are lightning loans where you can borrow a large amount of money from the lightning loan service, launch an attack, and then repay the money to the lightning loan. Additionally, some private transaction services can also be abused to launch attacks. We have seen many attacks that use lightning robot services to prevent attack transactions from being observed in the memory pool.
The unique properties of Web3 have led to more damage to protocols and users by attackers in the Web3 space. At the same time, tracking attackers in Web3 has become more difficult.
Based on these reasons, BlockSec has been developing a prototype system since February last year, thinking about how to solve these problems beyond code auditing. Can we take a more proactive approach to defend against DeFi hacker attacks? With these thoughts in mind, BlockSec has developed a system called Phalcon Block.
The basic idea of Phalcon Block is to monitor transactions in the memory pool. We monitor transactions on the blockchain, as well as transactions that have been rolled back. Why do we need to monitor rolled back transactions? That's because attackers may make mistakes and attack transactions may be rolled back. If we can capture such rolled back attack transactions, we can automatically take some action. After that, we can rebuild the attack logic by replaying the attack transactions and replicating the key attack logic of the attack contract, and then issue rescue transactions through some lightning robots or by giving higher gas fees to ensure that our rescue transactions can be faster than the attack transactions or on the blockchain after the attack transactions. By doing so, we can even prevent the attacker's transactions. Because we are faster, we are at the head of the attack transactions in the block.
The key part of this mechanism or system is how to automatically refactor attack transactions and attack contracts. I think the basic idea is to consider what is most important in attacking transactions and attacking smart contracts - the most important thing is the attack logic in this smart contract, as well as the attacker. They will authenticate the caller of this attack smart contract because they do not want their attack smart contract to be caught by others. Therefore, you need to automatically bypass all these checks. Then we can replace this attack transaction in the memory pool, and get a chain of basic blocks or traces of this attack transaction. In this chain of basic blocks, we can replace the JUMPI instruction. We call the frozen JUMPI instruction to the JUMP instruction, so as to jump to the attack logic instead of the basic block that was restored due to the failure of the attack contract authentication.
Therefore, we have proposed a basic thinking mode and methodology. However, it is not so simple in practice. Simply replacing instructions does not work in our case, as we face a series of technical challenges. The most important point is how to deal with the reuse of basic blocks in smart contracts. Compilers often use the reuse of basic blocks to generate smaller code, which is a common practice to reduce code size. So assuming we have two different jump targets, RA1 and RA0. At this point, we need a new jump target, so we need to establish a mapping relationship, that is, the mapping relationship between the old jump target and the new jump target. To do this, we use a jump table to establish the mapping relationship.
During this process, we drew inspiration from the approach of rewriting binary code, a technique that has been used and developed for over two centuries, and possibly even longer. Therefore, we borrowed this concept and applied it to the technology of bytecode rewriting.
By using our system, we have successfully prevented several protocol attack transactions and recovered a significant amount of liquidity losses. For example, we recovered $5 million in losses for ParaSpace this year and $3.8 million in losses for Saddle Finance last year. Therefore, I will now discuss some representative cases to explain how we prevented these transactions.
Take ParaSpace as an example. It was attacked in March this year, but the attackers made several mistakes. They did not prepare enough Gas to execute the attack, so the attack transaction was rolled back. As I mentioned earlier, we closely "monitor" the transactions rolled back on the blockchain. Therefore, even if the transaction is rolled back, BlockSec can still detect it as an attack. Then we automatically synthesized a similar attack contract, replacing the profit address with our own address. After these transactions were executed on the blockchain, BlockSec successfully recovered five million dollars in losses for ParaSpace.
Another example is Platypus, which was attacked in February of this year. Due to vulnerabilities in the smart contract, the attacker found a way to exploit the DeFi protocol of Platypus. However, the attacker made a mistake and did not set up the logic for withdrawing funds in the attacked smart contract. As a result, the hackers faced a problem: how to withdraw the remaining $2.4 million from the attacked contract?
BlockSec has an internal system that can automatically disassemble the attacked contract. We can use heuristic methods to conduct in-depth analysis of the AttackSmart contract and reveal some interesting features of this contract. First, the flash loan callback of this contract is open; second, USDC has approved the Platypus pool contract. What can we do at this point? We upgraded the pool contract and used the privilege approved by the attacked contract to extract the remaining USDC in the attacked contract. We shared this approved concept with the protocol, and the protocol successfully extracted $2.4 million from the attacked contract.
Another example is Transit Swap. Transit Swap was once attacked by a MEV bot. We found that the address of the MEV bot was generated by a vulnerable tool called Profanity. Due to the vulnerability of this tool, we were able to calculate the private key of the MEV bot and extract the funds to return to the protocol.
How to improve the efficiency of this system? I think we have some considerations. Firstly, we need to respond quickly, quickly understand the situation and take immediate action. Secondly, accuracy is also crucial. We cannot introduce too many false positives. As we discussed yesterday, if your monitoring tool reports too many alerts to customers, the usability of the product will be greatly reduced. Therefore, we should operate systematically, rather than just tracking attackers. BlockSec has some tools that can analyze and disassemble contracts, and use heuristic methods to analyze bytecode in depth. BlockSec takes all these measures with the intention of building a complete system and creating an efficient product.
We have seen a competition between attackers and security researchers, as well as some attackers using obfuscation and runtime measures for defense. Based on these, we have built a system called Phalcon Block. If you are interested, you can join our Waitlist to get the latest information on Falcon Block system. We also have a tutorial group on Twitter. If you are interested, please follow us.
Question: BlockSec has carried out many counter-attack operations, let's call them counter-attack operations for now. In this process, how does BlockSec protect itself from legal liability and disputes?
BlockSec founder Andy: This is a very good question. BlockSec attaches great importance to security ethics. We only execute counterattacks or prevent attack transactions after seeing attack transactions occur. We will not execute these attack transactions without prerequisites. Therefore, I believe that the way BlockSec protects users is proactive. If we do not take action, more cunning people may take away all the money.
Question: This may be a follow-up question to the previous one. If someone discovers an unexploited vulnerability and no attack transaction occurs, do you act legally like a white hat hacker to safeguard user funds?
BlockSec founder Andy: Let me rephrase, we did not seize users' funds. We simply automatically restructured the attacker's contract and moved the funds to another wallet. We will return all of these funds to the protocol and users. Although it is controversial in terms of ethics, I believe we are on the side of justice if we only do these things to protect users.
Question: It is obvious that you are doing the right thing, do you have any actual legal protection measures? Do you have a lawyer sitting there checking?
BlockSec founder Andy: Currently we don't have one, but we will consider it.
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia