Vulnerabilities > CVE-2018-10705 - Unspecified vulnerability in Auroradao Aura
Attack vector
NETWORK Attack complexity
LOW Privileges required
NONE Confidentiality impact
NONE Integrity impact
NONE Availability impact
PARTIAL Summary
The Owned smart contract implementation for Aurora DAO (AURA), an Ethereum ERC20 token, allows attackers to acquire contract ownership because the setOwner function is declared as public. An attacker can then conduct a lockBalances() denial of service attack.
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| Application | 1 |
Seebug
| bulletinFamily | exploit |
| description | This morning, our vulnerability-scanning system at PeckShield identified a new vulnerability named ownerAnyone in certain ERC20-based smart contracts such as [AURA](https://etherscan.io/address/0xcdcfc0f66c522fd086a1b725ea3c0eeb9f9e8814#code), which is deployed by a decentralized banking and finance platform – [AURORA](https://auroradao.com/). 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.  Figure 1: Ownership-Checking Function Modifier: onlyOwner We can see from the Figure 1, sensitive functions (e.g., unlockToken / lockBalances) use the onlyOwner modifier to guarantee that only the current contract owner can call them. It seems pretty legitimate, so what’s the problem?  Figure 2: The Vulnerable setOwner() Method 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 replace owner to 0xcafebabe.  Figure 3: A Demo Ownership-Replacing Transaction And we can verify by checking the owner variable of AURA contract.  Figure 4: AURA's New Owner: 0xcafebabe ### 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 that ownerAnyone in this particular case only does limited harm. It can get much worse if AURA contains 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. |
| id | SSV:97319 |
| last seen | 2018-06-26 |
| modified | 2018-05-31 |
| published | 2018-05-31 |
| reporter | My Seebug |
| title | New ownerAnyone Bug Allows For Anyone to ''Own'' Certain ERC20-Based Smart Contracts (CVE-2018-10705) |