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 3114and 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.

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 3114and 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.

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 3114and 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 builds security infrastructure for sovereign blockchains and rollups, focusing on the Cosmos and modular ecosystems and bridges such as the Inter-Blockchain Communication Protocol (IBC). Range's product suite encompasses tools for monitoring, threat detection and prevention, analytics, and forensics in order to strengthen the security of the interchain and modular ecosystems.

The blockchain security and intelligence platform

Helping the best teams build and use DeFi protocols, blockchains, rollups, and cross-chain bridges with peace of mind.

Get in touch

Areas of interest*

The blockchain security and intelligence platform

Helping the best teams build and use DeFi protocols, blockchains, rollups, and cross-chain bridges with peace of mind.

Get in touch

Areas of interest*

The blockchain security and intelligence platform

Helping the best teams build and use DeFi protocols, blockchains, rollups, and cross-chain bridges with peace of mind.

Get in touch

Areas of interest*

The blockchain security and intelligence platform. Featuring a comprehensive security and risk management suite powered by machine learning and security expertise.

Resources

The blockchain security and intelligence platform. Featuring a comprehensive security and risk management suite powered by machine learning and security expertise.

Resources

The blockchain security and intelligence platform. Featuring a comprehensive security and risk management suite powered by machine learning and security expertise.

Resources