Crypto Wallet Security – Video

Let’s talk about mobile crypto wallets and compare their security with the security of banking applications.  

Here are basic differences between a wallet application and a banking application: 

To create and develop an application, a bank uses strict rules and regulations. Usually, banks implement all features very carefully and verify those multiple times because they want to protect the clients’ money and data. They try to avoid attacks at any cost because such attacks have a significant impact on their reputation and are very costly.  

On the contrary, companies creating wallet applications are not responsible for your funds since, as a rule of thumb, they cannot access your money. If there is any security flaw, you will be left without your funds because such companies will not be able to give them back to you. 

Crypto wallets can be made by anyone. This means, that the best security practices may be neglected. 

The only problem is that private keys CAN REALLY be stolen. To avoid this, private keys should be properly stored. What is meant by this is that iOS applications should store all the secrets inside a keychain, where all keys are encrypted. Normally, the rest of the files and information can be stored inside application’s sandbox. 

As the Apple’s definition says: 

App Sandbox provides protection to system resources and user data by limiting your app’s access to resources requested through entitlements. 

It means that one application cannot simply read files of the other application unless there is a system vulnerability. 

I have decided to check how different applications have implemented this rule. I have downloaded around 10 applications. It did not take long to find a vulnerable application. The second wallet app that appears after searching “Solana” in App Store has exactly this issue. It stores private keys outside the keychain – in a simple database file in the sandbox. 

One more thing that we have to bear in mind – we should protect not only private keys, but also mnemonics that are used to generate these private keys – generally, they are the private keys.  

Many developers did their job and most of the applications that I have checked showed big notifications informing their users about consequences of sharing and losing private keys. Some descriptions were better than the others, but a couple of them also had silly issues. 

The problem appears when you copy your private key, want to store it in some safe place, you switch between apps, and immediately see that some other app copied your private key to the clipboard. 

Allowing to copy private keys or mnemonics was quite a common issue. But there was an application that went a little bit further.  

It was verifying whether you screenshotted a private key or mnemonics. There was a button called “Export private key” – after clicking it, the private key was exported as a QR-code, and the application was saving this QR-code in your photo gallery. This does not make any sense. 

Quick threat modeling revealed another problem – what if someone knew a passcode to your phone? It may be someone from your family or a stranger that saw your passcode on a bus and decided to pickpocket your phone. How will the application protect your data and money? 

For an attacker, it is pretty easy to access your funds.  

After opening the application, they may simply click random buttons and try to brute force your passcode. If it is something simple, like 1111, they can easily get access to your profile in the application. If there is no passcode, there is no protection. So, we should ensure that the application does not allow users to set simple passcodes or at least informs them about consequences.  

But there is even a simpler way. What if an attacker abuses biometric functionality? The application should verify whether biometric settings have been changed. How does the attack look in reality? 

First, the attacker obtains your device passcode and gets access to your phone. In our case, the application uses biometric verification instead of a passcode. The attacker adds their fingerprint in settings and, by doing that, gets access to your wallet. In this scenario, the application should verify whether biometric settings have been changed, disable biometric authentication and request a passcode. 

This trick works not only on some no-name applications. It has worked even on such apps as a high-budget Phantom wallet. After obtaining a system passcode, one could disable biometric settings on your phone and, therefore, disable any protection in the application, because the application did not have passcode protection. 

Since wallet must be treated like a banking application, there should be some quality-of-life features like hiding balance – 1inch made a great job by implementing this. Also, such applications should inform users if they are being run on a compromised (read: jailbroken) device. 

If you are interested in security of your mobile application, be sure to check our offer for mobile application testing. 

Dawid Pastuszak Senior IT Security Consultant