Bybit exploit tied to Safe developer machine vulnerability

SlowMist founder Yu Xian said anyone using Safe’s multi-signature services may be exploited in theory.

Cover art/illustration via CryptoSlate. Image includes combined content which may include AI-generated content.

Bybit revealed that the recent $1.4 billion hack did not compromise its infrastructure and was caused by a vulnerability in a Safe developer machine.

According to the exchange’s initial forensic report, the attack was executed through Safe’s AWS S3 bucket, allowing bad actors to manipulate the wallet front end.

Meanwhile, Safe said in a separate Feb. 26 report that the hackers used a compromised machine to submit a disguised malicious transaction proposal. This proposal injected harmful JavaScript into key resources, enabling the attackers to manipulate transactions.

The forensic investigation conducted by Bybit and blockchain security firms Sygnia and Verichains reached the same conclusion as Safe.

Attack execution and forensic findings

The Safe report highlighted that the attackers designed the injected code to modify transaction contents during the signing process, effectively altering the intended execution.

Publicly available web history archives and timestamp analysis indicate that the injection occurred directly into the S3 bucket — an Amazon Web Services (AWS) public cloud storage resource that stores data for objects in distinct units.

The malicious JavaScript code analysis revealed an activation condition tied to specific contract addresses, including Bybit’s contract address and an unidentified contract address suspected to be controlled by the threat actor. This suggests the hackers employed a targeted approach rather than a widespread attack.

Shortly after the malicious transaction was executed and published, Safe uploaded updated versions of the JavaScript resources to its AWS infrastructure. These versions removed the injected code, indicating an effort to erase traces of the compromise. 

Despite this, forensic investigators identified the attack vector and linked it to the broader tactics used by the North Korean hacker group Lazarus. The group is allegedly state-sponsored and notorious for leveraging social engineering and zero-day exploits to target developer credentials.

A small security detail

SlowMist founder Yu Xian said it’s still unclear how the hackers tampered with the front end. He added that, in theory, anyone who uses Safe’s multi-signature services could suffer the same exploit.

According to Xian:

“What is terrifying is that all other user-interactive services with front-ends, APIs, etc. may be at risk. This is also a classic supply chain attack. The security management model for huge/large assets needs a major upgrade.”

Additionally, he assessed that if the Safe front-end had performed basic subresource integrity (SRI) verification, the attack would not have been possible even if a malicious actor modified the JavaScript file, which is a “small security detail.”

SRI verification is a security feature that enables browsers to verify that the resources they fetch are not unexpectedly manipulated based on a cryptographic hash that the fetched resource must match.

Safe response and remediation measures

Safe said it had initiated a comprehensive investigation to assess the extent of the compromise. The forensic review found no vulnerabilities in its smart contracts, front-end source code, or back-end services.

Safe has fully rebuilt and reconfigured its infrastructure to mitigate future risks while rotating all credentials. The platform has been restored on the Ethereum mainnet with a phased rollout, incorporating enhanced security measures. 

While the Safe front-end remains operational, the report urged users to exercise heightened caution when signing transactions.

Additionally, Safe said it is committed to leading an industry-wide initiative to increase transaction verifiability. This initiative addresses an ecosystem-wide challenge, emphasizing security, transparency, and self-custody within DeFi applications.

Lessons from the incident

Despite Safe and Bybit’s reports concluding that the exchange was not compromised, Hasu, the strategy lead at Flashbots, believes they still need to be held accountable.

He said that Bybit infra was insufficient to catch “a pretty simple hack” and that there is no excuse for not verifying message integrity when moving over $1 billion of funds.

Hasu added:

“I’m afraid if we put the blame on SAFE instead of Bybit here, we are learning entirely the wrong lesson from this as a space. Frontends should _always_ be assumed compromised. If your signing process doesn’t accommodate that, you’re ultimately still at fault.”

Jameson Lopp, co-founder and chief security officer at Casa, pointed out that “a major lesson” from the Safe security incident is that no developer should have production keys on their machines. He recommended that production code deployments undergo peer review and involve multiple employees to enhance security.

Mudit Gupta, the chief information security officer at Polygon Labs, also criticized the fact that only one developer had the system authority to submit changes to Safe’s production website and questioned why changes in the objects were not monitored.

Mentioned in this article