About the recent Solana Private Key Scare: What Builders Can Learn

Oak Security Blockchain Audits

Security is in the news again. This time a widespread exploit in the Solana ecosystem that looks to be linked to Slope. Details are still emerging and the hack has not been resolved yet.

What is becoming apparent is that users’ wallet seed phrases were leaked, allowing the hacker to access these wallets. We have a lot of experience working with clients who manage private keys and would like to offer some advice for developers, so that they can avoid this situation and secure their users’ private information.

What we know so far

So far we know that an estimated $6 million dollars worth of assets have been taken. The cause seems to be a leak of private keys of Slope wallets. This means that the hacker can derive all private keys and access any wallet derived from these seeds as if it was theirs.

When a protocol is exploited, be it a bridge, a yield aggregation farm, or a lending protocol, we would see the project’s assets drained, the TVL reduced and watch as the funds are Tornado-ed out.

This situation is different as it’s the private keys that have been compromised en masse, meaning the hacker has direct access to all assets of the compromised wallets and can make transactions as if they were theirs.

A number of excellent threads have been written about what happened in this case.

What actually happened?

From early forensic efforts, it seems that the seed phrases were leaked via wallets’ logging data. Whilst it is still unclear at which stage exactly the attacker got access to the leaked data, it has been established that seed phrases have been sent out in clear text to a third-party logging provider.

Default logger configurations can easily lead to sensitive data being leaked (internally, or even worse involving external providers), and has very serious implications. Such logger and configuration setups are things we come across often in our security audits, particularly in the case of wallet and key management solutions (example).

How you store data should be a top priority for your project, especially one that manages keys.

Just as users are told to never share their seed phrase, so too applications need to keep that information private. Key management, in particular in the combination with storage and logging are critical parts that require attention.

With that in mind, what are some best practices for how you can store and manage private data?

Guidelines to deal with logging

Sensitive Data Exposure is one of the most common problems in the OWASP classification. When it comes to logging data important security measures can slip under the radar. Developers can accidentally log a data structure that has the private keys nested as one of its properties. It can even happen due to attaching metadata like an account which is shown when throwing an error, which can get logged. It is of little use to store keys in highly secure cryptographic enclaves if they are then also stored in clear text in a simple log file. Here is a list of guidelines for using logging:

1. Do not log or propagate data structures that are not sanitized and may contain sensitive data! This includes, of course, any information that can be used to derive private keys, such as passwords used in key derivation schemes and seed phrases.
2. Make sure production logs are free from additional data used in testing that might have security or privacy implications.
3. Only use logging software that is well tested, trusted (open-source and community verified), and downloaded from a trusted source. This should hold for any libraries used in critical software (see below).
4. If the logging framework used stores data externally (third-party logging providers), be extra careful with what is sent out.
5. Consider things like user data protections and jurisdictions. Depending on where you offer your service, where data is stored, and how easily it can be deleted again might be regulated by data protection laws, such as GDPR.

Guidelines to deal with key material (in memory and storage)

In addition to the logging situation, there are a number of other things that can go wrong with software handling keys. Some of these precautions might be obvious, but others are more nuanced and we see plenty of related vulnerabilities in our audits. We offer pentesting for data storage including device storage, keyboard caching, and best practices when it comes to story and protecting private data. While a full tutorial is beyond the scope of this article, here are a few guidelines:

1. Ideally, all key management should be performed in a protected enclave, such as a trusted execution environment. Server-side hardware security modules (HSM) can be used. Cloud-based key management solutions are an alternative but are considered less secure. However, many end-user devices include cryptographically secure enclaves, such as mobile phones and laptops. These should be used if possible, which requires some integration work on part of the software developer.
2. Software components dealing with key generation, key usage, and key storage should be cleanly separated in the architecture to keep them unpolluted and manageable. Memory should be cleaned as early as possible.
3. Key generation material and keys themselves should only be in memory when needed and should never be stored unencrypted.
4. Keys should only ever be generated from a cryptographically secure random number source.
5. Special care must be taken when using cryptographic libraries. These must be sourced carefully (see below) and configured correctly. We often see cases of incorrect library use, such as insecure initialization vectors or salts, insufficient computational rounds used in key derivation processes, or nonce reuse.
6. Additional recommendations for wallet apps that we include in our pentesting services and that you include in your own testing and internal/external audits:

• Checking whether sensitive key material can be copied into a clipboard or if the keyboard cache is active.
• Background behavior to assess how the application behaves once it goes into the background. Any sensitive information should be cleared from memory at that stage, sensitive information should be hidden from views when it moves to the background.

Guidelines to using secure libraries and avoiding supply chain attacks

Dealing with the supply chain for software libraries can be challenging. As we know, the more complex the code is and the more external projects it interacts with, the more attack vectors there are.

Besides the obvious risks of data leakage to external providers and insecure libraries, there is a real risk of supply-chain attacks through distribution channels. Here is a list of basic guidelines:

1. Keep the dependency tree as lean as possible. The more libraries you use, the harder it is to keep track of all the nested dependencies. This should, of course, not come at the expense of re-implementing the wheel, such as rolling your own crypto to avoid importing dependencies.
2. Keep dependencies updated.
3. Use only well-tested and commonly used libraries. This may seem obvious for cryptography implementations but it applies to everything. It is very easy to accidentally import a key logger that tracks user passwords disguised as a font library or something similar.
4. Make sure that library imports are sourced correctly. Bad actors could see you mistyping a single letter when importing an npm package and have a tweaked version ready for this case.
5. Be wary of attacks that substitute software packages distributed through Content Distribution Networks. Some high-profile supply-chain attacks have occurred this way.
6. Lock versions. There have been cases where someone injected malicious code in a new version, and a new build automatically imports that malicious code. It’s best practice to set up notifications about new releases, and diligently review them before updating them

In summary: Treat every external source as suspicious.

Final thoughts

We hope that this post helps you to manage your users’ sensitive data more securely. Wallets and other crypto software protocols are tasked with securing private information, and a leak or hack can have disastrous consequences.

Oak Security

Oak Security provides auditing and security advisory services to blockchain projects, DeFi protocols, and related software creators. For support please contact us to discuss your project and needs further.

Website | Twitter | Github | LinkedIn