Event Insights | Solana Ecosystem Security and Audit Strategies
Background
From November 14th to 17th, the Solana Hacker House held a four-day offline event in Hong Kong, featuring on-site guidance from core engineers at Solana Labs, supported by mentors from various ecosystem teams. Johan, our head of blockchain security at SlowMist Security, was invited to deliver a presentation titled “Advanced Security and Auditing Strategies for the Solana Blockchain”. His talk covered three main aspects: security considerations in development, security incidents in Solana, and how to conduct security audits for smart contracts. This article provides a comprehensive insight into the security and auditing strategies of the Solana ecosystem.
Security Considerations in Development
Public and Private Key Pairs in Accounts
Solana’s public key is generated using the Ed25519 algorithm, known for its security and speed. This algorithm has some resistance to quantum computing attacks and produces deterministic signatures, enhancing resistance against signature malleability attacks.
Solana Accounts
Solana’s design philosophy shares certain similarities with Linux’s file system. Accounts in Solana can be used for data storage and have strict ownership and read-write permission controls. In Linux, a path is used to point to the file to be read, written, or executed, whereas in Solana, this is done using the public key. However, Solana differs in that accounts need to pay for storage space.
Key Characteristics of Solana Accounts:
- Accounts are used for data storage.
- The maximum storage space for an account is 10 MB.
- Storage space incurs a rental fee.
- By default, the owner of a newly created account is the System Program.
- Programs are executable codes stored in accounts.
- Programs can be called by users and other programs.
- Programs are stateless.
- The maximum storage space for a PDA (Program Derived Address) account is 10 KB.
Program Accounts & Data Accounts
In Solana, since the Programs are stateless, there is a need to create accounts specifically for data storage, known as Program Derived Accounts (PDAs). The owner of a PDA can serialize the data in a specific structure and store it in a Data Account.
Program Instructions
The following is an illustrative diagram of a Solana smart contract call, which differs from Ethereum’s smart contracts. In Solana, a single Transaction can call multiple Programs through Instructions. When a client calls a Program, it must first input several key parameters (Program ID, Accounts, Data) to construct the Instruction. This process is straightforward and flexible, but it also introduces numerous security vulnerabilities.
Account Verification as a Major Security Risk
Account verification is a significant security concern in Solana’s ecosystem. Smart contracts need to meticulously design the relationships between accounts. Looking at the structure below, ‘key’ points to the account itself. ‘Lamports’ need to be verified to ensure sufficient rent is available. ‘Data’ must be interpreted and validated according to specific scenarios. The ‘owner’ is usually associated with the Program ID. Additionally, it’s crucial to verify signatures, check if the account is writable, and so on. Each of these elements plays a vital role in maintaining the security and integrity of the transactions and operations within the Solana blockchain.
Runtime Constraints for Programs
Programs running on Solana are subject to certain constraints imposed by the runtime environment. These constraints include:
- Only the owner of an account can change its owner.
- Accounts not allocated to a Program cannot have their balance reduced.
- The balance of read-only and executable accounts cannot be altered.
- Only the owner can change the account size and data.
- Once an account is marked as executable, it cannot be reverted.
- The associated rent_epoch of an account cannot be modified by anyone.
Reentrancy Protection
This is another limitation imposed by the runtime on smart contract calls. In Ethereum’s early days, a well-known reentrancy attack led to significant financial losses. Learning from this, Solana prohibits contract reentrancy to prevent such vulnerabilities.
Account Security Coding Best Practices
- Key Verification: Ensure that the incoming account is the expected one, such as a Sysvar account.
- Owner Verification: Confirm that the data writer has the appropriate authorization.
- Signer Verification: Authenticate the identity of the caller initiating the request.
- Program ID Verification: Ensure that the execution environment meets the expected conditions.
- PDA Verification: Verify data integrity to confirm it originates from a trusted source.
- Lamports Verification: Check the adequacy of the rent paid for data storage.
- Data Verification: Analyze the data format to ensure it meets the expected structure, such as verifying compliance with the SPL-Token standard.
Assets on Solana: Tokens
Tokens represent assets on the Solana blockchain, and their security and management are closely tied to these runtime constraints and security coding practices. This ensures that assets are handled securely and efficiently within the Solana ecosystem.
Token Structure in Solana’s Stateless Programs
Due to the stateless nature of Solana’s programs, a token cannot be implemented in a single account. Instead, the structure of tokens in Solana primarily consists of three components: the token-program, the mint-account, and the token-account. In essence, issuing a token involves creating a mint-account, and receiving a new token involves creating a token-account.
Mint-Account: This account stores basic token information such as mint-authority, supply, decimals, whether it’s initialized (is_initialized), and freeze-authority.
Token-Account: This account records the token information held by a user, including mint, owner, amount, and account authorization information like delegate and delegate_amount.
Relationship Diagram of Token Accounts: The diagram below illustrates the relationships among these accounts. The token-program can create an unlimited number of tokens, and users can have an unlimited number of token-accounts. The account owner for both mint-accounts and token-accounts is the token-program. This structure allows for the flexible creation and management of tokens within the Solana ecosystem, each with its distinct properties and authorities.
NFTs as SPL-Tokens and Security Considerations in Solana
NFTs in Solana are a type of SPL-token, currently defaulting to the standard created by Metaplex. Unlike fungible tokens, the main characteristic of an NFT is that its supply is 1, and its decimals are 0, indicating that each NFT is unique and indivisible.
An important aspect of Solana’s token authorization model is that it allows authorization to only one account at a time. Compared to the ERC-20 standard, this approach significantly reduces the risk of token theft.
Key Programming Considerations for SPL-Tokens:
- Token Program ID Verification: Ensure that the token is issued by an official project.
- Mint Verification: Confirm that the received token is the correct one.
- Mint Authority Verification: Protect the token minting rights using methods like multi-signature to prevent private key misuse.
- Decimal Verification: Verify the token’s decimal precision to ensure accurate transactions.
- Amount Verification: Implement range checks to prevent overflow and maintain calculation accuracy.
- Freeze Authority Verification: Ensure that the NFT’s minting rights are irreversibly terminated.
Security Incidents on Solana
According to the SlowMist Blockchain Hacked Archive as of now, the losses in the Solana ecosystem have exceeded 500 million USD. This highlights the importance of robust security measures and the ongoing need for vigilance in the blockchain space.
Overview of Notable Hacker Attacks in Solana
1. Wormhole Cross-Chain Bridge Attack
The main cause of this incident was the failure to verify an incoming system account. The hacker used a forged account with carefully crafted data to fill the account, causing the smart contract to erroneously issue additional tokens to the hacker. This incident resulted in a loss of 120,000 ETH.
2. Nirvana Flash Loan Attack
Nirvana, a project that was not open-source, could only be analyzed through a browser. Hackers borrowed a large amount of USDC from Solend, manipulated the token’s price, and then profited over 3 million USD. This case illustrates that not being open-source does not make a project immune to hacking. Experienced and patient attackers can still find potential security vulnerabilities in the protocol. Hence, development teams should not be complacent regarding security.
These incidents underscore the importance of rigorous security practices in the development and maintenance of blockchain applications, particularly in areas like account verification and the handling of cross-chain transactions. Even sophisticated systems like Solana are not impervious to attacks, and continuous vigilance and improvement in security measures are essential.
3. Mass Private Key Theft Incident
In August 2022, a significant number of Solana community users experienced private key thefts. Intriguingly, the investigation revealed that they were not using the same wallet, nor did they share similar usage habits, making it difficult to pinpoint the exact cause of the incident. However, it was discovered that some wallets, due to the use of the Sentry component, inadvertently uploaded private keys to a server. The SlowMist Security Team has written an analysis titled “SlowMist: Analysis of the Mass Token Theft Event on Solana Blockchain” for those interested in a detailed breakdown of this event.
4. Token Deposit Forgery Attack
This incident involves an off-chain security issue. Attackers created a token-account and transferred tokens into this account, then transferred them out. Subsequently, they changed the owner of this token-account to a deposit address of an exchange. When the exchange checked the on-chain records of the token-account, it mistakenly identified these transactions as legitimate deposits. As a result, the exchange credited the malicious user’s account, leading to the success of the attack.
These events further highlight the complexities and vulnerabilities that can exist in blockchain ecosystems, emphasizing the need for robust security protocols and continuous vigilance against evolving types of cyber threats.
How to Conduct Smart Contract Security Audits
Security in the context of smart contracts is not solely a matter of technical proficiency; it also depends on the changing environment over time, which may introduce new variables that can weaken the system. Effective security management involves three key elements: a dedicated security budget, continuous audits, and direct oversight by senior management.
Smart contract security auditing is a meticulous process that requires a broad spectrum of knowledge and skills. The SlowMist Security Team has shared resources on GitHub, including a skill tree for smart contract auditors “SlowMist-Learning-Roadmap-for-Becoming-a-Smart-Contract-Auditor” and best practices for Solana smart contract security “Solana-smart-contract-security-best-practices”. These resources are valuable for anyone interested in diving deeper into this field.
Conclusion
The SlowMist Security Team has been committed to smart contract security auditing for many years. Their commercial system, Badwhale, has served dozens of platforms over the years, averting an estimated several billion dollars in asset risks related to fake deposits. It also supports the detection of fake deposits on Solana. To date, the team has audited numerous Solana projects and is open to inquiries from projects seeking audit services.
Finally, the team expresses gratitude for the invitation to Solana Hacker House and hopes that this sharing session has helped attendees better understand the ecosystem’s security and auditing strategies in Solana.
About SlowMist
At SlowMist, we pride ourselves on being a frontrunner in blockchain security, dedicating years to mastering threat intelligence. Our expertise is grounded in providing comprehensive security audits and advanced anti-money laundering tracking to a diverse clientele. We’ve established a robust network for threat intelligence collaboration, positioning ourselves as a key player in the global blockchain security landscape. We offer tailor-made security solutions that span from identifying threats to implementing effective defense mechanisms. This holistic approach has garnered the trust of numerous leading and recognized projects worldwide, including names like Huobi, OKX, Binance, imToken, Crypto.com, Amber Group, Klaytn, EOS, 1inch, PancakeSwap, TUSD, Alpaca Finance, MultiChain, and Cheers UP. Our mission is to ensure the blockchain ecosystem is not only innovative but also secure and reliable.
SlowMist offers a variety of services that include but are not limited to security audits, threat information, defense deployment, security consultants, and other security-related services. They offer AML (Anti-money laundering) software, Vulpush (Vulnerability monitoring) , SlowMist Hacked (Crypto hack archives), FireWall.x (Smart contract firewall) , Safe Staking and other SaaS products. They have partnerships with domestic and international firms such as Akamai, BitDefender, FireEye, RC², TianJi Partners, IPIP, etc.
By delivering a comprehensive security solution customized to individual projects, they can identify risks and prevent them from occurring. Their team was able to find and publish several high-risk blockchain security flaws. By doing so, they could spread awareness and raise the security standards in the blockchain ecosystem.
