
Original compilation: ChinaDeFi
Original compilation: ChinaDeFi
Since a year ago, the Solana ecosystem has seen hyper-growth while witnessing multiple hacks (including Wormhole, CashioApp, CremaFinance, Nirvana, and Slope Wallet) that collectively caused nearly $400 million in damage.
Importantly, most of these hacks (with the exception of Slope Wallet) were due to smart contract vulnerabilities, i.e. coding flaws in on-chain protocols:
Wormhole: $320 million stolen due to lack of account verification;
CashioApp: $50 million stolen due to lack of account verification;
CremaFinance: $10 million stolen ($8 million returned) due to lack of account verification;
Nirvana: $3.5 million stolen through price manipulation through flash loans;
Slope Wallet: $4 million stolen due to leaked seed phrase.
first level title
What do these hackers have in common?
1. Almost all hackers (except Slope Wallet) have crafted one or more fake accounts.
Wormhole: Hackers created two fake sysvar accounts to skip key verification.
CashioApp: Hackers created 8 fake accounts to pass validity checks.
CremaFinance: Hackers created a fake account and used flash loans to steal fees.
Nirvana: Hackers crafted a flash loan account to manipulate token prices.
Slope Wallet: The hacker directly obtained the private key of the user's wallet through the leaked mnemonic.
2. All hacks involve multiple transactions
Wormhole: The whole attack was completed with 6 transactions: the first tx creates the first fake sysvar account, and the last tx calls complete_wrapped.
CashioApp: More than 10 transactions were made during the entire attack from creating all the fake accounts to sending the final attack transaction.
CremaFinance: Each attack requires at least 3 transactions; create a fake account, deploy a flash loan program, and launch an attack to steal fees; in addition, hackers have repeatedly initiated 10+ flash loan transactions from different token pools to steal from.
Nirvana: The attack carried out at least 2 transactions; deployed a well-designed flash loan receiving program, and invoked Solend flash loan.
Slope Wallet: The entire attack drained more than 9,000 wallets, involving more than 9,000 SOL or SPL token transfer transactions.
3. All attacks last at least a few minutes (hours or even days)
Wormhole: The time span between the tx of creating the first fake sysvar account and the tx of completing the transfer is 6 hours.
CashioApp: The hacker's first fake account was created 5 days before the transaction took place.
CremaFinance: This fake account was created more than an hour before the first attack.
Nirvana: The time window span between two transactions (deploying the flash receiver and calling Solend flash) is 4 minutes.
Slope Wallet: The widespread attack lasted at least 8 hours.
4. The biggest loss is due to lack of account verification
The root cause of the previous three hacks (Wormhole, CashioApp, and CremaFinance) was a lack of proper account verification.
Coincidence or not, these attacks have caused a lot of financial damage.
5. Flash Loans Involved in Two Hacks
Both the CremaFinance and Nirvana hacks involved direct flash loan transactions, and both were conducted through Solend.
At CremaFinance, flash loans are used to channel deposit liquidity.
first level title
How to prevent similar hacks in the future?
secondary title
1. Pre-deployment: Verify all input accounts of the smart contract
When writing Solana smart contracts, always keep in mind that all inputs can be forged by an attacker, including all accounts and external programs (i.e. user wallet accounts, PDA accounts, and other smart contracts).
Solana's programming model decouples code and data, so all accounts used in the program must be passed as data inputs.
In almost all cases, you should verify:
account ownership
account signer
Relationships (or logical constraints) between accounts
Depending on the protocol logic, one should also check:
Constraints need to be added to prevent discrepancies if any internal price oracles manipulate flash loans (with bulk transfers).
secondary title
2. Post-deployment: Proactively use real-time threat monitoring
Since all of these hacks involve multiple transactions spanning at least a few minutes or hours, it is possible to proactively detect suspicious transactions in advance and contain attacks in the middle.
This is a unique property of Solana that allows on-chain threat monitoring technology to act as a defensive solution to help effectively prevent and stop security attacks:
In principle, a threat monitoring solution might help:
Monitor mass transfers of SOL or SPL tokens;
Monitor flash loan transactions against your smart contracts;
Monitor potential vulnerabilities by upgrading dependent programs;
Monitor abnormal status (e.g., calculate fees);
Monitor round-trip transaction events such as deposit-claim-withdraw in a single tx);
Monitor duplicate transactions from the same signer;
Any custom monitoring for protocol-specific properties.
Original link