Security
Terra IBC Hooks Exploit Analysis
On 7/31/2024, an attacker exploited Terra Blockchain’s IBC implementation using a known vulnerability. More than $4M have been affected, making it one of the largest exploits in the Cosmos ecosystem.
Range Team
On 7/31/2024, an attacker exploited the Terra Blockchain’s IBC implementation using a known vulnerability. This bug was known as the IBC reentrancy infinite mint bug, and all Cosmos chains issued an emergency patch to remediate this issue. Ultimately, the validators decided to halt the chain at block height 11430400.
Note: This investigation is still ongoing, and this post intentionally omits information that could be sensitive to the identification of the attacker or the recovery of the funds.
In April 2024 theIBC-Go
library issued an emergency patch for the reentrancy bug. The affected version that is relevant to Terra is < 7.4.0. Terra was utilizing a custom version of IBC-Go 7.3.1
at the time of the attack (github.com/terra-money/ibc-go/v7 v7.3.1-terra.0) that was vulnerable to the exploit.
The IBC hooks bug itself was discovered and covered in detail by Asymmetric Research, so this post will cover the on-chain activity before, during, and after the attack.
It is estimated that the total stolen funds amount to approximately:
3.5 Million axlUSDC
500K USDT
2.7 BTC
58M ASTRO tokens
Let's talk about a story of how an attacker turned about 56 LUNA and 7,800 USDC into approximately $4 million dollars.
Before the exploit
When investigating an exploit the first step is to identify the perpetrating address and identify the initial source of funds that supplied the wallet and facilitated the attack. The attacker on-ramped around $8000 from exch.cx exchange (a non-custodial exchange that supports Ethereum, Bitcoin and Monero) to Ethereum and then used Squid Router to bridge the funds to Osmosis.
Addresses Involved
Osmosis Funder:
osmo16wynag7xgfy35sp8c5ls25c0je7dydmvvsmppj
Ethereum Funder:
0xD5120B0857CB01CB897B57AEf4a4C4d22dD09A42
This initial amount was utilized to initiate the attack and start the fund duplication at a relatively high level so that it didn’t take too many iterations to extract all of the available funds from the chain. They then swapped these initial funds into the gas tokens (AXL and LUNA) of the target chains used to orchestrate the attack.
The next step of the process was to upload the malicious contract used to manipulate the IBC timeouts as code id 3114
and then subsequently instantiate the contract two times. It is unknown why the attacker instantiated the contract twice and only used one instance for the attack. The contract was created with the label “pool-test
”. The attacker waited roughly 20 minutes and then began the exploit.
During the attack
Over the course of the next 3 hours the exploiter was able to repeatedly execute the attack sequence. With each iteration, they would double the funds sent in the IBC transfer. Periodically, they would exfiltrate funds through various avenues such as Axelar, Squid Router, Noble, and the Skip API.
The attacker targeted assets on the Terra blockhain with the most amount of liquidity, so this sequence generally went to USDC, USDT, WBTC, and then ASTRO. Ultimately this attack was limited to the amount of these tokens that were transfered over IBC into Terra at the time.
Addresses Involved
Terra primary:
terra1wrve5z5vsmrgy6ldcveq93aldr6wk3qmxavs4j
Terra secondary address:
terra1ra4hejz65ss8y52umg7pmerueedtfn9evnln0r
Exploit contract:
terra1et73lp74z9d4d2489a7kml8q343fjsqaejvrvvye0wj3x7pwr9wqufquus
Image 1: Funding transactions in the IBC Explorer.
After the attack
The funds extracted by the attack mostly flow to the Ethereum address 0xBDe173c4C2249d3a98cD6ed844a4421728114F5A
. Where they currently sit as of the time of the writing of this article and have a current value of ~$2,500,000 USD.
Addresses involved
Neutron primary:
neutron16wynag7xgfy35sp8c5ls25c0je7dydmvq5pnd8
Neutron secondary:
neutron1lheus53ndpa8rfwe9gxf0ungmpkfavsyhlkask
Ethereum Primary:
0xBDe173c4C2249d3a98cD6ed844a4421728114F5A
Image 2: Exfiltration of funds address graph shown by Range Trail.
Image 3: Exfiltration transactions shown in the IBC Explorer.
Partial Fund Recovery
After these events, both the Terra and Astroport teams took swift action to lessen the impact of the attack. The Terra team upgraded the IBC-Go
version appropriately and also introduced a new blacklist antehandler. This will effectively add a step to the transaction pre-processing to see if the transaction signer is on a list of blacklisted addresses, and if so, it will block the transaction. It is important to note that this blacklist only has one address, and it is the ibc-exploiter’s terra address that is holding around $650,000 USD in stolen funds, mainly consisting of 20,000,000 ASTRO. These funds are now locked and are out of circulation.
The Astroport team was able to seize the ASTRO in the attacker's Neutron wallet because ASTRO recently migrated from a cw20
Terra token to a tokenfactory
denom on Neutron. This gives the token admin unique privileges to recover the funds. This was accomplished through a force transfer from the attacker's Neutron wallet. It should be noted that this action was only possible on the origin chain of the Astro token (Neutron in this case) and would not have been possible if the token versions were wrapped.
Conclusion
This exploit sheds light on the complexity of modular components. The IBC transport layer (IBC Core, Client, and Relayer) in isolation did not have a vulnerability in this situation, and it was a vulnerability in the interaction between IBC components. The application layer builds on top of the transport layer and allows for customized packet processing depending on the use case. On this occasion, it was relevant to the interaction between the IBC-Hooks
middleware and the core IBC timeout functionality. It is a lesson that we must understand the security properties of both the individual components but also their interactions with each other. Another important lesson we can learn from this situation is that we need to audit and monitor dependencies in the same way that we manage core project code.
We will issue a revisited version of this post-mortem when all information can be shared without obstructing the recovery of the funds or identification of the attacker.
About Range
Range is the blockchain security and intelligence platform featuring an advanced transaction explorer, real-time security and alerting, cross-chain wallet monitoring, and IR and forensic capabilities. We protect more than $20B in TVL and work with the best organizations in the industry, such as Circle, Solana, dYdX, and Osmosis. Start leveraging Range today with the Range Community platform, or book a demo with us.