⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

From 12th August to 2nd September 2024, the ThunderNFT protocol hosted an Invite-Only Program (IOP) on the Immunefi platform for researchers to hunt on code for their unique NFT marketplace on Fuel, an L2 on Ethereum that utilizes Fuel VM.

An IOP is a form of Audit Competition which is exclusively accessible to a select group of security researchers, and in this case, they consist of researchers who have submitted at least 1 valid report during the Fuel Attackathon event.

A total of 12 researchers were invited to compete, and 41 valid reports were rewarded from a pool of $65,000 USDC.

Here are the top three findings from the Shardeum Ancillaries audit competition, as identified by the Immunefi team. As of this publication, all vulnerabilities have been FIXED.

1. Insufficient validation in order modifications leading to the theft of NFTs — 34980

• Finder: Solosync6
• Severity: Critical
• Asset: https://github.com/ThunderFuel/smart-contracts/blob/main/contracts-v1/thunder_exchange/src/main.sw

The contract includes a functionality that allows users to update their orders from the buying side to the selling side using the update_order(…) function. However, a vulnerability exists in the update_order(…) function due to insufficient validation of NFT ownership.

It is important to note that switching sides is permitted within _validate_maker_order_input.

However, critically, there is no validation to ensure that the attacker actually owns the NFT when the order side is changed. This flaw enables a user to set a sell order for an arbitrary NFT without properly verifying ownership.

On cancellation, the NFT asset is transferred back to the maker, only this time, the maker was never the original owner of the NFT.

An attacker can exploit this by calling the cancel_order(…) function. During the cancellation process, the contract relies on the strategy contract to return the correct order information without performing additional ownership verification. This allows the attacker to transfer an arbitrary NFT to themselves, resulting in the theft of the NFT.

PoC and Exploit Steps:

1. Create buy orders for valuable NFTs they do not own.
2. Convert these buy orders into sell orders without actually owning the NFTs.
3. Cancel these “sell” orders, potentially gaining possession of NFTs they never owned.

Here is a test case that showcases the above exploit.

2. Hardcoded Logic in Execution Result Library Leads to Maker Losses — 34534

• Finder: NinetyNineCrits
• Severity: Critical
• Asset: https://github.com/ThunderFuel/smart-contracts/blob/main/contracts-v1/libraries/src/execution_result.sw

The project allows makers to specify the desired quantity of an assetId through the MakerOrder struct as shown below.

However, when an order is fulfilled, the maker receives only a single unit of the assetId regardless of the specified quantity. Despite this, they are charged the full price for the order due to a hardcoded value in the contract.

When a taker fulfills a maker’s order, the _execute_sell_taker_order function verifies that the taker has sent the required amount of tokens as part of the transaction call:

Currently, execution_result.amount is hardcoded to 1, meaning the maker always receives only 1 unit of the specified tokenId, regardless of the quantity requested. This mismatch results in unexpected losses for the maker.

For ERC1155 tokens, the maker always receives only 1 unit of the specified tokenId, regardless of the requested quantity, resulting in unexpected losses.

PoC and Exploit steps:

1. Deploy and initialize all project contracts, ensuring proper references between them.
2. Deploy a simple ERC1155 contract that allows arbitrary token minting.
3. The taker (seller) mints 10 tokens for themselves.
4. The maker (buyer) places an order for 10 units of the same AssetId minted by the taker.
5. The taker fills the order but transfers only 1 unit (the transaction fails if more units are transferred).
6. Verify that the maker received only 1 unit of the ERC1155 token instead of the requested 10 units.

Here is a test case that showcases the above exploit.

3. Flawed Logic in ThunderExchange: NFT Owners with Sell Order Blocked from Accepting Bids — 34714

• Finder: zeroK
• Severity: Medium
• Asset: https://github.com/ThunderFuel/smart-contracts/blob/main/contracts-v1/thunder_exchange/src/main.sw

The _execute_sell_taker_order function validates msg_asset() when the user calls the execute_order function, making it impossible for the NFT seller to accept any bids.

This is because the place_order function requires the seller to transfer the NFT to the Thunder Exchange, leaving the seller without the asset_id (the NFT).

To list an NFT, the owner must call the place_order function with Side == Sell.

When the seller decides to accept a bid, they need to call the execute_order function with Side == Sell.

However, the call to execute_order fails because the user is required to use the transfer function in Sway. This built-in function includes critical checks enforced by the FuelVM, one of which ensures that the caller possesses the specified asset_id and the required amount.

This makes it impossible for the seller to accept any bids; they must either wait for someone to buy the NFT directly or cancel the order.

As a result, sellers are unable to accept bid offers due to incorrect logic in the _execute_sell_taker_order function, which causes the transaction to revert when a bid is accepted.

PoC and Exploit Steps:

1. Initialize all necessary contracts and configure them, including adding strategies and assets.
2. The NFT owner places a sell order, transferring their NFT to the ThunderExchange contract.
3. A bidder places a buy order targeting the same NFT but at a lower price.
4. The NFT owner attempts to accept the buy order, but the execute_order function fails as the NFT is no longer in their possession.
5. The PoC highlights a logic flaw that prevents NFT owners from accepting bids while their NFT is listed for sale.

For more interesting bugs and writeups about web3 security, do check out our Medium as well as follow our X/Twitter to get daily updates!

Top 3 Bugs from the ThunderNFT Invite Only Program was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

From July 8 to August 14, 2024, the Shardeum protocol hosted two simultaneous audit competitions on the Immunefi platform, Shardeum Core and Shardeum Ancillaries, welcoming top whitehat talents to find vulnerabilities within their unique EVM-based network infrastructure.

52 of the very best submissions of various severities from participating whitehats were rewarded from a pool of up to $500,000 USDC.

Here are the top three findings from the Shardeum Ancillaries audit competition, as identified by the Immunefi team.

Throughout the event, an active development phase was in progress, allowing for real-time fixes of the identified issues. As of this publication, all vulnerabilities have been FIXED.

1. Malicious Archiver can overwrite account data on any active archiver — 34508

