BitRent Smart Contracts Audit Case Study

Brief

BitRent (RNT) is the blockchain platform meant to attract commercial and residential property investments at an early stage of construction in order to gain maximum profit by selling and renting out the acquired property.

For their upcoming ICO they required a security audit. The presale started in 10 days, so we were under strict time constraints. The customer have provided the sources and 17-page specification. They needed agility during the development so the ICO was structured in several contracts:

• RNToken — ERC20-compatible token used in the presale and ICO
• RNTEthereumMultiSigWallet — wallet, that will accept Ethereum from investors during the presale and ICO. Is slightly updated version of Consensys multisig wallet
• RNTokenVault — the token storage for the Ethereum investors. Stores the ID’s of registered users and their token amounts
• RNPresaleEthereumDeposit — smart contract that will accept Ethereum deposits during the presale and transmit them to the RNT Ethereum Multisig Wallet. Also stores the investors addresses and transferred funds amount
• RNPresaleFinalizeAgent — agent that finishes the presale and calculates the cost of 1 token (total investments/number of tokens)
• RNICOPricingStrategy — contains the rewarding rules of the ICO, specifically the amount of tokens to be sent for the given Ethereum
• RNCrowdsale — main smart contract, that is used in the presale and ICO. Rules the ICO using RNToken, RNPricingStrategy, Presale, PresaleFinalizeAgent, MultisigWallet contracts
• RNCrowdsaleBackendProxyBuyer — vehicle for the investors using other currencies through the backend

Solution

We always prefer to expedite the specs and code before the audit. Typically our audit process takes 20 to 40 hours during 1–3 weeks. In this case we needed to speed up.

The audit took several stages:

1. Launching smart contracts on the test-rpc and check up of all unit tests (passed)
2. Specification analysis to find out corner cases and missing unit tests (several specs inconsistencies and corner case found)
3. Smart contracts code review
4. Common vulnerabilities test (passed):

• Reentrancy
• Cross-function Race Conditions
• Pitfalls in Race Condition Solutions
• Transaction-Ordering Dependence (TOD) / Front Running
• Timestamp Dependence
• Integer Overflow and Underflow
• DoS with (Unexpected) revert
• DoS with Block Gas Limit
• Forcibly Sending Ether to a Contract

5. Search for logic errors

6. Test on the data exchange limitations between contracts

7. Test on the contracts addresses control (in several places such check was missing)

8. Test on the access rights to different methods (several methods found, that should be available only to the owner, but were public)

9. Test on the optimal gas usage (several improvements were found)

Additional recommendations contained:

• Code style improvements
• Code refactoring improvements to avoid mistakes in the course of support
• Specifications inconsistencies
• Libraries usage
• Grammar mistakes found

We usually use additional tools for the security check, however in this case we’ve skipped it due to the time constraints:

1. Solgraph — for building the interaction graph between the contracts
2. Manticore — for binary analysis of vulnerabilities

Results

The resulting report in the excel included 37 found issues (from grammar to medium importance vulnerabilities). Each issue stated the solidity file and line number, recommendations on the resolvement. It was discussed with the customer and contracts were sent for the update.

After the rework, new version of contracts was checked and contained no found vulnerabilities. Presale was launched. Customer was satisfied with the result.