Recap

Welcome back to Token-2022 Security Best Practices. In Part 1, we addressed the potential security issues associated with Mint and Token Accounts when supporting Token-2022. In this part, we will explore the extensions of Token-2022, analyze potential security risks, and suggest recommended solutions. Please pay close attention to each topic, especially the Attention section.

How to hedge the security risks of Token-2022 Extensions

Token-2022 expands the functionality of mint and token accounts compatible with SPL Token through an extension model. It introduces nearly 20 Extensions. If developers lack sufficient understanding of the assumptions and characteristics of these extensions, serious security issues, such as DoS or financial losses, may arise.

In this chapter, we will explore five Token-2022 extensions closely related to security, summarize their security assumptions, and outline potential security issues associated with these extensions.

1. Metadata, Group & Member

Token-2022 includes three metadata extensions to describe mint, along with three corresponding pointer extensions that pair with each of these metadata extensions.

Pointer extensions, which ensure that data accessed through the pointer is valid and trusted, are stored within the extension part of mint account. Data, however, are more flexible—they can reside either within the extension part of mint account or as a separate account.

If a contract or DApp requires the data from Metadata, Group, or Member, it is essential for the project team to verify the authenticity of the data, which depends on the mutual reference relationship between the data and the pointer.

Attention

Everyone can create Token-2022 accounts of type Metadata, Group and Group Member, fill these accounts with deliberately crafted data, and point them to a legitimate mint. However, only the metadata accounts that mint’s pointer references are considered authoritative and verified by itself.

The following diagram illustrates the expected relationship between Metadata and Metadata Pointer. There is a Mint A and its corresponding Metadata M here:

• A.metadata_pointer.metadata_address == M

• M.mint == A

Token-2022 allows mint creators to embed their token’s Metadata, Group and Member data directly into the mint account to simplify the use of data. In this case, the relationship diagram can be simplified as follows:

2. Permanent Delegate

Token-2022 introduces a high-risk extension to the mint account: Permanent Delegate.

The authority designated as a permanent delegate holds high privileges to directly transfer or burn any amount of mint from any token account.

