HildisviniOttar

Pay to Pub Key results in double-spend (x3)

In THORChain a user sends a transaction to Swap an asset for another. The other asset is specified in a memo string attached to the inbound transaction.

The toAddress specified in the memo can be various formats (eg an ETH address would be 0xabcd... and a Bitcoin address is typically bc1....

An exploit exists where a customer that sends a swap destined for a mangled public key will swap to BTC, but not observed by the system resulting in 3x more outbounds (double-spend x3).

A user who sends in $5m in this manner would receive around $14m in illegal funds (assuming they are not caught).

HildisviniOttar

Version downgrade attack

In order to maintain consensus and allow sync-to-tip from block zero, all old code paths are still present in the system, including vulnerable paths (e.g. Infinite mint via affiliate fees).

Code paths taken are chosen based on the result of GetLowestActiveVersion():

version := nodes[0].GetVersion()
for _, na := range nodes {
	if na.GetVersion().LT(version) {
 version = na.GetVersion()

HildisviniOttar

TSS Churn with 2 evil nodes

Currently TSS works by the system auto-generating a set of TSS invitees that collectively generate a new vault pubkey outside of process. Each node that participates in the signing ceremony then posts in their results into THORChain as a MsgTssPool.

Two evil nodes are able to front-run a TSS signing ceremony by posting in a fake TSS result and voting twice, which achieves consensus and creates a vault controlled by attacker, stealing funds (before the valid tx arrives).

Note: #thorsec team found a similar bug allowing spoofing ID which was patched in https://gitlab.com/thorchain/thornode/-/merge_requests/1922 - this vulnerability is similar but works even with the original ID spoof patch. After disclosure, MR 1922 also incorporated fixes to stop this attack presented below.

Difficulty

HildisviniOttar

Non-observed ETH outbounds

In THORChain, the ETH chain works by sending assets to/from a router contract as specified in the https://thornode.thorchain.info/thorchain/inbound_addresses endpoint.

Currently: https://etherscan.io/address/0xc145990e84155416144c532e31f89b840ca8c2ce

The router emits events which are logged in the Ethereum virtual machine. THORChain Bifrost module reads these logs from each tx where the To() address is whitelisted (XRune / Router). Only logs emitted by the actual THORChain router are processed.

Multiple logs (two or more emit Event(...)) may occur for each transaction. When this happens, Bifrost is very aggressive at ensuring events with parameters that don't exactly match eachother (sender, to, and memo) are rejected so this transaction is not observed at all.

HildisviniOttar

Forging tx consensus

THORChain works by Bifrost observing external chains and posting MsgObservedTxIn messages to all nodes on what it thinks it saw. Each node does the same, and when 2/3 consensus is achieved, it is considered truth and the transaction is processed.

Thornode keeps track of consensus via an ObservedTxVoter, uniquely identified by tx ID (a sha256 hash):

voter, err := h.mgr.Keeper().GetObservedTxInVoter(ctx, tx.Tx.ID)

MsgObservedTxIn are only able to be sent by active nodes:

HildisviniOttar

Repeated bond fine past zero creates arb opportunities

When an active validator steals from their Yggdrasil vault, they are immediately fined 1.5x the amount stolen, down to zero.

When Ygg assets are stolen, THORChain deducts the asset stolen from internal accounting to adjust the pool ratio.

A Yggdrasil can be "topped up" by the user, which is not recognised by any thorchain accounting.

A rogue validator with active bond can repeatedly top-up, steal, top-up, steal past when their bond is zero, and thorchain keeps adjusting pool asset ratio down to zero (even though no funds are stolen). This creates a fake arbritrage opportunity.

HildisviniOttar

Vulnerability in utxo mempool observation

THORChain operates by delegating a large number of small transactions to nodes that each hold their own hot wallet called "Yggdrasil" that is constantly topped up.

Node operators know their Yggdrasil wallet private key. To prevent theft, the Yggdrasil wallet is monitored for outbounds and any unauthorised outbounds results in a bond fine of 1.5x stolen.

A vulnerability exists where an attacker can replace legitimate outbounds in the mempool with nefarious non-observable transactions resulting in theft from SWAP/WITHDRAW recipients (customers).

Attack

HildisviniOttar

Synth Vulnerability: Upgrading cheap synths to RUNE native

Description

The handler_deposit.go assumes that msg.Tx.Coins[0] is of type THOR.RUNE to determine affiliate rewards.

Once synths are enabled on Chaosnet, an attacker is able to convert a synth asset worth less than THOR.RUNE to THOR.RUNE native which can be swapped for ETH, BTC (etc).

This process can be repeated until small value asset pool(s) are drained.

HildisviniOttar

Description

THORChain started with a BEP2 token (RUNE-B1A) and ERC20 RUNE. To "upgrade" RUNE to native, a user sends BEP2 RUNE-B1A to the BNB vault with memo switch:<rune address>.

There is a bug where 90 billion fake BEP2 RUNE can be sent and redeemed for real RUNE, then swapped for 100% of assets.

Attack:

Firstly an attacker needs to create a BEP2 token, exactly RUNE-67C on mainnet. This is available because it is only registered on Binance testnet (as of writing!). The token suffix -XXX is selected by Binance chain as the first 3 digits of the transaction hash.

HildisviniOttar

Description

THORChain accepts messages of type SWAP and ADD that contain affiliate fees.

Affiliate fees are defined in basis points, for example an affiliate fee of 100 (of 10000) is 1%.

Affiliate fees are indicated by MEMO as described in https://docs.thorchain.org/developers/transaction-memos

THORChain does not do any bounds checking on the affiliate fee percentage, which can result in payment of unlimited affiliate fees to an attacker.