On August 30th, the decentralized lending protocol Cream Finance was hacked, resulting in a loss of over $29 million worth of funds. An estimated amount of 2800 ETH and 462,000,000 AMP were stolen in the attack. This is the second time the lending protocol has suffered at the hands of a flash loan attack, losing funds worth $37 million just last February.
Interestingly enough, almost 90 percent of the funds stolen have been returned by the hacker since the exploit. This trajectory of first creating chaos by stealing funds and then subsequently returning them a few weeks later is no longer unheard of. The interoperability protocol Poly Network underwent a similar situation just a month before.
The key question that arises among all this is that of motivation. What motivates attackers who have spent hours poring over code in search of a vulnerability to at the end return all they had gained? Can we believe this to be the result of a rising sense of morality in the blockchain community- or something much more practical?
Before we get into discussing the intricacies of how a hacker’s brain may function, let us first break down exactly how the attack took place as well as the protocol that was affected.
What is Cream Finance?
Cream Finance is a decentralized lending protocol created for individuals and protocols who wish to access financial services. Users can lend any supported assets on their markets, and use the provided capital as collateral to borrow another supported asset.
One of the most popular features Cream Finance offers is that of flash loans. Flash loans are a type of lending system in which users can borrow all available assets with zero collateral, as long as the provided liquidity is returned by the end of the transaction. If a user who has borrowed assets fails to do this, the transaction will be reverted.
Flash loans have remained a controversial idea since their inception. Many argue that since there is no real-world analogy to flash loans, anyone can easily use them to attack or exploit a contract.
Breaking Down The Hack
As confirmed by Cream Finance in their post-mortem report, the attack stemmed from an error in integrating AMP token into the Cream Finance protocol, and not the AMP contract itself. The attacker was able to create a reentrancy opportunity that caused excess borrowing. This allowed him to steal millions of dollars worth of funds.
First, the attacker loaned 500 ETH from UniSwap via Flash loan and then immediately staked the amount as collateral to the crEth contract to mint a certain amount of Cream Ether. He then borrowed AMP against this Cream Ether, calling the crAMP contract in the process. However, before the initial borrow has been completed, the attacker goes on to borrow more ETH within the token transfer() call in the AMP contract. The nested borrow function is a part of the crEth contract while the first borrow is part of the crAmp contract.
Source: ethtx
The bug that enabled this had to do with how AMP was integrated with Cream Finance. Since the AMP token transfer was part of a contract that implemented the ERC-1820 standard, it had a hook titled _callPostTransferHook. The transfer function of AMP calls back the tokensReceived function of the attacker contract using this hook. This allowed him to continually borrow using the crEth contract with the very same collateral he had provided initially. The crEth contract records the loan amount after the loan transfer is completed. This enabled the attacker to borrow more than should be allowed normally.
This exploit is a classic example of a reentrancy attack, in which a function call can be started over or interrupted. In this case, the bug was present in the crAMP token contract which allowed for reentrancy when used in conjunction with an ERC-777 token like $AMP.
Aftermath
Just a week after the attack, almost 90 percent of the funds stolen have been returned by the hacker. The hacker transferred 5,152.6 ETH (worth $17.6M at the time of writing) to the multi-signature wallet controlled by Cream Finance.
Platforms and protocols have suffered at the hands of cyberattacks for ages; in fact, there were several consecutive hacks on established spaces in the cryptocurrency community just last month. However, only recently have we begun to see hackers end up returning the money they had stolen, with the only precedent being the Poly Network hack that took place a few weeks ago.
Why Steal Only To Return It All Later?
From an outsider’s perspective, returning millions of dollars worth of funds after successfully pulling off a complicated exploit is, at best, admirable, and at worst, foolish. There are many theories as to what the motivation behind such a decision may be, offering explanations that are both technical and moral.
Some experts argue that even if an attacker is able to secure funds for himself, the risk of being caught after attempting to spend his loot is far too great to be ignored. In the end, hackers find themselves trapped, ultimately deciding that the safest bet for them would be to return whatever it is that they had stolen.
This view is shared by Tom Robinson, Chief Scientist of blockchain analytics firm Elliptic.
“I think this demonstrates that even if you can steal crypto assets, laundering them and cashing out is extremely difficult, due to the transparency of the blockchain and the use of blockchain analytics.”
Tom Robinson, Chief Scientist of Elliptic
Another motivator for hackers to return their loot is that they simply have no interest in the money to begin with. Oftentimes people who are firm believers in the ideology behind blockchain technology are behind these exploits. They invest their time and energy as members of the community because they care about it. Perhaps the only reason an attacker may carry out an exploit is to prove a point about the security of the victim protocol.
It is possible that as time goes by, this trend of returning crypto loot amplifies, uncovering more motivators in the process. Until then, it is our responsibility to ensure our smart contracts are as watertight as possible to eliminate the risk of any further exploits.
References
Explore further Hack Analysis:
