The 16th of December is a day that will go down in crypto history, and for all the right reasons. Bitcoin, the king of cryptocurrency and the brainchild of Satoshi Nakamoto, skyrocketed above the $20,000 price mark, and between then and now there’s been no sign of this slowing down.

With institutions buying more BTC than is mined on a daily basis, and the floodgates of crypto being opened up to retail investors by the likes of payment giant PayPal, there has never been a more exciting time to be an investor in the cryptocurrency space. However, on the inverse, there’s never been a better time to be a malicious hacker looking to earn a quick buck (or, more realistically, a quick few hundred million dollars).

No individual or organization is immune to these types of cyber attacks, which often result in the losses of hundreds of millions of dollars in crypto assets. Binance, Bithumb, and UpBit are all major players in the crypto space, each with its own history of crypto hacks.

With the advent and rise of decentralized finance(DeFi), the blockchain and cryptocurrency world have, again, garnered attention from individuals and organizations around the world. A rise in users and value, makes for a rise in potential security incidents. Due to the sheer amount of value they’re holding, security of crypto wallets is vital.

Companies like Shapeshift build wallets that support different blockchain protocols, whilst a number of projects build native wallets to support their own chain, similar to DeepWallet for CertiK Chain

After looking at a wide variety of wallets during our research(check out our talk at Defcon blockchain village) and client engagement, we want to share the methodology and workflow for software-based crypto wallet security assessment. We believe that in order to assess an application, the most fundamental requirement is to understand how it operates.

Following our checklist, the next step is to examine whether the implementation follows security best practices and, if not, how these failures can be exploited. The checklists cover wallets in the form of a web application, mobile application, extension, and electron(desktop) application.

You can find the result of our research below, we consider the impact of both client and server-side configuration.

The fundamentals:

Questions below are suitable and should be focused on for all forms(mobile, web, extension, desktop) of crypto wallet applications, especially the first and second questions.

• How does the application generate the seed phrase and private key?
• How and where does the application store the seed phrase and private key?
• Does the wallet connect to a trustworthy blockchain node?
• Does the application allow users to configure a custom blockchain node, if so, what can a malicious blockchain node do to the application?
• Does the application utilize a cartelized server, what information is sent from the client to the server?
• If the server stores sensitive data, how are they stored?
• Does the application enforce a strong password policy?
• Does the application require 2FA or pin code when users attempt to access sensitive information or transfer a token out?
• Does the application use vulnerable third-party libraries?
• Any secret(ex. API keys, AWS credentials) leaks in the source code repository?
• Any notable bad coding practice(ex. misuse cryptography) in the codebase?
• Does the application server enforce TLS connection?

Mobile wallet:

Compared to a laptop, mobile devices are easier to get lost or stolen. When analyzing threats for mobile devices, we must consider the situation that the attacker can potentially gain access to the user's device. During the assessment, we seek to identify issues that can potentially lead to accounts and crypto assets compromised if the attacker gains access to the user's device or the user's device infected by malware.

In addition to the checklist in the general section above, below is the list of items we check when assessing a mobile wallet.

• (Android) Does the application stop users from taking screenshots while displaying sensitive data? (iOS) Does the application warn users not to take screenshots of sensitive data?
• Does the application leak sensitive information in the background screenshots?
• Does the application detect jailbreak/root?
• Does the application implement certificate pinning?
• Does the application log any sensitive information?
• Does the application contain misconfigured deeplink and intent, can they be exploited?
• Does the application package protected by code obfuscation?
• Does the application implement anti-debugging?
• Does the application check for app repackaging?
• (iOS)Does data stored in the iOS keychain have the secure accessible attribute?
• (iOS)Does the application suffer from keychain data persistence?
• Does the application disable the custom keyboard when users enter sensitive information?
• Does the application securely use "webview" to load an external website?

Web Wallet:

Web application becomes a less popular option for a fully decentralized wallet. MyCrypto disallows users access their wallet with keystore/Mnemonic/private key in the web application, and MyEtherWallet recommended users not to do the same thing. Compared to wallets run on the other three platforms, it's easier to perform the phishing attack against a wallet in the form of a web application. Moreover, if the attacker compromises the web server, he can easily steal wallet secrets from users by injecting malicious javascript into the web page. However, a securely built and thoroughly tested web wallet can still be a good option for users to manage their crypto assets.