Finder: periniondon630

Severity: Critical

Asset: https://github.com/shardeum/archive-server

Archive servers are responsible for maintaining transaction receipts and sharing them across the network using the gossip endpoint. When an archive server receives a receipt, it invokes the collectMissingReceipts function to check whether the receipt is unique.

If the receipt is unique, collectMissingReceipts forwards the receipt data to the storeReceiptData function to log the transaction.

As we can see, the collectMissingReceipts function only validates if the supplied receipt data contains txId and txTimestamp and doesn’t filter or strip out any extra data from the receipt object before forwarding it to the storeReceiptData function, which allows a malicious actor to attach extra fields related to account settings in the receipt.

When storeReceiptData processes the attacker-crafted receipt containing global account config fields, it interprets those fields as instructions to update the account settings.

The exploit steps are as follows:

1. A malicious archiver initiates a gossip request to the victim archiver.

2. The victim archiver requests details about the receipt.

3. The malicious archiver sends crafted receipt data that replaces the global network account.

4. The victim archiver stores the data, resulting in changes to the global network account settings.

2. Bypassing Same-Site Through XSS to Shutdown Node — 33692

Finder: neplox, @neploxaudit

Severity: Low

Asset: https://github.com/shardeum/validator-gui

Before delving into the technical details of the vulnerability, let’s look at the SameSite=Strict attribute, a browser security mechanism used in the validator-gui for Cross-Site Request Forgery (CSRF) protection.

CSRF attacks occur when an attacker tricks a victim into performing unintended actions on a website where they are already logged in. For instance, the attacker might lure the user into submitting a form on a malicious site, which then sends a request to vulnerable.com/account/settings to make unauthorized changes.

When cookies are set to SameSite=Strict, however, the browser is restricted from including cookies in cross-site requests. While this reduces the risk of CSRF attacks, it doesn’t provide complete protection. Cookies are still included in same-site requests from different subdomains or ports within the same top-level domain (e.g., app.vulnerable.com or vulnerable.com:1337).

If you are interested in learning more about SameSite cookies, check out this amazing article: The great SameSite confusion

In this case, validator-gui relied solely on SameSite=Strict to protect against CSRF, without associating unguessable and random tokens with HTTP requests. A whitehat exploited the lack of a CSRF token at <validator-gui>/api/node/stop by chaining an XSS vulnerability in shardus-core, as these applications are likely to be hosted on the same server.

The validatorListRoute function of shardus-core, located in /src/p2p/SyncV2/routes.ts , retrieves a list of validators based on a hash in a GET request. If the hash doesn’t match any records, the function returns a 404 error with the user-supplied hash unsanitized:

res.status(404).json({ error: `validator list with hash '${expectedHash}' not found` })

This means an attacker could execute malicious JavaScript code by crafting a URL like this:

https://shardus-core.example.com/validator-list?hash=<img src=x onerror=fetch("https://validator-gui.example.com/api/node/stop")>

The exploit steps are as follows:

1. The victim authenticates to validator-gui.example.com.

2. The malicious actor tricks the victim into visiting following URL to trigger the XSS:

https://shardus-core.example.com/validator-list?hash=<img src=x onerror=fetch("https://validator-gui.example.com/api/node/stop", {"credentials":"include","method":"post"})>

3. The browser sends a request to https://validator-gui.example.com/api/node/stop using the victim’s session, due to “credentials”: “include”.

4. The node is shut down without the victim’s knowledge

3. Archive-Server can be killed by connected shardus-instance — 34298

Finder: riproprip, @riproprip

Severity: Medium

Asset: https://github.com/shardeum/archive-server

The Archive Server uses an outdated version of Socket.IO that is vulnerable to CVE-2023–32695, allowing a connected shardus-instance to crash the Archive Server by sending a malformed packet.

A typical Socket.IO packet looks like this:

42["eventName", "String Value", {"Object": "value"}]

However, a malicious shardus-instance can send a packet like:

42[{"toString":"1337"}, "1337"]

When the Socket.IO parser in the Archive Server processes this packet, JavaScript tries to convert the object to a string by calling the toString() method. If toString is defined as a property instead of a function, it will cause an error because it cannot be invoked as a method.

Proof of concept:

Install packages and replace encoder with evil encoder:

Run evil shardus instance:

node evil-shardus.js

Top 3 Bugs from the Shardeum Ancillaries Audit Competition was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

From July 8 to August 14, 2024, the Shardeum protocol hosted two simultaneous audit competitions on the Immunefi platform, Shardeum Core and Shardeum Ancillaries, welcoming top whitehat talents to find vulnerabilities within their unique EVM-based network infrastructure.

52 of the very best submissions of various severities from participating whitehats were rewarded from a pool of up to $500,000 USDC.

Here are the top three findings from the Shardeum Core audit competition, as identified by the Immunefi team.

Throughout the event, an active development phase was in progress, allowing for real-time fixes of the identified issues. As of this publication, all vulnerabilities have been FIXED.

1. Account balance can be manipulated due to broken signature verification — Report 34456

Finder: neplox, @neploxaudit

Severity: Critical

Impact: Direct loss of funds

Asset: https://github.com/shardeum/shardus-core/tree/dev

It was possible to overwrite the account data of any address in the network on all validator nodes at once, effectively changing the state of the account in the whole network.

There are two internal protocol endpoints called repair_oos_accounts that are legitimately used by Shardeum validator nodes to restore broken accounts after consensus is reached.

However, the “repaired” account information is simply passed as an argument and its signatures are not verified. This fact allows to forge and send a request to “restore” any account to any value, breaking the intended AccountPatcher trie hash consensus mechanism.

2. Taking over the network with Golden Ticket — Report 33696

Finder: ZhouWu

Severity: Critical

