Last month, Solana blockchain faced yet another attack in a series of recent attacks targeting blockchains. Blockchains are the ultimate record of crypto assets and recording transactions from one wallet to another on the ledger guarantees that money gets transferred and the operation virtually remains anonymous.
This is an absolute gem for criminals because 1) few financial and security regulations exist in this modern decentralized finance (DeFi) world as of now and; 2) anonymity on the blockchain guarantees a very difficult investigation trajectory and almost no way to pinpoint where the money actually went.
Imagine hundreds of D.B Coopers jumping from hundreds of airplanes every day with bags full of cash 😀
The top vectors of blockchain attacks are smart contract vulnerabilities, protocol and design flaws, crypto-related bugs, rug-pull scams, etc. Out of these, wallet compromises and key leaks together accounted for 14% of total attacks last year!
The Hack
On August 3, around USD $6 million worth of SOL, BTC, ETH, USDT and other currencies on Solana as well as Ethereum blockchains were siphoned off from thousands of individual wallets and transferred to hackers’ wallets and that eventually were sent to various money laundering wallets.
SlowMist was the first to report this attack and begin investigations. While a thorough investigation is still in progress, some undeniable facts have emerged on how the attack occurred. The key to the attack as well as the discovery of the attack is the Slope wallet app that boasts itself as “Robinhood of DeFi.”
The Steep ‘Slope’ of Trust
Like thousands of other apps, Slope used a log monitoring tool called Sentry to track various events in the app. This is common practice and not considered harmful in itself. However, note that technically anything that the app produces while interacting with a human can be tracked and sent to a corresponding log tracking server.
In this instance, the Slope wallet from v2.2.0+ was quietly collecting sensitive data such as mnemonics and private keys from the app and sending it to their own hosted Sentry server. While Sentry specifically recommends users to scrub sensitive data, it is objectively difficult to implement each and every piece of advice.
Moreover, different apps will have different definitions and requirements of what data is considered sensitive. It is impossible to really create a generic guideline on what to log and what not to log. However, in this instance, logging mnemonics are absolutely a sure-shot way to provide a stepping stone for an attacker to mount attacks on wallets.
What Is a Mnemonic?
A mnemonic is usually a collection of 12 words that a user can choose when they create a new crypto wallet. In the case a user is unable to use the password, they can use the mnemonic to recover the wallet. It provides a more user-friendly recovery system in the absence of a centralized password store and recovery system. This is so crucial that some people use metal seed plates to store their mnemonics.
While SlowMist investigation is still not complete, there is no doubt that the decision to log mnemonics was a dangerous one. The analysis suggests that approximately 31% of known compromised victim wallets were the same ones that were found in the Sentry logs. Therefore, the mnemonic leak could merely be a correlation or could actually be the root cause. We won’t be surprised either way. This is how someone who is able to access the hosted sentry server could have accessed it:
But, we know developers and we empathize with them. This is not their fault — this era’s coding paradigm is complex. Modern software is built upon layers and layers of libraries and other code. Logging has gone from printing something pretty on a local console in a basement machine to monitoring billions of actions in millions of devices and machines running globally. Fine-grained data is collected on all user actions and about their details — sometimes as damning as critical wallet details. The data has now exited the confines of the app. And it is not coming back.
How to Fix This?
No amount of operational safety and privacy policies can alone help fix this. The nature of modern software prevents detailed manual scrutiny of such leaks. What we need are tools that help give us visibility into what is happening to the data across large codebases so that privacy/security engineers or a developer themselves can identify specific points of possible leaks before they can happen. This approach of shifting left has been used in security before — it is now time to implement it for data and privacy.
Hunting for a Mnemonic Leak Using Privado Open Source
While we can’t really get the source of the Slope app, we can surely try to recreate the scenario with a sample app. Let’s take this simple BitcoinWallet app that I have modified and add some Sentry logging to an imaginary endpoint:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
public static void main(String[] args) throws Exception {
// initialize Sentry
Sentry.init(options –> {
options.setDsn(“https://examplePublicKey@o0.ingest.sentry.io/0”);
});
String entropy = createEntropy();
try {
String mnemonic = generateMnemonic(entropy);
System.out.println(mnemonic);
Sentry.getContext().addTag(“mnemonic”, mnemonic);
} catch(Exception e) {
Sentry.capture(e); |
Here we can see that the user’s mnemonic could “accidentally” leak to Sentry service they are running. Imagine this, but deep within layers of your app. So every time a user would create a new wallet and get a 12-word mnemonic (that is essentially a key to recover the wallet), There is a risk it gets logged to their central logging infra.
One way to find this type of leakage now is to use the Privado open source tool. A developer can run a privacy scan and start exploring what data it discovers and visually see if something like a mnemonic is flowing to a third-party logging service as shown below:
To try this out yourself on this sample BitcoinWallet app or to find data leaks in your own Java apps, head to the Privado OSS repo and try it out. In addition to out-of-the-box discovery, there are hundreds of custom sources and sinks that can be defined as rules in Privado. If you come across interesting data sources and data sinks you want to add, feel free to contribute to the project and submit pull requests.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
– id: Data.Sensitive.AccountData.Mnemonic
name: Mnemonic
category: Account Data
isSensitive: False
sensitivity: high
patterns:
– “(?i).*(mnemonic)”
tags:
law: GDPR |
In this example, to track a wallet mnemonic, I simply had to add the above rule in a rules YAML file and the data tracking just worked all the way to Sentry sink!
It is now time to bring a privacy engineering tool to every developer and data security analyst so that we can collectively ensure that private data in the app remains private from day 1 of development.