Cuộc chiến giành 97 triệu USD trên chuỗi Blast, tin tặc một quốc gia nào đó đã trở nên vụng về?
Tuyển chọn TechFlowTuyển chọn TechFlow
Cuộc chiến giành 97 triệu USD trên chuỗi Blast, tin tặc một quốc gia nào đó đã trở nên vụng về?
Dự án Munchables bị tấn công, khoảng 97 triệu đô la Mỹ đang đối mặt với rủi ro, chuyện gì đã xảy ra?
Chuyên sâu báo cáo Web3Tác giả: CertiK
Bối cảnh
Blast là một mạng lưới Layer2 Ethereum do Pacman (Tieshun Roquerre, còn gọi là Thiết Thuận), người sáng lập Blur, phát triển và đã chính thức khởi chạy mainnet vào ngày 29 tháng 2. Hiện tại, có khoảng 19.500 ETH và 640.000 stETH được stake trên mainnet Blast.
Dự án bị tấn công Munchables là một dự án chất lượng cao giành chiến thắng trong cuộc thi Bigbang do Blast tổ chức.
Người dùng stake ETH trên mainnet Blast sẽ nhận được điểm thưởng thông thường từ phía đội ngũ Blast:
Để khuyến khích người dùng tham gia vào các dự án DeFi trên hệ sinh thái Blast, đội ngũ Blast sẽ lựa chọn những dự án chất lượng để giới thiệu, đồng thời khuyến khích người dùng stake lại ETH lần thứ hai vào các ứng dụng DeFi nhằm nhận tốc độ tích lũy điểm nhanh hơn cũng như điểm vàng. Do đó, rất nhiều người dùng đã tiếp tục stake ETH đang nằm trên mainnet Blast vào các dự án DeFi mới ra mắt.
Tuy nhiên, mức độ trưởng thành và tính bảo mật của các dự án DeFi này vẫn còn cần được kiểm chứng – liệu các hợp đồng này có thực sự an toàn để quản lý hàng chục triệu, thậm chí hàng trăm triệu đô la tài sản của người dùng hay không?
Tổng quan sự việc
Chưa đầy một tháng sau khi ra mắt mainnet, vào ngày 21 tháng 3 năm 2024, một vụ tấn công đã xảy ra nhắm vào token SSS (Super Sushi Samurai) trên Blast. Hợp đồng token này chứa một lỗi logic chuyển khoản cho phép tin tặc tăng số dư SSS tùy ý cho bất kỳ tài khoản nào, dẫn đến thiệt hại hơn 1310 ETH (khoảng 4,6 triệu USD).
Và chưa đầy một tuần sau vụ tấn công token SSS, một vụ tấn công lớn hơn nữa đã xảy ra trên Blast: dự án Munchables bị tin tặc rút sạch 17.413,96 ETH, tương đương khoảng 62,5 triệu USD.
Nửa tiếng sau giao dịch tấn công, 73,49 WETH trong hợp đồng của dự án cũng bị chuyển đến một địa chỉ khác do hacker kiểm soát.
Lúc này, trong địa chỉ hợp đồng của dự án vẫn còn tồn đọng 7.276 WETH, 7.758.267 USDB và 4 ETH – tất cả đều sẵn sàng rơi vào tay tin tặc, vì hacker nắm quyền kiểm soát toàn bộ quỹ của dự án, với tổng giá trị phơi nhiễm rủi ro lên tới khoảng 97 triệu USD.
Ngay sau sự việc, nhà điều tra chuỗi nổi tiếng ZachXBT trên X (Twitter) đã chỉ ra nguyên nhân gốc rễ của vụ việc là do đã thuê phải một tin tặc "từ một quốc gia nhất định".
Hãy cùng đi sâu tìm hiểu cách mà "tin tặc đến từ một quốc gia nhất định" này đã thực hiện một cuộc tấn công gần chạm mốc 100 triệu USD.
Khôi phục hiện trường
Phản hồi từ nạn nhân
[UTC+0] 21h37 ngày 26 tháng 3 năm 2024 (5 phút sau khi vụ tấn công xảy ra), Munchables chính thức đăng bài trên X (Twitter) xác nhận bị tấn công.
Theo điều tra của nhà điều tra chuỗi ZachXBT, nguyên nhân là do một trong các nhà phát triển của họ là "một tin tặc đến từ một quốc gia nhất định". Người sáng lập Aavegotchi, coderdannn, cũng khẳng định trên X (Twitter): "Đội ngũ phát triển Pixelcraft Studios của Aavegotchi từng thuê ngắn hạn kẻ tấn công Munchables này để làm một số công việc phát triển trò chơi vào năm 2022. Kỹ năng của anh ta rất tệ, đúng kiểu một tin tặc đến từ một quốc gia nhất định, chúng tôi đã sa thải anh ta trong vòng một tháng. Anh ta còn cố gắng thuyết phục chúng tôi thuê thêm một người bạn của mình, rất có thể người này cũng là một tin tặc."
Do vụ tấn công gây tổn thất nặng nề cho cộng đồng người dùng, chúng tôi ngay lập tức khởi động điều tra chuỗi. Hãy cùng phân tích kỹ chi tiết cuộc tấn công của "tin tặc đến từ một quốc gia nhất định" này.
Hiện trường đầu tiên
[UTC+0] 21h32 ngày 26 tháng 3 năm 2024, vụ tấn công liên quan đến 17.413,96 ETH xảy ra.
Thông qua Blastscan, chúng ta có thể xem giao dịch tấn công này: https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95
Hợp đồng bị ảnh hưởng (0x29..1F) là một hợp đồng proxy lưu giữ tiền gửi stake của người dùng. Chúng ta có thể thấy, tin tặc đã gọi hàm unlock của hợp đồng stake, vượt qua mọi kiểm tra quyền hạn và chuyển toàn bộ ETH trong hợp đồng sang địa chỉ của tin tặc (0x6E..c5).
Trông giống như tin tặc đã gọi một hàm unlock tương tự hành vi withdraw, rút phần lớn ETH khỏi hợp đồng bị ảnh hưởng (0x29..1F).
Có phải kho bạc của dự án quên khóa không?
Hàm unlock trong hợp đồng bị ảnh hưởng (0x29..1F) có hai bước kiểm tra liên quan. Hãy xem xét từng cái một.
Thứ nhất, trong quy trình kiểm tra quyền hạn, hệ thống gọi phương thức isRegistered của hợp đồng (0x16..A0) để kiểm tra xem msg.sender hiện tại – tức là địa chỉ tin tặc 1 (0x6E..c5) – đã được đăng ký hay chưa:
Câu trả lời là: Đã vượt qua xác minh.
Ở đây liên quan đến hợp đồng (0x16..A0) và hợp đồng logic mới nhất tương ứng của nó (0xe7..f1).
[UTC+0] 8h39 ngày 24 tháng 3 năm 2024 (hai ngày trước khi vụ tấn công xảy ra), hợp đồng logic tương ứng với hợp đồng (0x16..A0) đã được nâng cấp.
Giao dịch nâng cấp hợp đồng logic:
https://blastscan.io/tx/0x9c431e09a80d2942319853ccfdaae24c5de23cedfcef0022815fdae42a7e2ab6
Hợp đồng logic đã được cập nhật thành 0xe7..f1.
Địa chỉ hợp đồng logic ban đầu có thể xem tại đây, là 0x9e..CD.
https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003
Lúc này, chúng tôi nghi ngờ rằng tin tặc đã cập nhật hợp đồng thực hiện logic của proxy, thay đổi từ 0x9e..CD thành 0xe7..f1 độc hại, từ đó vượt qua kiểm tra quyền hạn.
Có đúng như vậy không?
Trong Web3.0, chúng ta không bao giờ cần phỏng đoán hay tin tưởng người khác; bạn chỉ cần nắm vững kỹ thuật để tự tìm ra câu trả lời.
Bằng cách so sánh hai hợp đồng (đều không mở mã nguồn), chúng tôi thấy có một số khác biệt rõ ràng giữa hợp đồng ban đầu 0x9e..CD và bản cập nhật 0xe7..f1:
Phần cài đặt hàm initialize của 0xe7..f1 như sau:
Phần cài đặt hàm initialize của 0x9e..CD như sau:
Có thể thấy, tin tặc đã thiết lập địa chỉ của mình (0x6e..c5) là register trong hợp đồng logic ban đầu (0x9e..CD), đồng thời hai địa chỉ khác của tin tặc là 0xc5..0d và 0xbf..87 cũng được register, và field0 của chúng được đặt bằng thời gian khối lúc khởi tạo – field0 sẽ được giải thích chi tiết sau.
Thực tế, ngược lại hoàn toàn với suy đoán ban đầu của chúng tôi: chính hợp đồng logic chứa backdoor lại là bản ban đầu, còn bản được cập nhật về sau lại là bản bình thường!
Khoan đã, bản cập nhật này xuất hiện vào [UTC+0] 8h39 ngày 24 tháng 3 năm 2024 (hai ngày trước vụ tấn công), nghĩa là trước sự kiện này, hợp đồng logic đã trở thành bản không có backdoor. Vậy tại sao tin tặc vẫn có thể tấn công thành công sau đó?
Lý do là do cơ chế delegatecall, nên trạng thái thực tế được cập nhật trong hợp đồng (0x16..A0). Điều này dẫn đến việc ngay cả khi hợp đồng logic sau đó được cập nhật thành bản không có backdoor 0xe7..f1, các slot đã bị thay đổi trong hợp đồng (0x16..A0) vẫn không được khôi phục.
Hãy cùng kiểm chứng:
Có thể thấy, slot tương ứng trong hợp đồng (0x16.....A0) có giá trị.
Điều này cho phép tin tặc vượt qua kiểm tra của phương thức isRegistered:
Sau đó, tin tặc thay thế hợp đồng backdoor bằng hợp đồng bình thường để che giấu dấu vết, nhưng lúc này backdoor đã được cài đặt từ trước.
Ngoài ra, trong quy trình unlock, còn có một kiểm tra thứ hai:
Kiểm tra thời gian lock – đảm bảo tài sản bị khóa không bị rút trước khi hết hạn.
Tin tặc cần đảm bảo thời gian khối khi gọi unlock lớn hơn thời gian hết hạn yêu cầu (field3).
Phần kiểm tra này liên quan đến hợp đồng bị ảnh hưởng (0x29..1F) và hợp đồng logic tương ứng 0xf5..cd.
Trong giao dịch lúc 11h54 ngày 21 tháng 3 năm 2024 (năm ngày trước vụ tấn công),
https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170
Chúng ta thấy rằng hợp đồng logic ban đầu của hợp đồng bị ảnh hưởng (0x29..1F) là 0x91..11, và chỉ bốn phút sau,
https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f
Nó đã được nâng cấp thành 0xf5..cd.
Một lần nữa, so sánh hai hợp đồng, chúng tôi thấy tin tặc cũng can thiệp vào hàm initialize, giống như trước.
Phần cài đặt hàm initialize của 0xf5..cd:
Phần cài đặt hàm initialize của 0x91..11:
Rõ ràng, một lần nữa sử dụng thủ đoạn tương tự: sửa đổi số lượng ETH nắm giữ và thời gian mở khóa, sau đó thay thế lại bằng hợp đồng bình thường để che giấu. Khi đội ngũ dự án và các nhà nghiên cứu an ninh tiến hành debug, họ chỉ thấy các hợp đồng logic bình thường, và do tất cả đều không mở mã nguồn, việc nhìn thấu vấn đề trở nên cực kỳ khó khăn.
Tới đây, chúng ta đã hiểu cách tin tặc thực hiện giao dịch liên quan đến 17.413 ETH. Nhưng thông tin đằng sau sự việc này chỉ dừng lại ở đó thôi sao?
Trong phân tích ở trên, chúng tôi thấy tin tặc đã tích hợp sẵn ba địa chỉ bên trong hợp đồng:
0x6e..c5 (địa chỉ tin tặc 1)
0xc5..0d (địa chỉ tin tặc 2)
0xbf..87 (địa chỉ tin tặc 3)
Nhưng trong giao dịch tấn công chúng tôi phát hiện ở trên, chúng ta chỉ thấy 0x6e..c5. Hai địa chỉ còn lại đã làm gì? Và các address(0), _dodoApproveAddress, _uniswapV3Factorty kia còn ẩn giấu bí mật gì nữa?
Hiện trường thứ hai
Hãy cùng xem địa chỉ tin tặc 3 (0xbf..87), sử dụng cùng thủ pháp để đánh cắp 73,49 WETH:
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
Và địa chỉ nguồn gas tấn công (0x97..de) đồng thời cung cấp phí giao dịch cho cả 0xc5..0d (địa chỉ tin tặc 2) và 0xbf..87 (địa chỉ tin tặc 3).
Nguồn 0,1 ETH cho địa chỉ gas tấn công (0x97..de) đến từ owlto.finance (cầu nối chéo chuỗi).
Sau khi nhận phí, 0xc5..0d (địa chỉ tin tặc 2) không thực hiện bất kỳ cuộc tấn công nào, nhưng thực tế nó đang đảm nhiệm một kế hoạch ẩn giấu – hãy tiếp tục theo dõi.
Thực tế, theo giao dịch cứu trợ sau sự việc của đội ngũ dự án, ban đầu trong hợp đồng bị ảnh hưởng (0x29..1F) không chỉ có 73,49 WETH; cho đến khi kết thúc vụ tấn công, vẫn còn tồn đọng 7.276,5 WETH và 7.758.267 USDB.
Giao dịch cứu trợ:
https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb
Ban đầu, tin tặc định đánh cắp toàn bộ tài sản này. Có thể thấy địa chỉ 0xc5..0d (địa chỉ tin tặc 2) vốn được dùng để đánh cắp USDB.
_dodoApproveAddress tại đây là 0x0000000000000000000000004300000000000000000000000000000000000003
Là địa chỉ của usdb
Địa chỉ 0xbf..87 (địa chỉ tin tặc 3) được dùng để đánh cắp weth:
_uniswapV3Factory tại đây là 0x0000000000000000000000004300000000000000000000000000000000000004
Là địa chỉ của weth
Còn 0x6e..c5 (địa chỉ tin tặc 1) chịu trách nhiệm đánh cắp address(0), tức là tài sản gốc ETH.
Tin tặc thiết lập field0 để có thể đánh cắp tài sản tương ứng thông qua logic sau:
Vấn đề
Tại sao tin tặc không đánh cắp toàn bộ tài sản?
Lý thuyết mà nói, hắn có thể lấy toàn bộ tài sản còn lại, bao gồm WETH và USDB.
0xbf..87 (địa chỉ tin tặc 3) chỉ lấy 73,49 WETH, trong khi hoàn toàn có thể lấy hết 7.350 WETH, và cũng có thể dùng 0xc5..0d (địa chỉ tin tặc 2) để lấy toàn bộ 7.758.267 USDB. Tại sao lại dừng lại sau khi lấy một ít WETH? Chúng tôi không biết, có lẽ cần nhà điều tra chuỗi nổi tiếng đào sâu nội bộ để tìm hiểu.
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
Tại sao tin tặc không chuyển 17.413 ETH về mainnet Ethereum?
Ai cũng biết rằng Blast mainnet có khả năng chặn các ETH này một cách tập trung, khiến chúng bị mắc kẹt mãi tại đây, từ đó tránh được tổn thất thực tế cho người dùng. Nhưng một khi ETH đã vào mainnet Ethereum thì không thể ngăn chặn được nữa.
Chúng tôi đánh giá cầu nối chính thức của Blast không giới hạn số lượng nhưng cần 14 ngày rút tiền, đủ thời gian để đội ngũ Blast chuẩn bị kế hoạch chặn.
Trong khi cầu nối bên thứ ba có thể rút gần như tức thì, giống như nguồn phí của tin tặc – nhanh chóng hoàn thành chéo chuỗi. Tại sao tin tặc không lập tức rút tiền?
Thực tế, tin tặc đã thực hiện rút tiền ngay lập tức (trong 2 phút đầu sau tấn công):
https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f
Và tiền đã về đến Ethereum mainnet chỉ sau 20 giây. Về lý thuyết, tin tặc có thể tiếp tục rút tiền liên tục, chuyển lượng lớn ETH trước khi có can thiệp thủ công từ cầu nối.
Lý do tại sao mỗi lần chỉ rút được 3 ETH là do giới hạn thanh khoản cầu nối, từ Blast sang ETH:
Một cầu nối khác hỗ trợ Blast thì giới hạn còn thấp hơn:
Sau giao dịch rút tiền này, tin tặc không thực hiện thêm hoạt động rút nào khác. Lý do thì chúng tôi không rõ, dường như "tin tặc đến từ một quốc gia nhất định" dường như chưa chuẩn bị đầy đủ cho việc rút tiền khỏi Blast.
Diễn biến sau vụ tấn công
Theo phản hồi từ người dùng cộng đồng Nearisbuilding, anh ấy đã tìm ra thêm thông tin danh tính của tin tặc và tìm cách buộc tin tặc hoàn trả tiền.
https://twitter.com/Nearisbuilding/status/1772812190673756548
Cuối cùng, dưới sự quan tâm và nỗ lực của cộng đồng mã hóa, có lẽ vì lo sợ lộ danh tính, "tin tặc đến từ một quốc gia nhất định" đã cung cấp khóa riêng tư của cả ba địa chỉ tấn công cho đội ngũ dự án, hoàn trả toàn bộ tiền. Đội ngũ dự án cũng đã thực hiện giao dịch cứu trợ, chuyển toàn bộ quỹ từ hợp đồng bị ảnh hưởng sang một hợp đồng đa chữ ký để quản lý.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
CertiK
