Explained: The BiFi Hack (July 2022)

In July 2022, BIFROST’s BiFi service was the victim of an attack.  By exploiting a vulnerability in the service’s address management, the attacker was able to steal 1,852 ETH (worth $2.25 million) from the project.

Inside the Attack

The attack on BiFi was made possible by an error in how the BiFi service managed addresses.  BIFROST is a cross-chain bridge, which means that it needs a means of tracking deposits on one blockchain to trigger withdrawals on another.

When a user deposits Bitcoin into the service, the address issuing server issues a deposit address to that user and digitally signs the address.  After this digital signature is verified, the address is accepted and usable on the BiFi service.  The user can then make a deposit to that address and transfer assets over the cross-chain bridge.

The security of this scheme depends on the security of the private key of the address issuing server, which is then used to generate these digital signatures.  In this case, the attacker managed to gain access to this key, enabling them to create a valid digital signature for a deposit address of their choice.

When the attacker performed a transfer of BTC to their deposit address, the BiFi service interpreted this as a deposit into BiFi.  This provided the attacker with a balance in the service that enabled them to extract 1,852 ETH from BiFi.  However, since the deposit address was actually under the attacker’s control, they still retained the fake BTC deposit as well.

Lessons Learned From the Attack

This attack was made possible by the BiFi service’s reliance on a single secret key to validate deposit addresses.  After the key was compromised, it was possible for the attacker to forge deposits.  Instead of a single private key, a multi-signature wallet should have been used to eliminate this single point of failure.

Another issue was the lack of validation that a digitally-signed deposit address was actually controlled by the protocol.  Without a key to sign transactions, deposits made by a user into a deposit address would either be lost forever (in the case of an incorrectly generated address or lost key) or under the control of an attacker.  Validating that the service controlled the key for an account before accepting deposits to it could also have prevented this attack.