SlowMist: Revealing the truth behind the suspension of IOTA, the hacks on bZx and SIM, and how to protect personal cryptocurrency assets

IOTA mainnet paused, bZx attacked twice, and Whale SIM card hacked. What's the mystery behind it all? Listen to SlowMist founder, Yu Xian, discuss recent cryptocurrency security incidents and how to protect personal crypto assets.

Let's first discuss some security incidents that have been disclosed in the past month.

The first incident involved the hacking of the Italian cryptocurrency exchange Altsbit. Although the amount stolen was relatively small, and it was a relatively new exchange, the exchange had a smaller amount of funds to begin with. The stolen amount accounted for about half of their funds, leading them to announce closure.

The second incident involves IOTA; the main reason for this incident was the temporary halt of the entire mainnet.

One can imagine that for a well-known public chain to temporarily halt its mainnet, something significant must have triggered it. When a public chain's mainnet is halted, such as Bitcoin or Ethereum, it means that no transactions can be conducted, and various contracts running on it cannot be executed properly, resulting in significant losses. In IOTA's case, their official wallet introduced a third-party component that was compromised, indirectly impacting many of their users' private keys and passwords, leading to the theft of approximately 8.55 million IOTA tokens, valued at around 2.3 million USD.

Initially, the community and officials were very alarmed by this incident. They were unsure of the source of the problem, receiving numerous complaints from users about their missing coins. To investigate the matter, they had to temporarily halt the entire mainnet.

This incident had a profound impact in our view. However, apart from proactively following up on it, disclosing it, and engaging with the official and community members on Twitter, we did not see many other security teams responding to this emergency.

The reason for the hack was discovered to be due to the official wallet releasing a new version that included a transaction module, essentially giving the wallet exchange-like functionality.

This wallet's desktop version used a well-known JavaScript development framework. The wallet integrated with a third party through a remote call using JavaScript. This led to a problem where if the third party was hijacked or compromised and the JavaScript content was altered, it could directly impact IOTA's wallet since its entire environment operates on JavaScript.

Essentially, if the third party had issues, as long as a user opened the wallet while connected to the internet, their private keys, passwords, and possibly other related information could be compromised by malicious JavaScript code. This is a very real case of an attack. We also produced research reports in both Chinese and English on this incident.

Next is bZx, a DeFi project. Before it was hacked, we didn't hear much about it, especially since it wasn't heavily promoted domestically, and there weren't many users. It wasn't until it was hacked twice that we became very concerned about why it was targeted.

The fundamental reason lies in the economic model and risk control deficiencies. This includes the flow of funds within these protocols, both internally and externally. From our perspective, it's a systemic risk control flaw that combines internal and external aspects of the system, leading to an attack event. Before the attack, other teams had warned them about potential issues. However, those who engage in underground hacking often prioritize taking action. They want to demonstrate their abilities rather than speculating about potential issues.

While early warnings are beneficial, many times, officials may feel overly confident in their understanding of smart contracts and the DeFi world. Only after being attacked do they realize that theoretical risks can indeed materialize. This is the lesson bZx has taught us.

It represents the decentralized label. However, whether decentralized or centralized, there are associated risks.

One recent memorable incident occurred over the weekend with Josh Jones. We also made relevant speculations. At that time, he claimed on Reddit that he was hacked, losing approximately over 1,500 bitcoins and nearly 60,000 BCH. He mentioned that his SIM card was compromised.

Why do we tend to believe his claim of a compromised SIM card? It's because last year, several users of the Coinbase exchange had their funds stolen due to SIM card hacks, which can be classified under a similar risk category, involving third parties.

In fact, it's very similar to the IOTA case mentioned earlier where the wallet was compromised due to the integration of a third-party exchange component. Both the Coinbase and Josh Jones incidents were due to third-party vulnerabilities.

SIM card attacks are quite common, but domestically, it's less of a concern due to the improved operations of domestic operators. There used to be various chaos within domestic operators, including internal malpractice situations. Laws and regulations, along with related agreements, ensure that phone numbers in our country are not easily duplicated by others.

About a decade ago in our country, such phenomena were quite common. However, the technical capabilities of overseas operators may not be as strong as those in our country. Our country's infrastructure is very robust, while many overseas operators are private enterprises with potentially outdated technology and risk management practices, making them susceptible to SIM card cloning through social engineering methods.

We would like to remind users, especially those overseas, that besides using a phone number as a two-factor authentication, it's best to use second-factor authentication apps like Google Authenticator or hardware-level solutions. These are some of the disclosed incidents from the past month, but many more remain undisclosed.

In the past month, we have seen many issues, both internal and external. When it comes to private keys, it's crucial to consider three key aspects: generation, storage, and usage. If any of these steps are not handled with caution, over time, when risks are exposed, the chances of rectifying them or investigating them are very low.