Impact: Network not being able to confirm new transactions (total network shutdown

Asset: https://github.com/shardeum/shardus-core/tree/dev

An attacker could become part of the validator network without fulfilling the necessary conditions. This was made possible by the Golden Ticket system built into the protocol. This mechanism is intended for protocol operators, but insufficient ticket validation allows anyone to use it.

By gaining the majority of seats in the validator network, the attacker will gain control of the consensus and through this will be able to control the data in the network and the availability of the network.

3. Decentralized operations could be performed without necessary consensus — Report 33632

Finder: neplox, @neploxaudit

Severity: Critical

Impact: Network not being able to confirm new transactions (total network shutdown)

Asset: https://github.com/shardeum/shardeum/tree/dev

A malicious validator can mislead other nodes to sign data using unexpected fields in signAppData.

Due to lack of input validation in signAppData malicious validator can make network nodes to sign arbitrary data. The signAppData checks if appData has required fields: nominator, nominee, stake, certExp, but doesn’t check the presence of unexpected extra fields.

By obtaining the necessary signatures, an attacker can perform extensive reconfiguration of the Shardeum network up to full control of the network.

Top 3 Bugs from the Shardeum Core Audit Competition was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

From June 17th to July 22, 2024, Fuel protocol ran a month-long Attackathon on the Immunefi platform, welcoming top whitehat talents to find vulnerabilities within Fuel’s Layer 2 infrastructure. With a reward pool of up to $1 million USDC, participants were successful in uncovering interesting bugs with various severities.

These vulnerabilities are now FIXED, as of publication.

Here are the top five findings, as identified by Immunefi’s triagers, that showcased critical vulnerabilities and enhanced the security of the Fuel Network.

1.Messages to L1 included during reverts allows theft from bridge — Report 32965

Severity: Critical

Impact: Direct loss of funds

Asset: https://github.com/FuelLabs/fuel-core/tree/v0.31.0

The function executor/src/executor.rs::update_execution_data adds all message_ids from the MessageOut receipts of the current tx to the execution data even if the tx itself has reverted.

This means it’s possible to send out messages to the L1 but revert the tx, which un-does the burn of the bridged tokens. This fake withdrawal can be repeated over and over, with the messages still being relayed on the L1, potentially allowing the theft of all tokens from the bridge.

The exploit steps are as follows:

1. The attacker and victim both deposit the same amount of the same token
2. The attacker withdraws 2 times. For the first time, he reverts his transaction at the end, and the second time follows the regular flow. He can relay this twice, which will result in the attacker having double the amount of tokens he originally deposited.
3. As the victim withdraws, the process on the L2 side will be successful and his tokens will be burned. The relay process on L1 will fail, due to underflow (no tokens left)

2.ABI Supertraits are available externally — Report 33351

Severity: Critical
Impact: Direct loss of funds

Asset: https://github.com/FuelLabs/sway/tree/v0.61.2

ABI supertraits are, as the docs say, intended to make contract implementations compositional. As such they allow defining methods that can be inherited by the contract implementing the trait. However, what is essential is that these methods shouldn’t be available externally as contract methods. However, this is not the case, and the methods are available externally.

As we can see in sway-core/src/language/ty/program.rs::validate_root, ABI supertraits should not expose their methods to the user.

The following example demonstrates how the renounce_ownership function is available externally when inheriting the Ownable traits. An attacker would have access to any supertraits of a contract.

3.Sway compiler wrongly modeled register usage of WQAM instruction — Report 32269

Severity: High

Impact: Incorrect sway optimization leading to incorrect bytecode

Asset: https://github.com/FuelLabs/sway/tree/7b56ec734d4a4fda550313d448f7f20dba818b59

The sway/sway-core/src/asm_lang /virtual_ops.rs::def_registers function and sway/sway-core/src/asm_lang /virtual_ops.rs::use_registers function are used to define which registers in the argument will be written to or read from by the given instruction. This information is used in DCE optimization to decide which instructions only write to “dead” registers and could be removed.

DCE is an optimization pass most compilers make which eliminates dead code (code that does not affect the program results). This decreases program size and increases program efficiency by eliminating unused instructions. However, the Sway DCE optimization step incorrectly labeled instructions which had results which were used as dead code, which were then removed from the output bytecode of the compiler.

In the function sway/sway-core/src/asm_lang /virtual_ops.rs::use_registers, we can see that WQAM is incorrectly thought to modify r1 while not relying on its value, while the actual behavior of the WQAM instruction uses r1 as a memory pointer.

4. Lack of Overflow Protection in pow Function for Unsigned Integers in standard libraries — Report 33227

Severity: Medium

Impact: Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield

Asset: https://github.com/FuelLabs/sway/blob/ebc2ee6bf5d488e0ff693bfc8680707d66cd5392/sway-lib-std/src/math.sw

The pow function implementations for the u8, u16, and u32 types in the Sway standard math library lack overflow protection. Overflow for larger data types like u64 and u256 is handled by the Fuel Virtual Machine (VM), but the VM does not handle overflow for the smaller types (u8, u16, u32). Consequently, when the result of the pow function exceeds the maximum value of the data type, the result wraps around without raising any errors. This can lead to incorrect calculations on the integration side of the contracts.

As we can see the issue is in the following Power function implementation for the types u8, u16, and u32 in the Sway standard library that it doesn’t handle the overflows.

Here’s the PoC that demonstrates the overflow vulnerability for the data types u8 and u32.

The following test case demonstrates how the value of u8 and u32 exceeds the maximum limit of their respective types, resulting in an overflow and producing an incorrect, wrapped-around value.

5.Exploiting CCP Instruction for Low-Cost Memory Clearing via Code Copy with Zero-Fill — Report 32465

Severity: High

Impact: Modification of transaction fees outside of design parameters

Asset: https://github.com/FuelLabs/fuel-vm/blob/c21af9c8eazfff020ddf468b51d9bcb58a0bb2295/fuel-vm/src/interpreter/blockchain.rs#L887

The CCP (Code Copy) instruction copies code from a specified contract into memory, charging gas based on the contract’s total size rather than the actual number of bytes copied.

By manipulating the offset and length parameters, users can trigger a scenario where the function zero-fills large memory areas without incurring the appropriate costs, effectively performing a cheap memory clear operation.

This exploit allows users to perform expensive memory clearing operations at a significantly reduced gas cost. By underpaying for resource usage, it can lead to network resource exhaustion and potential denial-of-service attacks, compromising the stability and security of the system.

The code_copy function invoked by the CCP instruction loads the target contract’s bytecode, charges gas based on its length, and then copies data with zero-fill using a different length parameter. Here’s how it works:

The copy_from_slice_zero_fill function handles copying and zero-filling: By choosing a large offset that exceeds the length of the contract’s bytecode, the data slice becomes empty (unwrap_or_default() returns an empty slice). The copy_from_slice operation does nothing, and the entire memory range specified by len is filled with zeros:

Users can clear large memory areas cheaply, bypassing the proper gas charges for memory operations.

Here’s the PoC test case demonstrates how the CCP instruction can be exploited to clear memory cheaply:

*Changes: Report #5 was misidentified as 33519, it was corrected to 32465. The gist will also be updated shortly.

Top 5 Bugs from the Fuel Attackathon was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

Summary

On August 20th, 2023, one of our top 50 whitehats, Kayaba, identified a vulnerability in Threshold Network’s tBTC. This vulnerability was concerned with the inherent malleability of Bitcoin transactions, which, in combination with the Threshold Network’s SPV proof verifier, allowed arbitrary transactions to be included using feasible brute force.

In recognition of Kayaba’s discovery, he was rewarded with $50,000 worth of Threshold’s T tokens.

What is the Threshold network?

The Threshold Network is a collection of related decentralized services based on “threshold cryptography”, which is a type of consensus encryption/decryption protocol relying on the cooperation of multiple secret-keepers to decrypt or access a secret, similar to how multi-signature wallets work.

The “threshold” is a minimum number of signers or network participants who are needed to sign a transaction or approve a network action. This is an oversimplification of course, but it’ll work for understanding this vulnerability.

For the full exploration of threshold cryptography, it’s highly recommended that you check out this article by the Massachusetts Institute of Technology.

One of these services is tBTC, which provides an asset bridge from the Bitcoin blockchain to the Ethereum mainnet, allowing users to use their Bitcoin to access DeFi and other tools in the Ethereum ecosystem.

Bitcoin nodes participating in the Threshold Network use SPV, a more lightweight method that is popular with node operators as it is a less resource intensive way to verify Bitcoin transactions. However, the way that the Bitcoin Merkle root is constructed has some weaknesses, one of which allows for the inclusion of arbitrary transactions when verified by SPV clients.

How is the Merkle tree constructed?

Here’s a visualization of the Merkle tree:

Image source: https://iq.opengenus.org/merkle-trees-and-spvs-in-bitcoin/

Suppose we have four transactions A, B, C & D:

1. Initial Hashing (Leaves of the Tree)

• HashA = SHA256(SHA256(TxA))
• HashB = SHA256(SHA256(TxB))
• HashC = SHA256(SHA256(TxC))
• HashD = SHA256(SHA256(TxD))

2. Pairing and Hashing (Intermediate Nodes)

Pair and hash the hashes obtained in step 1:

• HashAB = SHA256(HashA + HashB)
• HashCD = SHA256(HashC + HashD)

3. Pairing and Hashing Again (Root of the Tree)

Pair and hash the intermediate hashes:

• MerkleRoot(HashABCD) = SHA256(HashAB + HashCD)

The resulting MerkleRoot is then included in the block header.

This structure allows any participant in the network to efficiently verify the inclusion of a transaction in the block without needing to download the entire block. They can validate the authenticity of a transaction by following the path from the transaction’s hash up to the Merkle root.

What is SPV?

SPV, or Simplified Payment Verification, is a method used by light Bitcoin clients to verify transactions without downloading the entire blockchain. Instead of storing the entire blockchain, SPV clients only download block headers, which contain essential information like the Merkle root and block hash.

When an SPV client needs to verify a transaction, it requests relevant information from full nodes in the Bitcoin network. These nodes provide the SPV client with a Merkle proof, a cryptographic method used to confirm the inclusion of a specific transaction within a block.

The proof is crafted by collecting every node along the path connecting the Merkle root to the transaction in question, bundling them together to form the proof.

The hash path is then checked against the Merkle root included in the block header. If the hashes match, it confirms that the transaction is indeed included in the block.

Image source: https://iq.opengenus.org/merkle-trees-and-spvs-in-bitcoin/

For example, to confirm the inclusion of transaction K in a block, a node can provide a path composed of four hashes: HL, HIJ, HMNOP, HABCDEFGH. Utilizing this path, an SPV can calculate four hashes, HKL, HIJKL, HIJKLMNOP and validate K’s presence in the block by comparing the Merkle root.

Vulnerability Analysis:

As mentioned above, SPV is a lightweight method of verifying transactions on the Bitcoin network using information from the block header and merkle proof.

However, since the block header does not contain the number of transactions, SPV clients are not initially aware of the total transactions within the block, and consequently, lack knowledge of the accurate tree depth.

In the merkle tree, the H( ) values consist of 32 bytes, while the T values, representing transactions or leaves of the Merkle tree, are 64 bytes long. To fit the transaction into our merkle tree which only accepts 32 byte values, we must hash the T value resulting in H(T). Now to get the parent node of two leaf nodes we simply concatenate them and hash them H( H(T) . H(T) ).

The hashing of two values within the merkle tree, H( H(T) . H(T) ), looks very similar to the hashing of a valid transaction to be included. If we take our 64 byte transaction and split it into two sides of 32 bytes, T₁ and T₂, we see the parent of T, H(T), can also be described as H( T₁ . T₂ ).

Within this transaction, the last 32 bytes, T₂, are less constrained compared to the first 32 bytes, T₁. This is because the last 32 bytes contain multiple values which are controllable by a transaction creator. This creates the possibility that in a valid 64-byte transaction, the last 32 bytes are intentionally manipulated to collide with the hash of an invalid transaction, F.

If this happens, a node could deceive an SPV client into believing that a non-existent transaction, F, exists in the block by offering a path leading to T, then considering T as a node within the tree structure.

This weakness of Bitcoin’s SPV clients is further discussed in section 3.2 at this linked article. The article also discusses other weaknesses of Bitcoin’s Merkle Root construction, which is a valuable read for any Blockchain/DLT bug hunters. Note that work must still be done to mine for a valid transaction T which collides with the invalid transaction by finding the correct combination of unconstrained values.

The Threshold Network was utilizing the ValidateSPV library, where the prove function first validated the transaction’s inclusion by checking its presence in the proof on line 37. Subsequently, it called the verifyHash256Merkle function, which iteratively computed the Merkle path using the provided proof hashes. It then compared the computed root hash with the expected root hash to ascertain the proof’s validity. However, this logic was vulnerable to explained malleability, where arbitrary transaction inclusion wasn’t effectively detected.

While the Threshold team was already aware of the issue before the report, their initial mitigation strategy did not fully resolve the issue.

The primary concern lies in the inclusion of 64-byte transactions. However, within the tBTC system, transactions deemed valid are consistently longer than 64 bytes. Additionally starting in Bitcoin Core 0.16.1, 64-byte transactions will no longer be accepted to the mempool. This invalidates the attack, since we cannot convince the system the leaf node, or the real transaction, is an intermediary node in the merkle tree since it cannot be split into equal 32 byte parts. Therefore, the vulnerability stemming from the Bitcoin Merkle Tree weakness cannot be exploited within the tBTC bridge contract.

However, there is still a way where an SPV proof can be forged through the use of a coinbase transaction.

The coinbase transaction is the first transaction in a block. It is a special type of transaction that creates new bitcoins and collects the transaction fees paid by users sending transactions. Miners include a coinbase transaction in the blocks they mine. The size of a coinbase transaction can vary but is generally limited to 100 bytes.

A malicious miner could produce a valid 64-byte coinbase transaction that would be accepted by the network. They would then need to prepare a fake transaction whose 32-byte ID fulfills the constraints of the second half of the coinbase transaction.

This inclusion of a valid 64-byte coinbase transaction contradicts the project’s assumptions and was highlighted in the report by the whitehat.

Vulnerability Fix:

Threshold team deployed the fix at this commit to also check for the coinbase transaction.

The fix had two aspects.

1. Length check of coinbase proof and merkle proof:

• As described above, in the Merkle tree, each level halves the number of hashes, forming parent nodes from pairs of hashes. And each transaction in a block is a leaf node. When proving a transaction’s inclusion, a series of hashes connects it to the root. The length of this proof matches the tree’s height, determined by the block’s transaction count.
• The length check ensures that the Merkle proof of the coinbase transaction (the first transaction in the block) has the same length as the proof of the transaction of interest. Since all transactions in a block are on the same level of the Merkle tree, their proofs should have the same length.
• So, by comparing the length on line 195, the code ensures that both transactions are on the same level of the Merkle tree and that no tampering has been done.

2. Validating the coinbase proof on line 222 ultimately ensures that the provided coinbase proof is valid.

Acknowledgments

We extend our gratitude to our elite whitehat, Kayaba, for their exceptional contribution in responsibly disclosing a vulnerability to the Threshold network. Special acknowledgments go to the Threshold network team for addressing the insufficiencies in mitigation, and effectively resolving the reported issue.

If you’re a developer or a whitehat considering a lucrative bug-hunting career in web3 — this message is for you. With 10–100x the rewards commonly found in web2, your efforts will pay off exponentially by switching to web3.

Check out the Web3 Security Library, and start earning rewards on Immunefi — the leading bug bounty platform for web3 with the world’s biggest payouts.

Threshold Transaction Malleability Bugfix Review was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

Summary

On September 23, 2023, the security researcher Koiush submitted a high vulnerability to Alchemix via Immunefi, which consisted of improper configuration of access control for harvesting of yield.

At the time of the submission, the vulnerability would have allowed an attacker to steal yield generated during harvesting in rETH, stETH, and FraxETH pools.

After receiving Koiush’s report, the bug was quickly neutralized by Alchemix’s team with no impact to user funds. Alchemix promptly awarded a bounty of 1,000 ALCX ($28,730) to Koiush for this finding.

Immunefi is pleased to have facilitated this responsible disclosure with our platform. Our goal is to make web3 safer by incentivizing hackers to responsibly disclose bugs and receive clean money and reputation in exchange.

Introduction to Alchemix

Let’s break it down. Alchemix Finance is primarily a synthetic asset protocol that centers around the idea of tokenizing “future yield”.

To achieve this, it has a family of synthetic assets with the prefix “al-” (alETH, alUSD) which allow users to borrow against their yield-accruing deposits in lending/borrow protocols, accessing some portion of this “future” yield upfront.

How it works is, users deposit yield-bearing variants of ETH and DAI, USDC, etc. and then borrow alETH or alUSD against their value. The al-assets can be redeemed for the underlying collateral at any time with some time delay (transmuting), or exchanged instantly at the market rate for any token of value (swap). This system of exchange forms the basis of value, and the main utility of the protocol.

The Alchemix protocol features “Alchemists”, which are the central smart contracts powered by AlchemistV2.sol. This allows users to deposit yield-bearing or underlying assets as collateral in the protocol. Multiple yield strategies are supported in this format, but each “Alchemist” is dedicated to issuing a specific alAsset, such as alUSD.

Alchemix smart contracts allows users to borrow only up to 50% of their collateral’s value, ensuring that all borrowing across the protocol is collateralized by at least 200% in valuable yield-bearing assets. The accrued yield is periodically harvested from these assets, which is then put to work reducing the user’s debt or increasing the user’s borrowing limit if no debt is taken.

To accrue yield, the harvest() function must be periodically called on the Harvester contract. Alchemix utilized Gelato, a smart contract automation service, to manage calls to the harvest() function automatically, ensuring that users can passively earn yield without needing to manually interact with the protocol.

Gelato

Gelato is a Web3 serverless cloud platform that provides roll ups as a service and offers a suite of Web3 Services, such as Functions, Account Abstraction Infrastructure, VRF, and more. Alchemix utilized Gelato’s Web3 Functions system designed to manage and automate smart contract tasks.

The Web3 Functions Automate contract allows projects to create tasks which are analyzed and executed automatically by Gelato’s off-chain cloud services. When a task is created, the following parameters must be specified:

• _execAddress, which is the target of the call
• _execDataOrSelector, which is the function to be called by the automated keeper
• _moduleData which are any conditions / specifications about the task
• feeToken, which is the optional fee token.

Calling the createTask function in the Automate contract emits the TaskCreated event, which is registered by Gelato’s off-chain services to later be executed by the Automate contract through exec.

Optionally, task’s creators have the ability to specify the created task to be executed through a dynamically generated proxy contract by setting the proxy module to PROXY type. This allows target contracts to whitelist the generated proxy contract and limit access to the automated function through onlyDedicatedMsgSender, instead of the call originating from the generic Automate contract which allows any user to create and execute tasks to trigger functionality of a target contract.

Alchemix Harvester

The AlchemixHarvester contract enables the Alchemix contracts to collect outstanding yield from underlying assets and distribute it to token holders.​​ The harvest function in AlchemixHarvester is a proxy for the call to AlchemixV2 contract’s harvest function, where the majority of the logic exists. Within the harvest function, yield tokens are unwrapped for their underlying asset and sent to the Transmuter. The _unwrap function is a critical component that makes a call to the specified yield token’s TokenAdapter contract, which handles the actual unwrapping of the yield-bearing collateral token to the underlying token of a Vault.

Due to some token adapters utilizing Balancer swaps (Balancer is an exchange protocol) to unwrap yield-bearing tokens to collect on accrued yield, the harvest function can be susceptible to MEV attacks (Miner or Maximal Extractable Value, also known as sandwich attacks) which manipulate the price of the asset before and after the unwrapping occurs. Normally, this isn’t an issue, since the harvest function provides a parameter to specify the `minimumAmountOut` for unwrapping.

However, since the AlchemixHarvester contract restricts access to the harvest function by only specifying the caller to be the generic Automate contract address, anyone could create a Gelato task which calls the harvest function with arbitrary parameters.

Vulnerability Analysis

Access control, or the lack of it, is at the heart of this vulnerability. Having proper checks is crucial for limiting access to important assets and functions, ensuring the security and continued safe operation of your smart contracts. Due to its ubiquity, it was found as #4 of the top 10 most common smart contract vulnerabilities identified by Immunefi in 2023.

Alchemix’s Gelato task was not created as a PROXY, meaning the Automate contract would directly call the target contract. This means the harvester contract had to whitelist the Automate contract for the harvest function execution to succeed. However, since Gelato task creation through the Automate contract is permissionless and the same contract will be used for execution unless the task is specified to use a dedicated msg.sender, anyone could create a task which would call the AlchemixHarvester contract and trigger a harvest with arbitrarily specified parameters. An attacker could create a Gelato task that targets the AlchemixHarvester and specify 1 for the minimumAmountOut, which would make the harvest call vulnerable to sandwich attacks.

The attack could be further escalated by specifying a custom contract as the alchemist parameter, causing the resolver to record a harvest, but not actually harvest any yield. This would prevent the Gelato keeper from calling the harvest function, since it utilizes the checker function of the resolver to determine if the conditions for calling harvest have arrived. Blocking the harvest of yield would allow an attacker to accumulate higher unharvested amounts in the vault so the final attack can be more profitably sandwiched.

Editor’s note: the ability to look for ways to maximize profit such as blocking the harvest is an essential skill to learn for whitehats wanting to demonstrate the maximum impact for their vulnerability. Take note of this if you would like to improve your bug-hunting experience!

Of the six ETH-type assets that could be targeted by this attack, there were only three token adapters that had unwrap functions which were vulnerable to sandwiching. And of the three, only the rETH adapter was vulnerable to profitable sandwiching at the time of submission due its configuration best matching the requirements for the attack.

Proof of Concept (PoC):

The Immunefi team prepared the following PoC to demonstrate the vulnerability. You are encouraged to follow along by using Foundry to produce the results and examine them on your own.

The attack first creates a Gelato task to call the AlchemixHarvester contract with a minAmountOut of 1. The attacker would then trigger their automation for the Gelato keeper to call the harvest function, and sandwich the vulnerable swap. The attacker front runs the harvest transaction and manipulates the Balancer pool which is utilized for the unwrapping of rETH in the Alchemix adapter. The attacker can now manipulate the balancer rate back down to recover the collateral deposited for each account in the same block, and is now left with a portion of the accrued WETH.

In the following PoC, an arbitrary harvest transaction call was utilized as a baseline for the amount of yield that would have been accrued in the transmuter and treasury during normal operation operation. The PoC then demonstrates the impact of the attack if the vulnerable harvest call was triggered and subsequently sandwiched by the attacker.

As we can see, after running the PoC, our test scenario resulted in a profit of 4.975 rETH for the exploiter.

Vulnerability Fix

Since AlchemixHarvesters are immutable, and the gelato poker address is set during contract creation, Alchemix would need to migrate Harvesters and update the contracts to utilize a dedicated msg.sender instead of the generic Automate contract address. The contracts were redeployed with an EOA set as the _gelatoPoker.

This remediated the access control issue by replacing the gelato poker address with an Alchemix-controlled EOA.

Acknowledgements

We would like to thank Koiush for doing an amazing job and responsibly disclosing such an important bug. Big props also to the Alchemix team who responded quickly to the report and patched the bug.

This bugfix review was written by Immunefi triager, Alejandro Muñoz-McDonald.

If you’d like to start bug hunting, we got you. Check out the Web3 Security Library, and start earning rewards on Immunefi — the leading bug bounty platform for web3 with the world’s biggest payouts.

If you’re feeling good about your skillset and want to see if you will find bugs in the code, check out the bug bounty program from Alchemix.

Alchemix Access Control Issue Bugfix Review was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

Exciting news! The Floki Ecosystem recently launched a bug bounty program on Immunefi, and they’re offering up to $50,000 for critical bugs!

The Floki Ecosystem is an innovative protocol offering a 3D NFT Metaverse, DeFi utilities, a crypto education platform, NFTs, a merchandise store, and more. The token linked to the project, FLOKI, is designed to work across multiple blockchains, including Ethereum and BNB Chain, as it meets the requirements of both ERC-20 and BEP-20 standards. FLOKI tokens are capable of being transferred between these chains, allowing FLOKI holders the flexibility to use either blockchain for managing and conducting transactions with their tokens.

And now, the Floki Ecosystem has wisely opted to leverage the security expertise of Immunefi. This comes after Web3 saw $53 million lost to hackers in the month of April, bringing total losses to more than $401 million in 2024 so far. This demonstrates that proactive measures are needed to enhance on-chain security and protect users’ funds.

Immunefi boasts the largest and highest-quality pool of security researchers in Web3, comprising over 45,000 experts who’ve prevented more than $25 billion in potential losses. Our talent is unmatched, with more than 1,000 researchers having identified bugs that could have resulted in losses of mainnet funds.

The Floki Ecosystem’s bug bounty program offers between $20,000 and $50,000 for critical threat level bugs, between $2,000 and $5,000 for high, $2,000 for medium, and $1,000 for low-impact bugs. For more information, please check Floki Ecosystem’s bug bounty page on Immunefi.

Floki Ecosystem Has Launched a $50,000 Bug Bounty Program on Immunefi was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

On January 7 and January 24th, 2024, whitehat @GregadETH submitted High and Critical vulnerabilities in the Graph ecosystem, which consisted of 2 rounding errors that had the potential to result in the loss of user funds or unclaimed yield.

The Graph quickly patched the issue, and paid out a bounty total of $290,497 to the whitehat.

The Graph overview

The Graph considers itself a “decentralized indexing protocol”. What does this mean? It enables mainly developers to access and query data across different blockchains using its “subgraphs”, which are APIs. As with other decentralized protocols, it relies on the coordination of multiple parties, i.e. indexers, curators, and delegators, to provide its services, and thereby generate value.

Although blockchain data is by default, public, the process of collecting it is not as straightforward. Assuming you have the technical knowhow and the right setup to download and interpret the raw block data from a node, you’d still have to hunt the needle in the haystack of transactions, and do it efficiently.

By using The Graph, users can more easily access data from the blockchain via its GraphQL API, paying only for the specific information they need with GRT, the protocol’s native token. This token is also used by indexers (node operators of the network) to stake and index data based on specific curated subgraphs (APIs).

The part of The Graph that we will be discussing in this vulnerability analysis mainly concerns this staking functionality.

Vulnerability Analysis

The root cause of the vulnerability are two rounding errors, occurring in two separate assets and causing discrete impacts on each. Ensuring the precision or proper handling of floating-point arithmetic is crucial to avoiding financial discrepancies or exploitation of contract logic. Its versatility and frequency of finding makes it #6 of the Top 10 common smart contract vulnerabilities identified by Immunefi in 2023.

Locating the first issue

When a new subgraph API is created, the “curator”, or creator of the subgraph, stakes a certain amount of GRT tokens to do so, and pays a curation tax of 1% of the staked amount to the platform. This amount is variable, as a higher amount increases the likelihood that they will be indexed and earn fees. From this part onwards, the curator will be referred to as “user”.

The first rounding issue occurred in `Curation.sol` and `L2Curation.sol`, precisely in the `mint` function. The expected behavior of this function is that a user passes an amount of tokens to mint and then pays the `curationTax` amount of tokens to the called contract.

Here, the `curationTax` calculation implemented in the body of the `tokensToSignal` is working incorrectly when the amount of minted tokens is below 100.

Let’s take a closer look at the rounding implementation in the calculation in the `tokensToSignal` function presented below.

On the moment of the submission of the bug report the curation tax percentage was capped at 1% (variable equal to `uint256(10000)`), and the constant `MAX_PPM` was capped at 100% (variable equal to `uint256(1000000)`). That means that if an attacker is passing `uint256(99)` as a `tokensIn` variable, he will need to pay 990000/1000000 of the `curationTax`, which is rounded down to 0.

Normally, high gas costs on mainnet would prevent this from becoming a lucrative attack. But because this target contract is also deployed on Arbitrum, an L2 with much cheaper gas, the attacker could successfully avoid paying the `curationTax` completely by minting needed amount of tokens in batches of 99 tokens per call as presented in the PoC created by @GregadETH.

This could essentially rob the protocol of owed revenue and cause loss of user funds or yield owed to protocol participants.

Deploying the fix

In order to fix this vulnerability The Graph dev team presented a new way of calculating the tax, where code calculates tokens after tax first, subtracting that from the tokensIn in order to get the curation tax to avoid rounding down to zero.

https://github.com/graphprotocol/contracts/commit/6a87193f809d403a835ab188bdd90beeb77d6c2b

Locating the second issue

The second rounding issue @GregadETH uncovered was in another asset, `L2Staking.sol`.

When an indexer (node operator or hardware provider to the network) wants to provide services to the network in order to earn rewards and fees, they need to stake GRT tokens, which will stay locked for a period of time.

The Graph documentation states: “GRT that is staked in the protocol is subject to a thawing period and can be slashed if Indexers are malicious and serve incorrect data to applications or if they index incorrectly.”

However, this second rounding error results in a calculation error, which allows a malicious user to bypass the proper lock duration, unstaking tokens earlier than they should.

Let’s take a look.

In the `unstake` function, a call to the vulnerable `lockTokens` function was made. This function was responsible for adding unstaked tokens to a thawing (locked) pool and calculating the duration of the lock.

The `lockTokens` function adds the unstaked tokens to an existing pool containing previously unstaked and locked tokens. This then calculates the new duration of lock to a value between the current lock duration and the maximum locked duration, which was capped at 28 days at the time of submission.

If there are some tokens already unstaked and sitting in the locked pool, the calculation of a new lock time will be done like this:

newLockedUntil = ((currentLockedUntil * currentlyUnstakedTokens) + (201600 * newUnstakedTokens)) / (currentUnstakedTokens + newUnstakedTokens)

If `currentUnstakedTokens` is roughly 201600 times larger than `newUnstakedTokens`, `newLockedUntil` will evaluate to `currentLockedUntil`. Thus, the attacker can pass a small enough value to the `unstake` function to withdraw small portions of the staked tokens without any additional lock applied. After that, he could proceed with the same attack plan as in the first bug described in the article: unstake small batches of tokens to avoid adding any value to the lock period.

The process of unstaking — calling unstake() and then waiting until the tokens will be unlocked — is now broken. The described attack can be used by a malicious user to avoid the lock period for unstaked tokens, enabling an attacker to immediately withdraw them without any penalty.

The impact of this varies, from an individual indexer making unfair gains and being able to unstake tokens faster than other indexers, to the possibility of multiple indexers being able to remove their stake entirely without penalty, adversely affecting the security of the network overnight.

Deploying the Fix

To fix the problem in the calculation process the separate library contract, `MathUtils.sol` was changed: where the vulnerable `weightedAverage` was changed to `weightedAverageRoundingUp`to ensure that the result is always greater than the lesser of the two input values.

This commit solves the problem of allowing users to unstake before they should.

Old Function

New Function:

Closing Acknowledgements

We would like to thank the whitehat @GregadETH for doing an amazing job in responsibly disclosing such an important bug. Big props also to the team at The Graph who quickly responded to the report and patched the issue.

If you’re a developer or a whitehat considering a lucrative bug-hunting career in web3 — this message is for you. With 10–100x the rewards commonly found in web2, your efforts will pay off exponentially by switching to web3.

Check out the Web3 Security Library, and start earning rewards on Immunefi — the leading bug bounty platform for web3 with the world’s biggest payouts.

To read more bugfix reviews, visit the Immunefi Blog. Or check out the Immunefi Top 10 Bugs page for more information on common vulnerabilities.

The Graph Rounding Error Bugfix Review was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

We’re excited to unveil a new collaboration between Immunefi and Three Sigma, marking a significant milestone in fortifying the blockchain landscape!

The imperative for enhanced security measures has never been more pressing, with the crypto industry experiencing significant losses totaling $333 million to hacks in the first quarter of 2024 alone. In response to this challenge, Immunefi and Three Sigma are committed to raising the bar for security standards within the blockchain ecosystem.

Three Sigma, a distinguished blockchain engineering and research consulting firm, is a leader driving blockchain technology’s adoption and fostering the growth of the crypto/web3 space. Their comprehensive suite of services, including code audits, economic modeling, and blockchain engineering, has consistently delivered value to clients seeking to navigate the complexities of decentralized ecosystems.

The services offered by Three Sigma are a perfect complement to Immunefi’s mission of safeguarding blockchain projects by harnessing the collective expertise of the largest and most proficient community of elite security researchers in the industry. With over 45,000 security researchers, including over 1,000 who have successfully identified critical vulnerabilities, Immunefi has successfully prevented a staggering $25 billion in potential crypto theft and fraud.

By synergizing Immunefi’s unrivaled security expertise with Three Sigma’s blockchain engineering prowess, we are empowering our shared customers with exclusive offerings designed to mitigate security risks and fortify their blockchain ecosystems.

“This partnership represents a significant step forward in our mission to advance the adoption of blockchain technology while ensuring the utmost security for our clients,” remarked Sajjad Rehman, VP of Revenue at Immunefi. “We are well-positioned to redefine industry standards and create a safer, more resilient Web3.”

In an era defined by rapid innovation and transformative change, the partnership between Immunefi and Three Sigma stands as a beacon of collaboration, innovation, and unwavering commitment to security excellence!

Immunefi Joins Forces with Three Sigma to Redefine Blockchain Security was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.

⚠️ THIS ARTICLE HAS MOVED

This Medium version is archived and is no longer being updated.

Read the current and maintained version on the Immunefi Blog.

We’re thrilled to announce a groundbreaking partnership between Immunefi and OpenZeppelin!

OpenZeppelin, an industry leader in securing blockchain ecosystems, has been at the forefront of innovation since its inception in 2015. Renowned for its bedrock open-source Contract Libraries, OpenZeppelin helped to set the standard for smart contract development by ensuring robust security measures are in place. With a comprehensive suite of professional services and the cutting-edge Defender developer security platform, OpenZeppelin seamlessly integrates security throughout the development lifecycle.

By joining forces, OpenZeppelin and Immunefi are empowering our shared customers with unparalleled protection against security threats. Sajjad Rehman, Immunefi’s VP of Revenue, aptly captures the essence of this partnership, stating, “OpenZeppelin’s commitment to security excellence aligns perfectly with Immunefi’s mission to fortify the Web3 landscape.”

Recent data underscores the critical need for enhanced security measures that this partnership will foster. In the first quarter of 2024 alone, the cryptocurrency ecosystem experienced staggering losses totaling $336.3 million due to theft and fraud. These figures serve as a stark reminder of the persistent threat posed by malicious actors seeking to exploit vulnerabilities within blockchain networks.

In response to this challenge, Immunefi leverages the most skilled and prolific security researchers in the industry. In total, we have successfully prevented the loss of an astounding $25 billion in potential crypto theft and fraud — a testament to our unwavering commitment to safeguarding the assets of our clients.

The synergy between Immunefi and OpenZeppelin heralds a new era of security excellence. By combining OpenZeppelin’s expertise in securing blockchain ecosystems with Immunefi’s unparalleled track record in vulnerability mitigation, we are uniquely positioned to offer our shared customers unparalleled protection and exclusive offerings.

Together, Immunefi and OpenZeppelin are creating a more secure and resilient Web3 — one bug at a time.

OpenZeppelin Partnership Announcement was originally published in Immunefi on Medium, where people are continuing the conversation by highlighting and responding to this story.