Security at Sodot has been and will always remain a top priority. In addition to applying external and internal security measures, we also actively analyze and discuss security incidents across both Web3 and Web2. This blogpost presents our main takes on the Bybit hack, emphasizing the shared learnings that can be derived from it.
Note: As of the time of writing, the investigation is still ongoing, and not all details are publicly available.
What Happened?
It has been concluded that the attack was carried out by the Lazarus Group, a notorious North Korean hacker group responsible for several high-profile Web3 breaches, including: The Phemex hack ($30M), the Ronin Bridge hack ($620M), the Horizon Bridge hack ($100M) and the Atomic Wallet hack ($100M).
The Bybit hack, however, was significantly more severe, resulting in the theft of $1.4B from the exchange’s warm wallet, which was managed using a multisig Safe{Wallet}.
The attack was executed via a supply-chain compromise:
- Lazarus Group phished and socially engineered a Safe{Wallet} developer.
- The compromised developer’s laptop contained critical credentials, most likely an API key, allowing the attackers to modify Safe’s AWS S3 bucket.
- Lazarus Group injected malicious JavaScript files, which remained dormant unless accessed by ByBit employees.
- When triggered, the altered script pushed a transaction to be signed, modifying the Safe{Wallet} smart contract logic.
- This enabled Lazarus Group to drain ByBit’s wallet, while other wallets remained unaffected.
More in-depth analyses can be found here (Verichains - hired by Bybit), here (Safe), here (Halborn), and here (Slowmist).
What Can We Learn?
We’ve been frequently asked: Would using MPC instead of Multi-Sig have prevented this attack? The answer is - not on its own.
While MPC could have introduced additional security layers that would have made the attack harder, a core issue here was operational security (OpSec).
However, enforcing and strengthening the foundational principles that stand at the heart of MPC - risk distribution and elimination of single points of failure - could have prevented it.
Key takeaways & best practices for key management and OpSec:
- Distributed approval/access mechanisms go beyond key management - One of Safe’s dev devices was compromised, allowing attackers to steal credentials and modify sensitive code on Safe’s AWS S3 bucket. Distributed authority is as critical here as distributing the key. It is important to ensure that no dev/admin is a single point of failure, from pushing code to cloud account access.
- External UI interface is also a potential point of failure - The UI that was served by Safe{Wallet} is in fact, a single point of failure and affected all parties involved in the multi-sig signing process. Measures of mitigation include securing the UI integrity through code signing and content security policies (CSP).
- The power of combining human and machine verification - A server-side policy engine that independently verifies transactions according to pre-defined policies wouldn’t have signed the malicious masked transaction. It is best to also accompany that by a mobile (human) user to verify the validity of the intended transactions.
- Cross-environment setting reduces attack feasibility - Using distributed approval/access mechanisms across different environments makes pulling off an attack significantly more complicated. Reducing the risk of a compromised dev environment can be achieved by distribution of risk across independent cloud providers and the corresponding tech stacks used therein (e.g TEEs) or by combining a mobile phone for signing sensitive transactions/actions.
- Secure key management is not a replacement for proper OpSec - Defining internal simple, enforceable and clear rules on the way employees interact with internal and external systems and in particular regarding the software development lifecycle security is vital.
- Effective mitigation starts with clear threat modeling - a clear statement of the threat model and the identification of possible threats and mitigations are what makes an organization highly secure. The last step – mitigations – is where security products and other sorts of mitigations (e.g. key sharding via MPC) come into play.
Final remarks
Security is not a one-time effort. It’s a continuous process of staying ahead of sophisticated attackers, with an emphasis on unifying and minimizing internal attack surfaces.
Please feel free to reach out if you have any questions or want to discuss your architecture, internal processes, or any other related matter.