For instance, in the implementation of SPL Token-2022’s process_transfer function, when verifying the transfer authority, the permanent delegate is automatically authorized without further checks.

    pub fn process_transfer(
        ...
    ) -> ProgramResult {
        ...
        match (source_account.base.delegate, maybe_permanent_delegate) {
            (_, Some(ref delegate)) if cmp_pubkeys(authority_info.key, delegate) => {
                Self::validate_owner(
                    program_id,
                    delegate,
                    authority_info,
                    authority_info_data_len,
                    account_info_iter.as_slice(),
                )?
            }
        ...
    }

This diagram summarizes three types of transfer scenarios:

• A standard transfer initiated directly by the authority of the source token account

• A transfer initiated by a delegate account, previously approved by the authority of the source token account

• A transfer initiated by the permanent delegate account, bypassing the need for a signature from the authority of the source token account

Attention

Both developers and users need to be particularly concerned at mints that include Permanent Delegate. It is important to closely monitor and manage the actions of the permanent delegate to avoid unexpected losses due to their high privileges.

As a developer, it is vital to clearly define and describe the permissions and security policies linked to the permanent delegate role in projects involving mints with this extension. The high-privilege operations of this role must not be misused. Additionally, implementing monitoring for this role is recommended to provide timely alerts and prevent unforeseen actions.

As a user, it is necessary to be aware of whether your asset's mint supports a Permanent Delegate. We strongly recommend you to transfer assets to this mint only after confirming that the delegate authority can be fully trustworthy.

3. Memo Transfer

Memo Transfer is a new Token-2022 extension that allows users to enable memos on their token accounts, enabling them to view memos attached to transfers when receiving tokens.

The Token-2022 program requires that the transfer IX must be immediately preceded by a Memo IX when processing a Memo-enabled destination token account.

This is the code snippet from the SPL transfer related to memo. If the IX immediately preceding the transfer is not a memo, the SPL transfer will result in an error.

    pub fn process_transfer(
        ...
    ) -> ProgramResult {
        ...
        if memo_required(&destination_account) {
            check_previous_sibling_instruction_is_memo()?;
        }
        ...
    }

Attention

As a protocol developer, if your contract supports Token-2022 transfers, you’ll consider whether to handle by ensuring a Memo IX added before each Transfer IX for memo-enabled token accounts or not. Otherwise, if a memo-enabled token account is used as a destination account, the transfer process will fail, potentially disrupting protocol’s functionality and effecting user experience.

4. Interest-Bearing Tokens

Interest-Bearing Tokens is an extension in Token-2022 that pertains to token interests and UI amount. By using this extension in combination with the AmountToUiAmount and UiAmountToAmount instructions, developers can convert between raw amounts and UI amounts.

Attention

Hardcoded Formula

This extension uses a fixed formula to calculate interests based on the timestamp. The extension cannot be applied when the interests calculation formula expected by developers for this mint differs from it or the interests is calculated based on a unit except the timestamp (e.g., based on slots).

For example, when converting the raw amount to the UI amount, the following formula is utilized in the extension:

Developers need to confirm whether this is consistent with the conversion rules expected in your project or not.

Unstable Network

Due to network instability on Solana (such as occasional congestion), the actual timestamp during execution may deviate, resulting in accumulated interests that may not match the expected value.

Since the Bank Timestamp Correction was updated in May 2022, clock drift issues have been significantly improved, except for timestamp jumps caused by temporary block production halts.

In summary, developers should use this extension only after verifying that it aligns with the project’s requirements. The project should not overly rely on the conversion result provided by the IX, as it is simply a UI representation and does not guarantee consistency with the actual amount.

5. Transfer Fees

Transfer Fees is a crucial extension in Token-2022, offering built-in support for handling transfer fees.

When Transfer Fees is enabled for a Token-2022 mint, each transfer operation records its associated fee amount in the extension data of the recipient’s token account. These recorded fees are inaccessible to the recipient and are not included in the available balance of their token account.

If the mint’s transfer_fee_basis_points is greater than 0, the actual amount received by the receiver is less than the amount specified in the transfer IX after the process of transfer.

Attention

If the contract calling transfer_checked IX requires additional accounting, developers must consider how to account for the transfer fee. Counting this fee as part of the amount actually received by the receivers may lead to unexpected losses in various scenarios within protocol, contract, or user accounts.

A Negative Case

Let’s have a look at a simple case where a protocol fails to account for the transfer fee, leading to a loss:

The vault handles deposits and withdrawals for a Token-2022 mint with a 20% fee rate, and it currently has a balance of 1000 in its token account.

• Step 1: Alice deposits 100:

  • The vault calls the transfer_checked to move 100 from Alice’s token account to the vault.

    • Alice’s balance decreases by 100.

    • After the transfer fee is applied, the vault actually receives 80, bringing its balance to 1080.

  • The vault logs Alice’s deposit as 100.

• Step 2: Alice withdraws 100:

  • The vault confirms Alice’s balance is at least 100 and logs her withdrawal of 100.

  • The vault calls the transfer_checked to send 100 from its token account back to Alice.

    • After the transfer fee, Alice receives 80, increasing her balance by 80.

    • The vault’s balance decreases by 100, leaving it with 980.

In this example, after Alice’s deposit and withdrawal, the vault ends up losing 20 units (1000 - 980 = 20). This is because the vault didn’t account for the Token-2022 transfer fee during its bookkeeping, causing an unintended loss.

The Difference Between fee and inverse_fee

In a specific scenario, the program needs to utilize the post amount (after deducting the fee from original transfer amount, i.e., pre amount) to determine the fee required for the actual transfer. The SPL struct spl_token_2022::extension::transfer_fee::TransferFee includes methods like calculate_inverse_fee and calculate_pre_fee_amount to meet this requirement.

It is worth noting that the calculate_fee method in TransferFee is commonly used to compute the transfer fee for the transfer_checked IX. However, calculate_inverse_fee is not a strict inverse operation of calculate_fee. The relationship of these two operations is:

calculate_fee(amount_in) >= calculate_inverse_fee(amount_in - calculate_fee(amount_in)) 

Here are some specific links for additional reference:

• For a detailed implementation of these functions, please check this code link.

• For a discussion on the relationship between these two operations, refer to this Github PR.

Here is an example dataset to illustrate the inequality mentioned above.

Let’s start by defining all input parameters that will be utilized throughout the following computation.

// Transfer Amount
amount_in : 5238206430131997821

// Transfer Fee Config
transfer_fee_basis_points: 1000
maximum_fee 5704976840628159154

By inputting this data into the SPL code's calculation method, the following results are obtained:

In this example, the difference between calculate_fee(amount_in) and calculate_inverse_fee(amount_in - calculate_fee(amount_in)) is 523820643013199783 - 523820643013199782 = 1. This demonstrates that the two values can indeed be unequal.

Note: Although these two methods may yield slightly different fees, the corresponding post-amounts are identical. Which means, in the following pseudocode snippet, despite pre_amount_2 possibly is smaller than pre_amount_1, post_amount_1 and post_amount_2 are always equal:

post_amount_1 = pre_amount_1 - calculate_fee(pre_amount_1)
pre_amount_2 = calculate_pre_fee_amount(post_amount_1)
post_amount_2 = pre_amount_2 - calculate_fee(pre_amount_2)
// Despite pre_amount_2 possibly being smaller than pre_amount_1, 
post_amount_1 == post_amount_2

Given this potential discrepancy, developers should avoid interchanging fees derived from these two methods to prevent unexpected issues.

If project has a specific requirement to reverse the inequality mentioned above, i.e.,

calculate_fee(amount_in) <= calculate_inverse_fee(amount_in - calculate_fee(amount_in)) 

There is one possible solution: In the calculate_pre_fee_amount method of struct spl_token_2022::extension::transfer_fee::TransferFee, adjust the algorithm for calculating raw_pre_fee_amount by modifying the calculation formula as follows:

For the mathematical proof, please check the appendix at the end of this article.

The Expected Transfer Fee

For contracts or users who want to ensure that the fee charged during a transfer aligns with their expectations, they can use the transfer_checked_with_fee IX provided by Token-2022.

This IX ensures that the transfer will only succeed if the correct fees are specified to help to prevent any unexpected issues during the transfer process.

Transfer Fee Effective Time

Token-2022 includes a security feature that delays fee configuration updates.

When a new Fee configuration is set, it doesn’t take effect immediately; instead, it becomes active after 2 epochs (around 4 days). During this period, the previous fee configuration remains in place. This delay serves as a safeguard for users, protecting them from potential financial losses due to frequent fee adjustments.

For developers updating the fee configuration, it is important to keep in mind that the old fee settings will continue to apply during the 2-epoch transition period before the new settings come into effect.

The getTransferFeeConfig IX and getEpochFee IX can be used to check the current transfer fees for a given mint in the current epoch.

The Maximum Fee

The maximum_fee sets the upper limit for the fee charged per transfer. If it is not set, the default is 0, which effectively means no fees are charged during transfers.

When configuring or updating the fee config during development, it is important to ensure that the maximum_fee is properly set.

The Withheld Amount Synchronization

TransferFeeConfig.withheld_amount does not reflect real-time data. This value is stored in the mint account and is not automatically synchronized with the actual fees collected during transfers. Typically, the withheld_amount is less than the total transfer fees that have been collected.

You should invoke the HarvestWithheldTokensToMint IX, which manually updates the withheld_amount from a group of token accounts to synchronize this value.

This synchronization is optional.

Conclusion

In this post, we highlighted several extensions that are susceptible to security issues and provided detailed information on related security considerations.

Token-2022 is still at its early stages that lacks extensive publicly available security documentation. Despite the extension capabilities in Token-2022 are quite robust, notable security risks may be come with. Since extensions are directly tied to Mint and Token Accounts, many of these risks can pose significant threats to funds of users and projects.

Throughout our research, we devoted significant effort to studying the official Token-2022 documentation and SPL source code. Recently, we came across a blog by Neodyme, a well-known security research team in the Solana ecosystem, which also addressed security concerns related to Token-2022 extensions. Fortunately, many of our perspectives on the security of these extensions align with theirs. We are also looking forward to more research on Token-2022 security in the future to help the community build a more secure Solana ecosystem.

This is the second blog from Offside Labs regarding Token-2022 security best practices. Check out our last blog on:

Acknowledgements

We would like to thank the Meteora team, especially @sudoku_defi, for their valuable insights, which shaped the solution for calculate_inverse_fee.

Appendix

Mathematical Proof for Modified calculate_inverse_fee

Given x as the amount_in of transfer_checked IX and r as the transfer_fee_basis_points, where x and r are natural numbers satisfying 0 < r < 10000.

The post_amount satisfies following equation:

The function implementation for calculate_fee and calculate_inverse_fee can be represented as:

The modified calculate_pre_fee_amount can be represented as:

Now let’s prove the following inequation:

Proof:

The inequation is:

As calculate_fee is a monotonically increasing function of x, the inequality to be proved can be simplified to:

The proof follows:

Introduction

As Solana continues to evolve, users' demands for sophisticated and flexible token functionalities are growing. However, Token on Solana have so far only provided basic functionalities, which are unable to meet this increasing demand.

In response, Solana has introduced Token-2022, a suite of enhanced features designed to expand token capabilities within the ecosystem. Token-2022 is fully compatible with the existing SPL Token and extends native token features through nearly 20 Token Extensions.

There is not much publicly available material on the types of security issues. The purpose of this series of articles is to shed light on the secure development, helping Solana developers avoid potential security risks while implementing support for Token-2022.

This first article of our series will discuss the following 3 topics. And we hope you can pay extra attention to the Attention section in each topic.

• Security risks across various stages of Account Lifetime

• Commonly confused terms between SPL Token and Token-2022

• Best practices for securely using Token-2022 in Anchor

How to secure accounts during its whole lifetime?

Following the design principles of Solana Account Model, the extensions in Token-2022 are built around the Token Account and Mint Account. Throughout the various stages of these Account Lifetimes, there exist several security risks to which developers must pay attention during both the design and implementation phases. We will illustrate these risks for Token Account and Mint Account respectively.

1. Token Account

As for the Token Accounts, the essential difference between Token-2022 and SPL Token is the addition of the extension data.

In terms of implementation, Token-2022 serves as a proper superset of SPL Token, maintaining the structural layout of Token Accounts while appending additional fields of Extension Data to the original Token Account.

The general structure is depicted as follows.

Here is a list with the extensions that could be appended to Token Account：

• Immutable Owner

• CPI Guard

• Required Memo on Transfer

• Non-Transferable Tokens

• Transfer Fees

• Transfer Hook

• Confidential Transfer

• Confidential Transfer Fee

We will examine the three stages of the Token Account lifecycle: creation, reallocation, and closure.

At each stage, there are potential security risks that developers should be aware of.

1.1. The Creation of Token Account

The size of Token Account in Token-2022 CAN differ from that of SPL Token, depending on the types and number of Extensions supported by the Mint and Token Account. Different sizes of Token Accounts will be created based on the number of Extensions supported. These accounts can take up more space than those in SPL Token, and their size will grow as additional extensions are added.

Attention

It is not recommended to hardcode a fixed space size for the Token Account or the minimum rent-exempt amount that the fixed space size requires, if you need to create a Token-2022 Token Account for a user at the runtime.

Vulnerable Case

The function below allows a Keeper to dynamically create a Token Account with Token-2022 support.

export const getCostToOpenTokenAccount = async () => {
  const cost = 0.00203928 * (10 ** 9);
  return cost;
};

A hardcoded SOL amount of 0.00203928 is used when creating the Token Account, which matches the rent needed for the 165 bytes required by a Token Account in the Token Program.

The problem arises when this Token Account needs to support Token-2022 extensions: the specified amount is insufficient to cover the extra space needed by Token-2022 account extensions, then the creation of Token Account will fail.

If the space size is determined by the user and the Backend Keeper is responsible for creating the Token Account, there will be a potential risk of the Keeper overpaying rent, resulting in financial losses.

Therefore, it is recommended to avoid having the Keeper create Token Accounts for users.

Recommendation

The @solana/spl-token library now offers API interfaces that assist in calculating the account length and the minimum rent requirement with extensions.

• getExtensionTypes: Returns all the extensions supported by the mint.

• getMinimumBalanceForRentExemptAccountWithExtensions: Calculates the minimum rent needed for a token account with extensions.

Here is an improved code snippet to mitigate the above issue.

export const getCostToOpenTokenAccount = async (mint) => {
    const extensions = getExtensionTypes(mint.tlvData);
    const rent = await getMinimumBalanceForRentExemptAccountWithExtensions(
      connection,
      [...extensions]
    );
    const cost = rent * (10 ** mint.decimals);
    return cost;
}

1.2 Reallocation

Some Account Extensions, such as Memo Transfer, can be added to a Token Account after its initial creation. Thus, the size of a Token Account may change dynamically.

To support the addition of new Account Extensions after the creation of Token Account, Token-2022 introduces a Reallocate IX that allows increasing the size of an existing Token Account to accommodate additional extension bytes.

Within the Reallocate IX, if it is determined that the current Token Account size already meets the necessary requirements, the process will return without further reallocation.

Attention

When reallocating a Token Account to a larger size, additional rent will be charged according to the number of additional bytes. It is essential to consider who will cover this extra rent during the development process, as overlooking this aspect could lead to the protocol or project covering unexpected costs.

In particular, for the APIs that may be used, it is important to carefully consider how to set values for these parameters.

• payer parameter in createReallocateInstruction

• payer parameter in reallocate

1.3. Closing the Token Account

A Token Account can be closed.

In SPL Token, a non-WSOL Token Account can be closed by the account.authority as long as account.amount == 0 is satisfied.

However, in Token-2022, some additional conditions must be met to close a Token Account:

• account.amount == 0

• If the close method is invoked in a CPI context and the Token Account has the CPI Guard extension enabled, the destination for the lamports must be the owner of Token Account.

• If the Token Account supports the Confidential Transfer extension, both pending_balance == 0 and available_balance == 0 must be true.

• If the Token Account supports the Confidential Transfer Fee extension, withheld_amount == 0 must be ensured.

• If the Token Account supports the Transfer Fee extension, withheld_amount == 0 must be ensured.

This is a simplified check flow in SPL:

Attention

If the contracts need to determine at runtime whether the criteria for closing a Token Account in Token-2022 are fulfilled, it is imperative that all the aforementioned conditions are satisfied. Otherwise, the Token Account cannot be closed directly.

Vulnerable Case

In the following contract code snippet, an attempt is made to close Token Account A when its amount is 0.

        if ctx.accounts.A.amount == 0 {
            close_account(CpiContext::new_with_signer(
                ctx.accounts.token_program.to_account_info(),
                CloseAccount {
                    account: ctx.accounts.A.to_account_info(),
                    destination: ctx.accounts.B.to_account_info(),
                    authority: ctx.accounts.B.to_account_info(),
                },
                signer_seeds,
            ))?;
        }

If A is a Token Account of Token-2022 that supports Transfer Fee extensions, and TransferFeeAmount.withheld_amount is larger than 0, then it cannot be closed and an error will be raised in close_account: AccountHasWithheldTransferFees: "An account can only be closed if its withheld fee balance is zero, harvest fees to the mint and try again". This error will cause the contract to fail to execute the IX because the condition TransferFeeAmount.withheld_amount == 0 was not checked when verifying if A meets the closing requirements.

The TransferFeeAmount extension provides closable method to check this condition to avoid raising the error. Similarly, the other extensions also provide closable method for checking.

Recommendation

The following examples show how to close Token Accounts with various extensions and illustrate how to verify whether these extensions are closable.

Cpi Guard

use solana_program::instruction::{get_stack_height, TRANSACTION_LEVEL_STACK_HEIGHT};
...
     if let Ok(cpi_guard) = source_account.get_extension::<CpiGuard>() {
         if cpi_guard.lock_cpi.into()
             && get_stack_height() > TRANSACTION_LEVEL_STACK_HEIGHT
             && !cmp_pubkeys(destination_account_info.key, &source_account.base.owner)
         {
             return Err(TokenError::CpiGuardCloseAccountBlocked.into());
         }
     }

Transfer Fee

   if let Ok(transfer_fee_state) = source_account.get_extension::<TransferFeeAmount>() {
       transfer_fee_state.closable()?
   }

Confidential Transfer

   if let Ok(confidential_transfer_state) =
       source_account.get_extension::<ConfidentialTransferAccount>()
   {
       confidential_transfer_state.closable()?
   }

Confidential Transfer Fee

   if let Ok(confidential_transfer_fee_state) =
       source_account.get_extension::<ConfidentialTransferFeeAmount>()
   {
       confidential_transfer_fee_state.closable()?
   }

You can refer to the links below for detailed code implementations.

• Transfer Fee

  • TransferFeeAmount: closable()

• Confidential Transfer

  • ConfidentialTransferAccount: closable()

• Confidential Transfer Fee

  • ConfidentialTransferFeeAmount: closable()

2. Mint Account

Similar to Token Accounts, Token-2022 maintains the structure layout of the Mint Account and appends additional Extension Data fields.

Layout diagram is provided below.

Here is a list with the extensions that could be appended to Mint Account：

• Non-Transferable Tokens

• Transfer Fees

• Transfer Hook

• Confidential Transfer

• Confidential Transfer Fee

• Mint Close Authority

• Default Account State

• Interest-Bearing Tokens

• Permanent Delegate

• Metadata Pointer

• Metadata

• Group Pointer

• Group

• Group Member Pointer

• Group Member

Next, let's examine the security risks associated with the Mint Account at its creation and termination stages that developers should be aware of.

2.1. Create Mint

Different from Token Accounts, Token-2022 requires all extensions to be created before initializing the Mint Account. This is because most Mint Extensions are closely related to the Mint's tokenomics and core functionality.

Here is the list of Mint Extensions:

• confidential transfer

• confidential transfer fee

• default account state

• group member pointer

• group pointer

• metadata pointer

• interest-bearing mint

• Transfer fee

• Transfer hook

• Immutable Owner

• Mint Close Authority

• Non Transferable

• Permanent Delegate

Furthermore, when initializing the Mint Account, additional checks are required due to predefined constraints among Mint extensions. For example:

• If the confidential transfer fee is enabled, the transfer fee and confidential transfer must also be enabled.

• If the transfer fee and confidential transfer are enabled, the confidential transfer fee must also be enabled.

Attention

Unlike Token Accounts, where extensions can be added after creation, all extensions for a Mint Account must be initialized before the Mint is created. Once a Mint Account is created, it is not possible to add new extensions.

This code snippet illustrates how to create a Mint with extensions.

    // List extensions to be added to the new mint
    const extensions = [ExtensionType.TransferFeeConfig];

    // Calculate length of mint
    const mintLen = getMintLen(extensions);

    // Transfer Fee Config Parameters
    const decimals = 9;
    const feeBasisPoints = 50;
    const maxFee = BigInt(5_000);
    // Calculate minimum rent for create the new mint account
    const mintLamports = await connection.getMinimumBalanceForRentExemption(mintLen);

    // Mint Creation IXs
    // 1. Create a raw mint account with calculated mintLen and mintLamports
    // 2. Create TransferFee Config and append this extension to the mint account
    // 3. Initialize Mint 
    const mintTransaction = new Transaction().add(
        SystemProgram.createAccount({
            fromPubkey: payer.publicKey,
            newAccountPubkey: mint,
            space: mintLen,
            lamports: mintLamports,
            programId: TOKEN_2022_PROGRAM_ID,
        }),
        createInitializeTransferFeeConfigInstruction(
            mint,
            transferFeeConfigAuthority.publicKey,
            withdrawWithheldAuthority.publicKey,
            feeBasisPoints,
            maxFee,
            TOKEN_2022_PROGRAM_ID
        ),
        createInitializeMintInstruction(mint, decimals, mintAuthority.publicKey, null, TOKEN_2022_PROGRAM_ID)
    );
    await sendAndConfirmTransaction(connection, mintTransaction, [payer, mintKeypair], undefined);

2.2. Close Mint

In SPL Token, Mint accounts cannot be closed.

However, in Token-2022, it is possible to close a Mint by applying the MintCloseAuthority extension.

Attention

MintCloseAuthority requires that Mint.supply == 0.

When the Mint is closable, the amount of all token accounts related to this mint should be zero at that time.

However, if the Mint is closed and re-created with a different purpose at the same address. Inconsistencies will arise if your project stores information related to the Mint Account. If your project stores mint information, be aware of this potential issue and consider redesigning the code to ensure that it consistently fetches data from the correct mint.

3. Summary

Some extensions in Token-2022 add data only to the Mint Account, some only to the Token Account, and others append data to both the Mint Account and the Token Account.

At the end of this section, we offer a brief summary that correlates these extensions with their respective accounts.

Token Twins: Are You Using the Right One?

Token-2022, being a proper superset of SPL Token, fully supports all 25 Token IXs with the same instruction layout and identical format.

In the following section, we outline several key differences between SPL Token and Token-2022 in the SPL.

transfer VS transfer_checked

In SPL Token, the spl_token::instruction::transfer method is used for mint transfer. However, in Token-2022, the transfer method has been deprecated.

/// Creates a `Transfer` instruction.
#[deprecated(
    since = "4.0.0",
    note = "please use `transfer_checked` or `transfer_checked_with_fee` instead"
)]
pub fn transfer(

The above code comments clearly indicate that it is recommended to use transfer_checked or transfer_checked_with_fee.

So, what issues might arise if you still uses the transfer method?

First, let’s review the definitions of the two suggested functions:

/// Creates a `TransferChecked` instruction.
#[allow(clippy::too_many_arguments)]
pub fn transfer_checked(
    token_program_id: &Pubkey,
    source_pubkey: &Pubkey,
    mint_pubkey: &Pubkey,
    destination_pubkey: &Pubkey,
    authority_pubkey: &Pubkey,
    signer_pubkeys: &[&Pubkey],
    amount: u64,
    decimals: u8,
) -> Result<Instruction, ProgramError> {
...
}

/// Create a `TransferCheckedWithFee` instruction
#[allow(clippy::too_many_arguments)]
pub fn transfer_checked_with_fee(
    token_program_id: &Pubkey,
    source: &Pubkey,
    mint: &Pubkey,
    destination: &Pubkey,
    authority: &Pubkey,
    signers: &[&Pubkey],
    amount: u64,
    decimals: u8,
    fee: u64,
) -> Result<Instruction, ProgramError> {
    ...
}

The changes could be found from diffs in transfer vs transfer_checked and transfer vs transfer_checked_with_fee.

From the diff result, we have the following observations:

• transfer_checked has 2 additional parameters compared to transfer: mint_pubkey and decimals.

• transfer_checked_with_fee has 3 additional parameters compared to transfer: mint, decimals, and fee.

By reviewing the implementation of the transfer IX in Token-2022 program, it becomes clear that use of transfer may result in failure if the Token Account supports the Transfer Hook or Transfer Fees extensions, as these would prevent the transfer from being completed.

    /// Processes a [Transfer](enum.TokenInstruction.html) instruction.
    pub fn process_transfer(
        program_id: &Pubkey,
        accounts: &[AccountInfo],
        amount: u64,
        expected_decimals: Option<u8>,
        expected_fee: Option<u64>,
    ) -> ProgramResult {
        ...
        let expected_mint_info = if let Some(expected_decimals) = expected_decimals {
            Some((next_account_info(account_info_iter)?, expected_decimals))
        } else {
            None
        };
        ...
        let (fee, maybe_permanent_delegate, maybe_transfer_hook_program_id) =
            if let Some((mint_info, expected_decimals)) = expected_mint_info {
                ...
            } else {
                // Transfer hook extension exists on the account, but no mint
                // was provided to figure out required accounts, abort
                if source_account
                    .get_extension::<TransferHookAccount>()
                    .is_ok()
                {
                    return Err(TokenError::MintRequiredForTransfer.into());
                }
                // Transfer fee amount extension exists on the account, but no mint
                // was provided to calculate the fee, abort
                if source_account
                    .get_extension_mut::<TransferFeeAmount>()
                    .is_ok()
                {
                    return Err(TokenError::MintRequiredForTransfer.into());
                } else {
                    (0, None, None)
                }
            };
        ...

The code shows that when the transfer function is invoked with expected_decimals set to None, it triggers the else branch in the code snippet. If the Token Account supports Transfer Hook or Transfer Fees, the transfer function will immediately return a MintRequiredForTransfer error and exit.

Attention

It is recommended to stop using transfer in Token-2022 and use transfer_checked and transfer_checked_with_fee instead.

The full rust crate path for methods:

• transfer_checked: spl_token::instruction::transfer_checked

• transfer_checked_with_fee: spl_token_2022::extension::transfer_fee::instruction::transfer_checked_with_fee

Two wSOLs

In SPL Token, the account ID for WSOL is So11111111111111111111111111111111111111112.

Token-2022 has introduced a new WSOL with the account ID 9pan9bMn5HatX4EJdBwg9VgCa7Uz5HL8N1m5D3NdXejP.

Attention

If your contract needs to special handling WSOL, it is important to distinguish WSOL between SPL Token and Token-2022.

As of September 2024, the WSOL in Token-2022 has very little trading activity, so WSOL usually refers to the SPL Token's So11111111111111111111111111111111111111112.

For some DeFi platforms, where SOL/WSOL assets carry specific importance, it is advisable to blacklist the Token-2022 WSOL address to avoid any potential ambiguity.

The Different Program ID

SPL Token Program and Token-2022 Program are separate programs, each with a different Program ID.

• SPL Token Program ID: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

• Token-2022 Program ID: TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb

Attention

In some Solana SDK interfaces, if the corresponding instructions work for both SPL Token and Token-2022, the SPL Token program is typically used as the default program ID parameter.
For example, here's the declaration of the createAssociatedTokenAccountInstruction function in the solana/@spl_token SDK:

export function createAssociatedTokenAccountInstruction(
    payer: PublicKey,
    associatedToken: PublicKey,
    owner: PublicKey,
    mint: PublicKey,
    programId = TOKEN_PROGRAM_ID,       // <---- SPL Token Program ID
    associatedTokenProgramId = ASSOCIATED_TOKEN_PROGRAM_ID
)

When using these SDK interfaces, developers should clearly identify which Token program they need to call.

How to Integrate Token-2022 into an Anchor Project?

Anchor, the most popular development framework on Solana, supports Token-2022 by providing various types and IX wrappers. Developers could utilize these types and methods provided by Anchor.

Types

Here is a summary of the type definitions and the SPL Token Program types they support:

We have some observations from the table:

• Types under the token_interface path are compatible with both the SPL Token Program and the Token-2022 Program.

• Types under the token path are only compatible with the SPL Token Program.

• Types under the token_2022 path are exclusively for the Token-2022 Program.

Attention

When developing, it is crucial to decide whether the contract needs to support Token-2022.

• If Token-2022 support is required, it is recommended to use the types under anchor_spl::token_interface.

• If Token-2022 support is not needed, it is recommended to use the types under anchor_spl::token::Token.

If your contract does not intend to support Token-2022 but uses types from the anchor_spl::token_interface path, it could lead to unexpected issues due to ambiguity.

Conclusion

This is our first article on Token-2022 series, based on our experiences from dozens of Token-2022-related audits. The article highlights potential security risks in Token-2022 accounts during development. Developers should be cautious, as improper design or implementation can lead to significant threats to project security.

In the next article, we will dive deeper into Extensions in Token-2022 that could affect the security of funds for both projects and users. Stay tuned for more insights.

Recently, there’s been a surge in sophisticated phishing attacks targeting Solana users, bypassing even the most secure wallet protections. While users authorize transactions with a simple click, they may unknowingly approve malicious activities.

These attacks exploit the hidden complexities of wallet interactions, putting funds at risk. We’ll reveal how these attacks work, share real-life cases, and provide tips to help you stay safe.

The Hidden Dangers of Wallet Interactions

Imagine a scenario where your wallet shows you’re about to make a swap on Jupiter, but in reality, you’re unknowingly authorizing a malicious transaction that could drain your entire account. This isn’t just a hypothetical situation – it’s a growing threat in the Solana ecosystem.

Every day, countless users interact with their Solana wallets, authorizing transactions with a simple click. But what really happens behind the scenes once you hit that “Sign” button? The truth is, there’s much more going on than meets the eye.

In recent weeks, the community has witnessed a disturbing trend: sophisticated phishing attacks targeting Solana users that bypass even the most robust wallet security measures. As we delve deeper, we'll uncover the “black magic” behind these attacks, explore real-world cases, and arm you with the knowledge to protect yourself.

Drainer Alert: A Series of Sophisticated Attacks

The alarm bells started ringing a few weeks ago when the Jupiter Team forwarded reports of suspicious hacking incidents from multiple victims. With no clear indication of the root cause and new victims coming every few hours, we found ourselves in a race against time to uncover the grifter's hiding place before more users got drained.

A pattern quickly emerged among the victims: they were Solana users using the Phantom wallet via a Chrome extension on Windows. These attacks weren’t limited to a specific DeFi protocol but were identified on various platforms, including Jupiter products and Raydium.
From these incidents, we could draw a few important conclusions:

• The attack method was not widespread, as the number of victims was not explosively increasing.

• These attacks were not targeting specific users, because the victims appeared to be random and not exclusively “whales”.

• The vulnerability didn’t seem to be tied to a specific DeFi product but appeared to be related to the Phantom browser extension wallet.

• The attacker had no direct control of the victim’s wallet or private keys because the attacks were only triggered by user interactions.

As we delve deeper into this mystery, we invite you, our fellow sleuths, to join us in tracing the root causes. What theories or ideas come to your mind, Sheriff Cat?

Solana Transactions Basics

Unpacking a Solana Transaction

To comprehend the sophistication of these attacks, we first need to understand the structure and workflow of a typical Solana transaction. A Solana transaction is a compact but powerful data structure that encapsulates all the information needed to execute a set of actions on the blockchain. Let’s break down its components:

• Signatures: A list of signatures, one for each signer required by the transaction. These signatures cryptographically prove that the signers authorize the transaction.

• Message: The core content of the transaction, containing:

  • Header: Includes metadata such as the number of required signatures and the number of read-only account references.

  • Account Addresses: A list of all accounts that will be read from or written to during transaction execution.

  • Recent Blockhash: A recent blockhash to prevent transaction replay and ensure freshness.

  • Instructions: The actual commands to be executed. Each instruction within the transaction message contains the following:

    • Program ID: The address of the program that will process this instruction.

    • Accounts: A list of accounts involved in this specific instruction.

    • Instruction Data: Arbitrary byte array interpreted by the program.

The Lifecycle of a Token Swap

Let’s take a common scenario like token swapping on Jupiter as an example. When you initiate a swap on Jupiter, several steps occur behind the scenes. First, Jupiter fetches the current token price for your reference. It then queries its backend to determine the most efficient routing for your swap. With this information, the front end assembles the routing details into a series of instructions that will form the transaction.

Once the instructions are assembled, an unsigned transaction is created and submitted to your connected wallet. At this point, your wallet plays a crucial role in security. It typically queries a backend service for simulation results (more details covered in the next section), allowing it to predict the outcome of the transaction. Based on these results, the wallet prompts you, the user, for confirmation. If you approve, the wallet signs the transaction and submits it to an RPC client, which then broadcasts it to the Solana network for confirmation.

“Unlimited Approval” as a Signer

On Solana, signing a transaction grants full authority over your account for that transaction’s scope. This is similar to “unlimited approval” in Ethereum, but with a key difference: it happens automatically with every signature.

When you sign, you authorize the transaction to act on your behalf for all included accounts. This means a single signature can permit multiple actions, including unexpected token transfers, without additional prompts. In the context of a malicious attack, this could allow a bad actor to include harmful instructions that appear legitimate to the user!

Case Study – Anatomy of a Malicious Transaction

To illustrate this, let's examine a malicious transaction we encountered during our investigation. Transaction 5krgaq2FTZAp9CT1X1ue4dY7JV2rSVYeNLQFgHjWKFcyTE88wU54KWKhvuzcG4Fm6bfdByk1ngiyewcjLydWc93d appeared to be a standard token swap on the surface.

However, upon closer inspection, we discovered additional instructions embedded within the transaction.

These malicious instructions were made to steal funds and take control of the victim’s token account while pretending to be part of the normal swap process.

Default Safeguard: Transaction Simulation

Modern wallets like Phantom usually utilize embedded analyzers to provide users with comprehensive information before signing. Transaction simulation is a critical feature that allows the wallet to predict transaction outcomes before execution.

Phantom Wallet employs this measure in partnership with Blowfish, a specialized analysis provider, as stated in their blog:

Secure transaction scanning
We scan transactions and messages with Blowfish. If we find anything fishy, we warn you via a pop-up alert so you can take a closer look, and if necessary, avoid the transaction altogether. If we can’t simulate it, we’ll return you to the normal confirmation flow. If something is wrong, we break out of Auto-Confirm and alert you.

When a user initiates a transaction in Phantom, the unsigned transaction is sent to Blowfish’s servers for simulation in a controlled environment. This process can identify various threats, including unexpected token transfers, interactions with suspicious smart contracts, potential rug pulls, and abnormal slippage in DEX transactions.

However, simulation has limitations. As we’ll see in our case study, sophisticated attacks can still bypass these checks through clever programming and exploitation of simulation constraints.

Case Study – Examining a Simulation Log

We were quite confused as to why the built-in transaction simulation did not protect the victims. Luckily, a sample of a victim’s simulation provided by Blowfish confirmed our guess: the simulation failed to reveal the malicious behaviors.

In the log, the malicious program did not execute long or consume many compute units:

“Program  5UMucMksJweA1AtgyxrK8DJeBXr3DQGEGRs5Kkq2pZjr invoke [1]”,
“Program  5UMucMksJweA1AtgyxrK8DJeBXr3DQGEGRs5Kkq2pZjr consumed 1106 of 102657 compute  units”,
“Program  5UMucMksJweA1AtgyxrK8DJeBXr3DQGEGRs5Kkq2pZjr success”

However, the on-chain log shows different traces:

Program  5UMucMksJweA1AtgyxrK8DJeBXr3DQGEGRs5Kkq2pZjr invoke [1]
Program  11111111111111111111111111111111 invoke [2]
Program  11111111111111111111111111111111 success
Program  TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA invoke [2]
Program log: Instruction:  SetAuthority
Program  TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA consumed 2875 of 97266 compute  units
Program  TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA success
Program  5UMucMksJweA1AtgyxrK8DJeBXr3DQGEGRs5Kkq2pZjr consumed 8480 of 102668 compute  units
Program  5UMucMksJweA1AtgyxrK8DJeBXr3DQGEGRs5Kkq2pZjr success

So, what happened in this program 5UMucMksJweA1AtgyxrK8DJeBXr3DQGEGRs5Kkq2pZjr?

Unmasking the Malware: Reverse Engineering

Executable Program Accounts on Solana

On Solana, smart contracts are deployed as executable program accounts. These accounts store the compiled bytecode of the program, which can be executed by the Solana runtime. Unlike Ethereum’s EVM bytecode, Solana programs are compiled to BPF bytecode, which is a nightmare for reverse engineering.

Our target program is 5UMucMksJweA1AtgyxrK8DJeBXr3DQGEGRs5Kkq2pZjr. The program content could be dumped via Solana’s built-in command:

$ solana program dump 5UMucMksJweA1AtgyxrK8DJeBXr3DQGEGRs5Kkq2pZjr a.elf -u https://api.mainnet-beta.solana.com
Wrote program to a.elf

$ file a.elf
a.elf: ELF 64-bit LSB shared object, eBPF, version 1 (SYSV), dynamically linked, stripped

Now we have an ELF file containing BPF bytecode.

Reverse Engineering like an OtterSec Pro

Reverse engineering a program in a nontraditional instruction set is never a trivial task. Luckily, we could stand on the shoulders of pioneers: OtterSec has open-sourced their amazing eBPF decompiler plugin for reverse engineering!

The decompiled pseudo c code is like this:

As we mentioned earlier, the program in simulation consumed much fewer computing units. We suspected an early exit was triggered somewhere and we found these suspicious constant comparisons and “goto label_100000718” jumps, as shown above.

A deeper analysis reveals that variable r7 here points to the array of input accounts, with each size being 0x30 bytes. Thus r7 + 0x30 is account #2, r7 + 0x60 is account #3. Dereferencing the first pointer in an account is reading its key.

The four magic numbers 0x4d702b828d0f0a6e, 0x2a8e185ab7b764da, 0x7752c6d53f4d424b, and 0xef7a7aa1ace0d9, make up a 256-bit big number 0x6e0a0f8d822b704dda64b7b75a188e2a4b424d3fd5c65277d9e0aca17a7aef00, which is exactly the raw representation of account 8QYkBcer7kzCtXJGNazCR6jrRJS829aBow12jUob3jhR!

The program rejects any invocation with mismatching account #2. But what makes its on-chain behavior deviate from the simulation? Let’s take a deeper look at the last “goto” jump.

Function sub_100003120(account #3) just dereferences and loads the lamports field of account #3. If it’s zero, the program silently exits. (Check the definition of AccountInfo struct here)

Thus the balance (lamports) of the third input account, is the key to the backdoor!
Checking the corresponding account BKW62NtBeQJkjbBdh61WNfpfuT6ai34pU1eX4QPjxQyW in our case, only three consecutive transactions are recorded.

The first transaction (last in the picture) deposited SOL into account BKW6. The final transaction zeroed account BKW6 and tipped Jito. The malicious transaction was “sandwiched” by the others, just like quickly turning the switch on and off. In this way, the malicious behavior can only be triggered in a very narrow time window, never in the simulation, nor even after the execution.

Crime Scene Investigation

The Suspected Extension: Bull Checker

Upon further investigation of several affected users who have been drained by the same program, we have identified an extension called “Bull Checker”, which has the permission to read and change all the data on the website, as a potential cause.

Bull Checker is supposed to be a read-only extension that allows you to view the holders of memecoins. There should be no need for an extension like this to read or write data on all websites.

This should have been a major red flag for users, but apparently, several users continued to install and use the extension.

Targeting Memecoin Traders

In addition to the above information, while researching “Bull Checker” we discovered that it was publicized by an anonymous Reddit account, “Solana_OG” (now deleted). This person appeared to target users looking to trade memecoins and lured them to download the extension.

Spoofing Workflow Revealed

The extension has now been removed from the Chrome Web Store. We can find the cached stats here. The bundled files can be extracted by unzipping the extension as a zip file. These files are compressed but not heavily obfuscated and can be recovered using JavaScript beautifier tools.

The prettified `pha.292c2974.js` contains suspicious code related to the Phantom wallet. Since it can read and change data on all websites, it actively monitors apps containing the wallet adapter.

It replaces the wallet adapter’s signTransaction method with its own implementation. If it detects a “simple” transaction with only one signer, it forwards this unsigned message to a remote server through an encrypted channel. On the server side, it determines the token accounts owned by the victim to take over, generates a fresh “switch” account for the victim, and then appends the drainer instruction to the original unsigned transaction.

The modified transaction is then submitted to Phantom for user confirmation. Once approved, the signed transaction is immediately sent to the server again. The server broadcasts the “sandwiched" transaction in a Jito bundle to ensure the drainer in the backdoor is exactly triggered on-chain.

Stop Spoofing and Stay Safe

Through collaborative efforts with Jupiter, Blowfish, Raydium, Phantom, and Offside Labs, we have uncovered the root cause of this series of crypto thefts. The Bull Checker extension has been removed, and the associated program account has been labeled as malicious.

While we have identified one malicious extension, there might still be other malicious extensions out there. There have been reports of other drains that we have not been able to track down. It’s crucial to maintain a healthy skepticism, even towards seemingly popular recommendations on social media platforms. Do not trust something just because someone mentioned it on Reddit or other media and it has many upvotes. Stay away from those “Solana OG”. Astroturfing and social engineering are very real.

Extensions that request extensive permissions are highly suspicious. An extension like Bull Checker should not need to read and modify all your website data. You should have an extremely high degree of confidence in an extension before you start using it.

Fortunately, there are ways to mitigate similar spoofing issues in the future. Unlike Ethereum, Solana transactions predeclare all accessed accounts in the message header before signing. This feature allows wallets and simulation-based analyzers to detect unusual patterns or unknown program invocations, potentially raising alarms regardless of whether the execution triggers malicious behavior.

In addition, Blowfish has released a new guard instruction feature called SafeGuard that prevents all simulation spoofing attacks. It’s currently being adopted by multiple Solana wallets and will prevent future such attacks.

Conclusion

This investigation has been an insightful journey, made possible through close collaboration with the Jupiter team. We extend our sincere gratitude to the teams at Blowfish, Raydium, and Phantom for their invaluable assistance throughout this process.

It's been a privilege to work alongside these dedicated teams, all of whom share a common mission: prioritizing the security of every user in the web3 ecosystem. This commitment aligns perfectly with our core values at Offside Labs.

As we conclude this investigation, we urge all users to remain vigilant in the face of evolving threats. The crypto landscape is dynamic, and new challenges will undoubtedly emerge. Remember to always verify, question, and stay informed. Keep watching for updates from Offside Labs as we continue our mission to enhance blockchain security.

Stay safe, stay curious, and keep an eye out for the Offside!

In this blog post, we reveal an issue in the Trader Joe v2 Liquidity Book. This flaw lets arbitragers perform swaps without paying fees, allowing them to reclaim a portion of the fees meant for existing liquidity providers. As a result, arbitragers can swap tokens without any cost.

Who’s Trader Joe?

To understand the flaw, let's first introduce the core concepts of Trader Joe v2. Trader Joe v2 Liquidity Book (LB) is a decentralized exchange that offers concentrated liquidity. It uses the Constant Sum Market Maker Function, which means liquidity is stacked vertically across different bin arrays. This setup aims to improve trading efficiency and maximize rewards for liquidity providers.

In JOE LB, token X is called the Base Asset, and token Y is called the Quote Asset. Price P is defined as the amount of the quote token you supply (Δy) compared to the amount of the base token (Δx) you can get.

Since the price of each individual bin Pi is the same, the liquidity of each bin is defined as

Bin Composition (c), or composition factor/ratio, denotes the ratio of the remaining quote token in the current active bin.

Fee Accounting in JOE v2

There are two types of fees charged in JOE v2: the normal swap fee and the composition fee.

Normal Swap Fee

Swapping tokens in the JOE v2 Liquidity Book incurs a certain amount of fees. The basic rate applied to the total swap amount is defined as fs:

Here, fb​ is a fixed rate, and fv​ is a variable rate used to measure market volatility. For the purposes of this blog post, we can safely assume that fs​ is a fixed percentage for normal swaps.

Composition Fee

Another situation that requires fee accounting is when liquidity providers increase their positions in the current active bin.

Why do we need to charge fees when adding liquidity?

Remember that the liquidity of a certain bin with price Pi is defined as L = Pi · x + y. So, the liquidity for a given bin can be directly calculated from the amount of each token and is not related to the bin composition c. In theory, we can add some tokens x and y with a random composition rate to serve as supplied liquidity.

Liquidity providers (LPs) supply liquidity to a specific bin with a certain ratio of trading tokens. However, the ratio of tokens in the liquidity supplied by LPs can differ from the original ratio of tokens in that bin. A composition fee should be charged for this discrepancy between the composition of the supplied liquidity and the composition of the bin itself.

Demo - Why Charge a Composition Fee?

Here is a demo showcasing a liquidity provider, Alex, supplying liquidity into the bin with a different composition factor:

1. Assume the current bin's liquidity L' is purely composed of token Y (rounded rectangle in green shadow with solid border), resulting in the bin composition ratio c equals 1.

2. Now Alex adds liquidity ΔL into the current bin's liquidity. ΔL is purely composed of token X (in purple shadow with a solid border). After that, the total liquidity increases to L' + ΔL and the bin composition c decreases to 0.3 (for demonstration purposes). It implies that Alex gains a 70% share of the current bin's liquidity.

3. Immediately after adding liquidity, Alex decides to remove his 70% share. When liquidity providers (LPs) burn their shares, they should be rewarded with a proportionate amount of the total bin reserves based on their share. Thus, Alex receives 70% of both token X and token Y in the bin reserve (dotted border).

4. In the end, the liquidity of the current bin is still L'. Essentially, it is equivalent for Alex to just swap 70% of token Y for token X in the original bin.

If Alex is not charged any fees for his initial liquidity entrance, he effectively performs a swap without incurring a fee. This scenario highlights the importance of charging composition fees in preventing such fee-less arbitrage opportunities.

Charging the Composition Fee

Trader Joe v2 does its best to empower its liquidity providers to add liquidity with a random composition rate. It swaps LPs' liquidity to a target ratio and charges an extra composition fee fc:

where fs is the original fee being charged as if it is a normal swap.

In short, the actual composition fee rate fc is a bit higher than the normal swapping fee rate, which is somewhat reasonable because it is a pretty convenient and practical utility for LPs.

According to Trader Joe v2's whitepaper:

Liquidity that is added to the active bin will automatically be swapped across reserves if the composition is not equal to the bin’s composition. The amount swapped is calculated so that the resulting assets in the bin equal those that would result if the user were to swap prior to adding liquidity. The amount swapped incurs a fee that approximates the current market swap fee.

As JOE v2 does not perform the actual swap, it acts as if the provided liquidity ΔL is swapped to a target composition and charges the corresponding swap amount by the composition fee rate.

Compensation from Composition Fees

Now let's go back to the arbitrager Alex. When Alex adds his liquidity ΔL, a subtle amount of extra fee (in yellow shadow) is deducted from the input X, remaining amountsIn to be calculated as the effective liquidity amount that Alex provides.

Assume there's a target composition rate c' that is a bit larger than 0.3 (the final composition).

To absorb Alex's liquidity with a different composition, Trader Joe v2 first swaps the original liquidity L' to the target composition c' with no fee. Then Alex also swaps his liquidity ΔL to the target composition c' with some composition swap fee.

Since all quote token Y in the final liquidity bin is composed of existing tokens Y in the original liquidity bin, the following equation holds true:

After the swap, the amount of token X in the original liquidity equals the amount of token Y that Alex swapped:

At this point, there is no further obstacles for Alex to enter his liquidity. Since the composition factor c' is the same, adding liquidity is literally the same to adding the corresponding trading token pair.  

Implementation and the Hidden Flaw

So that's all for composition fee accounting when adding liquidity. It's time to cast light on Trader Joe v2's actual implementation, including the flaw.

In the case of entering liquidity, _mintBins() will be called by the public mint() function and for each bin in the LP's provided range, _updateBin() is called to calculate LP's share for this bin.

function _updateBin(...) returns (uint256 shares, ...) {
    ...

    (shares, amountsIn) = binReserves.getSharesAndEffectiveAmountsIn(...);

    if (id == activeId) {
        ...

        bytes32 fees = binReserves.getCompositionFees(...);

        if (fees != 0) {
            uint256 userLiquidity = amountsIn.sub(fees).getLiquidity(price);
            uint256 binLiquidity = binReserves.getLiquidity(price);

            shares = userLiquidity.mulDivRoundDown(supply, binLiquidity);
            ...
        }
    }

    ...
}

• getSharesAndEffectiveAmountsIn() calculates the corresponding share shares for LP's added liquidity and the actual trading token reserve change amountsIn.  

• getCompositionFees() calculates the corresponding composition fee for the swap to the target composition factor.

• the final LP's shares is userLiquidity / binLiquidity

Impact of Fee Misallocation

The subtle insight is that the composition fee for the swap is not involved in the share calculation. Three parts make up the total liquidity of the bin: binLiquidity, userLiquidity and fee. However, the liquidity provider’s share is simply put as userLiquidity / binLiquidity.The left-alone fee, which should only be claimable by existing liquidity providers, now is silently shared across all liquidity providers.

The correct way to calculate LP’s share is userLiquidity / ( binLiquidity + fee)

Alex, who entered 70% liquidity in our previous example, will be able to have a 70% discount on the swap fees he has just paid. In an ideal situation when userLiquidity / binLiquidity is large enough, like +∞, all composition fees will be returned to the LP. Arbitrager will be able to perform fee-free swaps by first entering and then immediately withdraw liquidity.

Fixing

The correct implementation is to put the composition fee into share calculation. Since the composition fee is reserved for the previous LPs, the fee parameter should also be accounted for in the denominator:

In commit 7e5b0b494, the Trader Joe Team has already fixed this issue:

if (fees != 0) {
    uint256 userLiquidity = amountsIn.sub(fees).getLiquidity(price);
-   uint256 binLiquidity = binReserves.getLiquidity(price);

-   shares = userLiquidity.mulDivRoundDown(supply, binLiquidity);
    bytes32 protocolCFees = fees.scalarMulDivBasisPointRoundDown(parameters.getProtocolShare());

    if (protocolCFees != 0) {
        amountsInToBin = amountsInToBin.sub(protocolCFees);
        _protocolFees = _protocolFees.add(protocolCFees);
    }

+   uint256 binLiquidity = binReserves.add(fees.sub(protocolCFees)).getLiquidity(price);
+   shares = userLiquidity.mulDivRoundDown(supply, binLiquidity);

    parameters = _oracle.update(parameters, id);
    _parameters = parameters;

After calculating the protocolCFees, which is reserved for the protocol itself, the code adds fees.sub(protocolCFees) to the binLiquidity. This step ensures that only the fees excluding the protocol fees are added to the liquidity pool. Then, it calculates the user's actual share of the liquidity pool. This process is precisely how it is intended to function.

Timeline

• 2023-11 Reported the issue to the Trader Joe v2 on Immunefi.

• 2024-07 the Trader Joe Team has fixed this issue in commit 7e5b0b494.

Reference

• Joe v2 Whitepaper

During Black Friday sales, he purchased several hardware wallets at a discount and sent me a OneKey Mini for my security expertise. As a new Web3 hacker with extensive experience in Web2, I don't trust the security of anything without thorough investigation.

Together with my colleagues at Offside Labs, we delved into hardware wallet vulnerability research and discovered significant security issues. In this blog post, we will share the first journey and findings of our research.

What We Learn

So what is a hardware wallet? A Hardware Wallet is a specialized device designed to secure digital currencies. Hardware wallets store sensitive information, like recovery mnemonics, within the secure computational compents of the device. Private keys are never exposed to the internet, thus reducing the risk of online threats and keeping your assets secure.

Trezor is a famous hardware wallet manufacturer that I knew about even before the commence of my web3 research. It is an actively maintained open-source project and it has been forked by many other competitor wallet manufacturers. OneKey also forked Trezor's repository for their own products.

As a hardware wallet project which was launched 12 years ago, I am pretty confident that I can easily find some previously discovered vulnerabilities. I took some time to make an investigation on its topic and summarized the following attack surfaces of hardware wallets.

• Trezor Side-channels. Prior to firmware version 1.3.1 (around 2015), Trezor was vulnerable to side-channel attacks leveraging information obtained from power fluctuations during the public key computation process. I read abount this attack surface from Jochen-Hoenicke's blog

• Trezor Secrets from SRAM. Some old version of Trezor failed to wipe out the content of SRAM when the hardware wallet is rebooted, so hackers are capable to recover some sensitive information. Saleem Rashid detailed a process of leaking private secrets from SRAM by doing hardware reset.

• KeepKey Glitching. STM32 has a security mechanism known as Read Protection (RDP). Wallet.Fail and Chip.Fail demonstrated that downgrading RDP can reliably be performed at boot with voltage glitching. Once a device is at RDP1, its SRAM can be read out. You can ead more about this attack surface on Kraken's blog post.

• KeepKey Buffer Overflow. Christian Reitter has an excellent series of blog post on a serious buffer overflow vulnerability in the KeepKey hardware wallet. In specific versions of arm-none-eabi-gcc, the stack canary code is incorrectly generated, resulting in a fixed canary value that can be easily bypassed.

• OneKey Man-in-the-Middle. Unciphered demonstrated a critical security vulnerability for the OneKey wallet. This security vulnerability allowed anyone with physical access to the hardware wallet to swipe its mnemonics by inserting a particular piece of hardware between the CPU and the secure unit of the wallet.

The discussion of these attack surfaces highlights that while hardware wallets are generally secure for storing cryptocurrency, there can be vulnerabilities that could potentially expose your private keys. Generally speaking, remote code execution vulnerabilities + physical access to your hardware wallet = takeover of your crypto assets there.

What We Find

I'm now well aware of what can go wrong with a hardware wallet. It's time to dive in and play with my little OneKey Mini.

OneKey Mini, priced $1 less than its Trezor competitor Trezor Model One, is one of the cheapest hardware wallets available in the market. Popular in Chinese-speaking regions, it offers additional features like a Secure Element (SE) and Chinese language support. However, it is just the addition of these relevent code and extra features that has expanded its attack surface and introduced risks due to their unsatisfying code quality. We can dive into its firmware code here.

One Pitfall

Due to the fact that OneKey is a fork of the Trezor project, much of their code are the same and we can easily figure out which part of the code is added by OneKey developers. The first thought occured to me was that I can figure out how OneKey implement their additional Chinese language support functionality, compared to the corresponding Trezor code. I quickly came across this font_data_read() function, which reads in the font files from the additional flash storage by calling inner flash_read_enc().

I analyzed all the functions that are related to flash reading and writing. Then I stumbled on these two additional "(facotry) = true" constraints on MessageType_SpiFlashWrite and MessageType_SpiFlashRead message types. I mean this is a factory, not facotry right? I guess it is a typo. 🤔

I searched for both factory and facotry in the project to prove my guessing. This (facotry) = true constraint suggests that the developers intended to limit certain SpiFlash read/write operations to Factory Mode. This mode is active before the products are distributed to customers. While the getattr in messages_map.py correctly spell factory, there's a typo in the messages.proto file. As a result, MessageType_SpiFlashWrite and MessageType_SpiFlashRead are mistakenly accessible in every OneKey Mini product.

We accidentally gained access to the fsm_msgSpiFlashRead and fsm_msgSpiFlashWrite functions. These should only be accessible in factory mode.

One Overflow

I carefully inspected these two functions. Within the fsm_msgSpiFlashRead function, I found that there's an absence of validation for the msg parameter regarding its length. This oversight implies that when storing user input data into the variable resp with function msg_write, those data can be written past the boundaries of the allocated buffer.

Furthermore, the presence of the fsm_msgSpiFlashWrite function opens the possibility for a hacker to manipulate the overflowed content. This function allows us to write arbitrary data into any address in the flash memory, at our complete disposal.

Things were looking promising here, yet the exploit's effectiveness hinged on the ability to overwrite meaningful data with the overflow. I promptly shared my findings with my teammates and collaborated on addressing a legitimate exploit.

The Exploit

The stack protection mechanism is active but the overflowed object resp didn't lie on the stack, so there was no concern to circumvent the stack protection mechanism in the exploit. Upon examining the compiled and symbolized binary file, we notice that the resp object was located at memory address 0x20009d58. Interestingly, not far from this location was the timer_array at 0x2001659c. This proximity suggests a potential target for the overflow to corrupt or manipulate. The timer_func is defined as:

typedef void (*timer_func)(void);

#define TIMER_NUM 4

typedef struct {
  char name[32];
  uint32_t current;
  uint32_t cycle;
  timer_func fp;
} TimerDsec;

TimerDsec timer_array[TIMER_NUM] = {0};

In this particular scenario, the function pointer fp is executed by the system's sys_tick_handler. This means that by strategically overwriting the contents of fp, it becomes possible to manipulate the Program Counter to execute arbitrary code. This capability is crucial for gaining control over the system's operations. However, we encountered an initial obstacle. At system startup, the firmware security function, mpu_config_firmware, configures the memory segment that includes resp (where we intended to place our payload) to be read-write but explicitly sets it to execute never. This security measure prevents execution of any code that resides in this segment, effectively safeguarding the system against unauthorized code execution.

Despite this security configuration, having control over the PC provided a significant advantage. It allowed us to circumvent the Memory Protection Unit (MPU) settings that were initially blocking our attempts to execute code from the resp segment. By executing the mpu_config_off function, we could disable the MPU restrictions entirely. This action removed the execution barriers on the resp segment. With these restrictions lifted, we were able to redirect the PC to execute shellcode specifically placed within resp. This maneuver effectively bypassed the system's initial security mechanisms, allowing us to execute our custom shellcode and manipulate the system as needed.

The Demo

Here is a demo of how we used this vulnerability to access the mnemonic before unlocking the OneKey Mini.

During my research and development of this exploit, guidance from my Offside Labs colleagues proved invaluable. Their top-tier expertise and remarkable experience significantly enhanced this enjoyable research journey. Immersed in the vibrant atmosphere of Offside Labs, I've found an invigorating desire to dedicate myself to the enthralling world of web3.

Timeline

Here is the complete timeline of our research and the vulnerability disclosure process:

• 2023-11-09: Purchased OneKey Mini.

• 2023-11-15: Began reviewing the source code of the OneKey Mini and - discovered the bug.

• 2023-11-16: Confirmed the severity of the bug by controlling the PC - register.

• 2023-11-22: Completed the first version of the demo video.

• 2023-12-05: Reported the vulnerability to OneKey.

• 2023-12-20: Patch was merged.

• 2023-12-25: Received bounty ($5k, top tier) for the vulnerability report.

• 2024-01: Mandatory updates were rolled out.

OneKey has generously set their top-tier bounty for this vulnerability, offering a reward of $5,000.

Following this discovery, my confidence in using hardware wallets to protect my cryptocurrencies was somewhat shaken. I still harbor doubts about whether these devices are truly the best option for safeguarding my investments, especially if I were to lose the devices one day.

References

• Extracting the Private Key from a Trezor

• Kraken Identifies Critical Flaw in Trezor Hardware Wallets

• wallet.fail - Hacking the most popular cryptocurrency hardware wallets

• Inside Kraken Security Labs: Flaw Found in Keepkey Crypto Hardware Wallet

• Inside Kraken Security Labs: Flaw Found in Keepkey Crypto Hardware Wallet (Part 2)

• Chip.Fail - Glitching the Silicon of the Connected World

• Extracting TREZOR Secrets from SRAM

• Hacking the ultra-secure hardware cryptowallet

• KeepKey Stack Buffer Overflow Vulnerability (CVE-2021-31616)

• Faulty Stack Smashing Protection on ARM Systems

• OneKey Masa - Write original firmware

• trezor/trezor-firmware

• OneKeyHQ/firmware

• Unciphered Reveals Now-Patched Vulnerability in OneKey Wallet

In the first part of our 'Saga of Saga' series, we initiated a discussion on the concept of true vulnerabilities, setting the stage for a deeper analysis. Now, in Part 2, we'll delve further into Saga's robust security design and implementation, appreciating its resilience even in the face of potential bootloader vulnerabilities. 

Security Hurdles in Mobile Crypto Wallets

Let's now navigate the technical maze of Saga. We find that Saga is built upon the Android Open Source Project (AOSP). It's almost a mirror image of your regular Android devices, with two notable features: the dApp Store and the Seed Vault. The dApp Store serves as the gateway to the vast ecosystem of Solana (a wonderland we might explore in future blogs), while the Seed Vault significantly boosts the device's security level.  

Incorporating the Seed Vault: A Look at System Settings 

The Seed Vault, listed first in the System Settings, is designed to support the creation and management of your crypto wallet's seed. But it's far more than just a system-level application; it's your gateway to a more secure trusted zone. 

Untrusted Apps: No Access to Trusted Computing 

You might wonder, what sets the Seed Vault apart from the standard crypto wallet on Android? Recall our recent discussion about the Trusted Computing Base (TCB)? Unfortunately, almost all mobile wallets fail to fully adhere to the TCB design principle.  

Some simply have no understanding of trusted computing. They might even store passwords and secret keys in plaintext. Others find themselves limited by the capabilities of the underlying operating system. Take Apple, for instance. While it does possess a Secure Enclave Processor (SEP) on iOS for handling cryptographic operations on sensitive data, it's exclusively used by its native apps. An unofficial app does not enjoy the luxury of utilizing the SEP on its own will. 

On Android devices, you could leverage the Hardware-backed Keystore API to do crypto related operations, so that the secret keys never leave the Trusted Execution Environment (TEE). 

Solana utilizes ed25519, an elliptic curve designed for use with EdDSA. This was recently included in FIPS 186-5, the Digital Signature Standard (DSS) issued by National Institute of Standards and Technology (NIST), as of February 2023. Notably, ed25519 is supported in the Hardware-backed Keystone on Android. 

However, just because ed25519 is supported in the Android framework does not automatically give you the ability to use EdDSA. It's up to the vendor of the underlying chipset to decide whether to implement the corresponding cryptographic operations. Surprisingly, even the Google Tensor chipset that comes with the Google Pixel 6 doesn't provide support for EdDSA yet. 

Considering the significant fragmentation among Android vendors, it's unwise for a mobile wallet app to solely depend on hardware-backed features. 

Crypto Compatibilities of Crypto Currencies 

In fact, most apps are unable to leverage the Hardware-backed Keystore for signing purposes; their use is largely confined to secure private key storage! This is because major cryptocurrencies, such as BTC and ETH, are intentionally designed to be incompatible with certain standard encryption protocols. 

The signing algorithm implemented on iOS and Android devices is ECDSA-secp256r1, also known as NIST P-256, which is recommended by the NIST. Worries regarding the NSA’s potential to crack the crypto system have been present since cryptocurrencies were first created. As a result, BTC and ETH deliberately use an alternative signing algorithm, ECDSA-secp256k1. However, this "mitigation" forces mobile apps to extract the credentials from the TEE and operate within a less secure environment. 

The threats present in an insecure computing environment aren't solely from malicious attackers; they can also originate from careless or misbehaving wallet developers. The Slope Wallet Sentry Vulnerability serves as an example of this, having occurred within a Solana mobile wallet. In this case, the seed phrases for users' private keys, stored in plaintext, were unintentionally transmitted to a centralized server without encryption. Thousands of wallets were compromised, and millions of funds were stolen due to the exposed credentials. 

Securing the Unsecure: The Potential of Seed Vault 

Seed Vault implements centralized, mandatory access control for users' credentials. Rather than dealing with the keys directly, the wallet must make requests to the Seed Vault to sign any transactions. This approach significantly reduces the attack surface within mobile wallet applications. 

At present, the Seed Vault exclusively supports Solana, but it has the potential to resolve compatibility issues associated with ECDSA signing algorithms for other crypto currencies. They could integrate any wallet-specific cryptographic operations within a Trusted Applet (TA), leveraging the crypto API made available by Qualcomm Secure Execution Environment (QSEE). As the vendor of Saga, they are both privileged and obligated to provide the most secure solutions. 

Another significant yet often overlooked risk within the mobile system is that the wallet app could suffer from a UI forgery attack. A malicious app could draw another layer of graphics over the wallet app, presenting fraudulent transaction confirmations or signature requests. This could lead to user interactions being misdirected or intercepted. The ultimate solution to this issue is using a Trusted UI, directly provided by the TEE. Once again, this calls for the vendor's privilege. 

 There are many tasks that vendors can and should do. What have they done for Saga? To understand this, we need to explore the security-related system design principles of Android. 

Exploring Android's Normal World

Android devices operate on various privilege levels with a range of programs:  

User Space Programs (EL-0)

These are the most common applications on your device. They fall into four categories:  

1. Untrusted Apps: Installed or downloaded from the dApp Store, these apps are typically not considered trustworthy. For example, dAppStore and Solflare are two such apps. 

2. Preinstalled Apps: Preinstalled on the Android ROM, these apps may be vendor-certified but should not possess extra privileges. SeedVaultManager and SolanaSettings are examples of this category. 

3. System Apps: Builtin apps on vanilla Android, or selected by the vendor, these apps have elevated permissions and control sensitive system settings. WalletProvider and SeedVaultServiceApp are examples of system apps. 

4. System/Vendor Services: Different from the apps, these services interact with Android's binder IPC mechanism, offering key functionalities and operating within restricted sandboxes. For example, vendor.osom.seedvault-service and vendor.qti.hardware.trustedui are two such services.  

Kernel (EL-1) 

The Android kernel manages these user space programs. Gaining kernel privilege can allow access to lower execution levels and the ability to perform sensitive actions, such as spying on phone calls and stealing your bitcoins.  

Hypervisor (EL-2) 

Qualcomm operates a hypervisor at EL-2, with the Android system as a monitored virtual machine. More virtual machines can be launched via an agent service on Android, found at /product/etc/init/qvirtmgr.rc. 

# Qualcomm Virtualization Manager 
service vendor.qvirtmgr /product/bin/qvirtmgr 
    class late_start 
    user root 
    group root 
    disabled 
    oneshot

Trusted VM (EL-1) 

This service loads configurations from /product/etc/qvirtmgr.json. 

{ 
	"qvirtmgr" : { 
		"major_number": 1, 
			"minor_number": 0, 
			"vm_config" : [ 
			{ 
				"name"          : "trustedvm", 
				"loader_type"   : "secured", 
				"restart_level" : "relative", 
				"try_count"     : 3, 
				"boot_wait_time": 2, 
				"boot_ops"      : "start", 
				"disk" : [ 
				{ "image"   : "/vendor/vm-system/trustedvm/system.img", "label" : 11 } 
				], 
				"enable"        : true, 
				"legacy"        : true 
			}, 
			{ 
				"name"          : "cpusys_vm", 
				"loader_type"   : "secured", 
				"restart_level" : "relative", 
				"boot_wait_time": 2, 
				"boot_ops"      : "start", 
				"enable"        : true, 
				"legacy"        : true 
			} 
		] 
	} 
}

We can see a virtual machine – "trustedvm" – booting with a customized system image from /vendor/vm-system/trustedvm/system.img. This image is independent of the Android system image, and its execution is isolated from the Android world. An attacker with Android kernel privilege can't infiltrate the running trustedvm directly. 

The trustedvm is dedicated to third-party programs by the vendor and for interaction functionality for the trusted UI. We found a program "tvmapploader" handling service requests from the normal world and delegating operations to the trusted apps inside the secure world. 

Note that you don't need any vulnerability to gain kernel privilege on Android. If your device supports unlocking, you can flash your customized boot image onto your device, as we discussed in the previous blog. 

However, communication from the normal world to the secure world is bridged through the trustedvm, making direct communication with the secure world challenging, you'll need another system image to interfere with the trustedvm. This is likely why hackers don't directly attack the Seed Vault and demonstrate on a BTC wallet instead.  

Despite all these measures, all parts of the normal world can be tampered with, potentially even in a fully patched Saga, if it's unlocked. So, the question is, If an attacker manages to gain root privilege through a backdoor on your phone, does this put the Seed Vault at risk? Let's investigate the design of Saga's secure world to find out. 

Demystifying the Seed Vault in the Secure World

The trusted applications, seedvault.mbn and argon2kdf.mbn, are in the directory /vendor/firmware_mnt/image/, and they play crucial roles in Seed Vault's operations. (This research was conducted on the first released version of Solana's Saga smartphone, originally released as TKQ1.221220.242 in April 2023.) 

These files are 64-bit arm64 ELF shared objects, stripped and unencrypted. This allows us to understand their low-level operations through reverse engineering. 

Decoding the Secure Storage

The file seedvault.mbn is the core component of Seed Vault's secure storage system. It provides several interfaces: 

1.  SeedVault_generateSeedIndices     
2.  SeedVault_importSeedIndices     
3.  SeedVault_wipeSeed     
4.  SeedVault_signTransaction    
5.  SeedVault_authPublicKeys    
6.  SeedVault_changeSeedPassword     
7.  SeedVault_retrieveSeedIndices     
8.  SeedVault_verifyPassword     
9.  SeedVault_recoverSeed    
10.  SeedVault_enableBiometric     
11.  SeedVault_disableBiometric    
12.  SeedVault_getAttemptsLeft    
13.  SeedVault_getSeedInfo     
14.  SeedVault_getSeedSalt 

These functions are straightforward and properly implemented. 

Sensitive data is stored within the secure file system (sfs) provided by QSEE. The system can support up to 8 different seed vaults. The relationship between seeds and users is maintained in the /seedvault_info file. This file is structured as follows: 

struct seedvault_info {
	struct {
		uint64_t seed_id;
		uint32_t user_id;
		uint8_t flags;
	} vaults[8];
};

Each seed is identified by a unique seed_id and is stored in a file named /seedvault_${seed_id}. The seed file is structured as follows:  

struct seed {
	uint32_t version;
	uint64_t seed_id;
	uint32_t user_id;
	uint8_t seed_salt[32];
	uint8_t seed_key_nonce[12];
	uint8_t seed_key_enc[32];
	uint8_t seed_key_tag[16];
	uint8_t salt[32];
	uint8_t sha256_recovery_seed[32];
	uint8_t seed_nonce[12];
	uint8_t seed_enc[113];
	uint8_t seed_tag[16];
	uint8_t remaining_attempts;
};

Limited Attempts Stop Guessing Attacks

The seed never leaves the Trust Zone, and all operations related to the seed are executed within it. It's important to note that the seed is not stored in plain text, but instead, it's encrypted and always requires the correct password to access. Biometric authentication methods do not function until the seed is successfully accessed for the first time with the correct password.  

If the password is unknown, there are only 10 attempts allowed to guess it. This is controlled by the remaining_attempts field in the securely stored seed. After 10 unsuccessful attempts, the seed is erased, your vault is gone forever! 

The seedvault.mbn communicates exclusively with the trustedvm, which receives input passwords through a trusted UI. It's as if, during this process, the display and touchscreen are unplugged from the Android and reconnect to an invisible device. Therefore, even without explicit limitations, malicious programs cannot automate password guessing. Importantly, this process remains secure even in the face of a root privilege attack on the Android system, because the attacker cannot interfere with or simulate the interaction during the use of the trusted UI.   

Infeasibility of Offline Seed Cracking

You may propose the following: could I not simply extract the seedvault files from the secure file system, potentially exploiting a vulnerability, and then brute force the password to recover the seed? 

While theoretically possible, this approach comes with significant challenges. The seed is used, and its authenticity verified in two cases: 

1. Decrypting with the correct password. 

2. Recovering with known mnemonic phrases. 

In the first case, the client in the Normal World, whether compromised or not, is required to employ a specialized algorithm to derive a tz_password, combining the guessed user password with a seed_salt that is queried from seedvault.mbn. 

Remember trusted app argon2kdf.mbn? argon2 is a key derivation function designed to resist GPU cracking attacks (argon2i) or side-channel attacks (argon2d). The Seed Vault password uses the hybrid version argon2id with enhanced parameters (iterations=8, memory size = 256KB), significantly amplifying the difficulty of brute-force attacks.  

The second scenario is less likely to be attacked. It’s a mechanism to whether a newly recovered seed from the mnemonic phrases corresponds to the old one. The plaintext of the original seed is never stored in the file system. Instead, the SHA-256 hash of the initial seed, combined with a random 32-byte salt, is preserved. The validation can only be passed if you are aware of the true mnemonic phrase! 

In conclusion, it’s just impossible to hack your seed vault if you use a strong password! This remains true even if your phone is physically hacked via a true bootloader vulnerability! 

Conclusion

The crypto community has witnessed the emergence of numerous wallets, yet what truly matters is a wallet that can be implicitly trusted while remaining uncompromised. Through trust computing isolation and fortified key storage, Saga has set a high benchmark for mobile cryptocurrency security. While no system is completely invulnerable, Saga's approach has drastically minimized potential points of attack.  

As we continue to delve into this rapidly evolving landscape, our focus remains on identifying potential vulnerabilities and enhancing security. It is our hope that more wallet providers will rise to the challenge, offering innovative solutions that match, if not exceed, the trustworthiness and safety Saga has showcased. 🫡 

About Offside Labs

Offside Labs is a professional team specializing in security research and vulnerability detection. Our primary focus includes rigorous bug hunting, comprehensive audits, and expert security consultation. We have extensive experience in the web3 environment and strive to enhance the security posture of our client's projects in this rapidly evolving digital space. 

References

1. https://offside.io/blog/saga-of-saga-part-1-unlocking-the-debate-on-true-vulnerabilities  

2. https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/keystore/java/android/security/keystore2/AndroidKeyStoreKeyPairGeneratorSpi.java;l=147-153 

3. Securing Web3 Mobile Wallets with TEE: Delving into the Security Guarantees and Real-world Implementation Pitfalls, Yuan Zhuang @ Certik, MOSEC 2023 

4. https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets/documents/How-5G-is-enabling-resilient-communication.pdf 

5. https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#argon2id 

6. https://slope-finance.medium.com/slope-wallet-sentry-vulnerability-digital-forensics-and-incident-response-report-d7a5904e5a39

7. https://csrc.nist.gov/pubs/fips/186-5/final

Alert! Unusual Transactions 

On December 8th, at 12:24 AM UTC, our monitoring system detected a malicious transaction on Polygon, where a hacker transferred out approximately $140k worth of USDC from the smart contract 0x829363736a5a9080e05549db6d1271f070a7e224. 

Later that same day, at 2:53 PM UTC, the same contract triggered our alarms again, this time for a significant influx of assets into the vault. 

The unusual signal caught our attention. The incoming sum was close to what had been stolen earlier. Could the hacker have just returned the stolen assets? We took a closer look at the smart contract. The first transaction seemed to be an attack related to the forwarded multicall—a novel vulnerability ThirdWeb had only recently disclosed. We have observed numerous similar attacks on-chain. The stolen funds had been swapped to ETH and bridged to Ethereum. 

Code Red: The Race to Safeguard the Vault 

The incoming USDC was not from the attacker. There were a few users continuing to deposit into the vault. It became clear that the DeFi project associated with the vault was still active; the owner and users seemed oblivious to the breach.   

The spider-sense of a hacker warned us something bad might happen again. Around $124K USDC was still at high risk, and we suspected that other predators in the ‘dark forest’ might be on the prowl. We had to take immediate action to prevent any black hat hackers from seizing the funds!  

However, what we knew about the vault was limited to only the source code of its smart contract and some addresses that had interacted with it. We didn’t know anything about the project behind the vault!  Identifying and alerting the responsible team discreetly and promptly, without compromising the endangered assets, was a complex task. We were left with two options: fix the flaw or extract the funds before it was too late. 

Failed Attempts to Mitigate the Bug 

Based on our understanding of the root cause of the vulnerability, we knew there was a trusted forwarder in the vulnerable vault that could allow someone to counterfeit the msgSender() of internal transactions.  For those interested, you can delve deeper into this type of bug. 

• Vulnerability Disclosure from OpenZeppelin

• Vulnerability Analysis from Dedaub

 An effective mitigation of this bug is to disable the trusted forwarder. The function setTrustedForwarder(address) was designed for this purpose. It requires the caller to be a specific governance address, but we could manipulate the caller identity! 

Our plan was to leverage the bug to set the TrustedForwarder to a null address. We spent some time debugging based on this idea. yet, we missed a critical detail: the onlyGovernance() modifier didn’t rely on the compromised _msgSender(); instead, it validated using msg.sender directly. 

Replaying the Exploit of the Original Hacker  

Our initial misdirection cost us time, but fortunately, the funds remained untouched. Another hack could happen at any time! We decided to preemptively execute a white-hat hack to rescue the funds. This meant exploiting the very same bug to preempt any malicious attempts, an approach that's unconventional in the real world, but very common in the web3 world, where swift action is often crucial and self-reliance is key. 

The most effective strategy is to replicate the original hacker’s transaction. Because the nonce of the signed inner transaction from the initial breach is not reusable, we have to replace the hacker’s address to our own and craft new signatures for the embedded transactions. 

Bypassing the Ineffective Mitigation 

We quickly tested and deployed our exploit code, however, it didn’t work on-chain!  Had the funds already been moved? It was then we noticed this transaction:  

Someone had paused the project! No further deposits or withdrawals could be made from the vault. It’s triggered from an address with the “Guardian” role. Great! The project owner was now clearly aware and responding to the emergency! 

But did a pause mean secure? We didn't think pausing is a legit fix of the bug. Because the attacker can impersonate any user, including the “Guardian”, and simply unpause the project. 

The potential workaround of the mitigation is pretty straightforward. The original hacker might have had a deeper understanding of the project's workings than us, but we had the advantage of speed. Rapidly, we deployed a refined exploit that included an unpause command, allowing us to resume operations and move all the at-risk funds to our secure vault. Finally relieved! 

Onchain Guidance 

We didn’t know who the owner of the vault was, but he must be desperate. So, we tried to deliver messages to him. 

We published a message to ourselves, stating: 

Don't worry, we are white-hat hackers. We will return the fund. 

We sent a message to the Governance address, teaching the owner the correct patch of the bug: 

Where should we return the funds to? First, you should disable the forwarder by 'setTrustedForwarder(0)' 

Remarkably, within 10 minutes, the Governance executed a transaction to reconfigure the trusted forwarder to itself.

Finally, the bug is patched! We have time to delve further into the source code while waiting for responses from the governance. 

Digging Beyond the Surface 

Let’s check the huge inflow of $124k USDC first. Where was it from? 

It’s processed by L2WormholeRouter and L2BridgeEscrow. Some components of this project are on another chain. The funds we transferred were just a portion of its TVL. 

We got some clues from the wormhole router contract. By searching the keywords L1_FUND_TRANSFER_REPORT, we tracked down to a DeFi project Affine. 

Gradually, we pieced together Affine's architecture:  

Affine is a cross chain yield aggregator. It pools deposits on L2 (Polygon) and sends funds to L1 (Ethereum), maintaining an investment ratio of 47:3.  

Since the manager on L2 has no direct knowledge of L1 status, a bot with the role “Harvester” is scheduled to synchronize the two layers via the wormhole network. 

Upon receiving updated TVL data from L1, L2 decides whether to rebalance the portfolio by either withdrawing from or sending extra funds to L1.  

After the initial hacker draining the vault on L2, the portfolio of Affine is heavily imbalanced. Consequently, the bot initiated a rebalance, prompting L1 to send funds back to L2. With over $2M on L1, roughly $120k - 6% of TVL - was transferred due to this automation.

Could we initiate a rebalance by ourselves? The rebalance is only triggered by a public function receiveTVL() in L2Vault, which requires the _msgSender() to be the L2WormholeRouter. Given the exploitability of _msgSender(), the hacker could have forced the L2 to rebalance and request the L1 to move all the 2M funds back to L2! 

We were really surprised that our intervention had safeguarded not merely $110k but $2M!

Meanwhile, we realized what we and the hacker had done in the exploit. We had burned and withdrawn shares on behalf of a major Liquidity Provider (LP) in the pool. The exploit had not affected others. With this insight, it became evident that we needed to return the funds to the LP's address. 

Closing 

Despite the absence of an on-chain response, we had identified the project's owner. We took to Twitter, broadcasting our findings and tagging @AffineDefi in our post:

Upon their confirmation of the LP's address, we promptly returned the funds. 

As a result, we were awarded with a $10k bounty for the white-hat hack. 

With the funds now secure and the vulnerability patched, our work comes to a close. But our mission is not over. We stand ready to confront emerging challenges, ever committed to safeguarding the integrity of the blockchain ecosystem. 

Timeline 

• 2023-12-08 00:24 UTC - First attack detected. 

• 2023-12-08 14:53 UTC - Alerted to a large influx of funds. 

• 2023-12-08 15:30 UTC - Initiated an investigation into the unusual activity. 

• 2023-12-08 16:40 UTC - Transferred funds to our secure vault for protection. 

• 2023-12-08 17:09 UTC - Disclosed our status as white-hat hackers. 

• 2023-12-08 17:20 UTC - Sent on-chain messages to the project owner. 

• 2023-12-08 19:54 UTC - Posted a tweet requesting direct messaging with Affine DeFi. 

• 2023-12-08 20:03 UTC - Affine DeFi reached out to us on Twitter. 

• 2023-12-08 20:21 UTC - Detailed our actions in securing $110k USDC. 

• 2023-12-08 22:24 UTC - Affine DeFi confirmed the plan for a public recovery. 

• 2023-12-08 22:34 UTC - Returned the funds to the user. 

• 2023-12-08 23:10 UTC - Received a bounty from Affine DeFi for our white-hat hacking efforts. 

There's been a recent debate between the Solana Mobile team and Certik, a security firm, about the security of the Saga, Solana's own mobile phone. As a leading group in web3 security with extensive experience in mobile security, we're here to offer our insights on this matter. 

In this blog post, you'll get a clearer picture of Saga's security design and understand why this premium crypto hardware might be a good (or not so good) investment for you. Let's delve into the Saga debate! 

The Saga Security Controversy 

Certik dropped a demo on how to steal from a BTC wallet on a web3 phone, the Solana Saga. They claimed they'd "revealed a significant bootloader vulnerability in the Solana Phone", which presents "a challenge not just for this device, but for the entire industry". 

This claim sparked a lot of chatter. But wait a minute, in the warm-up video for their demo, they're not chatting about any 'vulnerabilities' here, they're actually showing folks how to 'backdoor your phone'. Based on the content of Certik's latest demo, one could infer that they have installed backdoored firmware on their Saga, a process that required unlocking the bootloader. 

So, you might be scratching your head, “What on earth is 'unlocking the bootloader'?” Well, it's a handy optional feature that vendors offer, allowing you to install custom firmware. You'll find it in many Android devices, the Google Pixel included. 

The Solana Mobile team refuted the claim of the so-called vulnerability on their Discord, stating: 

The video shows the user unlocking the bootloader, which is something that can be done on many Android devices (as outlined in Android Open Source Project’s documentation). Additionally, unlocking the bootloader is an advanced feature of Saga which requires multiple explicit steps, and is disabled by default.

Verifying the Unlocking Process 

Following the buzz around Certik's demo and Solana Mobile team's rebuttal, we decided to verify the bootloader unlocking process ourselves. We've expanded on the key insights initially shared on our Twitter thread for a more comprehensive understanding. 

Insight 1: Standard Security Measures 

The first key insight from our investigation is that the Solana Phone, like many other mainstream devices including Google Pixel, is locked by default. This is a common security measure implemented by manufacturers to protect user data right out of the box. 

Insight 2: Unlocking Process 

Unlocking the Saga involves a two-step process. First, enabling developer mode, OEM unlocking, and USB debugging on the phone—actions that require your passcode. The second step requires connecting the phone to a laptop via USB, rebooting to the bootloader, and entering a specific command (fastboot flash unlocking_critical) into the laptop's console. 

This insight shows that unlocking the device requires a certain level of technical expertise and intentional actions, rather than being something that could happen accidentally.

Insight 3: Data Wipe After Unlocking 

A noteworthy observation is that once the Saga is unlocked, it automatically wipes all previous storage and credentials, including the "Seed Vault" — a core feature of Saga that we'll expand on later. The unlocking process functions like a comprehensive reset button, erasing all prior data. 

A final warning is also displayed to the user, outlining the risks and consequences of proceeding with the unlocking. This observation underscores the irreversible nature of unlocking and the serious data privacy considerations involved, especially in relation to the "Seed Vault" feature. 

Insight 4: Unmissable Alert

Lastly, unlocking the Saga does not go unnoticed. An unlocked phone triggers a clear and lengthy alert every time the device is booted up. This persistent alert serves as a constant reminder of the altered security state of the device. This insight emphasizes that while the unlocking feature is available, it is not treated lightly by the system or hidden from the user. 

In conclusion, these insights demonstrate that while bootloader unlocking is indeed possible on the Saga, it is designed as an advanced feature with numerous safeguards and warnings, rather than a vulnerability.

What Constitutes a Genuine Bootloader Vulnerability? 

An unlocked bootloader allows you to run a customized mobile operating system. However, this is not necessarily a vulnerability. A bootloader becomes a vulnerability if it can be unlocked without following the established rules. 

For instance, it would be considered a vulnerability if it can be unlocked even when the vendor has intentionally disabled this functionality. Similarly, it would be a vulnerability if the bootloader could be unlocked without user authorization, or if unlocking it doesn't erase user data. Lastly, it's a vulnerability if the system can boot without displaying permanent warnings after unlocking. 

In fact, there have been numerous notable bootloader vulnerabilities throughout history. Almost every popular hardware device, regardless of its price, has experienced hacks exploiting bootloader vulnerabilities. This includes devices from Apple, Samsung, Qualcomm, MediaTek, Huawei, Sony, and even Nintendo. We have seen many talented hackers discover new vulnerabilities in bootloaders, but none of them would agree that simply enabling unlocking constitutes a bug.  

That's why we firmly believe that Certik must have noticed something unusual inside Saga's bootloader. Otherwise, they could have simply demonstrated an attack against Google Pixel and claimed that its 30 million users were under threat of losing their bitcoins. 

So, our exploration into the depths of Saga's complexities continues. Next up, we'll tackle Saga's security design and implementation. Stay tuned for "Saga of Saga - Part 2". 

A few months back, our group stumbled upon an early bug bounty program hosted by Scroll, an up-and-coming zero-knowledge roll-up. They were offering big money - $5,000 each - for finding buggy transactions in their testnet. 

As skilled hackers always on the lookout for new frontiers, the pre-launch bug bounty from Scroll immediately piqued our interest. The announcement landed squarely on our radar for hunting down vulnerabilities! 

We went into hacking Scroll with zero knowledge about their clever zero-knowledge roll-up setup. By fuzzing their code and tweaking things, we found something interesting. It gave us a glimpse into how seriously they take security. 

In this blog post, we will not only narrate our exciting hacking journey but also share our observations and insights about the security measures employed by Scroll. 

Scroll: A Security-focused Scaling Solution for Ethereum 

Scroll is a zkRollup Layer 2 dedicated to enhancing Ethereum scalability through a bytecode-equivalent zkEVM circuit. The mainnet of Scroll was launched last month. 

Scroll is composed of three layers: settlement layer, sequencing layer and proving layer. 

The settlement layer refers to smart contracts deployed on the Ethereum network, where the roll-up submits and verifies the validity of computations conducted in the nested layer. The sequencing layer forms the major user-facing component as an isolated yet fully EVM-compatible chain. 

Together, these two layers make up the typical architecture found in alternative layer 2 public blockchain solutions, with the settlement layer confirming operations from the standalone sequencing environment. 

The proving layer differentiates zero-knowledge rollups from traditional implementations, representing an additional component. The most captivating advantage conferred by zk techniques is the rollup's ability to give a succinct proof of the entire layer 2 chain state without broadcasting individual transactions to Ethereum, thus ensuring time and space efficiency. 

However, generating these proofs demands non-trivial computational overhead beyond the capabilities of regular execution nodes. So, Scroll set up a layer just for intensive computation work. The proving tasks are handled by super powerful nodes or distribution across a group of such nodes. The specialized proving layer focuses only on that, keeping layer 2 running without proofing's steep resource costs slowing it down. 

The Rolling-up Scroll: Execution, Commitment and Finalization 

The rollup process can be broken down into three phases:

1. Transaction Execution 

2. Batching and Data Commitment 

3. Proof Generation and Finalization 

The first two layers function asynchronously yet cohesively irrespective of the additional computation in the proving layer. However, unavoidable lags from proving labor could potentially induce inconsistency between the two layers.  

Consider this scenario: A valid transaction is confirmed by the sequencing layer (L2Geth), and the settlement layer records the commitment with its batch details. However, the proving layer cannot craft a proof for it! Only after extensive GPU hours does the prover realize they are unable to generate a valid witness, or the proof does not match what is needed.  

It is important to note that this concept differs from chain reorg issues seen in other alternative chains. Typically, reorg problems in those systems are caused by networking difficulties among interconnected nodes. The current version of Scroll is running in a controlled (centralized) manner. Reorgs in other networks would happen and resolve silently by design. However, the proving failures may not be straightforward for Scroll. 

If a transaction is unprovable, it stops the full batch from finalizing. This blocks the whole network. Now you could revert any transactions after the toxic one and remove it and related transactions, like a hard fork. Or you could manually add fake proofs just for these cases. But that second option would go against the purpose of the roll-up system by adding unproven transactions.  

It is a tricky situation that requires carefully considering options like forks or alternate proofs to resolve inconsistencies without compromising integrity. Handling troublesome transactions in a safe way is exactly what the Scroll team is worried about. That is why they set up a bug bounty program for this specific problem! 

Fuzzing the Bus Mapping: Unleashing Chaos in Search of Vulnerabilities 

There are some potential reasons that could cause prover bugs, as listed on the bug bounty page: 

1. Missing information in the generated trace. 

2. Errors when the bus-mapping module processes traces from L2Geth. 

3. Divergent behavior between L2Geth and the zkEVM circuit. 

4. Bypassing the circuit capacity check. 

These bugs could appear in various parts of the Scroll project workflow: 

• Transactions are validated and executed by L2Geth, which generates execution traces. 

• The bus-mapping module converts traces to a format for the zkEVM circuit. 

• The witness and zkEVM circuit generate the proof, requiring a match with L2Geth behavior. 

• A capacity checker is needed because zkEVM circuits have finite capability. 

The trace generator and circuit capacity checker are implemented in L2Geth. We manually reviewed the Golang code added by the Scroll team and the code seems well written. 

As we did not have the budget to set up a powerful prover node capable of generating actual proofs, we decided to leave the bug hunting in zkEVM circuits as a challenge for moneyed hackers. (Conducting such proofs could require computational resources more expensive than the bounty rewards.) 

This effectively ruled out targeting the circuits themselves. The only component remaining within our scope to audit was the bus-mapping module, as evaluating its code would not demand generating a full proof.  

The bus mapping module is responsible for parsing transaction traces executed in L2Geth and converting them into the witness required to generate proofs.  

In reviewing the bus mapping source code, we discovered that the project has comprehensive unit tests. With only minor modifications, we were able to construct a basic harness to execute the tests. 

use libfuzzer_sys::fuzz_target; 
... 
fuzz_target!(|data: &[u8]| { 
    let code = Bytecode::from_raw_unchecked(data.into()); 
    // Get the execution steps from the external tracer 
    let block: GethData = TestContext::<2, 1>::new( 
        None, 
        account_0_code_account_1_no_code(code), 
        tx_from_1_to_0, 
        |block, _tx| block.number(0xcafeu64), 
    ) 
    .unwrap() 
    .into(); 
  
    let mut builder = BlockData::new_from_geth_data(block.clone()).new_circuit_input_builder(); 
    builder 
        .handle_block(&block.eth_block, &block.geth_traces); 
}); 

Within five minutes, we were able to trigger an interesting crash using cargo-fuzz. It generated corpus input with considerable complexity, yet the underlying crash seemed straightforward. 

The Discovery: Unveiling a Subtle Bug in Scroll  

Specifically, the crash occurred within the get_create_init_code function when the offset_end variable exceeded memory boundaries during an access, resulting in a segmentation fault. Despite the complexity of the randomly generated fuzzing corpus, the crash proved easily reproducible and localized to a single out-of-bounds memory access.

pub fn get_create_init_code<'a>( 
    call_ctx: &'a CallContext, 
    step: &GethExecStep, 
) -> Result<&'a [u8], Error> { 
    let offset = step.stack.nth_last(1)?.low_u64() as usize; 
    let length = step.stack.nth_last(2)?.as_usize();
 
    let mem_len = call_ctx.memory.0.len(); 
    if offset >= mem_len { 
        return Ok(&[]); 
    } 
 
    let offset_end = offset.checked_add(length).unwrap_or(mem_len); 
    Ok(&call_ctx.memory.0[offset..offset_end]) 

} 

The vulnerable function can be triggered when calling the create2_address function. 

pub(crate) fn create2_address(&self, step: &GethExecStep) -> Result<Address, Error> { 
    let salt = step.stack.nth_last(3)?; 
    let call_ctx = self.call_ctx()?; 
    let init_code = get_create_init_code(call_ctx, step)?.to_vec(); 
    let address = get_create2_address(self.call()?.address, salt.to_be_bytes(), init_code); 
    log::trace!( 
        "create2_address {:?}, from {:?}, salt {:?}", 
        address, 
        self.call()?.address, 
        salt 
    ); 
    Ok(address) 

} 

The CREATE2 opcode enables deterministic prediction of contract deployment addresses without actual deployment. The underlying idea is to make addresses independent of future blockchain events - a contract can always be deployed at its precomputed address regardless of what happens. 

New contract addresses are a function of: 

1. 0xFF, a constant that prevents collisions with regular CREATE 

2. The sending account address 

3. A salt value provided by the sender 

4. The bytecode of the contract to be deployed 

The address is calculated as: 

new_address = hash(0xFF, sender, salt, bytecode) 

The calculation of the new address triggered the memory access violation bug by fetching the bytecode from an unallocated memory region.  

We created a basic Proof of Concept (PoC) by invoking the CREATE2 instruction with specific parameters that were expected to exceed memory boundaries: value=0, offset=0, length=100, salt=0. Surprisingly, this did not result in a crash as expected. 

Analyzing the crashing corpus revealed that the CREATE2 instruction had been executed twice. This raised concerns about potential issues in the logic handling conflict resolution when multiple create2 operations share the same salt. 

Simply put, EVM does not allow multiple contracts to be created at the same address. The second creation will fail due to a contract address collision error. When parsing traces from L2Geth, the bus mapping module aims to analyze and understand the underlying causes of any encountered errors. If a CREATE2 instruction fails execution, it computes the cryptographic hash of the associated code to derive and track the duplicated contract address. 

if matches!(step.op, OpcodeId::CREATE | OpcodeId::CREATE2) { 
    let (address, contract_addr_collision_err) = match step.op { 
        OpcodeId::CREATE => ( 
            self.create_address()?, 
            ContractAddressCollisionError::Create, 
        ), 
        OpcodeId::CREATE2 => ( 
            self.create2_address(step)?, 
            ContractAddressCollisionError::Create2, 
        ), 
        _ => unreachable!(), 
    }; 
    let (found, _) = self.sdb.get_account(&address); 
    if found { 
        log::debug!( 
            "create address collision at {:?}, step {:?}, next_step {:?}", 
            address, 
            step, 
            next_step 
        ); 
        return Ok(Some(ExecError::ContractAddressCollision( 
            contract_addr_collision_err, 
        ))); 
    } 
} 

Nothing goes wrong until memory expansion occurs. If an instruction dereferences a location beyond the current memory boundary, memory is automatically expanded and initialized with zeroes. This is handled correctly by L2Geth and bus mapping for the execution of every opcode. 

However, memory expansion does not take place inside the error handler for failed executions. This is why the subtle bug can only be triggered during a contract address collision, when the failed create2 invocation does not cause an expansion of memory space before the address calculation dereferences outside the initialized region. 

The Circuit Capacity Checker: An Additional Layer of Defense 

We tried to launch the attack script against our local test node, but still nothing happened. We thought we were close to claiming the bug bounty, however, the Scroll team anticipated this one step ahead of us. It was the circuit capacity checker (CCC) that blocked the potential hacks. 

The CCC, as you may remember, is designed to calculate the required circuit gates for a specific transaction and reject those considered too costly. The L2Geth node invokes CCC to simulate incoming transactions. Any bugs within the bus mapping module would also affect CCC. If CCC were to crash, the L2Geth node would simply drop the troublesome transaction rather than exposing a vulnerability. 

The CCC provides extra protection as a firewall. It evaluates transaction costs before execution. This helps prevent unknown attacks from overloading resources or exploiting memory bugs through crashing. This auxiliary defense strengthens the overall security of the platform. 

Conclusion  

We reported our findings to the Scroll team, who then quickly deployed a fix for the memory corruption bug just before the launch of their mainnet. Our speed hacking attempts with Scroll did not yield a bounty. But we are glad we understood their rollup's robust security. The Scroll team clearly did great work fortifying it. Props to them! 

While this hack did not pay off, we are excited by how much we learned dissecting their defenses. It inspired us to keep challenging ourselves with zk-rollups and web3. The possibilities are endless - our learning has just begun! 

About Offside Labs 

Offside Labs is a professional team specializing in security research and vulnerability detection. Our primary focus includes rigorous bug hunting, comprehensive audits, and expert security consultation. We have extensive experience in the web3 environment and strive to enhance the security posture of our client's projects in this rapidly evolving digital space. 

References 

1. https://github.com/scroll-tech/zkevm-circuits/blob/40f4758f5b4b5a5c82fb312ee58492487f181185/bus-mapping/src/circuit_input_builder/input_state_ref.rs#L1666-L1690 

2. https://github.com/scroll-tech/zkevm-circuits/blob/40f4758f5b4b5a5c82fb312ee58492487f181185/bus-mapping/src/circuit_input_builder/input_state_ref.rs#L909-L921 

Will we see the doomsday of Ethereum? What if a catastrophic vulnerability is discovered and exploited in the Ethereum network? Considering the security model of Ethereum, I don’t think that could happen. The execution of smart contracts and the consensus of the network are implemented in multiple independent software clients, a single flaw or discrepancy that affects a minority of the clients will be discarded by the network. Even if we see a nuclear-level bug that destroys all the Ethereum nodes, the community can always fork a new secured chain as the canonical Ethereum, like we have done in the DAO fork.

However, not all EVM compatible chains are guarded at the same security level and with the same decentralization as Ethereum. In fact, most “Ethereum killer” chains only have one single implementation of their protocol. The lack of diversity is the Achilles’ heel of public chains: if anything goes wrong in their official implementation, the giant will be knocked down easily.

A few months ago, I found a critical vulnerability in paritytech/frontier, an EVM implementation written in rust and mainly used in Polkadot parachains. When I was writing my previous blog post, I decided to take one more quick review of the code used in the Moonbeam network, in case I missed anything trivial but critical. My hacker instinct led me to a tricky integer truncation bug!

Frontier executes normal Ethereum smart contracts, but uses a Polkadot substrate as the ledger. This has a quirk: while balance amounts are 256 bit integers in normal Ethereum, the currency in the Polkadot substrate is only 128 bit. To convert to Polkadot, frontier truncates the 256 bit transfer balance amount to 128 bits. This is the code that handles value transferring in the frontier EVM:

Since the balance can never be greater than 128 bit, and the transfer will be validated by the balance substrate eventually, what could go wrong?

The key is that the transfer.value here, or msg.value in EVM, is a totally controlled 256 bit value provided by the user. If we pass (1 << 128) in the msg.value, T::Currency::transfer will do nothing because it’s transferring a truncated zero, and we’ll finish the EVM execution smoothly. We won’t get any extra balance by transferring the zero, but what if the giant untruncated msg.value is accepted by some contract that does give us credit? We could achieve the impossible and attack WETH to make it depeg!

The WETH contract allows users to deposit native ETH that users specify through msg.value. It stores this value internally after transferring the appropriate amount of tokens. Normally if you don’t have enough balance for the transfer, the transaction will be rejected or reverted. However, since we have bypassed the transfer validation by truncating to 0, the contract is willing to add our gigantic credit to our address in its internal balance mappings. Suddenly we have an astronomical balance in the contract and can drain all the deposited native tokens from the wrapped token contract!

To clarify, it’s not the WETH token itself on Ethereum that is vulnerable (but the title made you click, didn't it!), but the analogous wrapped native tokens of the polkadot parachains powered by the frontier EVM, such as WASTR in Astar, WGLMR in Moonbeam, and WMOVR in Moonriver, which are implemented using the standard WETH contract but on their respective parachains!

WETH contracts are not the only vulnerable targets. The Uniswap-like DEX trading pair contract accepts direct swapping from native ETH to ERC20 tokens. It trusts the msg.value too. Compound-like lending protocols usually provide a dedicated native token vault, handling both the deposit and withdrawal of native tokens. DEXes and lending protocols are the fundamental infrastructure of the DeFi world, any insolvency would be contagious. As I mentioned, any critical vulnerability that could depeg WETH is actually the nightmare of the whole ecosystem.

The previous bug had a similar effect, but required a tricky exploit. This bug is trivial but more destructive.

The impact of the bug is complex. The direct exploit could drain all the wrapped token contracts. In addition to taking over the balance of the wrapped token, you can purchase other tokens from DEX by spending the rubber check from the wrapped token. Worse, a more sophisticated exploit could leverage the lending protocol to borrow all the other valuable tokens against the fake deposit.

At the time I reported the bug, the major victims were:

• WMOVR https://moonriver.moonscan.io/address/0x98878b06940ae243284ca214f92bb71a2b032b8a 560,369.286709772080185324 MOVR $6,511,491.11 (@ $11.62/MOVR)

• WMOVR https://moonriver.moonscan.io/address/0xf50225a84382c74cbdea10b0c176f71fc3de0c4d 39,495.093378689025337841 MOVR $458,932.99 (@ $11.62/MOVR)

• MGLMR https://moonbeam.moonscan.io/address/0xacc15dc74880c9944775448304b263d191c6077f 22,509,169.750566904824477505 GLMR $15,462,674.16 (@ $0.69/GLMR)

• Wrapped Astar https://blockscout.com/astar/address/0xAeaaf0e2c81Af264101B9129C00F4440cCF0F720 233,903,992.470478147048553875 ASTR ($12,110,613 USD)

• WASTR https://blockscout.com/astar/address/0x19574c3c8FaFc875051b665Ec131b7E60773d2C9 98,294,128.445114886025015582 ASTR ($5,080,234 USD)

• Wrapped Shiden https://blockscout.com/shiden/address/0x0f933Dc137D21cA519ae4C7E93f87a4C8EF365Ef 9,348,196.210407926441765242 SDN ($3,310,196)

The direct loss from wrapped token contracts could be more than $44M.

In lending pools the assets under risk is even larger:

• Moonwell Apollo Total Supply $89,023,722 Total Borrow $41,595,374.52

• Moonwell Artemis Total Supply $179,023,716.01 Total Borrow $94,486,490.85

• Starlay Finance Total Deposited $37,163,238.35 Total Borrowed $18,769,822.51

The remaining borrowable assets would be somewhere around $150M.

The vulnerability disclosure was troublesome as well. This bug affected at least two parachains: Moonbeam network and Astar network. I had to report to them simultaneously otherwise one team with earlier knowledge of the bug could conceivably launch an attack on the other one (I didn’t know if they were competitors). Furthermore, I noticed Acala network also shipped the same code, but they didn’t have as rich an EVM-based ecosystem as the other two, and the bug had no explicit impact on their system as a result, so I decided to postpone the bug disclosure to them.

All the three projects have their bug bounty program listed on Immunefi: Moonbeam network, Astar network and Acala. Each project has a maximum bug bounty of $1M 😮. I was worried that the triage process on Immunefi might be delayed, so I tried to contact the first two teams as soon as I finished my POC and reports. Thanks to the help from the Moonwell team, they set up a telegram channel between me and Moonbeam, who later invited the Astar and Polkadot guys to the group. All the bugs were quickly patched. A security advisory (CVE-2022-31111) was published later. This has been recorded on Moonbeam’s blog.

Another interesting fact about the bug: a few hours after my report, the Moonbeam team identified a suspicious transaction that triggered the vulnerability. You can see the transfer of 340,282,366 (T) MOVR! I believe the bug is dead now, but the corpse is living on the blockchain permanently.

The vulnerable substrate frontier is built by paritytech, the team behind Polkadot. The Moonbeam team maintains its own fork at https://github.com/PureStake/frontier. The Astar team forks from Moonbeam’s repo to https://github.com/AstarNetwork/frontier. All of them agreed to offer a bug bounty, but they decided to split a $1M bounty after months of negotiation🤣. To my surprise, Acala offered a huge bounty (compared to their negligible potential loss), which was also counted in the split. The final payout is $1M:

• Moonbeam $430k

• Astar $250k

• Polkadot $250k, in DOT

• Acala $70k, in DOT

Whether the result is $2M or $1M, since the bounty pays out in tokens living on the Ethereum blockchain, I guess I'm pretty lucky that WETH wasn't vulnerable to this bug after all!

This journey took me out of the safety of the moonlight and into the uncertain darkness of collateralization. I dug into new concepts to bring familiarity to unfamiliar code. I quickly found a trivial bug, but I suspected that there was more. After some comprehensive research, I discovered a novel, exciting flaw. Both bugs have been confirmed as critical, leading to the decision to deactivate the vulnerable module.

To understand the hack, you, like I had to do, will have to start with the basics. So sit back, read on, and let's learn about collateral!

the interBTC Bridge and Over-collateralization

The interBTC runtime allows the creation of interBTC, a fungible token that represents Bitcoin in the Polkadot ecosystem. Each interBTC is backed by Bitcoin 1:1 and allows redeeming of the equivalent amount of Bitcoins by relying on a collateralized third-party.

Over-collateralization is a popular technique in DeFi protocols, enabling the minting of a synthesized asset from another base asset. Most Collateralized Debt Position (CDP) protocols are designed for minting stable coins from valuable but volatile assets. The most successful case of over-collateralization is the MakerDAO protocol, which allows users to create debt in DAI by depositing ETH.

In the interBTC protocol, however, one is allowed to synthesize a mapping of a high value token (BTC) from its native tokens, like INTR and KINT. This feature is more like Synthetix, which allows minting any mapped assets by locking its native token SNX. The security of risky collateral usually means higher collateralization rate and lower capital efficiency. For SNX, the Collateralization Ratio (C-Ratio) is 400%. For interBTC, on their Kintsugi canary network, C-Ratio of KINT is 500%, C-Ratio of KSM (the native token of Kusama) is 150%.

As pointed out by the interlay team, they use mainly the KSM/DOT assets (the ceiling of INTR/KINT is very low due to missing liquidity). They primarily target exogenously priced collateral assets rather than endogenous ones - more like Maker, but they allow a small portion of our native asset.

The security properties are usually maintained by price oracles and arbitrageurs, but this may not work during market crashes. Luckily, the over-collateralization of interBTC is just the ​​last line of defenses, the system has guaranteed Bitcoin reserves as long as all the vaults are honest.

But how can we trust decentralized vaults that are controlled by anonymous entities? Now I will try to explain the innovation of interBTC’s fraud proof and slashing mechanisms.

Onchain SPV and Fraud Proof

InterBTC is designed specifically for BTC, so it has to deal with the complexity of bitcoin transactions. It is clearly impossible to maintain all the transactions on chain, so the protocol works like a light wallet. Accordingly, the BTC-relay module of the protocol implements the Simplified Payment Verification (SPV). Instead of tracking all the unspent notes (utxo), only the minimal information of every bitcoin block header is stored on the chain. The relayers are in charge of the synchronization of block headers, providing the root of trust. The validation algorithm only needs to verify a given transaction

1. has a valid merkle proof for its txid

2. the merkle root is found in the stored block headers

3. the corresponding block is mature enough

Thus the system is able to check the validity of any interactions between users and vaults (specifically, transfers of a specific amount of BTC). Where would the users deposit to? To addresses prepared by the vaults in the registry module. The vaults have to respond to reasonable requests from the user, and if no valid proof is supplied in a limited time, the locked collateral for that request will be slashed. All the required information is provided to the system, so it can confirm the honest behaviors with confidence.

What about malicious behaviors without corresponding user requests? The off-chain relayers monitor and check that vaults do not move BTC, unless expressly requested during Redeem, Replace or Refund. If a malicious vault moves BTC without authorization by the bridge, or reuses the authorization by committing the same OP_RETURN transaction, all of its collateral will be slashed. These two behaviors are reported by report_vault_theft and report_vault_double_payment extrinsics respectively.

Therein lie the bugs...

Bug 1: Double Payment Force Liquidation

report_vault_double_payment is exposed as an extrinsic call method. It takes two raw txs and verifies that they share the same input and reference the same user requests.

The two txs are compared to ensure they are different. However, the check of Vec<u8> is incomplete.

BytesParser ignores trailing bytes of the raw transaction, so different raw_txs.0 and raw_txs.1 can be parsed into same Transaction, bypassing all the following checks in report_vault_double_payment.

All the vaults with at least one processed user request (Redeem, Replace or Refund), are vulnerable to this force liquidation. The attacker would steal 5% of the vault's collateral, leaving the whole system broken: all the collateral would be transferred to the liquidation account and all vaults would be banned.

The bug is pretty simple. In the POC, a fake tx is crafted by simply appending an extra byte to the original tx. My patch and testcase were later adopted in their commit. Full Report

Bug 2: P2SH Address Forgery

The bitcoin address itself is a pretty interesting topic. There are many variants of address: P2PK, P2PKH, P2MS, P2SH, P2WSH, P2WPKH… It’s super confusing! Why?

As you may (should!) already know, there is no such concept as an account in Bitcoin: all the balances are maintained by utxos. Every utxo has a ScriptPubkey, which can only be unlocked by the corresponding ScriptSig. The different types of common ScriptPubkey are encoded in addresses of various forms. Notice that they are actually tiny scripts that support limited operations in the special stack-based virtual machine inside Bitcoin.

The interBTC system currently supports 4 types of addresses: P2PKH, P2SH, P2WPKHv0 and P2WSHv0. The vaults can freely register any type of address. One of these types is particularly interesting, P2SH – Pay To Script Hash. This feature has a subtle quirk: any ScriptPubkey can be encoded in a vault address with just its hash, and the actual ScriptPubKey will only be provided by the corresponding ScriptSig (and verified against the stored hash). Subsequently, the rest of the ScriptSig (which is not checked against any hashes), just like the key to a lock, can be forged arbitrarily to match the mutable ScriptPubkey!

The malleability of ScriptSig is not a nightmare until it is used in a SPV system. Due to the reduced amount of information stored in SPV, there is no way to lookup the matching ScriptPubkey of a ScriptSig (unlike a full node, which can look it up in the chain). So the system has to extract the ScriptPubkey/address from the ScriptSig. The extraction of the address must be accurate, otherwise

• Attack 1: If the correct address is not recovered from the ScriptSig, the use of the uxto will not be considered as the action of the vault, thus the misbehavior will never be confirmed by report_vault_theft.

• Attack 2: If the extracted address is misinterpreted as an address of another vault, the benign vault will be slashed by report_vault_theft.

Unfortunately, the address extraction algorithm is neither sound nor complete. For example, it only accepts a subset of valid addresses and detects the P2SH address by checking if the first opcode is OP_0. If the ScriptSig violates the hardcoded templates of P2SH and P2PKH, the correct address will not be recognized, leading to Attack 1. If the ScriptSig is carefully crafted by the attacker, any P2PKH or P2SH addresses can be counterfeited. That is Attack 2. It's worth noting that Attack 1 can be a side-effect of Attack 2.

In the POC, I use a P2SH address corresponding to a special redeem script and construct a transaction by spending from that P2SH address. The redeem script consumes 3 elements from stack: [fake sig, fake pubkey, real sig]. It has two OP_NIP opcodes that drop the first two elements of the input stack. The remaining real sig is verified with the hardcoded real pubkey. Because the first two elements, sig and pubkey, are pushed into stack just like other common P2PKH scriptsig, the extracted address from this scriptsig will be just like a normal P2PKH address from the fake pubkey (the fake sig is unused), thus leading to Attack 2. The transaction has been confirmed in the testnet. Full Report.

Patching the design failure is tricky: introducing stricter validations means more chances of missing actual thefts. The interlay team handled the issue quickly and decided to deactivate the vulnerable theft reporting functions. However, my exploration didn’t stop here.

Bonus: Segwit Address Confusion

The P2SH address is not the only type of address with a customized script. P2WSH, the segwit version of P2SH, works in a similar fashion, but the script is revealed inside of the witnesses instead of the ScriptSig. P2WPKH is another specially handled address type, validating the user public key embedded in witnesses. For both cases, there is a deterministic algorithm to infer the correct address from the witnesses. I failed to break the segwit style addresses at first, but eventually I found a weakness!

The extraction algorithm only cares about the last element of the witnesses, because it is either the public key for P2WPKH, or the ScriptPubkey for P2WSH.

So, how can an SPV system determine the exact type of the original address in the unified algorithm? Heuristics again! If the witness of P2WSH address looks like a valid public key:

1. length in 33 bytes

2. first byte is ‘\x03’ or ‘\x04’

then it is considered a valid P2WPKH address.

Some knowledge of the opcodes is required for building this tricky script. The confirmed transaction is on the testnet.

Downgraded Security?

In the postmortem of the interlay team, they have decided to remove the theft reporting functions. As we have discussed in the first section, the removal of fraud proof downgrades the security: it degenerates interBTC into a basic over-collateralization system, just like Synthetix. Will it be a problem? In theory, its economic security is unaffected.

There is no guarantee that a vault still holds BTC, but the value at risk for the vault is still the same. So if a vault does not send BTC at the time of redemption it is still the same decision process: keep BTC or lose collateral at the time when the user redeems.

However, the security achieved through sophisticated economic designs does not always work. While searching for more instances of failed fraud proof, I came across an unexpected protocol, ONEBTC, the “Trustless Bitcoin on Harmony”. They listed interlay/BTC-Bridge and interlay/BTC-Bridge-Spec in their references! Their code looks like an old version of interlay BTC bridge, with some random customizations (comment out some functions deliberately).

In OneBTC.sol, they have implemented reportVaultTheft and reportVaultDoublePayment! But these functions are restricted by requiring relay.isApprovedStakedRelayer(msg.sender), and they don’t really parse the transactions – they just slash anybody unconditionally!

I have not verified if they had ever used the fraud proof functions, but even if that happened, it would not be in a trustless style as they claimed (and users expected). It turned out that the “optimistic” and semi-trustless bridge worked pretty well, the decentralized nature of vaults were immune to the compromised private key! The ONEBTC bridge was the only survivor of the epic nine figure hack.😓

Funds SAFU? Maybe not... The fluctuation of its collateral, Harmony (ONE), caused a huge risk of under-collateration. The emergency (still ongoing!) freeze of the bridge reinforced the crisis. The users might not be able to cash out, but the vault operators can leave this dangerous game freely, because the raw Bitcoin is unstoppable!

Closing Thoughts

Given the potential for deceit that we find again and again in not just crypto, but almost every inter-human transaction, did we truly expect it to hold secure? Humans have been forging coins, cash, and checks for centuries. Is it really unexpected that, given the chance, we would forge scripts?

What keeps the darkness at bay? I hope that, in a small part, I've helped keep it at bay with this report. Perhaps there was a potential future with a headline of an interBTC hack that now won't happen. Perhaps not. But what there is, is you. I am but one hacker, just months into my crypto journey. You can come walk it with me: what took me months can take you weeks, and you, too, can keep crypto safe.

💡 Read the original post here: https://pwning.mirror.xyz/okyEG4lahAuR81IMabYL5aUdvAsZ8cRCbYBXh8RHFuE

My blockchains adventure continues! This time I protected Moonbeam network by disclosing a critical design flaw, safeguarding more than $100M assets at risk in various DeFi projects. I was awarded the maximum reward amount of their bug bounty program on Immunefi, $1M, and $50k bonus from Moonwell (I guess that’s also one of the top 10 highest bug bounties?)

After reporting the bug in Aurora engine, I started to think about the other potential misuses of delegate calls of native contracts. The original purpose of the delegatecall was to provide a mechanism through which one smart contract could share and reuse the code of another one’s to avoid the overhead of duplicated code storage. Native contracts are usually prebuilt contracts that implement special functions as extensions of the original EVM.

Now, the tricky part: if you delegatecall to a native contract, you may be able to execute some unexpected functions, even privileged ones! However, the developers of those native contracts might not realize that the actual user of the functions could be someone else. In the Aurora bug's case, the native contract just assumes the caller will always be a magical address, so the hardcoded log emitter leads to the malicious withdrawal vulnerability.

What other assumptions could be wrong? When you do a delegatecall, the calling context is inherited from the previous one, including the msg.sender and msg.value. From the view of a native contract, the contract that invokes delegatecall is transparent: its caller will be considered the real user instead. So if a malicious contract is invoked, it can impersonate its caller to operate on the native contracts!

Shadow in the Moonbeam

Moonbeam and Moonriver are both EVM-compatible platforms. There are some precompiled contracts in moonbeam runtime which are shared between Moonbeam and Moonriver.

The Balance ERC-20 precompile provides an ERC-20 interface for handling the native tokens (MOVR & GLMR) of balance. The implementation Erc20BalancesPrecompile is in moonbeam/precompiles/balances-erc20/src/lib.rs.

The designer did not take the usage of delegatecall in EVM into consideration. A malicious contract can pass its msg.sender to the precompile contract to impersonate its caller. In this scenario, there is no way for the precompile contract to figure out the actual caller. The attacker can either increase the allowance from the victim or transfer the available balance immediately.

There are similar issues in the Asset ERC-20 precompile, which provides an ERC-20 native implementation of interoperable tokens (xcKSM, xcDOT, ...). The implementation Erc20AssetsPrecompileSet is in moonbeam/precompiles/assets-erc20/src/lib.rs.

However, the designer did consider the usage of delegatecall in EVM for this case. The ERC20Instance contract in the tests has implemented approve_delegate(), transfer_delegate() and transferFrom_delegate(), with test cases ensuring their validity. Unfortunately (or, for us, fortunately!), it turns out that the design logic can not work properly, so they have removed the relevant code in their patch.

Here is a simple exploit that can be reused in both cases: the `asset` address of native token is 0x0000000000000000000000000000000000000802 and the asset address of a local token could be 0xFfFFfFff1FcaCBd218EDc0EbA20Fc2308C778080.

Perfect Contracts, or Perfect Victims?

What can we do with the design flaw? The basic idea is to ask someone to trigger your malicious contract, e.g., calling the `trap()` in the POC contract.

How can we persuade users to invoke some mysterious contracts? By Airdrop! The hackers behind the UNIH token have demonstrated the crypto-native solution of phishing! Any user who wants to sell an airdropped token in uniswap has to call the malicious token contract to approve the DEX to spend their balance. Due to the vulnerable design of RUNE tokens, where only the tx.origin instead of msg.sender is checked for approval, all the RUNE tokens could be stolen by a trojan contract.

The phishing idea is creative, but it strongly limits the potential damage of the vulnerability. We want to find a better victim that is

1. willing to call your contract

2. not as smart as users

3. rich!

Who are the best friends of poor hackers? The flash loan providers! They hold a lot of money and call your contract callbacks as you wish! In the flash loan callback, they are forced to approve your future transfer of their asset tokens, even if they are flawless contracts!

Some DEX pairs support callbacks to arbitrary contracts, such as SolarBeam on MoonRiver and StellaSwap on Moonbeam. The stable swap pair between xcKSM and stKSM is also vulnerable due to the support of flash loans. If one token can be drained from the trading pair, then the other token can be moved out in one single swap, all the liquidity will be cleared.

Now the perfect written contracts become perfect victims. By the time I reported, the richest vulnerable contracts were:

• 0xea3d1e9e69addfa1ee5bbb89778decd862f1f7c5 on Moonriver, SolarBeam LP Token, $7.5M

• 0xa927e1e1e044ca1d9fe1854585003477331fe2af on Moonbeam, Stella LP Token, $2.7M

• 0x77d4b212770a7ca26ee70b1e0f27fc36da191c53 on Moonriver, xcKSM & stKSM pair, $2.4M

These tokens are worth about $12.6M, even a 10% potential loss is already more than $1M, the maximal bounty prize that Moonbeam offers. But real hackers won’t be stopped by trivial achievements, will there be any crazier victims?

the Glimmer

The native tokens MOVR (on Moonriver) and GLMR (on Moonbeam) are equivalent to ETH on Ethereum. To be used in DeFi protocols, they have to be wrapped in ERC-20 compatible token contracts, just like WETH.

The Balance ERC-20 precompile provides the native wrapper of the native tokens. None of any deployed protocols ever use it because the official wrapped tokens WMOVR and WGLMR are more widely adopted. By leveraging the vulnerability of the Balance ERC-20 precompile, we are able to steal the native token balance from any userif it invokes the malicious contract. Unlike the Asset ERC-20 precompile tokens, e.g., xcKSM and xcDOT, which are directly used by DEXes, MOVR and GLMR balances are rarely used by smart contracts.

Most contracts with non-zero balances are multisig wallets, which are not so different from the externally owned accounts. The only exception, our glimmer of hope, is the MGlimmer contract of the Moonwell project.

The Moonwell project is the dominant DeFi protocol on Moonriver. It has nearly $200M in supply and $100M available for borrowing (at the time I reported). MGlimmer, or Moonwell: mMOVR Token is the specific contract that handles the lending and borrowing against MOVR, and it has the native MOVR in its balance.

The cool thing is that when it transfers the balance to the user, it will call the destination as a contract! Here is a simple exploit that gains the approval of spending all the balance of MGlimmer.

The balance stored in the vulnerable contract is not too much (a few thousand of MOVR now). Still, any amount you deposit into that contract will be considered your collateral in this lending protocol. The exploit can be further weaponized by repeating the deposit → borrow → transfer all back → leave bad debt procedure. All borrowable assets can be drained!

It could absolutely be in the top 10 heists of DeFi history if any hacker took all the $100M borrowable assets plus $12M vulnerable tokens in DEX pairs! Another amazing fact about these vulnerabilities is that actual attacks could be super stealthy by only keeping the unauthorized privilege instead of stealing immediately. Since the contracts themselves are flawless, it’s almost impossible for the developers of those DeFi projects to figure out what is going wrong!

Responsible Disclosure

Everybody is struggling in the bear market. I don’t want to hurt anyone, I want to help, especially when they are such hard working teams. So I tried my best to help the project teams understand the root causes and speed up the patching process.

The situation here is extremely complex at first. The flaw is in the deep core of the blockchain system, but the victims are the DeFi protocols built on top of it. Some protocols may have emergency exits to pause and upgrade their contracts, while others are just immutable.

The ultimate patch has to be made by the Moonbeam team, but the biggest victim, Moonwell, could have mitigations for this vulnerability before the actions of the Moonbeam. I noticed that both Moonbeam and Moonwell had launched their bounty program on Immunefi, so I discussed with the Immunefi team the potential special case (without disclosing the specific name of the projects). After realizing that other projects, like the uniswap style DEXes, can not really do anything useful, I decided not to report to them to minimize the risk of leaking the critical information. Since only the Asset ERC-20 issue might be a problem for the Moonwell team, I have to split the report for Moonbeam into two parts, only the necessary information and the exclusive GlimmerExploit POC are submitted to them.

I took special care of the Moonbeam team, even if they might not be aware of that. I spent extra hours learning their code base and writing two complete test cases (600+LOC) just in case they needed more explanation of the root cause. I asked the common timezone of the PureStake team in their discord to make sure I submit the report once the first engineer comes to work. Luckily, it worked out: they started handling this issue on Friday and finished the patch before the weekend without any inquiries!

Is this the last unexpected flaw hiding near the core design of blockchain-based smart contracts? Certainly not! For every delegatecall, there's another, even wilder issue hiding in the darkness. There are always other, more exotic issues waiting for me!. Stay with me on my journey as I find these bugs, push them into the light, and make the blockchain safer for everyone!

💡 Read the original post here: https://pwning.mirror.xyz/CB4XUkbJVwPo7CaRwRmCApaP2DMjPQccW-NOcCwQlAs.

Hi! I am pwning.eth, a wanderer in the hacking space who has recently jumped into the wonderland of crypto. A few months ago, I reported a critical bug in the Aurora Engine, a layer 2 EVM solution built on the NEAR protocol. At least 70000 ETH were at risk of being stolen, until I found the tricky vulnerability and helped the Aurora team fix it. It would be in the top 5 heists in the defi history, if the 200 million tokens were taken over by a blackhat hacker. In the end, I won a bug bounty of 6 million, which was the second highest bounty in history.

I am an experienced whitehat hacker from the web2 world. I have been watching the hacking drama in the crypto world for a while, and there is so much randomness! I am not too surprised at the astronomical profits of defi hackers, because the criminals in the real world also make an insane amount of money. However, I was really shocked by the story of saurik, a famous hacker in the jailbreak community. The size of his bug bounty is unheard of in the traditional security world, and so I can’t wait to start my own treasure hunt in web3.

I started by checking the bounty list on Immunefi. The Aurora bounty program, listed on the very top of the website due to its huge bounty offer, caught my eye. It was a novel project built by a group of talented engineers, which suggested that it might be complex enough to be immune to common defi hackers and mysterious enough for me to learn something magical. Thanks to my experiences in hacking modern complex systems, I was able to start my research on the new blockchains quickly. I had reviewed the Aurora bridge, which was a solid project. Then I moved on to the Aurora engine and discovered the unicorn bug in a few hours. Unlike ordinary defi vulnerabilities, I didn't think this bug could be identified by random people as fast or lucky as me, so I took my time verifying and reproducing the bug in case it was a false alarm. It took me a few days to learn, build, learn, test and finally finish the report.

I tried pinging the Aurora team in discord, sending messages to the official bounty email and submitting the issue through Immunefi. They confirmed and patched the vulnerability quickly, and have since recounted the general story. Their rewards for smart contract critical vulnerabilities are calculated as 10% of potential economic damage of their exploitation, up to a value of $6,000,000 USD. In this case, the potential damage could have been higher than ten times this maximum reward. Therefore I was eligible to receive the maximum possible amount, the total value of $6,000,000 USD, in the form of locked AURORA tokens. It’s a pretty smart and lucky move to be listed on Immunefi :)

The technical details have been explained by Immunefi. Here is my short summary:

1. The Aurora engine implements token bridging in prebuilt contracts at hardcoded addresses. They are the magical bridges connecting Ethereum, NEAR and Aurora.

2. The vulnerable contract always emits a fixed address in bridging events, assuming the msg.value will be collected by itself. However, if the contract is invoked by delegatecall(), the msg.value will never be sent to the contract but the log will be emitted as usual.

3. By repeating the malicious withdrawal then redeposit process, the attacker can double their balance exponentially. The infinity inflation of ETH could have destroyed the whole ecosystem of Aurora: all 71k ETH in the aurora account could have been drained, and other valuable tokens could have been purchased by free ETH. (There were billions of TVL in the Aurora bridge.)

If you are hardcore enough, you may find the original report and scripts interesting, enjoy!