Why unsuspecting data leaks are key to widespread blockchain hacks
Last month, the 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 is transferred and the operation remains virtually 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 trail of investigation and almost no way to find out where the money actually went.
Imagine hundreds of DB Cooper’s jumping off hundreds of planes every day with bags full of cash 😀
The main vectors of blockchain attacks are smart contract vulnerabilities, protocol and design flaws, crypto-related flaws, rug-pull fraud, etc. Out of these, wallet compromises and key leaks combined accounted for 14% of the total attacks last year!
Hacked
On August 3, approximately USD 6 million worth of SOL, BTC, ETH, USDT and other currencies on Solana as well as Ethereum blockchains were removed from thousands of individual wallets and transferred to the hackers’ wallets, which were ultimately sent to various money laundering methods. wallets.
SlowMist was it first to report this attack and start investigations. While one thorough investigation still ongoing, some undeniable facts have emerged about how the attack happened. Key to the attack as well as the detection of the attack is the Slope wallet app which boasts itself as the “Robinhood of DeFi”.
The steep ‘hill’ of trust
Like thousands of other apps, Slope used a log monitoring tool called Sentry to track various events within the app. This is common practice and is not considered harmful in itself. Please note, however, that technically anything the app produces while interacting with a human can be tracked and sent to a corresponding log tracking server.
In this case, the Slope wallet from v2.2.0+ silently collected sensitive data such as mnemonics and private keys from the app and sent it to their own hosted Sentry server. Mens Sentry especially recommend users to scrub sensitive data, it is objectively difficult to implement every single piece of advice.
In addition, different apps will have different definitions and requirements for which data is considered sensitive. It is impossible to really create a generic guideline for what should be logged and what should not be logged. But in this case, logging memory is an absolutely safe way to provide a springboard 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 creating a new crypto wallet. In 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 important that some use metal seed plates to store mnemonics.
Although the 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 as those found in the Sentry logs. Therefore, the mnemonic leak may just be a correlation or actually be the root cause. We won’t be surprised either way. This is how someone with access to the hosted guard server could have gained access to it:
But we know developers and feel for them. This is not their fault – this era’s coding paradigm is complex. Modern software is built on 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 about all user actions and about their details – sometimes as damning as critical wallet details. The data has now exited the app. And it won’t come back.
How to fix this?
No amount of security and privacy rules alone can help fix this. The nature of modern software prevents detailed manual investigation of such leaks. What we need are tools that help give us visibility into what’s happening with the data across large codebases, so that privacy/security engineers or a developer themselves can identify specific points of potential leaks before they happen. This shift-left approach has been used in security before – it’s now time to implement it for data and privacy.
Searching for a Mnemonic leak using Privado Open Source
Although we can’t actually find the source of the Slope app, we can certainly try to recreate the scenario with a sample app. Let’s take this easy BitcoinWallet app that I modified and added Sentry logging to an imaginary endpoint:
public static void main(String[] args) throws Exception { // initialize Sentry Sentry.init(options -> { options.setDsn(” }); String entropy = createEntropy(); try { String mnemonic = generateMnemonic(entropy); System.out.println(mnemonic ) ; Sentry.getContext().addTag(“mnemonic”, mnemonic); } catch(Exception e) { Sentry.capture(e);
1 2 3 4 5 6 7 8 9 10 11 12 1. 3 14 15 16 17 18 19 20 21 22 23 |
public static void main(String[] args) throws Exception { // initialize Sentry Sentry.in it(options –> { options.setDsn(“https://[email protected]/0”); }); String entropy = create entropy(); try { String mnemonic = generate Mnemonic(entropy); System.out.println(mnemonic); Sentry.getContext().Add a tag(“mnemonic”, mnemonic); } catch(Exception e) { Sentry.prisoner(e); |
Here we can see that the user’s mnemonic can “accidentally” leak to the Sentry service they are running. Imagine this, but deep inside your app. So every time a user creates a new wallet and gets a 12-word mnemonic (which is essentially a key to recover the wallet), there is a risk of it being logged to their central logging infra.
One way to find this type of leak now is to use the Privado open source tool. A developer can run a privacy scan and start exploring what data it detects and visually see if something like a mnemonic flows to a third-party logging service as shown below:
To try this yourself on this sample BitcoinWallet app or to find data leaks in your own Java apps, head over 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 that you want to add, you are welcome to contribute to the project and submit pull requests.
– id: Data.Sensitive.AccountData.Mnemonic name: Mnemonic category: Account data isSensitive: False sensitivity: high patterns: – “(?i).*(mnemonic)” tags: law: GDPR
1 2 3 4 5 6 7 8 9 10 11 12 1. 3 14 15 16 17 |
– id: Data.Sensitive.Account data.Mnemonic Name: Mnemonic category: Accounting Data is sensitive: False sensitivity: high patterns: – “(?i).*(mnemonic)” tags: law: GDPR |
In this example, to trace a wallet memory, I simply had to add the above rule into one rules YAML file and the data tracking worked all the way to the Sentry sink!
Now is the time to bring a privacy 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.