During the week from June 27 to July 3, 2022, security incidents that happened in the crypto space are all security hacks.

Here is a list of the security hacks:

1. Fishing Attack on Nickydooodles.eth

On June 28, the address 0xA97aB7a18133a13fEBeB33Dc661cf5bF3a2eebe1 (Nickydooodles.eth) suffered from a phishing attack.

The attacker’s address was 0x0730bCbd6Dfa86389eBF02109A5477fD65536175 on Ethereum.

17.8 ETHs valued at around 1,8000 and all the NFT (including Goblintowns, Doodles, and Sandbox Lands) held in the address were exploited.

The holder of Nickydooodles. eth was a famous NFT creator and also the founder of Meta bergs. Nickydooodles.eth claimed in its social media account that its address suffered from a phishing attack and lost ETHs and all the NFTs in the address. The attacker even controlled its Twitter account.

2. Goldfinch

On June 28, Goldfinch, a DeFi application deployed on Ethereum was attacked.

The attacker’s address was 0x86c595d81c8ab46d893065c3c674da72555fe7c0 on Ethereum.

The attacking contract was deployed at 0x541143d5eb30563a478eea23866e203b7c38c1ca on Ehtereum

The attacked contract (SeniorPool) was deployed at 0x9ffFAD7128152190065C800774443af102B62052 on Ethereum.

The hash value of the attack transaction was:

0xd56d801e07df9d8457973c3938f5d3e6343ec1ed11f4ebb76bc3f5cc73001707

Crypto assets valued at around $500,000 were exploited in the incident.

The root cause was the incorrect price calculation in USDC/FIDU in the implementation. This led to a big deviation between the price of FIDU in USDC in the SeniorPool contract and the price generated in Curve. The attacker leveraged a flash-loan to borrow USDCs, exchanged them for FIDUs in Curve, and then called “withdrawInFidu” in the SeniorPool contract to burn the FIDUs and get far more USDCs that were borrowed.

The attacker eventually exploited 28523 USDCs and the Goldfinch lost 541158 USDCs.

3. Quiuixotic

On July 1, Quiuixotic, an NFT application deployed on Optimism was attacked.

The attacker’s address was 0x0a0805082ea0fc8bfdcc6218a986efda6704efe5 on Optimism.

The attacking contract was deployed at 0xbe81eabdbd437cba43e4c1c330c63022772c2520 on Optimism.

The attacked contract(ExchangeV4) was deployed at:

0x065e8A87b8F11aED6fAcf9447aBe5E8C5D7502b6 on Optimism.

Crypto assets valued at $130,000 were exploited in this incident.

The root cause was the implementation didn’t correctly validate sell orders.

The attacked ExchangeV4 contract should ensure that a buyer’s order should match a seller’s order. But it didn’t. Therefore anyone could create an NFT and sell this NFT to a buyer that had been authorized in ExchangeV4 no matter whether or not this NFT was what the buyer expected to buy.

4. Ankr

On July 1, Ankr, a popular blockchain service provider suffered from a DNS hijack attack.

The news was published by Polygon’s chief information security officer Mudit Gupta. Both Polygon and Fantom’s gateway service provided by Ankr suffered from DNS hijack attacks.

At the time of writing the service had been recovered and back to normal.

5. Crema Finance

On July 2, Crema Finance, a DeFi application deployed on Solana was attacked.

The attacker’s address was Esmx2QjmDZMjJ15yBJ2nhqisjEt7Gqro4jSkofdoVsvY on Solana.

The attacker got its assets for the attack from 0x8021b2962dB803b73Aa874030B0B42c202E8458F on Ethereum

The attacker initiated a transaction to modify the “Tick Account” contract on Solana and its hash value was:

5kfoGgEvhBiHXz1MBVxn8rfJh3cf98m3D64YHE2Q1SsXLiaahvdK4hCJfkMA7jQFXLjP9YdNSTMSor3oXbKrLTev

Crypto assets valued at around $8.7 million were exploited in this incident.

The root cause was a lack of validation for Tick Account contracts in the implementation. The attacker exploited this vulnerability to deploy a fake Tick Account contract which would return a fake token price. The attacker used the fake token price and leveraged flash loans to do arbitrage transactions and eventually transferred the exploited assets to Ethereum.

Besides the security incidents, there was the latest security update from MetaMask.

On June 28, MetaMask announced that the “eth_decrypt” and “eth_getEncryption PublicKey” APIs had been deprecated and more secure APIs would be released soon. Although these two APIs hadn’t caused any issues, MetaMask suggested users should no longer use them.

Closing thoughts

There were five security attacks in the past week. Among the five attacks, three were smart contract vulnerabilities, one was a phishing attack, and one was a DNS hijack attack.

A reminder to project teams: always test thoroughly, do smart contract audits before deploying smart contracts on-chain, and employ comprehensive security solutions to daily operations and management. In addition, in daily operations, common attacks such as DNS hijack attacks, and DDOS attacks should always be watched.

A reminder to crypto users: be cautious about suspicious links, emails or websites, and projects that are launched by teams without an established reputation.

During the week from June 20 to June 26, 2022, security incidents that happened in the crypto space are either security hacks or rug-pulls.

Here is a list of the security hacks:

1. Whaleswap Finance

On June 20, Whaleswap Finance, a DeFi application deployed on the BNB chain was attacked.

The attacker’s address was 0xD793FF8D744828c25DA7F80123B88Dd5c2Bf7A50.

The attacking contracts were deployed at the following address on the BNB chain:

0xAA85fc75f2534FAA2668EF40C88e1dAe841Be6ba and

0xAA85fc75f2534FAA2668EF40C88e1dAe841Be6ba

The attacked contracts were deployed at the following addresses on the BNB chain:

0x8Bfee2cAFF6b5D4Ac9F438F4b1f36FeeB5E76794 (WhaleswapPair) and

0x4000EC3810DFD0A0068b38F64795AE2d521A46f2 (WhaleswapPair)

The hash values of the attack transactions were:

0x9f5b02cb1ce2d75ba457a2d152d89b6d3932ff057c03739a0071fb816e0ebab3 and

0x43ddb5965733ee71c4b29fe685ae76bfc4d121dc606cbdf317fc59d61fec4fcf

Crypto assets valued at around $12000 were exploited.

The root cause is the validation of the K value in the AMM algorithm was incorrect.

In the swap function defined in the WhaleswapPair contract, the ratio of transaction fees should be either 4/10000 or 25/10000 based on the different “stable” values. However, the actual ratio value that was used was 2/10000. This led to the incorrect validation of the k value. The attacker exploited this vulnerability and leveraged a flash loan to borrow a large number of token A and paid back the loan with token B whose price was much lower than token A’s price.

2. Neo Hunters

On June 21, Neo Hunters’ team announced that its Discord server suffered from phishing attacks and phishing links were sent to its Discord server. Users should never click on these phishing links.

3. PandorachainDAO

On June 22, PandorachainDAO, an application deployed on the BNB chain was attacked.

The attacker’s address was 0xa11e104601582280672d6ed81eec3af2e4d21940 on the BNB chain.

The attacking contract was deployed at 0x51626f9a6cc5d55c042e43a3c0fa8cd2233a0098 on the BNB chain.

The attacked contract was deployed at 0x83757110409d993FCF3610260D7Af753e2423529 (PCDNFT) on the BNB chain.

The hash value of the attack transaction was:

0x1fff2189ef23e3c6dd3d643cbb91ee7ae20686fb6584e6d987f7fc55d98923be

Crypto assets valued at around $120,000 were exploited in this incident.

The root cause is that the implementation used an incorrect algorithm to calculate a token’s price.

The shouchan function defined in the PCDNFT contract would use the balances of USDT and PCD in the USDT-PCD trading pair to calculate the PCT’s price. The attacker exploited this vulnerability and leveraged a flash loan to manipulate the balance values and push the PCD’s price to an extremely low level such that the attacker used very few USDTs to purchase a large number of PCDs

4. Harmony ETH Cross-Chain Bridge

On June 23, Harmony’s ETH cross-chain bridge was attacked.

The attack was launched from the following three addresses on Ethereum:

0x0d043128146654C7683Fbf30ac98D7B2285DeD00,

0x9E91ae672E7f7330Fc6B9bAb9C259BD94Cd08715 and

0x58F4BACcb411ACef70A5f6DD174Af7854fc48Fa9

Crypto assets valued at around $100 million were exploited.

For more details please refer to:

https://medium.com/@FairyproofT/fairyproofs-analysis-of-the-attack-on-harmony-9f95bd76ab9d

5. Convex Finance

