New ownerAnyone Bug Allows For Anyone to ''Own'' Certain ERC20-Based Smart Contracts (CVE-2018-10705

This morning, our vulnerability-scanning system at PeckShield identified a new vulnerability namedownerAnyone in certain ERC20-based smart contracts such as AURA, which is deployed by a decentralized banking and finance platform – AURORA. This bug, if successfully exploited, might introduce the danger of serious financial accident. Fortunately, the attackers would not be financially benefited from exploiting the vulnerability. Instead, the ownerAnyone bug can be used to trigger Denial-of-Service (DoS) attack on the affected smart contracts.

Details

Solidity provides function modifiers, which can be used to amend the semantics of functions in a declarative way. For example, privileged functions need to check the identity or the privilege level of the caller.

We can see from the Figure 1, sensitive functions (e.g., unlockToken / lockBalances) use theonlyOwner modifier to guarantee that only the current contract owner can call them. It seems pretty legitimate, so what’s the problem?

Let’s take a closer look into the AURA contract which inherits SafeMath for safe mathematical calculation and Owned for contract ownership management. Inside the Owned contract, there is a method setOwner() for changing the contract ownership, which is a highly sensitive operation. However, this sensitive method doesn’t have any function modifier, like onlyOwner, to restrict its use. Even worse, the method’s visibility is public by default, which means anyone can call it to modify owner to anyone at their choice.

As a proof-of-concept demonstration, we launch the following transaction and essentially replaceowner to 0xcafebabe.

And we can verify by checking the owner variable of AURA contract.

Consequences

With the ownerAnyone bug to essentially change the smart contract ownership, any sensitive operations restricted by onlyOwner can be easily bypassed. For example, the unlockToken()method can be used to unlock transfer, which might be used during early stage to control token transferring. Also, the lockBalances() method can be called to set the balancesUploaded variable to true (with false as the default value), essentially locking up the uploadBalances() operation and making it no longer accessible.

line 140) bool public balancesUploaded = false;

In other words, once balancesUploaded is set to true, uploadBalances() can never be reached, which lead to a DoS attack:

line 142) require(!balancesUploaded);

During our investigation, we initially think there is a questionable operation in the end:

line 148) balanceOf[owner] = safeSub(balanceOf[owner], sum);

It turns out that it is protected by safeSub(), which will revert the whole transaction if balanceOf[owner] doesn’t have enough tokens. Note that ownerAnyone is a twin vulnerability to the IDXM bug in [1].

Conclusion

Writing a safe smart contract is NOT an easy job. It requires different security considerations from our traditional software development. Any security miss may allow for attackers to take advantage of your contract with valuable assets and cause significant financial damage. It is fortunate thatownerAnyone in this particular case only does limited harm. It can get much worse if AURAcontains other administrative functions, say, controlling token supply by owner.

We cannot over-emphasize the importance of smart contract auditing. Here are some basic security guidelines to follow:

• Always use libraries like SafeMath for safe mathematical calculations

• Always declare your functions with right modifiers and visibilities

Being said, if at all possible, audit your smart contracts before deployment by consulting professional auditing services from qualified security companies. After all, precaution is better than cure.

References

• [1] Aurora IDEX Membership(IDXM), ERC20 Token, allows attackers to acquire contract ownership