Chuyện Gì Đã Xảy Ra?
Hệ thống ví lạnh đa chữ ký (Multisig Cold Wallet) từ lâu đã được xem là một trong những giải pháp bảo mật hàng đầu cho sàn giao dịch tiền mã hóa. Nhưng vụ tấn công vào Bybit vừa qua lại cho thấy một điều đáng lo ngại: bảo mật hệ thống có tốt đến đâu cũng fail nếu người vận hành bị cài mã độc.
Nhóm hacker Lazarus, nổi tiếng với các cuộc tấn công tinh vi, đã khai thác lỗ hổng trong quy trình ký giao dịch và đánh cắp số Ethereum (ETH) trị giá 1.5 tỷ USD. Vậy bằng cách nào chúng đã thực hiện điều đó?
COMPROMISE AWS S3/CLOUDFRONT
Tin tặc đã xâm nhập vào hệ thống AWS S3 hoặc CloudFront của Safe.global, nơi lưu trữ mã giao diện người dùng, và chỉnh sửa các tệp JavaScript. -> Giống như kiểu tôi cài hàng vào các cánh cửa.
Safe.global xác nhận rằng hacker đã khai thác máy tính của một nhà phát triển bị xâm nhập, có khả năng thông qua phishing hoặc tấn công xã hội, để chiếm quyền truy cập vào thông tin đăng nhập AWS. Cái này thì chưa thấy confirm chính thức.
Cuộc tấn công bắt đầu vào ngày 19/02/2025, 15:29:25 UTC, và được kích hoạt khi Bybit thực hiện giao dịch vào ngày 21/02/2025, 14:13:35 UTC.
JAVASCRIPT INJECTION
Thông qua wayback machine, người ta đã phát hiện ra tin tặc đã chèn mã độc vào hai tệp JavaScript: _app-52c9031bfa03da47.js và 6514.b556851795a4cbaa.js, được thiết kế để chỉ kích hoạt khi sử dụng ví Bybit, hoạt động như một “quả bom hẹn giờ”.
Safe.global xác nhận rằng mã độc này không xuất phát từ smart contract mà từ giao diện người dùng bị chỉnh sửa. Sau khi thực hiện tấn công, hacker nhanh chóng xóa mã độc để che giấu dấu vết, theo báo cáo từ BleepingComputer.
Dụ người dùng ký vào giao dịch độc hại
Hacker không tấn công trực tiếp vào smart contract mà giả mạo giao diện ký giao dịch. Những người có quyền ký mở giao diện và thấy thông tin giao dịch có vẻ hợp lệ, nhưng thực chất, họ đang ký một lệnh thay đổi logic smart contract của ví lạnh mà không hề hay biết. Khi giao diện bị làm giả, người ký không thể biết rằng họ đang phê duyệt một giao dịch nguy hiểm.
Khi quản lý ví Bybit ký giao dịch trên Safe.global, mã độc sao chép giao dịch gốc, sau đó thay đổi tham số, chuyển từ operation=0 sang delegatecall (operation=1). Đây là màn đánh tráo hoàn hảo, khiến người dùng ký nhầm vào giao dịch độc hại. Halborn xác nhận kỹ thuật này đã thao túng logic hợp đồng.
DELEGATECALL EXPLOIT
DELEGATECALL hoạt động ở Layer 1 của blockchain vì nó là một opcode trong EVM, tức là nó diễn ra trực tiếp trong blockchain và được thực thi bởi các node Ethereum.
Nếu contract B có một hàm độc hại (ví dụ: thay đổi owner hoặc gửi tiền ra ngoài), nó có thể thao túng storage của contract A.DELEGATECALL có thể bị “storage collision”, nghĩa là nếu contract gọi và contract được gọi có cấu trúc lưu trữ khác nhau, nó có thể ghi đè lên các biến không mong muốn.Hacker có thể lợi dụng DELEGATECALL để thực thi code trái phép bằng cách đánh tráo địa chỉ contract được gọi.
DELEGATECALL là một opcode trong EVM (Ethereum Virtual Machine) cho phép một smart contract gọi hàm của một smart contract khác nhưng giữ nguyên context của contract gọi.
- Nó giống với CALL, nhưng thay vì sử dụng bộ nhớ (storage) của contract đích, nó sử dụng bộ nhớ của contract gọi.
- Khi sử dụng DELEGATECALL, biến trạng thái (state variables) của contract gọi có thể bị thay đổi bởi code của contract đích.
- DELEGATECALL thường được dùng trong các proxy contracts, giúp nâng cấp smart contract mà không thay đổi địa chỉ.
Giả sử có hai smart contract:
- Contract A: Gọi Contract B thông qua DELEGATECALL.
- Contract B: Chứa code mà Contract A sẽ thực thi trong ngữ cảnh của chính nó.
Ví dụ:
// Contract B: Chứa logic nhưng không có biến trạng thái
contract B {
uint public num;
function setNum(uint _num) public {
num = _num; // Thay đổi giá trị của biến 'num'
}
}
// Contract A: Gọi Contract B bằng delegatecall
contract A {
uint public num; // Có cùng layout storage với Contract B
function delegateSetNum(address _contractB, uint _num) public {
(bool success, ) = _contractB.delegatecall(
abi.encodeWithSignature("setNum(uint256)", _num)
);
require(success, "Delegatecall failed");
}
}Contract A gọi Contract B.setNum(uint256) nhưng trong context của A.Thay vì cập nhật num trong Contract B, nó thay đổi num trong Contract A.Nếu Contract B có một hàm độc hại, nó có thể thay đổi bất kỳ biến nào trong Contract A.
Tóm lại attack vector như sau:
Thay vì dùng call (operation=0), mã độc chuyển sang delegatecall (operation=1), cho phép hợp đồng tấn công (sga) thực thi mã trong ngữ cảnh Safe.global, như một “con dao hai lưỡi”. Check Point Research và Safe.global đồng thuận rằng lỗ hổng nằm ở giao diện, không phải smart contract.
Qua delegatecall, hacker “nâng cấp” hợp đồng multisig Bybit, thay logic an toàn bằng backdoor độc hại. Tưởng tượng như giữ nguyên khóa nhưng cánh cửa dẫn thẳng đến kẻ trộm. Safe.global xác nhận contract không bị lỗi, vấn đề nằm ở máy tính nhà phát triển.
Chiếm quyền kiểm soát và rút toàn bộ ETH
- Sau khi smart contract bị thay đổi, hacker nắm toàn quyền kiểm soát ví lạnh.
- Chúng nhanh chóng chuyển hết số ETH sang địa chỉ riêng, hoàn tất phi vụ mà không cần thêm bất kỳ sự xác nhận nào khác.
Bybit Đã Làm Gì Để Ứng Phó?
- Bybit xác nhận ví lạnh bị tấn công nhưng khẳng định các ví khác vẫn an toàn.
- Để đảm bảo thanh khoản, Bybit vay ETH từ Binance và Bitget.
- Safe{Wallet} tạm thời đóng băng một số chức năng để điều tra và ngăn chặn sự cố tương tự xảy ra.
Tóm lại các lỗ hổng cốt lõi
- Xâm nhập vào hệ thống lưu trữ giao diện: Hacker có được quyền truy cập vào AWS S3 hoặc CloudFront của Safe.global, nơi lưu trữ mã frontend.
- Chèn mã độc vào tệp JavaScript: Hacker chỉnh sửa mã nguồn frontend để thực hiện một cuộc tấn công “đánh tráo giao dịch” chỉ khi người dùng sử dụng ví Bybit.
- Khai thác delegatecall: Mã độc thay đổi tham số giao dịch, chuyển từ
operation=0(call) sangoperation=1(delegatecall), từ đó thực thi mã ngoài ý muốn ngay trong hợp đồng Safe. - Xóa dấu vết sau tấn công: Sau khi đánh cắp tài sản, hacker gỡ bỏ mã độc để tránh bị phát hiện.
Tham khảo:
Nhat Truong Blog 