Obviously, after what happened with MtGox or QuadrigaCX or similar cases where founders claimed they lost the private keys holding the majority of the digital assets of their exchanges while disappearing or found dead later, people in the crypto sphere are increasingly suspicious when they hear about a hack on a project, and the first thought that comes to mind is that the founders have basically emptied the fund and run off with it, that’s what commonly called a RUG.
This has probably been the case in many projects, but not necessarily in all of them, so today we’re looking at a case that we believe to be a real hack due to the nature of the situation.
We think it’s an interesting case to analyze because it will help to better understand the importance of security and audits in smart-contract or blockchain-related projects in general.
We will objectively analyze the drama that happened to the RING Financial project, a token launched on the BSC (Binance Blockchain).
Before coming to the hack, we will first summarize the project and its situation before it:
RING Financial before the hack
RING financial was a DeFi project with the aim of making the DeFi more accessible to the DeFi and crypto community. An ambitious project that wanted to create a node yielding protocol that would be governed by Node Holders and allocate liquidity into more than 300 protocols at once. The aim was to get access to all the protocols through one RING Node and through the RING Dapp.
These protocols were verified by the team and then the community would vote on them where to allocate. The same concept of voting as you would have in a DAO which made RING quite attractive.
RING Financial also simplified quite a lot of the research process and deployment process for one single Node Holder. One Dapp to access all the other Dapps so you would only need one interface instead of 300 different ones with their own accesses and own nodes.
Finally, RING Financial’s aim was to reduce the fees for deploying on different protocols, with volume comes lower transaction fees for individual holders which was one of the main selling points of the project. A project with flair and ambition to make things easier for the community and even more mainstream for those not aware of Defi.
However flair and ambition is not always enough and you need expertise and knowledge which in new and immature markets is a rare find and which is why RING Financial couldn’t come through on its’ promise entirely.
So what really happened with RING Financial? And why did it get hacked? Thanks to the blockchain we have all the forensic evidence needed to delve into this and see where the vulnerabilities were and why RING Financial was not a scam.
The RING Financial HACK happened on December 5th 2021 between 2:01PM and 2:06PM UTC.
Yes, everything happened in literally 5 minutes only! Thanks to the blockchain scanner for these details, by the way, we provide you just below the links of the transactions related to the HACK as well as the address of the contract for those who will want to search in more detail.
Here’s the summary explaining the flaw that the attacker has exploited:
You have to understand that RING Financial’s smart-contract was composed of several parts, one for the token and all the data related to it and another one for everything related to the accounting of nodes and rewards. The part of the token had a security so that only the administrator of the contract can modify the important data of this one, to show you some code, here is a header of a function of the contract which is protected via the attribute “onlyOwner’ which stipulates that the function can be executed only by the administrator:
A function that does not have an onlyOwner attribute (or equivalent attribute to protect the function’s access) can be executed by litterally anyone.
Now, guess what? The functions on the Nodes and Rewards part did not have this attribute, as you can see by looking at the function names below (the onlyOwner attribute is missing):
And as you can imagine, a hacker exploited and scammed this flaw to get an exponential number of rewards in RING, and then dumped them in the liquidity pool and almost violently emptied it in a few minutes. Thus, he perpetrated his scams.
Now you are probably asking yourself two questions:
How could the developers leave such a loophole?
After talking with Solidity developers (language used to code smart-contracts on Ethereum), this is an error related to the role inheritance between two smart-contracts, inheritance is a notion of programming language and in order not to cause you a headache, we will stay in simple words: Basically, it is very likely that the person who coded the contract thought that the functions of the Node part inherited the security roles of the functions of the Token part, but this is unfortunately not the case in Solidity, and it is necessary to redefine the roles of each function of each contract, whatever their link. So our conclusion on this point is that the developer was not an expert and that he probably published the contract WITHOUT taking the time to read it again, probably in a hurry.
How do you know that it is not the developer himself who left this flaw on purpose and it wasn’t a scam?
Very good objection and it’s easy to assume a scam when you’re not sure about how smart contracts work but it’s actually very easy to assume the innocence of the developer, because he published and verified the entire code of the smart-contract publicly on BSCSCAN.COM (the most popular scanner of the Binance Blockchain), on November 19, 2021, that is to say, more than two weeks before the RING Financial HACK happened. And as explained before, the flaw was written in BLACK ON WHITE in the contract, and any experienced developer would have noticed it and reacted, but unfortunately, the first one to had no mercy at all. It is therefore obvious that the developer was not aware of this flaw because he would not have taken the risk to let anyone kill RING Financial project at any time.
To return to the continuation of the RING Financial HACK, the developer realized his blunder and simply froze the contract to stop any distribution of rewards so that the attacker does not empty the pool completely. He then redeployed a Node contract, this time with the security attribute “onlyOwner”. This new Node contract was able to handle the new reward distribution correctly, except that it was too late, because as a result of the HACK all trust had been lost in the project and the team, and the selling pressure killed and ended the token and the project.
To conclude, we picked this story because it shows two important things about smart-contracts and crypto projects, never code a contract in haste and always contact the auditing firms, because once the hack happens, it is too late to save the boat, and RING Financial project is a good example, they have moreover, according to their communication, contacted auditing firms for this second Node contract and did not post it publicly on BSCSCAN until they were certain of its security. But as said before, it was too late for RING Financial, and the damage was irreversible.
Here are all the links of the scanner and the contract addresses:
wallet executing transaction for hack exploit: 0xfe58c9e2ecb95757be6f4bca33162cfa346cc34f
Ring smart-contract address: 0x521ef54063148e5f15f18b9631426175cee23de2
Ring reward pool address: 0xa46cc87eca075c5ae387b86867aa3ee4cb397372
transaction hack exploit:
TRX 1
link: https://bscscan.com/tx/0x596d38494ea5ae640b2a556a7029692928f15713d22b5948477c4eb4a92cf68e
TRX 2
link: https://bscscan.com/tx/0xfc890c855709bb6aeb5177ee31e08751561344402a88af13e7dfd02b9a2f6003
TRX 3
link: https://bscscan.com/tx/0x35c2f1ed9c5ce13a714af6c0dcbbce8fe720f7d6212232b6dd3657d8799a10f1
- SEO Powered Content & PR Distribution. Get Amplified Today.
- Platoblockchain. Web3 Metaverse Intelligence. Knowledge Amplified. Access Here.
- Source: https://www.fintechnews.org/how-to-judge-if-a-so-called-hack-that-happened-to-a-crypto-or-blockchain-project-is-legit-or-if-its-just-a-mechanism-to-hide-a-rug/