On June 24, Convex Finance’s team announced that the project’s website (http://convexfinance.com/) suffered from a DNS hijack. 215 ETHs valued at around $250,000 were exploited in this attack.

Here is a list of the rug pulls:

1. LV PLUS

On June 21, LV PLUS, an application deployed on the BNB chain turned out to be a rug pull.

The exploiter from 0x7721034753ebe6f5714a7c5ebd0d188fa4a3b167 on the BNB chain deployed the LVP token. The team behind the project claimed the project was part of “LV Metaverse” but it turned out that the project had nothing to do with LV. The exploiter distributed the tokens it held to multiple wallets, dumped them on the market, and got a profit of around $1.5 million.

All the profits were eventually sent to 0x0786e8682c11312cb547d6db46bc99a392050b26 on the BNB chain.

At the time of writing, 0x0786e8682c11312cb547d6db46bc99a392050b26 held crypto assets valued at around $8 million.

2. Justcows

On June 24, Justcows, a centralized platform that provided custody services turned out to be a rug-pull. The team behind the platform ran away with users’ crypto assets valued at around $5 million. The team distributed a large number of BUSDs via coin-join to thousands of addresses including Hunterswap, exchanges, etc.

Around one month ago, the team announced that it disabled the withdrawal of crypto assets.

Closing thoughts

There were five security attacks and two rug-pulls in the past week. Among the five attacks, the ones that happened to Whaleswap and PandorachainDAO were smart contract vulnerabilities that could have been prevented if they had undergone professional audits. The other three were more related to management and operations.

A reminder to project teams: always test thoroughly, do smart contract audits before deploying smart contracts on-chain, and employ comprehensive security solutions to daily operations and management.

A reminder to crypto users: be cautious about suspicious links, emails or websites, and projects that are launched by teams without an established reputation.

During the week from June 13 to June 19, 2022, security incidents that happened in the crypto space are all security hacks.

Here is a list of the security hacks:

1. FSwap

On June 13, FSwap, a DeFi application deployed on the BNB chain was attacked.

The attacker’s address was 0x000c84c59385b64c3EA4D48cC3fCa1f08f3ABCfC on the BNB chain.

The attacking contract was deployed at 0x7437e7a923a5b467a197c6fae991f0f0ced9af57 on the BNB chain.

The attacked contract was deployed at 0x0d5F1226bd91b5582F6ED54DeeE739CAC49C37Db on the BNB chain.

The hash value of the attack transaction was:

0xe75e30dafd865331e6a002d50effe084c21e413c96d4550d5e09cf647686fcbe

Crypto assets valued at around $390,000 were exploited in this incident.

The root cause is a bug in its swap algorithm that led to incorrect prices. This vulnerability was exploited, and a flash loan was leveraged to enlarge the loss.

2. Known Origin

On June 14, the team behind one popular NFT platform Known Origin announced that its Discord server was attacked. The team announced on its Twitter that they would never DM anyone or send any mint links.

3. Inverse Finance

On June 16, Inverse Finance, a DeFi application deployed on Ethereum was attacked.

The attacker’s address was 0x7b792e49f640676b3706d666075e903b3a4deec6 on Ethereum.

The attacking contract was deployed at 0xf508c58ce37ce40a40997c715075172691f92e2d on Ethereum.

The hash value of the attack transaction was:

0x958236266991bc3fe3b77feaacea120f172c0708ad01c7a715b255f218f9313c

Crypto assets valued at $1.2 million were exploited in this incident.

The root cause is that the implementation used an inappropriate algorithm to calculate an LP’s price. The implementation used its pair contract’s balance to calculate an LP’s price and the balance was easily manipulated. The attacker leveraged a flash loan to pump an LP’s price, and used the LP as collateral to borrow 10 million DOLAs valued at around $1.2 million.

Just two months ago, on April 12, 2022, Inverse Finance suffered from an attack and then followed by this attack.

4. Tether

On June 18, Tether’s CTO announced that the website suffered from a DDoS attack. Prior to the attack, the attacker asked for a ransom from Tether but got rejected. Then Tether’s website was flushed with 8 million requests within 5 minutes. In general, the frequency is 2000 requests per 5 minutes.

Right after the attack was launched, the Tether team used Couldflare’s AS-CHOOPA to mitigate this attack. No losses were found in this incident.

Closing thoughts

The ones that happened to FSwap and Inverse Finance were typical smart contract vulnerabilities that could have been prevented if they had undergone professional audits.

The one that happened to KnownOrigin was a typical phishing attack.

A reminder to project teams: always test thoroughly and do smart contract audits before deploying smart contracts on-chain.

A reminder to crypto users: be cautious about suspicious links, emails or websites, and projects that are launched by teams without an established reputation.

During the week from June 6 to June 12, 2022, security incidents that happened in the crypto space were either security hacks or rug pulls.

Here is a list of the security hacks:

1. Equalizer Finance

On June 7, Equalizer Finance, a DeFi application deployed on both the BNB chain and Ethereum was attacked.

The attacker’s address was 0x0000003502aa61A5f1B1fDaDFF2cf947DfDa526e on Ethereum.

The attacking contract was deployed at 0xf667e04A8D5910328aE92750c0459d2E9E29a67f on Ethereum.

The attacked contracts were deployed at 0xA2B5ee9645f6011b2d6E10f750aB47fB455316EE on Ethereum and 0xcd2d4938350ea9137c5eac19b08b546aa14df075 on the BNB chain.

The vulnerability was that its FlashLoanProvider contract was incompatible with its Vault contracts. The vulnerability was exploited by the attacker to leverage flash loans to withdraw a large number of tokens from the vaults and eventually drained the vaults.

2. OSMO

On June 8, Pool number 678 deployed on the Osmosis blockchain was attacked.

Crypto assets valued at around $5 million were exploited.

The vulnerability was a software bug that was exploited to withdraw additional large numbers of tokens.

For more details please refer to:

https://medium.com/@FairyproofT/analysis-of-the-attack-on-osmosis-by-fairyproof-1899997d5089

3. Apollox

On June 8, Apollox, a DeFi application deployed on the BNB chain was attacked.

The attacker’s address was 0x9e532b19abd155ae5ced76ca2a206a732c68f261 on the BNB chain.

The attacking contract was deployed at 0xcC6EEDeb5266AAe42A33b629380B78c570E29956 on the BNB chain.

The hash value of the attack transaction was:

0x21e5e6ee42906a840c07eb39fb788553a3fbb5794562825c2a1d37bfc910e5f7

In this incident, 53 million APX tokens valued at around $2.1 million were exploited.

The root cause was the Apollox system had a bug in its signature implementation and the attacker exploited this to generate 255 signatures and withdraw 5300 million APX tokens.

4. GYM

On June 8, GYM, a DeFi application deployed on the BNB chain was attacked.

The attacker’s address was 0xb2c035eee03b821cbe78644e5da8b8eaa711d2e5 on the BNB chain.

The attacking contracts were deployed at the following addresses on the BNB chain:

0x7cbfd7bccd0a4a377ec6f6e44857efe42c91b6ea,

0xa796406635272448fa30089cd4d71dadae01c169,

0xd36Ea4756cf157c1A57BFFC8d3F064a1e0EFBE9f,

0x8aedf4e03f70d0680b760a63c1b4acb0eb437874 and

0x2cdb504CEFE087e00F13F9283F2FcbbdE7C2A28D

The attacked contracts were deployed at the following addresses on the BNB chain:

0xA8987285E100A8b557F06A7889F79E0064b359f2 (GymSinglePool) and

0x0288FBA0BF19072d30490A0F3C81cD9B0634258a (GymSinglePool).

In this incident, crypto-assets valued at around $2.1 million were exploited.

The vulnerability was that the contract implementation didn’t execute a transfer transaction and didn’t check the transfer transaction’s status either.

The “GymSinglePool” contract’s “depositFromOtherContract” function would update a deposit’s

status but didn’t check whether or not that deposit was actually executed. Therefore a user could

call the “depositFromOtherContract” function to update a deposit status but didn’t deposit the tokens.

5. Optimism

On June 5, Optimism, a popular Ethereum layer 2 solutions was exploited.

The attacker’s address was 0x60B28637879B5a09D21B68040020FFbf7dbA5107 on Optimism.

The exploited address was 0x4f3a120E72C76c22ae802D129F599BFDbc31cb81 on Optimism.

In this incident, 20 million OP tokens valued at around $17 million were exploited.

For more details about this incident please refer to:

https://medium.com/@FairyproofT/analysis-solution-to-the-attack-on-optimism-by-fairyproof-95b09443dbf7

Here is a list of the rug pulls:

1. Baby Elon

On June 8, Baby Elon, a dApp deployed on the BNB chain turned out to be a rug-pull.

623 BNBs valued at around $170,000 were exploited and cashed out via Tornado Cash.

Closing thoughts

In the past week, there were six incidents. Five of them were hacks and one was a rug pull.

The one that happened to Optimisim is a new type of attack which we name “contract hijacking” and can be prevented by following the suggestion raised in https://medium.com/@FairyproofT/analysis-solution-to-the-attack-on-optimism-by-fairyproof-95b09443dbf7.

The other four hacks could have been prevented if the teams behind these projects had done thorough tests and had their projects audited by professionals.

A reminder to project teams: always test thoroughly and do smart contract audits before deploying smart contracts on-chain.

A reminder to crypto users: be cautious about suspicious links, emails or websites, and projects that are launched by teams without an established reputation.

During the week from May 30 to June 5, 2022, security incidents that happened in the crypto space were all security hacks.

Here is a list of the security hacks:

1. Novo

On May 29, Novo, a DeFi application deployed on the BNB chain was attacked.

The attacker’s address was 0x31A7CC04987520cEfaCd46F734943A105b29186E on the BNB chain.

The attacking contract was deployed at 0x3463a663de4ccc59c8b21190f81027096f18cf2a on the BNB chain.

The hash values of the attack transactions were:

0xc346adf14e5082e6df5aeae650f3d7f606d7e08247c2b856510766b4dfcdc57f and

0x23fd14a46b539c81ca4491a577de118925d9339a63fcf4c8a3ff36c14d6cec35

The attacked contracts were deployed at the following two addresses:

0x6Fb2020C236BBD5a7DDEb07E14c9298642253333 and

0xa0787DaAD6062349f63b7c228CBFd5d8A3dB08F1

In this incident, 279 BNBs valued at around $800,000 were exploited.

The root cause of the incident was that its “transferFrom” function didn’t deduct the “approval” amount.

The attacker leveraged a flash-loan to borrow BNBs and exchanged the BNBs for NOVOs on Pancake. Then the attacker exploited the vulnerability of the “transferForm” function and eventually pumped NOVO’s price and exchanged the NOVOs for WBNBs.

2. Mirror

On May 30, Mirror, a dApp deployed on the Terra 2.0 blockchain was attacked.

In this incident, crypto-assets valued at around $2 million were exploited.

The root cause was that Terra 2.0 Mirror still used the oracle that was used on Terra Classic and the price of LUNA fed by this oracle was incorrect. The attack exploited this vulnerability to use LUNAs as collateral to borrow crypto assets including mBTC, ETH, mGLXY, mDOT, etc.

3. BAYC

On June 4, BAYC, the most popular NFT application on Ethereum was attacked.

In this incident, the project’s Discord server was attacked, and quite a few users suffered from a phishing attack. NFTs valued at around 200 ETH were exploited.

Closing thoughts

In the past week, there were three incidents, the root cause of the Mirror incident was using an inappropriate oracle. The root cause of the NOVO incident was a smart contract vulnerability. The phishing attack could have been prevented if the victims had paid more attention and acted with care and caution.

A reminder to project teams: always test thoroughly and do smart contract audits before deploying smart contracts on-chain.

A reminder to crypto users: be cautious about suspicious links, emails or websites, and projects that are launched by teams without an established reputation.

During the week from May 23 to May 29, 2022, security incidents that happened in the crypto space were either security hacks or rug-pulls.

Here is a list of the security hacks:

1. Moonbirds

On May 25, an NFT collector’s Moonbirds collection was exploited. The Moonbirds collection is an NFT application deployed on Ethereum.

The attackers were from multiple addresses including:

0xe8250Bb4eFa6D9d032f7d46393CEaE18168A6B0D,

0x8e73fe4d5839c60847066b67ea657a67f42a0adf,

0x6035B92fd5102b6113fE90247763e0ac22bfEF63,

0xBf41EFdD1b815556c2416DcF427f2e896142aa53 and

0x29C80c2690F91A47803445c5922e76597D1DD2B6

The attacked NFT collector was a “DigitalOrnithologist”. Basically, the collector suffered from a phishing attack such that the collector’s Moonbirds NFTs were exploited.

In this incident, this collector lost 29 Moonbirds NFTs which were worth 750 ETHs and valued at around $1.5 million.

It is highly possible this attack was related to a Twitter account “@DVincent_”. At the time of writing, both this Twitter account and its corresponding Opensea page have been deleted.

It was reported that before the attack, “@DVincent_” had conversations about NFT deals with other NFT collectors. A Bored Ape holder “@just1n_eth” claimed that they had some agreement on the deals and “@DVincent_” insisted on using a website http://p2peers.io/ for the transactions. This made “@just1n_eth” suspicious because the website was never heard of. At the time of writing, http://p2peers.io/ which was registered in Finland was suspended.

2. Mirror

On May 28, Mirror, a popular application deployed on the Terra blockchain was publicly reported to be attacked.

The attacker’s address was terra1200zm8crgjaj949ta8r7p6pay0qq638js4sdmh on Terra.

In this incident, crypto-assets valued at around $30 million were exploited.

Basically, the root cause of this incident was the implementation lacked validation for the funding source of crypto assets. This vulnerability was exploited by the attacker to stake assets valued at around only $10 to repeatedly withdraw the staked assets in the application.

This vulnerability had existed for more than 1 year and had been exploited multiple times. However, it hadn’t been detected by the Mirror team until recently. After the team detected this, it silently patched the bug on May 9.

Here is a list of the rug-pulls:

1. Pokemoney

On May 27, Pokemoney, an NFT application deployed on the BNB Chain turned out to be a rug-pull.

In this incident, 11800 BNBs valued at around $3.5 million were exploited. The price of Pokemoney plummeted by 99.98%.

Closing thoughts

In the past week, there were three incidents, the root cause of the Mirror incident was a smart contract vulnerability. The phishing attack could have been prevented if the victims had paid more attention and acted with care and caution. The rug-pull could have been avoided if the token holders could have done basic research and investigations before buying the token.

A reminder to project teams: always test thoroughly and do smart contract audits before deploying smart contracts on-chain.

A reminder to crypto users: be cautious about suspicious links, emails or websites, and projects that are launched by teams without an established reputation.

During the week from May 16 to May 22, 2022, security incidents that happened in the crypto space were all security hacks.

Here is a list of the security hacks:

1. FEG

On both May 15 and May 16, FEG, a DeFi application deployed on both the BNB Chain and Ethereum was attacked twice.

Concerning the first attack, here is the basic information:

The attacker’s address was 0x73b359d5da488eb2e97990619976f2f004e9ff7c on both the BNB Chain and Ethereum.

The hash value of the attack transaction on the BNB Chain was:

0x77cf448ceaf8f66e06d1537ef83218725670d3a509583ea0d161533fda56c063

The hash value of the attack transaction on Ethereum was:

0x1e769a59a5a9dabec0cb7f21a3e346f55ae1972bb18ae5eeacdaa0bc3424abd2

3280 BNBs and 144 ETHs valued at around $1.9 million were exploited in the first attack.

With regard to the second attack, here is the basic information:

The attacker’s address was 0xF99e5F80486426E7d3e3921269FFee9c2Da258e2 on both the BNB Chain and Ethereum.

The attacking contract was deployed at 0xf02b075f514c34df0c3d5cb7ebadf50d74a6fb17 on both the BNB Chain and Ethereum.

4343.147 BNBs valued at around $1.9 million were exploited in the second attack.

The root cause of the two attacks was its parameter didn’t get verified. Its parameter “path” was passed onto by the caller. Because the parameter didn’t get verified, the attacker passed onto a fake value such that the attacker transferred tokens without doing token swaps.

2. Scream

On May 16, Scream, a DeFi application deployed on Fantom was attacked.

In this incident, crypto-assets valued at around $35 million were exploited.

The root cause was that Scream didn’t update its prices for fUSD and DEI. When the real prices of fUSD and DEI fell to $0.69 and $0.52 respectively, the prices Scream had were still $1, therefore some attackers including the team behind DEI used fUSDs and DEIs as collateral to borrow a large number of USDCs, DAIs, etc.

3. Phishing Attack on An RPG NFT Game

On May 16, it was reported that users that downloaded and ran an executable from a fake website (Pixelmon[.]gw) looked very similar to Pixelmon. club (an RPG NFT game) suffered from phishing attacks. Once the users ran the executable, their passwords for the game would be leaked and exploited by the attacker.

4. Feminist Metaverse

On May 18, Feminist Metaverse, a DeFi application deployed on the BNB Chain was attacked.

In this incident, 1838 BNBs valued at around $500,000 were exploited.

The attacker’s address was 0xaaA1634D669dd8aa275BAD6FdF19c7E3B2f1eF50 on the BNB Chain.

The attacked contract was deployed at 0x843528746F073638C9e18253ee6078613C0df0f1 on the BNB Chain.

The root cause of this incident was that the implementation didn’t use the correct way to add liquidity.

The attacked contract (FMToken) incorrectly used a transfer function that worked for ERC-20 tokens to add liquidity but didn’t update the liquidity’s reserve value. This caused the tokens that were added to the liquidity could be transferred away by anyone. The attacker, therefore, called the skim function to transfer the tokens added by the FMToken contract away.

5. Discord MEE6

On May 18, Discord’s bot MEE6 was attacked. This caused some crypto projects’ Discord servers to be exploited by hackers to send phishing links. The projects that suffered from this attack included Alien Frens, Lazy Lions, Axie Infinity, and LIamascape.

6. QanPlatform

On May 19, QanPlatform’s cross-chain bridge deployed on both the BNB Chain and Ethereum was attacked.

The attacker’s address was 0x1c8465662cAA8005ed41430e433E399c699cbcE2 on both the BNB Chain and Ethereum.

The hash value of the attack transaction on the BNB Chain was :

0xcf0a3e8a7a76241075f9c942af2780532295e209d5f89d180adbdc2bab07392b

The hash value of the attack transaction on Ethereum was :

0xf5a99333c4eeecf418e3f85079f49964962a32785f3035947f1917889b6788c8

In this incident, 270 million QANXs were exploited, converted to 325 ETHs valued at around $600,000.

The root cause of this incident was that the bridge’s server was attacked such that the attacker could save 1 QANX on the BNB Chain and withdraw 4.8 million QANXs on Ethereum. The attacker repeated this procedure 20 times and exploited a total number of 270 million QANXs

7. LIamascape

On May 20, the Discord account of a team member of LIamascape was compromised such that LIamascape’s Discord server was exploited by the hacker to send phishing links.

30 ETHs valued at around 60,000 were exploited in this incident.

Closing thoughts

In the past week, there were seven incidents, four of which suffered from smart contract attacks and three of which suffered from phishing attacks.

Among those suffering from smart contract attacks, all the vulnerabilities were commonly seen and could have been prevented if they had undergone a professional audit and a thorough test. All the phishing attacks were carried out by commonly seen procedures and could have been prevented if the victims had paid more attention and acted with care and caution.

A reminder to project teams: always test thoroughly and do smart contract audits before deploying smart contracts on-chain.

A reminder to crypto users: be cautious about suspicious links, emails or websites, and projects that are launched by teams without an established reputation.

During the week from May 9 to May 15, 2022, security incidents that happened in the crypto space fell into two categories: security hacks and rug-pulls.

Here is a list of the security hacks:

1. Google’s Vulnerability

On May 10, an attacker used a vulnerability detected in Google’s Ad system to display a fake website that showed its name as “http://x2y2.io/” which was the name of a popular NFT trading platform. Users that clicked on the fake site would be exploited.

Crypto assets valued at around 100 ETHs ($200,000 equivalently) were exploited in this incident.

2. OWNLY

On May 11, OWNLY, an NFT application deployed on the BNB Chain was attacked.

The attacker’s address was 0xba31058357ea2f474a2ed0d1b3f9183904ebd38a on the BNB Chain.

The attacking contract was deployed at 0xa81ea095e0c3708e4236c71146748fa15b620386 on the BNB Chain.

The attacked contract, which was the NFTStaking contract, was deployed at 0x41BF7F818F2Dc41c67932E63E87c86D05AB957e8 on the BNB Chain.

The hash value of the attack transaction was:

0x2cbe47edb040c710b7f139cbea7a4bced4d6a0d6c5aa4380f445880437ea072f

115 BNBs valued at around $36000 were explored in this incident.

The vulnerability was a lack of validation for a user’s status. The unstake function in the NFTStaking contract didn’t validate a user’s status such that the attacker launched a double-spend attack to exploit all the OWNLY tokens in the staking contract. The attacker exchanged the OWNLYs for 115 BNBs

3. Venus Protocol

On May 12, Venus Protocol, a DeFi application deployed on the BNB Chain was exploited.

The root cause was that the Chainlink oracle didn’t update LUNA’s price after LUNA’s price plummeted dramatically. This resulted in a large number of assets being borrowed by using LUNA as collateral at an obsolete price. Crypto assets valued at around $11.2 million were exploited in this incident.

4. Blizz Finance

On May 12, Blizz Finance, a DeFi application deployed on AVAX was attacked.

The root cause was that the Chainlink oracle didn’t update LUNA’s price after LUNA’s price plummeted dramatically. This resulted in a large number of assets being borrowed by using LUNA as collateral at an obsolete price. Crypto assets valued at around $8 million were exploited in this incident.

5. Spiritswap

On May 14, Spiritswap’s homepage that was deployed on AWS was attacked. The attacker modified some of the DEX’s parameters such that users would send crypto assets to the attacker’s designated address.

Crypto assets valued at around $18000 were exploited in this incident.

Here is a list of the rug pulls:

1. Cashera

In May, Cashera, a dApp deployed on the BNB Chain turned out to be a rug pull.

The dApp’s Twitter account was @CasheraOfficial.

Its token was deployed at 0x6e8ff72962750f0fa57a906f7833d1c657614abe on the BNB Chain.

The address of the token contract’s deployer was:

0xBaA0C3523877C68d26B88930AEe3FC1C44801344

The token’s symbol was CSR.

The hash value of an additional mint transaction that was related to this rug-pull was:

0x8d6b11a8584a148151fb2a1ca6f5c722b8da85d7839c5f48efc00e641c7adcc4

The admin withdrew 23 million CSR tokens from a “PinkLock” contract and exchanged the CSRs for BNBs. These operations led to CSR’s price plummeting hugely by 71% and caused a loss of around $90000.

Closing thoughts

In the past week, LUNA’s de-pegging was the biggest incident in the crypto space. Its de-pegging caused the Chainlink’s oracle to stop updating its price. DeFi applications that used Chainlink’s service but didn’t take corresponding actions to handle this case would suffer losses. Two incidents in our summary were of this kind. All other incidents were still commonly known issues or risks.

A reminder to project teams: besides smart contracts, the security of the front-end should be taken care of as well.

A reminder to crypto users: be cautious about suspicious links, emails or websites, and projects that are launched by teams without an established reputation.

The first mostly recognized DAO project is “The DAO” [2] which was launched in 2016. However, unfortunately, The DAO eventually failed due to a fatal vulnerability that not only destroyed the project itself but also resulted in a painful hard fork for Ethereum [3].

It seems that day one security concerns have surrounded the development of DAOs.

During the past years, although DAOs have evolved and achieved huge progress and today’s DAOs are far more mature than what they were back in 2016 in nearly every aspect, security concerns don’t seem to fade and DAOs still face a lot of security challenges.

Fairyproof’s research team has done retrospective research on the development of security situations and conditions of DAOs over the past years since 2016 when The DAO was launched.

Based on the vulnerability types, we think of the development of security situations and conditions of DAOs as having gone through three phases.

In the first phase, the biggest security concern lay in smart contracts. In the second phase, the biggest security concern lies in execution mechanisms. In the third phase which is now, the biggest security concern lies in the design of governance rules or mechanisms that apply tokens in governance.

We analyze the security concern in each of these phases and would like to share our exploratory observations with the crypto industry.

Phase I: Security Concerns in Smart Contracts

In this phase, the biggest event was the crash of The DAO. Basically, the root cause of this crash was that a combination of vulnerabilities in The DAO’s smart contracts was exploited by a hacker, and this led to one-third of the project’s funds being drained.

This overwhelming loss halted The DAO project and forced the Ethereum team to hard-fork Ethereum eventually.

After this incident, people no longer talked about DAOs and people’s initial passion for DAOs faded soon.

This incident revealed a painful fact: when smart contract-based dApps were still in their early stages, due to a lack of experience and experimentation in security, smart contract-based DAOs were far from mature to handle even simple cases as expected.

So, in this phase, security concerns in smart contracts were the biggest challenge.

Phase II: Security Concerns in Execution Mechanisms

Although the failure of The DAO severely hit DAOs’ development, there were still teams working hard in this space and pushing the limits of DAOs greatly. The team behind MakerDAO[4] was one of them.

MakerDAO was officially launched on Ethereum in 2017. Since its deployment on Ethereum the team behind it began to explore governing its operations and driving its development by using a DAO. Through years of careful development and management, MakeDAO had been running pretty well, safely and securely, and hadn’t suffered from serious attacks on its smart contracts or encountered any serious security issues.

It was considered one of the most robust, secure, and well-established projects on Ethereum.

MakerDAO’s well-being and accumulated reputation gradually and strongly built-up people’s confidence in DAOs. Meanwhile, over the years, increasingly more teams began to notice the importance of smart contract audits, and more projects got audited before their deployment. This greatly reduced the possibility of being hacked for a project if it had gone through a professional audit.

However, a disruptive incident that happened in March 2020 put MakerDAO in turmoil. And it raised security concerns that almost disappeared in DAOs again.

On March 12, 2020, the overall crypto space was brutally hit by a market crash. Ether which was one of the most important collaterals used in MakerDAO suffered from a huge loss in price. Its price plummeted by more than 50% on that single day. This dramatic change in Ether’s price triggered a massive liquidation of Ethers in MakerDAO.

This liquidation soon caused a serious on-chain traffic jam. However, since MakerDAO had never experienced this massive liquidation, the design of its liquidation mechanism didn’t have adequate resilience to handle this. This led to the liquidation mechanism failing to work as expected.

MakerDAO suffered huge financial losses in this incident.

In this incident, as far as MakerDAO’s smart contracts were concerned, there were no vulnerabilities in the implementation. It was the vulnerabilities in its mechanism that caused the loss.

After this incident, people began to be aware of the design of DAOs’ mechanisms. However, since most of the dApps in the crypto space didn’t apply DAOs that much in their governance like what MakerDAO did, the security concerns in DAOs didn’t last long and DAOs’ security still didn’t gain enough traction broadly.

Phase III: Security Concerns in Governance

In June 2020, one famous DeFi application Compound issued its governance token COMP [5]. In Compound’s design, the COMP token was not only used as a governance token but also used to reward people who provided liquidity to the protocol. This innovative design promptly took DeFi by storm. Nearly all DeFi applications or protocols that were launched before or after Compound followed this design and issued their own governance tokens.

Although Compound was not the first project that issued a governance token it was the project that triggered the issuance of governance tokens among nearly all projects in DeFi.

Since then, governance tokens have been widely used in DeFi applications to conduct their governance through voting. Anyone that holds a project’s governance token can participate in voting for a proposal or submitting a proposal.

Among the projects that issued governance tokens, some project teams listed vital decisions for token holds to vote and some teams designed a very low threshold for token holders to submit whatever proposals. This potentially gave opportunities to malicious actors to hack the projects and inevitably introduced risks. For instance, a malicious actor could bribe other token holders of a project into submitting a proposal or voting for a proposal to exploit the project.

Theoretically, any project that issues its governance token may possibly suffer from such an attack if the majority of the tokens are not held by goodwill actors.

In addition, with an innovative mechanism called “flash-loan” [6] being created by AAVE [7], a malicious actor could even launch such an attack without needing to hold governance tokens. He can leverage a flash-loan to borrow a large number of governance tokens to enforce a proposal to be passed or submitted for execution by paying only a few fees.

Since 2020, various DeFi applications have suffered from these attacks [8][9][10] and the loss of such an attack has been trending increasingly high these years.

Nowadays it has become a major attack on a dApp that uses a DAO to govern its decision-making process. And these attacks are commonly referred to as “governance attacks”.

Like the security issues we discussed in phase II, most of the projects that suffered from a governance attack are not due to vulnerabilities in their smart contracts but due to vulnerabilities in the design of their governance rules or mechanisms.

Nevertheless, governance attacks still haven’t gained adequate awareness compared to attacks on smart contracts.

We think governance attacks will be more popular as more dApps tend to use DAOs. Therefore

Fairyproof has been watching the development of governance attacks. We are not only researching this topic but also have developed utilities to tackle the challenges in this area.

Governance attacks are a new kind of attack that specifically pertains to blockchain applications. They are more complicated than attacks on smart contracts. They are a big challenge to both dApp teams and security companies. We will keep working in this area and publish more articles sharing our research results going forward.

References:

[1] Decentralized autonomous organizations (DAOs), https://ethereum.org/en/dao/

[2] The DAO (organization), https://en.wikipedia.org/wiki/The_DAO_(organization)

[3] Ethereum Classic, https://en.wikipedia.org/wiki/Ethereum_Classic

[4] MakerDAO, https://makerdao.com/

[5] Compound Governance,

https://medium.com/compound-finance/compound-governance-5531f524cf68, Feb 27, 2020

[6] Flash Loans, https://docs.aave.com/faq/flash-loans

[7] AAVE, https://app.aave.com/

[8] Build Finance DAO Suffers Governance Takeover Attack,

https://cryptobriefing.com/build-finance-dao-suffers-governance-takeover-attack/, Feb 15, 2022

[9] Beanstalk founders dismissed concerns about governance attacks before losing $182 million, https://www.theverge.com/2022/4/22/23037325/beanstalk-dismissed-governance-attacks-lost-182-million, April 22, 2022

[10] Fairyproof’s Analysis of the Attack on Fortress Protocol,

https://medium.com/coinmonks/fairyproofs-analysis-of-the-attack-on-fortress-protocol-6fb2df687845, May 9, 2022

The attacker’s address was 0xA6AF2872176320015f8ddB2ba013B38Cb35d22Ad on the BNB Chain.

The attacking contract was deployed at** 0xcd337b920678cf35143322ab31ab8977c3463a45** on the BNB Chain.

The attacked contract was deployed at 0xc11B687cd6061A6516E23769E4657b6EfA25d78E on the BNB Chain.

The hash value of the attack transaction was:

0x13d19809b19ac512da6d110764caee75e2157ea62cb70937c8d9471afcb061bf

The vulnerability that was exploited in this incident lay in the project’s governance mechanism.

Here is how the attack was carried out:

The attacker deployed a contract to submit a proposal (proposal ID: 11) to modify the parameters of the CollateralFactor contract 5 days prior to the attack. The hash value of the contract deployment transaction was:

0x12bea43496f35e7d92fb91bf2807b1c95fcc6fedb062d66678c0b5cfe07cc002

The attacker voted for the project 2 days before the attack. According to the governance rules, the proposal would be executed 2 days after it was passed.

At 8 AM on May 8 UTC, the attacker launched the attack by executing the proposal to successfully modify the CollateralFactor’s parameters.

After the parameters were modified, the attacker could mint many fFTS tokens by depositing only a small number of FTS tokens as collateral.

In this incident, the attacker minted 4999.9 fFTS tokens and used them as collateral to borrow crypto assets including BNBs, BUSDs, BTCBs, and ETHs. The attacker exchanged these borrowed assets for DAIs and ETHs, transferred the DAIs and ETHs from the BNB Chain to Ethereum via Celer Network’s cross-chain bridge, and cashed them out via Tornado Cash.

This is another typical governance attack that happened after the attack on Rari Capital.

A reminder from Fairyproof to all projects that are governed by DAOs: be careful with the design of governance rules and mechanisms. Be aware of governance attacks.

During the week from April 25 to May 1, 2022, security incidents that happened in the crypto space were all security hacks.

Here is a list of the security hacks:

1. BAYC

On April 26, the most popular NFT project BAYC’s Instagram was attacked.

Crypto assets valued at around $2.4 million were exploited.

This was a typical phishing attack. The hacker sent phishing links on BAYC’s Instagram, and some users were misled to sign a “safeTransferFrom” transaction which approved the hacker to spend the NFTs in these users’ wallets.

A total of 765 ETHs and 91 NFTs including BAYC, MAYC, BACK, and CloneX were exploited. Among these NFTs, 23 including 4 BAYCs, 6 MAYCs, and 2 CloneXs were sold out. The sold NFTs were valued at around $2.4 million.

2. Deus

On April 28, Deus, a DeFi application deployed on Fantom was attacked.

The attaker’s address was 0x701428525cbac59dae7af833f19d9c3aaa2a37cb on Fantom.

The attacking contract was deployed at 0x1f56CCfE85Dc55558603230D013E9F9BfE8E086C on Fantom.

The hash value of the attack transaction was:

0x39825ff84b44d9c9983b4cff464d4746d1ae5432977b9a65a92ab47edac9c9b5

The exploited assets in this incident were valued at around $13.4 million.

The vulnerability was the application’s implementation didn’t use a secure price oracle. The hacker leveraged a flash loan to manipulate the price of DEI, exploited a large number of DEIs, migrated these DEIs from Fantom to Ethereum, and cashed them out via Tornado Cash.

3. Saddle Finance

On April 30, Saddle Finance, a DeFi application deployed on Ethereum was attacked.

The attacker’s address was 0x63341ba917de90498f3903b199df5699b4a55ac0 on Ethereum.

The attacking contract was deployed at 0x7336f819775b1d31ea472681d70ce7a903482191 on Ethereum.

The attacker launched two attack transactions and the hash values of these two transactions were:

0x2b023d65485c4bb68d781960c2196588d03b871dc9eb1c054f596b7ca6f7da56 and

0xe7e0474793aad11875c131ebd7582c8b73499dd3c5a473b59e6762d4e373d7b8 respectively.

In this incident, a total of 3540 ETHs valued at around $10 million were exploited.

The root cause of this incident was an incorrect use of a smart contract. The implementation should use a newly deployed MetaSwapUtils’ lib however it used an obsolete MetaSwapUtils’ lib. This vulnerability was exploited, and the attack was enlarged by using a flash loan.

4. Rari Capital

On May 1, Rari Capital, a DeFi application deployed on Ethereum was attacked.

The attacker’s address was 0x6162759edad730152f0df8115c698a42e666157f on Ethereum.

The attacking contract was deployed at 0x32075bad9050d4767018084f0cb87b3182d36c45 on Ethereum.

The contract that had the vulnerability that was exploited was deployed at:

0xd77E28A1b9a9cFe1fc2EEE70E391C05d25853cbF on Ethereum.

Crypto assets valued at $79.21 million were exploited in this incident.

For more details about this incident please refer to:

https://medium.com/coinmonks/fairyproofs-analysis-of-the-attack-on-rari-capital-d8fb4538fbdf

5. Solana

On May 1, the Solana blockchain suffered from a DOS attack.

The incident was caused by a crawler application deployed by Metaplex, an NFT application. After this crawler application ran, Solana’s TPS hiked to 4 million which was far beyond what Solana could afford.

This issue caused Solana to shut down for nearly 7 hours. After Solana’s mainnet was restarted it resumed its work.

Closing thoughts

Among these 5 incidents, the incidents with Deus, Saddle Finance, and Rari Capital were all common issues that could have been prevented if they had undergone a thorough audit and system test.

The incident with Solana was not the first time in Solana’s development. And incidents of this kind may happen again if it is not carefully maintained and managed since Solana was designed to achieve high performance at the cost of relatively less decentralization.

Phishing attacks happen quite often these days as NFT projects keep gaining traction among people. It is easy to be exploited if users pay no attention to fake sites.

A reminder to smart contract developers: smart contracts should be thoroughly tested before being deployed. A third-party performed professional audit is a must-have step before being deployed.

A reminder to crypto users: be cautious about suspicious links, emails, or websites.

During the week from April 18 to April 24, 2022, security incidents that happened in the crypto space can be categorized into security hacks and rug pulls.

Here is a list of the security hacks:

1. ZEED

On April 21, ZEED, a DeFi application deployed on the BNB Chain was attacked.

The attacker’s address was 0xEc14207D56E10F72446576779d9b843e476e0fB0 on the BNB Chain.

The attacking contract was deployed at 0x05e55d051AC0a5fb744E71704a8fA4Ee3B103374 on the BNB Chain.

The attacked contract was the “YEED” contract deployed at:

0xe7748FCe1D1e2f2Fd2dDdB5074bD074745dDa8Ea on the BNB Chain.

The hash value of the attack transaction was:

0x0507476234193a9a5c7ae2c47e4c4b833a7c3923cefc6fd7667b72f3ca3fa83a

Crypto assets valued at around $1 million were exploited in this incident.

The vulnerability was in the “_takeReward” function in the YEED contract as follows. It was a logic error that caused the reward to be incorrectly calculated.

The function implemented an algorithm for how the “rewardFee” should be distributed. The expected behavior was that swapPair, swapPairZeed, and swapPairHo each should be given 1/2 * rewardFee, 1/4 * rewardFee, and 1/4 * rewardFee respectively. However, the implementation gave each of them the rewardFee. The pair contract had a “skim” function which could be called by any address to transfer the surplus tokens in the contract. The attacker called this function to exploit the distributed token rewards.

The attacker leveraged a flash loan to borrow 662 YEEDs and used it to launch the attack and eventually exploited 87 million YEEDs, exchanged the YEEDs for BSC-USDs, and sent them to the attacking contract. The attacker eventually destroyed the attacking contract and this means that the hacker didn’t take away the exploited tokens.

2. AKuDreams

On April 23, AKuDreams, an NFT application deployed on Ethereum was attacked.

The attacked contract was the “AkuAuction” contract deployed at:

0xf42c318dbfbaab0eee040279c6a2588fa01a961d on Ethereum.

A total of 11000 ETHs valued at around $34 million were locked permanently in its contract.

There were two vulnerabilities in this application:

The first one was in the processRefunds() function defined in the AkuAuction contract.

The “bidData.bidder” was the address where the bidder’s fee was returned. The “bidData.bidder” address was a contract address. If its fallback function reverted, the execution of the processRefunds() function might suffer from a DOS attack. And in this case, it DID suffer from a DOS attack.

The second one was in the claimProjectFunds() function defined in the AkuAuction contract.

The “require(refundProgress >= totalBids” would never hold true. This resulted in the ETHs being locked in the contract permanently. The “totalBids” should be “bidIndex”

Here is a list of the rug pulls:

1.MaxAPY

On April 20, MaxAPY Finance, a DeFi application deployed on the BNB Chain was found to be a rug-pull.

A total of 1042 BNBs valued at around $420,000 were taken away.

The project’s Twitter account has been deleted; the Telegram group has been closed.

Closing thoughts

Among these 3 incidents, 2 incidents including YEED and AKuDreams were attacked due to issues that could have been prevented if they had undergone a thorough audit. Specifically, in the AKudreams project, the second vulnerability was very likely a typo that should be easily uncovered if the contract had been carefully tested before being deployed.

A reminder to smart contract developers: smart contracts should be thoroughly tested before being deployed. A third-party performed professional audit is a must-have step before being deployed.

A reminder to crypto users: be cautious about projects which are created by teams’ lack of established reputation.

Although it was just proposed in December 2021, it soon garnered significant attention and great support from the Ethereum community and has been reported to be adopted by a few DAOs [2] including Tribe DAO [3] and Rari Capital DAO [4].

This EIP is intended to solve a pain point in the existing implementations of tokenized vaults, that is “tokenized vaults have a lack of standardization leading to diverse implementation details” [1]. This pain point makes integration of tokenized vaults “difficult at the aggregator or plugin layer for protocols which need to conform to many standards and forces each protocol to implement their own adapters which are error-prone and waste development resources” [1].

This EIP is based on ERC-20[5] which is a widely adopted standard in Ethereum’s DeFi applications and has considerable security issues or risks that need smart contract developers’ awareness.

As a blockchain security company, Fairyproof’s research team is quite interested in whether the issues or risks of ERC-20 implementation might be introduced in ERC-4626 as well. We studied this EIP, explored possible security checkpoints, and would like to share some ideas on these checkpoints.

This EIP requires that a tokenized vault MUST implement ERC-20 to represent shares and add new interfaces to convert shares to tokens or tokens to shares in both viewable functions and transfer functions. And these newly added functions introduce security considerations that need our awareness.

Here is a list of security considerations when implementing a tokenized vault based on this EIP:

- Implementation of Malicious Functions

Consider a vault’s implementation which conforms to the interfaces defined by this EIP but doesn’t conform to the specification. This happens quite often in rug-pulls where a proxy mechanism is used, and the proxy interface seems to conform to a token standard but actually, the real implementation is a malicious contract.

So, auditors or users need to carefully check its real implementation before taking further actions.

- Support for EOA Accounts

The EIP states that “If implementors intend to support EOA account access directly, they should consider adding an additional function call for deposit/mint/withdraw/redeem with the means to accommodate slippage loss or unexpected deposit/withdrawal limits” [1].

Besides the slippage loss and the unexpected deposit/withdrawal limits, there is another case that is commonly seen as well: a token burns on its transfers. This mechanism is used by some DeFi applications to decrease their tokens’ circulation supplies and inflate the tokens’ prices.

We would suggest ERC-4626 vaults disallow tokens of this kind to be deposited in the vaults.

- Using Interfaces as Oracles

The EIP states that “The preview methods return values that are as close as possible to exact as possible. For that reason, they are manipulable by altering the on-chain conditions and are not always safe to be used as price oracles.” [1], and “it would be correct to implement the convert methods as using a time-weighted average price in converting between assets and shares.” [1]

The most popular use case of oracles in the crypto space is to use them to obtain a token’s price, but any information that a smart contract needs may rely on an oracle. Hence, the preview methods which return information may be used as oracles as well. Although this may not seem to have significant use cases, for now, this listed potential issue needs our awareness. And a popular method to mitigate the risk of on-chain information being manipulated is to use a time-weighted average algorithm introduced by Uniswap[6].

- Rounding Issues

Vault implementers need to handle rounding directions carefully for the interfaces that calculate the vault shares or the number of tokens, and that convert shares to assets or assets to shares.

The specification suggests that when calculating the shares issued to a user for the amount of the underlying tokens, he/she supplies or the amount of the underlying tokens sent to him/her for a certain number of shares returned by him/her, it should round down.

When calculating the number of shares a user has to supply to receive a specific amount of the underlying tokens or the number of underlying tokens a user has to provide to receive a specific number of shares, it should round up.

When calculating the amour of shares or the underlying tokens in the converTo functions, the specification requires vault implementers to round down to ensure consistency across all ERC-4626 vault implementations.

These suggestions and requirements ensure there are always a sufficient number of underlying tokens reserved for transfers. This is what auditors need to be aware of when auditing vault implementations based on this EIP.

- Token Compatibility Issues

This EIP specifically mentions the ERC-20 token standard. It is the most widely adopted token standard for implementing fungible tokens. However, in our past audit experience, we audited some fungible tokens which were implemented based on alternative Ethereum tokens standards such as EIP-777[7] as well.

These alternative token standards are compatible with ERC-20 tokens but have some differences.

Let us take the EIP-777 token standard as an example. The token standard allows implementers to use a registry to look up the interfaces. If the registry has bugs, anything depending on it will have an adverse impact. A commonly seen issue that is introduced by this feature is a re-entrancy risk [8].

So, there might exist two kinds of scenarios that we need to pay attention to.

The first scenario is a vault is implemented based on an ERC-20 compatible but alternative standard. The second is an ERC-4626 value that interacts with a token that is ERC-20 compatible but is implemented based on an alternative token standard.

In both scenarios, the alternative token standard may introduce issues or risks. And the implementations based on the alternative standard should be carefully reviewed and audited.

Closing Thoughts:

In this paper, we list some possible security considerations when auditing an ERC-4626-based vault. Some of these considerations are already mentioned in the EIP and others are listed based on our audit experience.

We wish our tentative suggestions would give implementers, users, and auditors some rough ideas on how to handle ERC-4626 vaults securely and safely.

References:

[1] EIP-4626: Tokenized Vault Standard, https://eips.ethereum.org/EIPS/eip-4626 Dec 22, 2021

[2] Decentralized Autonomous Organizations, https://ethereum.org/en/dao/

[3] Tribe, https://docs.fei.money/governance/tribe

[4] Rari Capital, http://rari.capital/

[5] ERC-20 Token Standard, https://ethereum.org/en/developers/docs/standards/tokens/erc-20/

[6] Uniswap, https://uniswap.org/

[7] EIP-777: Token Standard, https://eips.ethereum.org/EIPS/eip-777

[8] Samreen N F, Alalfi M H. Reentrancy vulnerability identification in Ethereum smart contracts[C]//2020 IEEE International Workshop on Blockchain Oriented Software Engineering (IWBOSE). IEEE, 2020: 22–29.

During the week from April 11 to April 17, 2022, security incidents that happened in the crypto space were all security hacks.

Here is a list of the security hacks:

1. Creat Future

On April 11, Creat Future, an application deployed on the BNB Chain was attacked.

The attacker’s address was 0xde33456644c08c4CeFa05237D429CCDa158FE0b5 on the BNB Chain.

The hash value of the attack transaction was:

0x85b5a2f8210e499ff6a84d4e7d9969558418191c6aa9df2b2145edec13036fce

The attacked contract was deployed at 0x8B7218CF6Ac641382D7C723dE8aA173e98a80196 on the BNB Chain.

In this incident, the hacker exploited crypto assets valued at $1.9 million.

The vulnerability was its token contract didn’t have a proper validation for an input address.

The Creat Future’s token (CF) contract had a “_transfer” function whose visibility was public, and the function had a “from” parameter which was an address but wasn’t validated. Therefore, anyone could call this function to transfer the CF tokens from the “from” specified address.

The hacker exploited this vulnerability to launch 6 transactions to transfer a total of 4.2 million CF tokens and exchanged them into at least 4200 BNBs and cashed out via Tornado Cash.

2. Marvin Inu

Marvin Inu, a cross-chain application was attacked. Fortunately, the team behind the project promptly shut down its cross-chain bridge and fixed the issue. The team announced that it would take further actions to compensate for the loss.

3. Elephant Money

On April 12, Elephant Money, a stable coin deployed on the BNB Chain was attacked.

The attacker’s address was 0xe552133cc829a7f7e98e349763fac7ab0f3828b0 on the BNB Chain.

The attacking contract was deployed at 0xbceda90b2880fea5d511d54716229145508996da on the BNB Chain.

The attacked contract was deployed at 0xD520a3B47E42a1063617A9b6273B206a07bDf834 on the BNB Chain.

The hash value of the attack transaction was:

0xec317deb2f3efdc1dbf7ed5d3902cdf2c33ae512151646383a8cf8cbcd3d4577

The vulnerability lies in an unverified contract of the application. This contract used an instant price obtained from Uniswap and the price was manipulated by the hacker.

The hacker leveraged a flash loan to exploit this vulnerability and exploited 27416 BNBs valued at around $11 million.

4. Rikkei Finance

On April 15, Rikkei Finance, a DeFi application deployed on the BNB Chain was attacked.

The attacker’s address was 0x803e0930357ba577dc414b552402f71656c093ab on the BNB Chain.

There were two attacking contracts deployed at the following two addresses respectively:

0x9aE92CB9a3cA241D76641D73B57c78F1bCF0B209 and

0xe6df12a9f33605f2271d2a2ddc92e509e54e6b5f respectively.

The attacked contracts were deployed at 0xD55f01B4B51B7F48912cD8Ca3CDD8070A1a9DBa5 and 0x157822ac5fa0efe98daa4b0a55450f4a182c10ca respectively.

The hash values of the two attacking transactions were:

0x4e06760884fd7bfdc076e25258ccef9b043401bc95f5aa1b8f4ff2780fa45d44 and

0x93a9b022df260f1953420cd3e18789e7d1e095459e36fe2eb534918ed1687492.

In this incident, the hacker exploited 2671 BNBs valued at around $1.1 million.

The vulnerability was a lack of validation for access control in the function “setOracleData”. The hacker exploited this vulnerability to change the oracle contract to a malicious contract, exploited all the USDCs, BTCBs, DAIs, USDTs, BUSDs, and BNBs, and exchanged these tokens to BNBs and cashed out via Tornado Cash. After the hacker successfully finished the attack, it destroyed the attacking contracts.

5. FaceDAO

On April 16, FaceDAO, an application deployed on Ethereum was attacked.

The attacker’s address was 0xAAAA3467Ca1F70494Ca8B821Eef3E34DE2c139E5 on Ethereum.

The attacked address was deployed at 0xd432e8611377E307D3e5710132515be1E6AA6156 on Ethereum.

In this attack, the hacker exploited 121 ETHs valued at around $360,000.

For more details, please refer to:

https://medium.com/coinmonks/fairyproofs-analysis-of-the-attack-on-facedao-e34e24e711c0

6. Beanstalk

On April 17, Beanstalk, a stable coin deployed on Ethereum was attacked.

The attacker’s address was 0x1c5dCdd006EA78a7E4783f9e6021C32935a10fb4 on Ethereum

The attacking contract was deployed at 0x728ad672409da288ca5b9aa85d1a55b803ba97d7 on Ethereum

The hash value of the attack transaction was:

0xcd314668aaa9bbfebaf1a0bd2b6553d01dd58899c508d4729fa7311dc5d33ad7

The attacked contract was deployed at 0xc1e088fc1323b20bcbee9bd1b9fc9546db5624c5 on Ethereum.

In this incident crypto assets valued at around $182 million were exploited.

The vulnerability lies in its governance mechanism. The hacker proposed a malicious BIP-18 proposal, leveraged flash loans to borrow 350 million DAIs, 500 million USDCs, 150 million USDTs, 32 million Beans, and 11.6 LUSDs, converted these tokens to 795,425,740 BEAN3Crv-f and 58,924,887 BEANLUSD-f, used them to vote and pass the BIP-18, and called the “emergencyCommit()” function to execute the BIP-18 and exploited the assets in the application.

Closing thoughts

Among these 6 incidents, 2 incidents including Creat Future and Rikkei Finance were attacked due to a lack of validations for either access control or an address parameter, Elephant Money was attacked due to using an insecure oracle, FaceDAO was attacked due to a phishing attack and Beanstalk suffered from a governance attack.

Lack of validation and insecure oracles could have been prevented if these projects had gone through a professional audit. The governance attack was not a smart contract issue but still could have been prevented if the governance mechanism had gone through a mechanism audit. All these issues are common and solvable.

A reminder to smart contract developers: there are already mature solutions to prevent risks such as lack of validation, insecure oracles, and governance attacks. It is better to do a professional audit before deploying contracts.

A reminder to crypto users-always be highly cautious about any suspicious links or emails.

The attacker’s address was 0xAAAA3467Ca1F70494Ca8B821Eef3E34DE2c139E5

The attacked contract was deployed at 0xd432e8611377E307D3e5710132515be1E6AA6156

The hash values of the two attack transactions were:

0xad8123a858804254184ffda793b7416d2bf8958ade3e990a0361f45d6cfee68e and

0xb313ab9e845e461c7a795336d54b60cd4ede72f7a084bb26c26a4c4275f79ee0.

In this incident, 121 ETHs valued at around $360,000 were exploited.

Here is how the attack was carried out:

Before the attacker launched the attack, it tricked the FaceDAO deployer into doing three approval transactions to allow the attacker to transfer the FaceDAO tokens from the FaceDAO deployer.

Then the attacker exploited 60 billion and 5940.1 billion FaceDAO tokens in two transactions respectively. It exchanged the exploited FaceDAO tokens into 121 ETHs via Uniswap and cashed out the ETHs via Tornado.Cash.

It was claimed that it was the private key being leaked that led to this attack. However, based on our analysis this was a typical phishing attack because of two reasons.

The first reason is that if it were a private key being leaked the attack would just directly transfer the tokens rather than tricking the deployer into approving token transfers.

The second reason is that after the attack happened the attacker launched another attack on another application and exploited some STRONG tokens.

During the week from April 4 to April 10, 2022, security incidents that happened in the crypto industry were all security hacks.

Here is a list of the security hacks:

1. Juno

On April 5, Juno, a COSMOS-based blockchain suffered from a DOS attack.

The attacker first deployed a malicious “hello world” smart contract on the blockchain. And then sent a total of 400 transactions in three days to this contract and uncovered a vulnerability in the blockchain. The attacker then launched a DOS attack on the blockchain.

After the attack was detected, the team behind the blockchain installed a fix and put it back to work within three days.

2. Starstream Finance

On April 8, Starstream Finance, a DeFi application deployed on an Ethereum Layer 2 solution Metis was attacked.

The attacker’s address was 0xFFD90C77eaBa8c9F24580a2E0088C0C940ac9C48 on Metis.

The attacking contract was deployed at 0x75381c1f12733fff9976525db747ef525646677d on Metis

The attacked contract was deployed at 0x1075daD8CFd8bCbCfc7bEB234e23D507990C90e9 which was the StarstreamTreasury contract deployed on Metis.

The hash value of the attack transaction was:

0xb1795ca2e77954007af14d89814c83b2d4f05d1834948f304fd9d731db875435

The vulnerability that was exploited in this incident was in the DistributorTreasury contract deployed at 0x6f99b960450662d67bA7DCf78ac959dBF9050725 on Metis. The vulnerability was that the call to the “execute” function lacked necessary access control such that anyone could call this function.

Before the attack happened, the owner of the StarstreamTreasury contract was transferred to the DistributorTreasury contract. The attacker then called the execute function in the DistributorTreasury contract to call the withdrawTokens function in the StarstreamTreasury contract and withdrew 532,571,155.859 STARS tokens. The attacker sent these tokens to Agora DeFi as collateral to borrow a huge quantity of assets and used partial of the assets to pump the price of the STARS token and again borrow more assets.

In this incident, crypto-assets valued at around $8.2 million were exploited.

Closing thoughts

Both the vulnerability found in Starstream Finance and the one found in Juno were common issues.

A reminder to blockchain developers: there are mature solutions to prevent common risks such as DOS attacks. It is better for the developers to implement these solutions and carry out thorough tests before deploying their products online.

A reminder to smart contract developers: lack of access control is a common issue that could have been uncovered and fixed without being exploited if they had undergone a professional audit.

A reminder to crypto users: make sure you always interact with applications or platforms that haven’t endured long-time challenges with great care and caution.

During the week from March 28 to April 3, 2022, security incidents that happened in the crypto industry can be categorized into three security hacks, publicly announced vulnerabilities and rug-pulls.

Here is a list of the security hacks:

1. Cryptovoxels

On March 28, Cryptovoxels, a virtual social platform deployed on Ethereum was attacked.

The attacker’s address was 0x794ca38bc1e15e528a7991ce25707a25ad71b675 on Ethereum.

The platform’s Discord server suffered from a phishing attack. The attacker pretended to be a team member of Cryptovoxels and sent out a phishing link. Some users clicked on the link and approved their tokens to be spent.

In this incident, crypto-assets valued at around $171 thousand were exploited.

For more details about this attack please refer to Fairyproof’s report at:

https://twitter.com/FairyproofT/status/1508476086182502409

2. Ronin Network

On March 29, Ronin Network, an Ethereum sidechain was attacked.

The attacker’s address was 0x098b716b8aaf21512996dc57eb0615e2383e2f96 on Ethereum.

The attacked contract was Axie’s Ronin bridge deployed on Ethereum at:

0x1a2a1c938ce3ec39b6d47113c7955baa9dd454f2

The vulnerability that was exploited in this attack was in the system that managed its private key. The system more specifically, the gas-free RPC node had a backdoor such that the attacker eventually got the signature for the Axie DAO validator to abuse the system.

Crypto assets valued at around $610 million were exploited.

For more details, please refer to Fairyproof’s report at:

https://medium.com/coinmonks/fairyproofs-analysis-of-the-attack-on-the-ronin-bridge-of-axie-infinity-13933c22ecbc

3. BasketDAO

On March 30, BasketDAO, an application deployed on Ethereum was attacked.

The attacked contract was deployed at 0x4622aFF8E521A444C9301dA0efD05f6b482221b8 on Ethereum.

The vulnerability was a lack of validation for the input parameters of a “call” in the “_primitiveToBMI” function. This was exploited such that the attacker passed a malicious address to take away all the approved crypto assets by the BMIZapper contract.

The total exploited assets were valued at around $1.1 million.

4. Ola Finance

On March 31, Ola Finance, a DeFi application deployed on both Fuse and Ethereum was attacked.

The attacker’s address was 0x371D7C9e4464576D45f11b27Cf88578983D63d75 on Ethereum.

The vulnerability was an incompatibility issue. The application’s lending protocol was not compatible with ERC-677 tokens therefore it suffered from a re-entrancy attack.

The total exploited crypto assets were valued at around $4.67 million.

5. Discord Servers

On around April 1, the Discord servers of various NFT projects including BAYC, Doodles, Nyoki, Shamanz, Zooverse, Dreadfuls, Freaky Labs, and Kaijukingz suffered from phishing attacks. Quite a few users lost their NFTs. The biggest loss was with a famous pop star who lost his BAYC 3738 which was worth around $430,000.

Here is a list of the publicly announced vulnerabilities:

1. Jet Protocol

On March 30, the team behind Jet Protocol, a DeFi application, announced that a vulnerability was uncovered.

The vulnerability was a lack of validation for input parameters. If this vulnerability were exploited, the crypto assets of the users that interacted with this application would be withdrawn at will.

The team had already fixed this issue before it was exploited therefore no loss was caused.

Here is a list of the rug pulls:

1. Meerkat Finance

On March 30, Meerkat Finance, a DeFi application deployed on BSC was attacked.

The attacker’s address was: 0x9542966F1114eaA5859201aA8d34358BFedBFa79 on BSC.

The vulnerability was the contract’s upgradeability. And the team had the access control to upgrade the contract.

This vulnerability was exploited such that malicious contracts were deployed and then the attacker exploited all the crypto assets in the application’s vaults. The loss was around $30 million.

The whole process was like this:

Firstly, Meerkat Finance made an announcement saying that the application was attacked. Then two transactions were launched to take away crypto assets valued at around $31 million including BUSDs valued at $13.96 million, and BNBs valued at $17.4 million.

Soon after that, the application’s website couldn’t be opened, and the team members couldn’t be contacted either. Later on, the team’s Twitter was deleted as well.

Therefore, the incident was highly suspected to be a rug pull.

Closing thoughts

There were five security hacks in the past week. The vulnerabilities that were uncovered in BasketDAO and Ola Finance were commonly known issues that could have been uncovered and fixed without being exploited if they had undergone a professional audit. The one with Ronin Network was a leak of private keys. This incident should have been avoided if the team could have employed more stringent management of private keys. The other two hacks targeting Discord servers could have been prevented if the users participated in these activities with more caution and care.

The publicly announced vulnerability was a commonly known issue as well and it could have been uncovered if the project was audited before it was deployed.

The rug-pull project had a serious risk in its smart contract implementation. In general, if projects with this risk are audited by professional audit companies, this risk should be indicated. Therefore, this should remind users of the importance of checking a project’s audit report.

A reminder to smart contract developers: input parameters especially addresses should be handled with great care.

A reminder to project teams: always audit projects before deploying them.

A reminder to crypto users: always be cautious and alert to suspicious links, websites, and emails, and always be careful with interacting with applications whose teams don’t have established reputations or which haven’t gone through serious audits.

CryptoKitties[1] which may be the earliest blockchain game was deployed and released in 2017 and it opened the infinite possibilities for blockchain games. However, blockchain games didn’t see their rapid development or gain significant traction until Axie Infinity [2] became popular in Southeast Asia with strong promotion from YGG [3] since 2020. A significant reason why Axie Infinity could grow its user base rapidly was that it introduced DeFi into its game. The success story of Axie Infinity encouraged numerous developers and teams to enter the blockchain game area and follow its example or provide services pertaining to blockchain games that have in-built DeFi mechanisms. This combination of games and DeFi was later on called GameFi.

Although the blockchain GameFi ecosystem has achieved tremendous progress, neither has research on the ecosystem’s security in academies gained sufficient awareness nor have comprehensive practices in tackling the security issues or risks been carefully carried out or studied.

Based on the accumulated experiences and research results from Fairyproof’s technical team in years’ practice, Fairyproof would like to share some understanding and thoughts on the overall blockchain GameFi ecosystem and the audit of the applications in this ecosystem.

In this paper, we firstly present our understanding of the overall blockchain GameFi ecosystem, analyze the applications, and the roles and functions these applications play; then present the applications’ underlying technologies and list typical security issues or risks associated with the underlying technologies; and finally present our ideas and thoughts about the audit of each of these applications.

1. Overview of the Blockchain GameFi Ecosystem

Currently, although the blockchain GameFi ecosystem may not be as mature as some experts would expect, it is already an ecosystem with various players, roles, applications, services, etc. that are rapidly growing and developing.

Typical applications/roles in the current blockchain GameFi ecosystem mainly consist of games, game guilds [4], game developers, services, or applications pertaining to games.

Games in this ecosystem are applications that mainly implement play rules and logic. Users/players directly interact with games. From an application’s point of view, games are the core component of the GameFi ecosystem. CryptoKitties and Axie Infinity are typical blockchain games.

Game guilds are a special player in this ecosystem. Popular blockchain games in general have an in-built play-to-earn mechanism that rewards tokens to its players. To earn rewards, a player may need to use in-game utilities which may not be affordable to every player. In this case, a game guild comes to play. It is an organization that acts as a facilitating intermediary to help hundreds or thousands or even more players play and earn yields in blockchain games by lending these players in-game assets or utilities. A guild will usually take profits by sharing a portion of the earnings earned by the players that rely on its help and the rent paid by the players that borrow in-game utilities or assets from the guild. YGG is the most famous blockchain game guild.

Game developers here don’t mean individuals but organizations, teams, or even DAOs (Decentralized Autonomous Organizations) [5] that develop games, services, or applications pertaining to games. Some famous game developers include SkyMarvis[6], Vulcan Verse[7], etc.

Services or applications pertaining to games refer to those that help grow and develop games’ user bases or help games evolve. Typical services or applications include marketplace applications such as OpenSea[8] and SkyMarvis’ marketplace[9], and asset or utility lending applications such as NFTFI[10].

2. Blockchain GameFi Ecosystem’s Underlying Technologies and Associated Issues or Risks

If we review these applications/roles listed in the previous section from a technical point of view and study their underlying technical standards or protocols, the whole blockchain GameFi ecosystem can be depicted as follows:

The top layer is what we call an application layer that contains the major applications/roles in the ecosystem. The underlying layer is what we call an infrastructure layer that contains two kinds of technologies: web 2.0 technologies/protocols and decentralized technologies/protocols. These two interact with each other via RPC calls.

The web 2.0 technologies/protocols can be viewed as being composed of two sub-layers: the sub-layer of C/S infrastructure, and the sub-layer of application UIs and backend services that run on the C/S infrastructure.

A UI (user interface) is the front-end of an application. When a user interacts with an application, he/she directly interacts with its UI.

Backend services execute functions based on the requests sent from UIs and respond to UIs with results and feedback.

The decentralized technologies/protocols can be viewed as being composed of three sub-layers:

the bottom sub-layer is an infrastructure layer which contains blockchain infrastructure, decentralized storage protocols such as IPFS [11] and Arweave [12], and other decentralized protocols.

The one on top of the blockchain infrastructure is the token sub-layer which contains fungible tokens and non-fungible tokens implemented based on various token standards.

The one that relies on the token layer, the blockchain infrastructure, the decentralized storage protocols, and other decentralized protocols is the utility/asset sub-layer which provides various utility or functional building blocks for all the applications that users interact with.

3. Typical Issues or Risks Associated with The Components in The Infrastructure Layer

When we review the security condition of an application, we first need to study how the application works and what technologies or protocols are applied to make it work and then analyze what issues or risks might be introduced when these technologies or protocols are applied.

So, in this section, we review in general what typical issues or risks are associated with each of the components in the infrastructure layer.

3.1 Web 2.0 Technologies/Protocols

C/S Infrastructure: this refers to commonly used utilities, tools, and various network protocols. This is the infrastructure that all internet applications or conventional software applications rely on.

Professionals from around the globe have been working on this for a long time and overall, it has been pretty much mature so far. Occasionally bugs or vulnerabilities pertaining to it would be reported and bug fixes would be promptly released as well.

So, when we audit an application, we don’t usually audit this component but would check if the application has already been updated with the latest patches that are released for newly uncovered vulnerabilities or bugs.

UIs: a UI is what a user directly interacts with when the user interacts with an application. Therefore, if an application’s UI has vulnerabilities, its users would be easily exploited. Hackers have developed various ways to exploit vulnerabilities to attack UIs.

Typical vulnerabilities pertaining to UIs are including XSS attacks, CSRF attacks, CSS injection attacks, session hijacking, using unsafe third-party libraries, DDoS attacks, feature requests or access, etc.

Backend Services: in general, the backend service of an application processes requests sent by the application’s UI and returns the result to the UI.

With regard to a blockchain application, besides the commonly known communication between the backend and the UI, there is communication between the backend and a blockchain as well. Therefore, a security company needs to audit specifically the security condition of the latter as well. This somehow might be overlooked.

Typical vulnerabilities pertaining to backend services of blockchain applications are injection flaws, broken authentication, compromised access control, data breaches, insecure deserialization, server XSS attacks, etc.

3.2 Decentralized Technologies/Protocols

Blockchain Infrastructure: this refers to blockchains including layer 1 blockchains, layer 2 solutions, and sidechains. The blockchain infrastructure provides the fundamental security and consensus of the whole blockchain GameFi ecosystem. Therefore, its security condition is vital to the whole ecosystem.

Among the existing blockchains, some such as Ethereum have endured challenges but most of them were just online in the past two years and haven’t endured enough challenges. Thus, the security condition of these less mature blockchains needs our great awareness.

Typical vulnerabilities pertaining to blockchain infrastructure are 51% attacks, DDoS attacks, Sybil attacks, double-spend, race attacks, eclipse attacks, routing attacks, replay attacks, etc.

Decentralized Storage Protocols (IPFS, Arweave …): this refers to the protocols that are specifically used for storage in the GameFi ecosystem. The most popular protocols include IPFS and Arweave.

Typical vulnerabilities pertaining to decentralized storage protocols are DDoS attacks, Sybil attacks, etc.

Other decentralized protocols: these are protocols that may be introduced in the future. So, for now, no specific vulnerabilities are listed here.

Fungible Tokens: most of the fungible tokens today are implemented based on Ethereum’s ERC-20[13] standard. Some tokens are implemented based on Solana’s [14] token templates. Issues or risks related to fungible tokens are mostly in the tokens’ smart contract implementation.

Specifically for ERC-20 tokens, typical vulnerabilities are re-entrancy attacks, excessive admin rights, integer overflow/underflow, gas consumption issues, inappropriate callback, inappropriate function visibility, inappropriate arithmetic precision, and incorrect using tx. origin, fake deposit, shadow variable, token issuance issue, inappropriate proxy design, inappropriate use of slots, contract upgrade/migration issue, etc.

For fungible tokens implemented on Solana, typical vulnerabilities are missing ownership checks, missing signer checks, signed invocation of unverified programs, Solana account confusions, missing freeze authority checks, insufficient SPL account verification, missing rent exemption assertion, casting truncation, arithmetic overflow/underflow, numerical precision errors, instructions account checks, rug pull mechanisms or hidden backdoor checks, outdated dependencies, none returned during any failure, unreferenced accounts checks, serialize and deserialize checks, account address checks, unaudited external dependencies, program upgrade checks, account mutable checks, etc.

Non-Fungible Tokens: most of the non-fungible tokens are implemented based on Ethereum’s ERC-721[15] or ERC-1155[16] standard. Some tokens are implemented based on Solana’s token templates. Issues or risks related to non-fungible tokens are mostly in the tokens’ smart contract implementation.

For ERC-721 or ERC-1155 tokens, typical vulnerabilities are re-entrancy attacks, excessive admin rights, integer overflow/underflow, incorrect nonce values, gas consumption issues, inappropriate callback, inappropriate function visibility, incorrect using tx. origin, fake deposit, shadow variable, token issuance issue, inappropriate proxy design, inappropriate use of slots, contract upgrade/migration issue, etc.

For fungible tokens implemented on Solana, typical vulnerabilities are missing ownership checks, missing signer checks, signed invocation of unverified programs, Solana account confusions, missing freeze authority checks, insufficient SPL account verification, missing rent exemption assertion, casting truncation, arithmetic overflow/underflow, instructions account checks, rug pull mechanisms or hidden backdoor checks, outdated dependencies, none returned during any failure, unreferenced accounts checks, serialize and deserialize checks, account address checks, unaudited external dependencies, program upgrade checks, account mutable checks, etc.

Tokenomics: tokenomics is a term coined by combining the two words “token” and “economics”. It means the economics of a crypto token and it usually covers the issuance, functionality, objective, allocation policy, and more of the crypto token. These factors all together form the characteristics of the crypto token’s supply and demand. A good tokenomics makes a crypto token appeal to both investors and users. Therefore, the tokenomics of an application is vital to an application’s long-term development and success. For a blockchain game e.g., a play-to-earn game, its tokenomics plays a key role.

Vulnerabilities in tokenomics can usually be uncovered in the design of the rules and functionality of a crypto token. This is more from an economical point of view rather than a technical point of view. In general, an awful tokenomics lacks a mechanism to incentivize users or investors to buy and hold tokens.

Typical vulnerabilities pertaining to tokenomics from an economical point of view are lack of token utilities, unlimited token supply, lack of liquidity, etc.

Governance: a significant feature that a blockchain application has compared with a conventional web 2.0 application is that it has a governance mechanism with which its token holders can participate in its activities and make decisions in guiding its development by voting with the application’s token. Vulnerabilities in the governance usually are uncovered in its rules and voting mechanism.

Typical vulnerabilities in governance are including inappropriate voting rules, inappropriate staking rules, inappropriate snapshot rules, inappropriate proposal submission rules, etc.

In-Game Assets or Utilities: in-game assets or utilities are implemented by smart contracts as either fungible tokens or non-fungible tokens. They have utilities that can be used in games for specific purposes.

Vulnerabilities concerning in-game assets or utilities are those that cause the assets or utilities out of work. These vulnerabilities are usually uncovered in the functional design or logic design.

Typical vulnerabilities about in-game assets or utilities are implementation vulnerabilities, design vulnerabilities, functional vulnerabilities, etc.

Implementation of On-Chain Logic: this refers to the business logic of an application. Specifically, for a blockchain application, to make its rules and logic tamper-proof and censorship-resistant, the team behind the application would code some or all of its business rules or logic in smart contracts.

Popular on-chain logic that is implemented in smart contracts includes decentralized exchange rules, borrowing, and lending rules, staking rules, liquidity mining rules, NFT fractionalization rules, etc.

Typical vulnerabilities in the implementation of on-chain logic are using improper oracles, missing emergent withdrawal functions, inappropriate LP price algorithm, unsafe token transfer, excessive admin rights, hidden backdoors, risky contract upgrade/migration, implementation vulnerabilities, design vulnerabilities, etc.

Data Storage Solutions: for blockchain applications, a popular way to handle data storage is to use a decentralized solution to save data. These decentralized solutions in general are based on decentralized protocols such as IPFS, Arweave, etc.

A good data storage solution should be able to save data consistently and permanently. This is especially important for NFT projects which need to have long-term data availability and reliability for metadata.

Vulnerabilities in a data storage solution would cause data loss or data inconsistency. Typical vulnerabilities pertaining to data storage solutions are unreliable data storage, lack of data redundancy, lack of data consistency, unreliable data retrieval service, etc.

Other Solutions/Services: these will be solutions based on the protocols that may be introduced in the future. For now, no specific vulnerabilities are listed here for this.

4. Security Checkpoints That Should Be Covered for Each Kind of Application in the Ecosystem

4.1 Games

Specifically, a blockchain game is backed and supported by the technologies depicted in the following diagram:

The components represented by solid green blocks are the ones that Games must rely on. The components represented by transparent blocks are the ones that Games may optionally rely on.

From this diagram, we can see that the major technologies that a blockchain game directly relies on including **UIs, Backend Services, Tokenomics, Governance, In-Game Assets or Utilities, Implementation of On-Chain Logic, and Data Storage Solutions. **Optionally Other Decentralized Solutions may be relied on as well.

Consequently, the vulnerabilities we listed for each of the direct technologies and their underlying technologies in the previous section should be considered as the checkpoints for a blockchain game.

4.2 Game Guilds

Specifically, a blockchain game guild is backed and supported by the technologies depicted in the following diagram:

The components represented by solid green blocks are the ones that Game Guilds must rely on. The components represented by transparent blocks are the ones that Games may optionally rely on.

From this diagram, we can see that the major technologies that a blockchain game guild directly relies on upon including **UIs, Backend Services, Tokenomics, and Governance. **Optionally In-Game Assets or Utilities, Implementation of On-Chain Logic, Data Storage Solutions, and Other Decentralized Solutions may be relied on as well.

So, the vulnerabilities we listed for each of the direct technologies and their underlying technologies in the previous section should be considered as the checkpoints for a blockchain game guild.

4.3 Game Developers

Specifically, a blockchain game developer is backed and supported by the technologies depicted in the following diagram:

The components represented by solid green blocks are the ones that Game Developers must rely on. The components represented by transparent blocks are the ones that Games may optionally rely on.

From this diagram, we can see that the major technologies that a blockchain game developer directly relies on including **UIs, Backend Services, Tokenomics, Governance, Implementation of On-Chain Logic, and Data Storage Solutions.**Optionally In-Game Assets or Utilities and Other Decentralized Solutions may also be relied on.

So, the vulnerabilities we listed for each of the technologies and their underlying technologies in the previous section should be considered as the checkpoints for a blockchain game developer.

4.4 Services or Apps Pertaining to Games

Specifically, service or app pertaining to blockchain game(s) is backed and supported by the technologies depicted in the following diagram:

The components represented by solid green blocks are the ones that Services or Apps Pertaining to Games must rely on. The components represented by transparent blocks are the ones that Games may optionally rely on.

From this diagram, we can see that the major technologies that service or app pertaining to blockchain game(s) relies on upon including UIs, Backend Services, Tokenomics, Governance, and Implementation of On-Chain Logic. Optionally In-Game Assets or Utilities, Data Storage Solutions, and Other Decentralized Solutions may also be relied on.

So, the vulnerabilities we listed for each of the items in the previous section should be considered as the checkpoints for a service or app on blockchain game(s).

Conclusion:

In this paper, we explore the applications and technological modules of the existing blockchain GameFi ecosystem, list typical vulnerabilities of each of the technological modules and present our ideas on what specific areas we would study when we audit or check the security condition of an application in this ecosystem.

We are keeping our work and close attention to the GameFi ecosystem’s development and would always do our best to contribute to the ecosystem’s security and expansion.

References:

[1] CryptoKitties, https://www.cryptokitties.co/

[2] Axie Infinity, https://axieinfinity.com/

[3] YGG, https://yieldguild.io/

[4] Crypto VCs Are Making a Big Bet on Gaming Guilds. Why?

https://www.coindesk.com/markets/2021/12/21/crypto-vcs-are-making-a-big-bet-on-gaming-guilds-why/, December 27, 2021

[5] Decentralized autonomous organizations (DAOs), https://ethereum.org/en/dao/

[6] Sky Mavis, https://skymavis.com/, 2021

[7] Vulcan Verse, https://vv.vulcanforged.com/, 2022

[8] OpenSea, https://opensea.io/

[9] SkyMarvis’ Marketplace, https://marketplace.axieinfinity.com/

[10] NFTFI, https://www.nftfi.com/

[11] IPFS, https://ipfs.io/

[12] Arweave, https://www.arweave.org/

[13] ERC-20 Token Standard,

https://ethereum.org/en/developers/docs/standards/tokens/erc-20/

[14] Solana, https://solana.com/

[15] ERC-721 Non-fungible Token Standard,

https://ethereum.org/en/developers/docs/standards/tokens/erc-721/

[16] EIP-1155: Multi Token Standard, https://eips.ethereum.org/EIPS/eip-1155

About the author:

Yuefei TAN, CEO of Fairyproof

About Fairyproof:

Fairyproof Tech is a blockchain security company, established in Jan 2021.

It was founded by a team with rich experience in smart contract programming and network security. The team members participated in initiating several draft standards in the Ethereum field, including ERC-1646, ERC-2569, ERC-2794, and EIP-3712, of which ERC-2569 was officially accepted by the Ethereum team.

The team participated in the launch and development of various Ethereum projects, including blockchain platforms, DAO organizations, on-chain data storage, and decentralized exchanges, and conducted security audits of multiple projects which have been deployed on Ethereum. Based on its strong R&D capability and deep understanding of smart contract security, Fairyproof has developed comprehensive vulnerability tracking and security systems and tools.

Fairyproof Tech serves and works closely with customers by providing systematic solutions covering both “code vulnerabilities” and “logic vulnerabilities” and aims to provide customers with the best and most professional services.

According to this EIP’s specification, although it is a stop-gap solution, the format it introduced for blob transactions will be the same as the format that will exist in Ethereum’s final sharding specification [2]. And eventually, all rollup solutions [3] will have to use sharded data (i.e., blobs) instead of calldata which they use now if they expect to submit rollup data to Ethereum.

Therefore, this EIP will very likely be adopted and implemented in Ethereum’s clients and existing rollup solutions will eventually have to make changes to be compliant with this EIP.

Whenever changes are introduced, issues or risks might be introduced as well.

As a blockchain security company, Fairyproof’s research team is extremely interested in the issues or risks that might be introduced by these changes. We studied this EIP, explored possible security checkpoints, and would like to share some ideas on these checkpoints.

There are significant changes introduced by this EIP in both the implementation of Ethereum clients and rollup solutions.

On the Ethereum client-side, a new blob transaction is proposed, therefore new data structures such as SignedBlobTransaction and BlobTransactionNetworkWrapper are introduced, and new algorithms such as validate_blob_transaction_wrapper are introduced.

On the rollup solution side, both Optimistic-Rollup solutions [4] and ZK-Rollup solutions [5] need to put rollup data in a blob transaction.

The changes in both Ethereum’s client-side and rollup solutions may not introduce noticeable vulnerabilities however the newly introduced blob transaction may render two kinds of mempool issues.

The first one is that a blob transaction has a variable intrinsic gas cost. And this would expose a mempool to attacks since a transaction may be qualified to be included in one block but may not be qualified to be included in the next block. To prevent such an attack, this EIP recommends only broadcasting transactions “whose gas is at least twice the current minimum” to greatly increase a legitimate transaction’s chance of being included in a block.

The second one is that a blob transaction has a large data size at the mempool layer, which would expose a mempool to DoS attacks. This EIP recommends increasing “the minimum increment for mempool replacement from 1.1x to 2x” to increase an attacker’s cost thus decreasing his/her attempt to attack.

It is worth noting that the EIP says these two are just recommendations. This means a developer may not need to follow them in his/her implementation. But as far as security is concerned the developer needs, by all means, to handle these issues in his/her code.

This is what a blockchain security company needs to pay close attention to when auditing an Ethereum client implementing this EIP.

In addition, these two recommendations were proposed to counteract attacks on mempools. If they are implemented it implies that if a non-malicious user wants his/her transaction to be promptly handled, he/she needs to pay a gas fee that meets these recommendations.

This is something a user should be aware of.

References:

[1] EIP-4844: Shard Blob Transactions, https://eips.ethereum.org/EIPS/eip-4844, Feb 25, 2022

[2] Shard Chains, https://ethereum.org/en/upgrades/shard-chains/

[3] An Incomplete Guide to Rollups, https://vitalik.ca/general/2021/01/05/rollup.html, Jan 5, 2021

[4] Optimistic Rollups,

https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/,

[5] ZK-Rollups, https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/

It has truly been another eventful week!

During the week from March 21 to March 27, 2022, security incidents that happened in the crypto industry can be categorized into two security hacks and publicly announced vulnerabilities.

Here is a list of the security hacks:

1. OneRing

On March 21 UTC time, OneRing Finance, a DeFi application deployed on Fantom was attacked. In this attack, the attacker leveraged a flashloan to exploit a total of 1,454,672.244369 USDCs valued at around $1,454,672.24.

The vulnerability that was exploited was an inappropriate algorithm used to calculate an LP token’s price. This inappropriate algorithm caused the price of the LP token involved in this attack to be manipulated. And a flashloan was facilitated to enlarge the loss.

For more details about this attack please refer to Fairyproof’s article at:

https://medium.com/coinmonks/fairyproofs-analysis-of-the-attack-on-onering-finance-94d25b66f63c

2. Cashio Dollar

On March 23 UTC time, Cashio Dollar, a DeFi stable coin application deployed on Solana was attacked.

The attacker’s address was 6D7fgzpPZXtDB6Zqg3xRwfbohzerbytB2U5pFchnVuzw on Solana.

The hash value of the attack transaction was:

4fgL8D6QXKH1q3Gt9GPzeRDpTgq4cE5hxf1hNDUWrJVUe4qDJ1xmUZE7KJWDANT99jD8UvwNeBb1imvujz3Pz2K5

The vulnerability that was exploited was that the right to mint tokens was not properly verified.

Basically, the attacker exploited the vulnerability to mint 2 billion CASH tokens, exchanged them to 8.64 million USTs, 17.04 million USDCs, and 26.34 million USDT-USDC LP tokens, and exploited a total of around $50 million.

3.Revest Finance

On March 27 UTC time, Revest Finance, a DeFi application deployed on Ethereum was attacked.

The attacker’s address was 0xef967ECE5322c0D7d26Dab41778ACb55CE5Bd58B on Ethereum.

The attacking contract was deployed at 0xb480Ac726528D1c195cD3bb32F19C92E8d928519 on Ethereum.

The attacked contract was deployed at 0x2320a28f52334d62622cc2eafa15de55f9987ed9 on Ethereum.

The root cause of this attack was that there was a re-entrancy vulnerability in its ERC-1155 implementation.

In this attack, the attacker exploited 592 ETHs and some other crypto assets valued at around $120,000. The total loss was around $2 million.

Right after the attack was detected, the team behind the project promptly announced that emergent measures had been taken to protect the remaining crypto assets.

4. Maison Ghost’s Discord Server

Sometime near March 25 UTC time, Maison Ghost, an NFT project was attacked. Basically, the project’s Discord server suffered from a phishing attack.

Around 265 NFTs including those from Sandbox and 3Landers were exploited.

5. Wallet Compromised

On March 22 UTC time, Arthur Cheong, Founder of Defiance Capital claimed that his Ethereum wallet was exploited.

The attacker’s address was 0xe47E8cD58c8E95F765e642d7dCB898f622ceFA83 on Ethereum.

This was a typical phishing attack. The victim received an email containing a phishing link from a suspicious source that had a similar name to the name of a company which the victim was familiar with. The victim opened the malicious link and got exploited.

In this incident, 78 NFTs including Azukis, CloneX, and Second Self, and fungible tokens including 68 WETHs, 4349 stkDYDXs, and 1578 LOOKS were exploited. The total loss exceeded $1.5 million. The attacker cashed out 500 ETH at the time when the victim announced the incident.

Here is a list of the publicly announced vulnerabilities:

1. Chrome’s Vulnerability

On March 27 UTC time, Google announced that a zero-day vulnerability was detected in Chrome, and this vulnerability exposed plugins including MetaMask to huge risks. Google tagged this vulnerability as CVE-2022–1096. The vulnerability could be exploited by a hacker to insert malicious code to launch attacks.

This was the second zero-day vulnerability detected since 2022. The first one was tagged as CVE-2022–0609 and was fixed by Google in February 2022.

Google has released a patch for this bug and urged users of Chrome to install this patch as soon as possible.

Closing thoughts

There were five security hacks in the past week. The vulnerabilities that were uncovered in three of them including OneRing, Cashio Dollar and Revest Finance were commonly known issues and could have been uncovered and fixed without being exploited if these projects had undergone a professional audit. The other two hacks targeting a Discord server and an Ethereum Wallet could have been prevented if users operated these utilities with more caution and care.

The one publicly announces vulnerability could hardly be detected by third parties. The first and most important thing that users of Chrome need to do is to install the fix right after this bug was announced.

A reminder to smart contract developers: using an appropriate algorithm to calculate an LP token’s price, correctly handling access control to core token functions, and using effective measures to prevent re-entrancy risks in token implementation and always be kept in mind carried out in smart contract implementation.

A reminder to crypto users, always be cautious and alert to suspicious links, websites, and emails, watch for news about security issues with the tools and utilities often used, and install bug fixes as soon as possible.