The security firm V12 Security revealed that at the end of last April it found a critical vulnerability in the exchange protocol (swaps) THORChain that allowed a single validator node operator to steal funds from the protocol’s liquidity pools. The discovery, although it did not involve the same failure, occurred weeks before the USD 10 million hack suffered by the platform on May 15.
THORChain would have applied the patch silentlywithout public communication, and notified the firm that its vulnerability reporting reward program (known as bug bounty) was “permanently retired,” according to V12 Security researchers explained this June 1st.
ZachXBT, the on-chain researcher who had warned about the May hack, reacted with criticism direct to the protocol: «One would hope that after all the exploits they had, security would be taken more seriously. However, THORChain continues to lower the bar.
THORChain has had the network stopped for two weeks following the May 15 hack, which involved a different vulnerability than the one reported by V12 Security. The failure, as explained by CriptoNoticias, occurred at the level of the GG20 TSS, the cryptographic scheme that allows the protocol nodes to sign transactions together.
From THORChain reported on May 27 that the software version necessary to resume operations (v3.19.0) must complete testing before reaching mainnet, no confirmed date.
How did the bug work and what could a user lose?
THORChain operates with assets from different networks (bitcoin, ether, among others) that users deposit to make exchanges. Before running a swapthe protocol expects the originating transaction to reach a minimum number of confirmations in its chain: for bitcoin, for example, 10 blocks. That requirement exists to ensure that the deposit is irreversible before releasing the funds on the THORChain side.
The bug reported by V12 Security allowed this requirement to be avoided. Each THORChain validator cryptographically signs their observation of an external transaction (an attestation signature certifying that the deposit was viewed), but that signature only covers the basic transaction data, such as amounts and addresses. The fields that record whether the transaction reached the necessary confirmations were outside the signature and could be freely modified.
How was the attack carried out?
According to the V12 Security report, in THORChain validators take turns proposing blocks with a predictable and deterministic rotation.
In the context of the vulnerability found by the researchers, a malicious validator could, when it is his turn, take the observations signed by other honest nodes about a transaction not yet confirmed, alter the purpose fields to indicate that the transaction was already complete and inject it into the block.
According to the same report, the block validation stage would not verify that purpose, since I would just check that the transactions could be read correctly. The signatures of honest validators would still be valid because the altered fields were never covered by them.
The result, according to V12 Security, would be that THORChain would execute the exchange immediately and release the funds from the pool to the attacker, before the original deposit had reached the required confirmations. The attacker could then reverse that deposit and take both sides of the exchange.
V12 Security demonstrated the attack in a controlled test environment with four active validators. In that proof of concept (a technical demonstration verifying that the vulnerability is real and exploitable) a Bitcoin transaction with a single confirmation, when ten were required, was processed as if it were complete. The simulated pool lost the equivalent of more than 82 billion units of RUNE (THORChain’s native token).
The attack, V12 Security claims, required controlling a single active validator node, without the need to access keys from other validators or occupy a special position in the network.
A history of unpaid reports
The security firm QED Audit informed THORChain last January of two vulnerabilities in the protocol while the bug bounty was still active: one that would have allowed the theft of assets for more than USD 40 million and another that would have allowed all the validators’ RUNE bonuses to be emptied, as they explained.
According to QED Audit, both bugs were fixed before version 3.15.0, released on January 29, but the firm also did not receive the reward payment. “We are not going to advocate for open disclosure because we believe that responsible disclosure should be kept separate from compensation disputes,” said the firm, which also published the technical details of the rulings.
THORChain did not issue any public statement regarding these vulnerabilities or the removal of its bug bounty program. The May 27 release reported that the protocol’s core cryptographic library, tss-lib, was temporarily put into closed source for the internal THORSec security team to complete an audit without exposing ongoing remediation work.
After having suffered the exploit in mid-May that resulted in a loss of USD 10 million, the exchange protocol promises a “safe and stable” reopening without a confirmed date.