When we talk about private keys, we also consider multi-signature solutions, including the increasingly popular Secure Multiparty Computation (SMPC) algorithm. However, early on, many people were not entirely comfortable with multi-signature support, especially for assets requiring higher security. For instance, Ethereum's popular multi-signature solution is implemented through smart contracts. But even smart contract-based multi-signature solutions have had security issues in the past, so relying solely on on-chain smart contracts for multi-signature security might not be foolproof.

Even if not using smart contracts, when doing multi-signature on protocol layers, it's not guaranteed to be absolutely secure. However, we tend to trust this approach more because it has been validated numerous times in history. If issues arise, one can assume that the entire public chain or the foundational infrastructure of these well-known public chains have significant problems. In such cases, it's not just isolated incidents but a widespread event.

Therefore, in terms of probabilities, code audits, and usage frequency, many people prefer solutions like Bitcoin (BTC) that offer native transparent solutions rather than multi-signature smart contracts written by third parties. Although these smart contracts have undergone security audits, there is still a lack of trust in smart contracts and the underlying virtual machines.

Therefore, in the early days, many private key generation methods were primitive. For instance, after generating a private key or mnemonic, it was often copied multiple times for backup, meaning multiple individuals were responsible for safeguarding it. Initially, these individuals may trust each other, such as three people where any two can combine their private keys or mnemonic fragments to form a complete private key.

However, the first issue arises during private key generation: who is responsible for it, and was the environment secure? Even if the individual deletes the generated data afterward, it's possible to recover this data, raising questions about the initial trustworthiness, making it challenging to investigate these issues in hindsight.

Next is storage - how to securely store private keys.

Another aspect is usage - eventually, private keys need to be utilized. Whether you're making transactions or transfers, you are inevitably connected to the internet, and it's crucial to ensure the security of your operational environment.

Many recent internal incidents have revolved around private keys. As mentioned earlier, private keys are fundamental and foundational in the blockchain layer.

When we look at security issues, incidents of being hacked or having funds stolen often occur due to deficiencies in risk controls or the compromise of management platforms.

Many may wonder how a management platform can be compromised when it's not visible. The reality is that once you're online, your computer could potentially be infected with malware or viruses, compromising the permissions of these platforms.

When conducting an analysis of a hacking incident or fund theft, our approach is to break down many layers and modules from top to bottom, using a simple method called the process of elimination. By ruling out each piece, we eventually identify the root cause.

However, this process is time-consuming. The most time-consuming investigation took over two months before the truth was uncovered. When our team discovered the truth, there were tears shed, and a sense of disillusionment was felt instantaneously.

We understand deeply that any incident is akin to solving a case, requiring the use of the process of elimination to list out all possibilities and systematically rule them out. Often, people's descriptions have flaws, and their memories may be inaccurate or deliberately misleading, requiring thorough scrutiny.

In our history, successful case resolutions are not that common; the success rate may be just over half, not absolute. Furthermore, the probability of recovering stolen funds after solving the case is even lower.

As we all know, cryptocurrency transactions are transparent and visible on the blockchain, but this transparency is limited to transactions and does not record your IP address or your real-world privacy.

When tracking on the blockchain, one interesting point is that eventually, these coins will be converted into fiat currency, it's just a matter of time. Perhaps in a few years, after the storm has passed, one could convert the coins. Many cases we've observed are related to the urgency of converting the funds.

Whether you're an underground hacker who stole coins through vulnerabilities in exchange wallets, phishing users to steal their coins, or encrypting servers and computers through ransomware, the ultimate goal is to liquidate the stolen coins. This involves moving your coins to exchanges, and before entering these exchanges, it's increasingly common to use a mixing platform. For those who need to launder money, these mixing platforms present a strategic game. The amount I wash within the platform each time must be limited, as exceeding this limit would slow down the process. Additionally, one might engage with multiple platforms simultaneously to mitigate risks. If one platform is compromised, all the evidence trails of laundering on that platform can be traced back, including recording your IP address and more.

These methods are not particularly effective against superpowers. When faced with such entities, no matter the method used, whether exploiting vulnerabilities in exchange wallets, phishing users, or using ransomware to extort Bitcoin or Monero, there's always a way to convert the coins.

This involves your coins entering exchanges, and before entering these exchanges, it's crucial to consider your identity and account on the exchange. Professional hackers would never register on these exchanges with their real identities; their KYC, identities, and even video verifications could be fake.

This constitutes a full-fledged underground hacker industry, all fueled by money. For instance, if I stole 100 million USD worth of coins, after passing through various intermediary channels, making a mistake in one step might lead to my coins being stuck or lost, resulting in a 20-30% deduction in the end, which is already considered fortunate.

