Penetration Test Report (TrailOfBits): TokenCard

TokenCard
Security Assessment
August 13th, 2019
Prepared For:
Mischa Tuffield | T okenCard
mischa@tokencard.io
Prepared By:
Michael Colburn | T rail of Bits
michael.colburn@trailofbits.com
Gustavo Grieco | T rail of Bits
gustavo.grieco@trailofbits.com
John Dunlap | T rail of Bits
john.dunlap@trailofbits.com
Changelog:
May 3rd, 2019: Initial report delivered
July 26th, 2019: Added A ppendix D with retest results
August 13th, 2019: Final report for publication
Executive Summary
Project Dashboard
Engagement Goals
Coverage
Recommendations Summary
Short Term
Long Term
Findings Summary
1. Wallet and Licence are incompatible with non-standard ERC20 tokens
2. Parsing large JSON integers could result in interoperability issues
3. Base64 decoding does not validate its input
4. Solidity compiler optimizations can be dangerous
5. Lack of contract existence check may mislead the user about the transaction’s result
6. Contracts used as dependencies do not track upstream changes
7. No sanitization is performed when the Oraclize query is constructed
8. _licenceAmountScaled can be incorrectly initialized
9. Multiplication overflow can block certain wallet operations
10. AddressWhitelist owner can be added to the whitelist
11. Date validation in insufficient and returns imprecise timestamps
12. Malicious price source can block withdrawal of funds
13. Daily limits may be bypassed via executeTransaction for certain tokens
A. Vulnerability Classifications
B. Code Quality
C. Property-based testing using Echidna
D. Fix Log
© 2019 Trail of Bits TokenCard Assessment | 1
Executive Summary
From April 15 through May 3 2019, TokenCard engaged with Trail of Bits to review the
security of their smart contract wallet and iOS application. Trail of Bits conducted this
assessment over the course of four person-weeks with two engineers working from
commit hash b 99b7d1670f9ad7b90335e8391fe63fd7e20de9b from the TokenCard
contracts repository.
During the first week, we began to familiarize ourselves with the Solidity smart contracts
used by the TokenCard system. This consisted of manual review focused on the Wallet
contract as well as automated analysis of some of the libraries used by the smart contracts.
In the second week, we continued our review of the smart contracts and conducted a brief
review of the provided development build of the iOS application. For the final week of the
assessment, Trail of Bits concluded our manual review of the TokenCard system, continued
to build out a suite of Echidna tests of various properties as well as reviewed a fix for
TOB-TokenCard-001 and a work in progress migration from v0.4.x to the v0.5.x branch of
the Solidity compiler.
In total, Trail of Bits identified 12 issues, ranging from medium- to low-severity with one
additional finding of undetermined severity. Six issues—two medium- and four
low-severity—were the result of improper data validation by the contracts. A
medium-severity finding in the address whitelist contract allows the contract owner to add
her own address. Two low-severity potential denials of service were found relating to a
malicious price source via the oracle as well as the arithmetic computations of two wallet
functions. An additional low-severity finding relates to the potential for interoperability
issues when working with large JSON integer values. (Integer handling is not well defined by
the JSON specification.) The final low-severity finding is the result of including external
dependencies directly in the Github repository which makes tracking upstream changes
difficult or impossible. The remaining finding of undetermined severity pertains to
compiling the Solidity code with compiler optimizations enabled.
The code reviewed shows that the TokenCard team is aware of the most common smart
contract pitfalls and performed numerous tests of the codebase. We recommend
TokenCard remedy all of the reported issues and improve testing around untrusted input
validation. This was a common class of issue encountered in the code. This testing could
also be supplemented with Manticore and Echidna tests to verify correctness. Additionally,
continue to work toward migrating the codebase to use the v0.5.x branch of the Solidity
compiler before launch; the v0.4.x branch used by the application is no longer officially
supported.
© 2019 Trail of Bits TokenCard Assessment | 2
Project Dashboard
Application Summary
Name TokenCard
Version b99b7d1670f9ad7b90335e8391fe63fd7e20de9b
Type Solidity Smart Contracts & iOS Application
Platforms Ethereum, iOS
Engagement Summary
Dates April 15 - May 3, 2019
Method Whitebox
Consultants Engaged 2
Level of Effort 4 person-weeks
Vulnerability Summary
Total High-Severity Issues 0
◼◼◼
Total Medium-Severity Issues 3
◼◼◼◼◼◼◼◼
Total Low-Severity Issues 8
Total Informational-Severity Issues 0
Total Undetermined-Severity Issues 1 ◼
Total 12
Category Breakdown
◼◼◼◼◼◼
Data Validation 6
◼◼
Undefined Behavior 2
◼
Patching 1
◼◼
Denial of Service 2
◼
Access Controls 1
Total 12
© 2019 Trail of Bits TokenCard Assessment | 3
Engagement Goals
The engagement was scoped to provide a security assessment of the TokenCard Wallet and
ancillary smart contracts in the c ontracts repository as well as the companion iOS mobile
application.
Specifically, we sought to answer the following questions:
● Is it possible to trap funds in the Wallet?
● Can TokenCard access user wallet funds?
● Are access controls well-defined?
● Are there any potential arithmetic issues when converting tokens to base units?
● What influence does the oracle have over user funds?
Coverage
This review included the Wallet contract and all other TokenCard protocol smart contracts
it interacts with. The specific version of the codebase used for the assessment came from
commit hash b 99b7d1670f9ad7b90335e8391fe63fd7e20de9b of the TokenCard c ontracts
Github repository. Additionally, we briefly reviewed a development build of the companion
iOS application.
Contracts were reviewed for common Solidity flaws, such as integer overflows, reentrancy
vulnerabilities, and unprotected functions.
Access controls. Many parts of the system expose privileged functionality, such as adding
to the wallet's payee whitelist or transferring funds to be loaded to a TokenCard card.
These functions were reviewed to ensure they can be triggered only by the intended actors.
Arithmetic. We reviewed these calculations for logical consistency as well as potential
scenarios where reverts due to overflow may negatively impact use of the wallet.
Interactions with external contracts. The TokenCard wallet has explicit support for
holding both ether as well as any ERC20 token. We reviewed the contract's interactions with
these external, untrusted token contracts, to ensure proper behavior even in the case of
non-ERC20-compliant tokens.
Parsing third-party input. The TokenCard oracle uses t he Oraclize service to query and
parse exchange rates on-chain. To support this, the TokenCard team has had to include
libraries for parsing JSON, base64 and dates as part of the system. We reviewed this code
and considered potential scenarios that may occur upon parsing malicious input data.
© 2019 Trail of Bits TokenCard Assessment | 4
Access to wallet funds. TokenCard bills its application as having a non-custodial wallet.
We sought to verify that TokenCard cannot exert undue influence or otherwise access a
user's wallet funds aside from when the user loads her card.
© 2019 Trail of Bits TokenCard Assessment | 5
Recommendations Summary
This section aggregates all the recommendations made during the engagement. Short-term
recommendations address the immediate causes of issues. Long-term recommendations
pertain to the development process and long-term design goals.
Short Term
❑
Adopt the O penZeppelin SafeERC20 library or otherwise add explicit support for
ERC20 tokens with incorrect return values. This will allow the TokenCard wallet to
support tokens which deviate from the ERC20 standard.
❑
Properly document th