In this article, we introduce a few penetration testing tools to help detect vulnerabilities in Solana or Rust programs in general.

• Solana PoC Framework: a framework for creating PoCs for Solana Smart Contracts developed by Neodyme.
• afl.rs: a fuzz testing tool for Rust programs based on AFL
• cargo-fuzz: cargo subcommand for fuzzing with libFuzzer and LLVM sanitizers.
• cargo-tarpaulin: a code coverage reporting tool for Rust projects

Solana PoC Framework

The poc-framework provides a convenient way to simulate transactions in a local environment. To illustrate its usage, we will use an example provided by Neodyme on Github.

We first run x-ray -analyzeAll . to get a list of potential vulnerabilities, for which we then use the poc-framework to construct exploits. In particular, X-Ray reports the following issue:

In fact, this is a known vulnerability (a missing ownership check on line 104) in the level0 contract. In the next three steps, we will construct a PoC to exploit this vulnerability.

Step1. Initializing the contract states (owner)

To develop PoC, the first step is to set up the contract states, which typically includes deploying the contract on the blockchain, creating necessary contract accounts, and invoking a transaction to initialize the contract states.

More specifically, to call the initialization function (line 21), we need to prepare three parameters: program_id, accounts, and instruction_data. The program_id is trivial: it is the public key of the deployed contract.

However, the other two parameters must have proper data contents to satisfy the conditions in the initialization function (line 27).

• The accounts vector includes at least five accounts in the following order: wallet_info, vault_info, authority_info, rent_info, and system_program. The fifth account is used by system_instruction::create_account (lines 46 and 58)
• The accounts have relationships (enforced by assert_eq! line 42): wallet_info.key == wallet_address, and the wallet_address is a program derived address (PDA) determined from program_id and authority_info.key.
• The wallet account has empty data (enforced by assert!(wallet_info.data_is_empty()) on line 43)

To achieve our goal, there are three steps:

1. use the poc_framework to create three accounts: one for the authority, one user, and one hacker:

2.use the poc_framework local environment to deploy the contract (level0.so) with a program_id (wallet_program), add the three accounts above, and initialize them each with 1.0 sol:

3. construct an instruction with the three parameters, and then execute a transaction in the poc_framework local environment:

Note that wallet_address and vault_address are PDAs, which are constructed by Pubkey::find_program_address (lines 33–38):

Now, the first step is done. This step is typically performed by the contract owner with certain authority, and for the PoC we assume it is done correctly.

Running the code will produce the following log:

Step2. Constructing normal user interactions (user)

Currently, the vault account has almost zero money (except the rent exempt fee 0.00089088 sol). In the second step, we will create a transaction to invoke the deposit function to transfer money to the vault account. This step can be generalized to simulate any normal user interactions with the contract.

In the deposit function above, the accounts vector includes four accounts: wallet, vault, source (the user account to transfer money from) and system_program (used by system_instruction::transfer line 95).

The amount of money to transfer is a parameter passed to WalletInstruction::Deposit {amount}.

We can then construct an instruction with these parameters, and again use the poc_framework to execute a transaction:

Now, the second step is done. Running the code will produce the following log. Note that the vault account now has 1.00089088 sol. We have just successfully transferred 1 sol.

Step3. Launching the attack (hacker)

Finally, we are about to complete the exploit by creating an instruction that simulates the hacker’s behavior. The goal in this case is to invoke the withdraw function to transfer money from the vault account to the hacker.

From X-Ray report, recall that the wallet account is not trustful (line 104) . This means that the hacker may create a fake wallet account to invoke the withdraw function. To successfully steal the money (line 119), the fake wallet account and the other inputs must satisfy the following conditions:

1. The wallet.authority field must be the same as the authority_info account key (enforced by assert_eq! line 111):

2. The wallet.vault field must be the same as the vault account key (enforced by assert_eq! line 112):

3. The withdraw amount is no larger than the money in the vault account:

4. In addition, the authority account must be signed (enforced by assert! line 110):

To satisfy this condition, the hacker may also supply a fake authority account, e.g., use their own hacker account and sign the transaction.

Considering all these constraints, we can construct a fake wallet account with the hacker_address as the fake authority field:

We use the poc_framework to create a fake wallet account in the LocalEnvironment:

We can then create a transaction to call the withdraw instruction:

In the above, the amount_to_steal can be set to the amount of money in the vault:

Putting all the above together, we have successfully created a PoC to exploit the vulnerability. Running the code will produce the following log. Note that the vault account is empty now, and the hacker now has 2.00089088 sol.

What’s next

In the next few articles, we will continue to introduce auditing skills for Solana smart contracts, including the Anchor development framework.