REFI Security Compromise Post-Mortem
On 14 October 2022, REFI suffered a security compromise. It was an exploit from the known Profanity vanity address vulnerability, a weakness that has been exploited multiple times in numerous DeFi projects (i.e. recent Wintermute hack).
Unfortunately, this happened to REFI when a hacker generated the secret key of the REFI Contract Deployer address (which happens to be the contract owner of the REFI token smart contracts on both the BNB and ETH chains), thereby taking control of the contracts and moving the funds to his/her own wallets.
Consequently, the REFI token contracts were taken hostage via a function that sets the contract owner, allowing the hacker to set the fee or tax per transaction (currently set to 100%, which prevents people from selling the REFI token). In addition, all claimable rewards (denominated in ETH and BNB) yet to be claimed by REFI token holders were moved to the hacker’s wallets and are currently under his/her ownership.
At the time of writing, the contracts are still under hostage to the unknown hacker, all assets are static in his/her wallet, and when REFI token holders buy/sell REFI tokens, 100% of the purchase/sale proceeds will go to the hacker’s wallet as a result of the 100% token tax set by the hacker.
How Did This Happen?
As mentioned earlier, the Contract Deployer address which had ownership of the REFI tokens on the BNB and ETH chains was created using a vanity-address tool. This type of tool is easy to use, and allows the wallet owner to create addresses that may fit a specific sequence of digits. For instance, they could add their preferred digits or letters into the address (i.e. 0xrefi8K…) instead of the usual randomly generated address. However, utilizing this tool makes the address vulnerable to reverse engineering.
Vanity addresses are created by selecting a large number of private keys and deriving the public key. Once the public key looks like what the owner is looking for, they can stop the process.
However, most of these vanity tools utilize a 32-bit vector to find the right 256-bit private key. As the tool goes through many private keys at just 32-bit of complexity, it is likely to leave some of the keys easy to crack with pure GPU power. As a result, that was how the REFI Contract Deployer address was compromised.
Note: This is a simplified explanation of what had occurred.
In REFI’s case, it was the 0x0d1234fb3670978ce165efb01855184c888bc660 address that was compromised, and the address was originally created by Founder and Lead Dev, Mathdroid.
This address had no issues for several months (10 months since the REFI token on ETH Mainnet was first deployed) but eventually became the biggest security risk, given the recent exploits of Profanity vanity addresses.
Once the hacker had decoded the private key for 0x0d1234fb3670978ce165efb01855184c888bc660, they had access to the address and contracts under its ownership. In this case, the contracts under the ownership of the Contract Deployer addresses included the REFI token on ETH Mainnet and the REFI token on the BNB Chain. All assets under the Contract Deployer, including claimable rewards (in ETH and BNB) which have yet to be claimed by REFI token holders, and the BNB liquidity pool were compromised.
Here are the compromised assets thus far:
– BNB/REFI LP on PancakeSwap i.e. 297.43 BNB ($80,257.61)
– Claimable ETH in dividend tracker i.e. 167 ETH ($216,537)
Total: $296,794 in combined BNB and ETH values.
At the time of writing, the compromised assets still sit in the hacker’s wallet address 0x5dd7a80b127cb35b1d8e1706430f36295a0a6fcb.
Resolution Steps the REFI Team Will Take to Prevent Security Compromise Events In Future
1. A Deployer wallet will not be used in future.
2. Contract deployments will utilize temporary deployers, which will then transfer the ownership to a controlled, non-Profanity address.
3. Utilize multi-signature addresses.
4. Utilize Tenderly to monitor transactions which would alert the REFI team immediately when any wallet transactions are made.
