Mozart Finance Hack Post Mortem

On April 5th, 2021, Mozart Finance suffered from a hack, a minting hack, that caused the attacker to mint over 100k of PIANO tokens and dump them into the market.

Mozart’s contracted Solidity developer built a minting function in the PIANO contract’s code. He left the minter role in place, deeply rooted among the core functions of the contract. 

The deployed smart contract was swapped for a malicious one containing the minting functions employed during the attack. These minting functions were not present in the code at the time of the audit. 

View the initial Audit code here : 
https://bscscan.com/address/0x9eEC1044C5bD15782F806C63003F4730eeDfDAE4#code

View the Final audited code here: 
https://testnet.bscscan.com/address/0x1111cF91D816cF52b689E987e417006595d74391#code
View here the code deployed on the mainnet: 

https://bscscan.com/address/0xd46936677B2C1Bb696F2b67c55239331E2b7Cd42#code

In this article, we are going to be outlining the details and events observed during this attack. 

Mozart Incident Timeline 

The attack took place on 5th April 2021. Our team looked into the incident and has inferred the following conclusions:

1. The contracted Solidity developer builds a minting function into the PIANO contract, which gets deployed on the mainnet.
2. The attacker minted over 100k of PIANO tokens, so they could be the only ones to sell these tokens.
3. The attacker then sold the PIANO tokens into the market.

Additional Resource: Mainnet vs Testnet

Please note that the original contract that was audited by ImmuneBytes did not have any externally exposed (public/external) mint functionality.

Technical Analysis 

For a clearer understanding, we’ve added the code that was added by the developer, containing the unintended minting function. This code was not present during the time of the audit. Let’s take a look:

With this code, the attacker was able to exploit the smart contract in the following ways:

• The original code intended to have only a single minter role, the hacker, however, added a minter role for himself too. 
• The attacker also did not transfer the Ownership to the intended recipient.
• The modified code also had an initial supply added to it, [[ uint256 private constant _initialSupply = 45000*10**18 ]], with the use of which a supply of 45K PIANOs would be transferred to whoever deployed the smart contract. This was something that the code did not intend to do originally. 
• The true logic of the project was based on a Decreasing Supply Model, implying that as the funds are transferred, 1% of the transferred tokens would be burned. 

For example, let’s say you were to farm 100 PIANOs. According to the project model, you would burn 1% of these 100 PIANOs and would acquire 99 PIANOs.

• The hacker altered this decreasing supply model such that no percentage of PIANOs were burnt, using the transferFrom() function.

Such functionalities are sometimes added to the smart contract as and if intended by the project. We will make sure to enhance such special features more clearly in our future audits.

The Aftermath of it

As the Mozart Finance team has reported, none of the wallets have been compromised. Users, however, have been requested to stop any kind of trading and farming in PIANO, as the attacker can still exploit the contract.

Finally, we would only like to say that an audit can only analyze a computer program and not the trustworthiness of the people involved with the project. We sincerely hope that Mozart Finance recovers through this and comes out of it stronger. Here’s to wishing them good luck!

About ImmuneBytes:

We are a team of India-based security professionals who are skilled in their niches. With us, you’ll never have to compromise. We strive to push forward and provide overall surveillance and quality service to our customers. Get in touch with us to get a security audit for your smart contract.