Many people are concerned about whether a project is secure or not and how to assess it.

It's not an easy task, but we have provided some criteria that can serve as a reference for everyone.

First, does the project have a competent security team? Or are there experienced individuals with rich security backgrounds overseeing the project? This is crucial. If a project lacks a security team, having experienced individuals who can connect development, operations, and management to advance security measures in an organized manner is also effective.

How can one determine if the project indeed has an internal security team or core personnel? This isn't easy to answer, as the industry often relies on reputation. It might require more exposure and connections to accurately assess the situation.

Secondly, within the last six months, has the project been professionally audited by a third-party security firm and have publicly disclosed audit results? This requirement is challenging for many projects.

Given the rapid pace of industry development, having a project audited by a professional security firm within six months, especially one that is renowned and has publicly available reports, is ideal. However, many project teams are not keen on publicly disclosing internal audit reports, as they may contain sensitive project information, which is understandable.

Nevertheless, we've observed that many overseas projects are willing to transparently publish audit reports through professional auditing firms.

Third, is there a long-term close collaboration with third-party security firms? Since security requires long-term development, having one or more very close relationships with professional security firms is essential. If any black swan events occur, having a continuous relationship can facilitate faster containment.

From our perspective, being hacked is inevitable. No one dares to claim they've never been hacked, which is a certainty. While some projects manage to avoid fund theft, being hacked on the open internet is a constant possibility, even internally. Therefore, facing this reality is essential.

As long as you haven't lost too much or you weren't acting with malicious intent or lack of transparency from the start, embracing these challenges can actually garner wider community support.

This leads to our fourth point, where core members should have an open and honest attitude towards security, admitting mistakes rather than just making empty claims. For instance, many project teams boast about their exceptional security on their official websites. They may use terms like "Zeus-level" security, but these slogans are essentially meaningless. Those with malicious intent can exploit such claims to hold you accountable in the future.

Fifth, a project should approach security with reverence and respect. This attitude is not only applicable to security but also across the entire industry. Everyone involved in the industry, from top to bottom, should approach their work with a sense of awe and respect.

Recently, we audited several hardware wallets and summarized what makes a hardware wallet secure and robust.

1. It's best if the wallet supports a wide range of mainstream cryptocurrencies.

While this isn't an absolute requirement, it's a peace of mind consideration. Ideally, a person's hardware wallet shouldn't hold more than two types of cryptocurrencies, as having too many isn't necessarily ideal. Moreover, a truly secure hardware wallet is quite rare.

2. The hardware should use internationally top-tier hardware modules, and the production and shipment supply chain should also be top-notch.

Many hardware wallet teams may not entirely utilize top-tier, professional-grade chips, modules, and components. Thus, it's essential to rely on internationally top-tier standards. Even if you can't make them, you should use them well. This includes selecting top-quality supply chains, production processes, and shipping methods.

3. The coupling security design between the firmware and hardware modules must be top-notch.

Put simply, the firmware is an operating system, and it's not based on Android modifications, as Android's mission is not to cater to hardware wallets. The coupling between the firmware and hardware modules must have a top-notch security design.

4. Communication modules like Bluetooth and USB at the hardware level should use the latest secure standard processes.

5. The hardware wallet should ideally have a screen for users to visually confirm the correctness of the target address when transferring funds.

6. The accompanying hardware wallet's networked computer or mobile environment should ensure purity and singularity.

If you're uncertain, it's best not to mix usage in other environments. For example, if you're confident in your setup, it's fine, but if you're unsure, it's better to have a separate virtual machine or computer dedicated to important asset operations.

7. The hardware wallet should preferably support multi-signature security management.

Multi-signature or multi-party computation is an excellent method. However, multi-signature mechanisms vary, and there's no one-size-fits-all solution. Nevertheless, multi-signature mechanisms can standardize solutions, making them more universal, which we eagerly anticipate.

8. The design for mnemonic recording, storage, and even co-management should ideally incorporate the implementation of Shamir's Secret Sharing Scheme (SSSS).

In simple terms, when splitting the mnemonic, for example, it could be designed as 2-3 or 3-5. No one person should remember all the words. After copying, if you can ensure that the multiple copies you've made can be combined to form a complete mnemonic, such as using two copies for a 2-3 scheme, it can be pieced together to form a complete mnemonic.

9. Physical security of the hardware wallet should not be overlooked.

For instance, it should have good waterproofing, fire resistance, and protection against lightning strikes. Additionally, it should be resistant to physical damage and capable of non-perfect recovery, preventing tampering during the shipping process or in the supply chain.

10. The secure upgrade mechanism for the firmware and accompanying software should not be neglected.

You