Delay in SushiSwap Listing. Security Breach Averted!
We have had to delay the Listing Announcement on SushiSwap due to a breach in our Eth. token contracts. The details of the contract breach have been mentioned below.
Bridging contract for Poly <> Eth. worked with a lock/unlock, burn/mint functionality.
- If the user wants to bridge their tokens from the Ethereum chain to the Polygon chain, they will have to call the [deposit()](<https://github.com/getsafle/bridging-contract/blob/main/contracts/FxBaseRootTunnel.sol#L77>) function in the FxBaseRootTunnel contract.
- The deposit() function will call the [burn()](<https://github.com/getsafle/bridging-contract/blob/main/contracts/eth%20token/Safle.sol#L34>) function from the Ethereum token contract.
- The burn(address, amount) should accept the address from where the tokens are to be burnt and the amount of tokens to be burnt.
- The burn(address, amount) function should have a condition check to allow only the FxBaseRootTunnel contract to call that function and that check that was not present.
On Monday January 17, 2022 we deployed test liquidity on SushiSwap Liquidity Pool. Within minutes the attacker burnt SAFLE tokens in the SushiSwap Liquidity Pool in multiple transactions, draining 480,853 SAFLE
This inflated the price of SAFLE and the attacker swapped SAFLE/WETH in a transaction. Since the tokens had been burned, the attacker was able to convert 56.88 SAFLE to 16.04 WETH.
Here are more details of the incident as captured by the blockchain explorer: https://etherscan.io/tx/0xd457aeb845985c415decb5e1bec2c90a8ce8e3191a54f9e85168a608c84d1ef4
https://etherscan.io/tx/0xd457aeb845985c415decb5e1bec2c90a8ce8e3191a54f9e85168a608c84d1ef4 — Transaction of the Exchange
https://etherscan.io/address/0x7b1088a749c868017f8ba34ea10e761288c6a509 — Address of The Attacker
https://etherscan.io/tx/0xa015c1af7ad9a297b1e0b93cc28c0bc25037e10958f415cdb1ff1151c00ead3f — Seeding Money on the Attacker Account
Figure- Bridging-contract/contracts/eth token/Safle.sol.
The burn method used for an attack. Due to lack of the ‘caller checking’ it can be called by anyone.
There was a lapse in the audit by Smart State as they were unable to flag the vulnerability in the token contract. They didn’t point to that part so this is the communication level issue.
The best part is that the vulnerability has now been resolved. More details are given here — https://github.com/getsafle/bridging-contract/pull/8.
Figure- The vulnerability resolved.
Even though the SushiSwap Liquidity Pool deployment was never officially announced or promoted by our channels. We apologise for any inconveniences caused in the process. This can be avoided with more eyes on, as well as a re-think in developer procedures and peer-review. We assure our community that we will further investigate and compensate for any personal losses.
Figure- Hacker’s Track
We’ll announce a new date for SushiSwap Listing soon. It won’t take too long! Thanks all for your patience and support once again, there’s only one way forward.