In addition to the checklist in the general section above, below is the list of items we check when assessing a web wallet on the client-side. For server-side vulnerabilities, see the last section of this article.

• Is the application vulnerable to cross-site scripting(XSS)?
• Is the application vulnerable to clickjacking?
• Does the application have an effective content security policy?
• Is the application vulnerable to open redirect?
• Is the application vulnerable to HTML injection?
• It's rare to see web wallets use Cookies nowadays, but if they do, we check for:
• • Cookie attribute
  • Cross-site request forgery(CSRF)
  • CORS misconfiguration
• Does the application contain additional features other than basic wallet functionalities and can they be exploited?
• Does the application vulnerable to any of the OWASP Top 10 vulnerabilities not mentioned above.

Extension Wallet:

Metamask, one of the most famous and frequently used crypto wallet, is present in the form of a browser extension. An extension wallet internally works pretty similarly to a web application by itself. The difference is it contains unique components called Content Script and Background Script. A website communicates with an extension page by passing events or messages through Content Script and Background Script. One of the most important things to look at during the extension wallet assessment is to test if a malicious website can read or write data belong to the extension without the user's consent.

In addition to the checklist in the general section above, below is the list of items we check when assessing extension wallets.

• What permissions does the extension require?
• How does the extension decide which website is allowed to communicate with the extension?
• How does the extension interact with the web page?
• Can a malicious website exploit vulnerability such as XSS(cross-site scripting) in the extension page or other active tabs in the browser by exploiting a vulnerability in the extension?
• Can a malicious website read or modify data that belongs to the extension without the user's consent?
• Is the extension vulnerable to clickjacking?
• Does the extension(often the background script) correctly check the origin of the message before processing it?
• Does the application implement an effective content security policy?

Electron(Desktop) Wallet:

After writing the code for the web application, why not reuse the code to build a desktop application in Electron? Around 80% of desktop wallets we looked at are electron based desktop applications. When testing an electron based desktop application, we not only look for vulnerabilities that could exist in a web application but also examine the electron configuration.

Check out our article(link) and talk(link) on exploit vulnerability in electron based desktop applications.

• What version of Electron does the application use?
• Does the application load remote content?
• Does the application disable "nodeIntegration" and "enableRemoteModule"?
• Does the application enable contextisolation, sandbox and webSecurity?
• Does the application allow users to navigate away from the current wallet page to another arbitrary external web page in the same window?
• Does the application implement an effective content security policy?
• Does the preload script contain code that can be abused?
• Does the application pass user input into dangerous functions such as "openExternal"?
• Does the application use any insecure custom protocols?

Server Side:

More than half of all crypto wallet applications we look at communicate with blockchain nodes directly and don't have a centralized server. We believe this is the way to minimize the attack surface and protect user's privacy. However, if the application wishes to provide more functionalities other than account management and token transfer, it probably requires a centralized server with a database and server-side code.

What item to test for the server-side component is highly application feature dependent.

We compile the checklist below based on server-side vulnerabilities we found during our research and client engagement. It's not meant to contain all possible server-side vulnerabilities. For example, the list doesn't contain the XML external entity(XXE) because we never encounter any wallet application that deals with an XML file.

• Authentication and authorization
• KYC and its effectiveness
• Race conditions
• Cloud misconfiguration
• Web server misconfiguration
• Insecure direct object references(IDOR)
• Server-side request forgery(SSRF)
• Insecure file upload
• Any type of injection(SQL, commend, template) vulnerability
• Arbitrary file read/write
• Business logic error
• Rate limiting
• Denial of service(check out our article for more information about DoS attack)
• Information leakage

About CertiK

We at CertiK strive to secure the cyberworld regardless of the nature of each project that might be entrusting the integrity of its operations on DLTs and smart contracts and our numbers are loud about it.

Since our inception, we've audited and secured more than 150 smart contracts, and over 25 whole chains, while our security experts have performed more than 20 application penetration tests for top-shelf industry pioneers including but not limited to Binance, Tera, Kava, e-Money, Fetch.ai, Akropolis, Bancor, Shapeshift, and Blockstack.

To learn more about application penetration tests, smart contract audits, and find out the most optimal way to secure your next venture, don't hesitate to connect with one of our engineers and get a free consultation today.