lý lịch
Blast là mạng Ethereum Lớp 2 được ra mắt bởi Pacman (Tieshun Roquerre, hay còn gọi là Tieshun), người sáng lập Blur. Nó đã ra mắt mạng chính vào ngày 29 tháng 2. Hiện tại, khoảng 19.500 ETH và 640.000 stETH được cam kết trên mạng chính Blast.
Dự án bị tấn công, Munchables, là một dự án cao cấp đã giành chiến thắng trong cuộc thi Bigbang do Blast tổ chức.
Các quan chức của Blast sẽ cấp điểm thông thường cho những người dùng cam kết ETH trên mạng chính 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, các quan chức của Blast sẽ chọn các dự án chất lượng cao để đề xuất và khuyến khích người dùng cam kết ETH lần thứ hai vào DeFi để nhận được điểm tăng và điểm vàng nhanh hơn, do đó có khá nhiều một số Người dùng đã cam kết ETH trên mạng chính Blast cho dự án DeFi mới được tạo.
Độ trưởng thành và tính bảo mật của các dự án DeFi này vẫn chưa được kiểm tra và liệu các hợp đồng này có đủ cân nhắc về bảo mật để bảo vệ hàng chục triệu hay thậm chí hàng trăm triệu đô la của người dùng hay không.
Tổng quan về sự kiện
Chưa đầy một tháng sau khi mạng chính Blast lên mạng, một cuộc tấn công vào SSS Token (Super Sushi Samurai) đã xảy ra vào ngày 21 tháng 3 năm 2024. Đã xảy ra lỗi logic chuyển trong hợp đồng Token, cho phép kẻ tấn công tăng SSS Token của tài khoản được chỉ định ngoài số dư không khí, dự án cuối cùng đã mất hơn 1.310 ETH (khoảng 4,6 triệu USD).
Chưa đầy một tuần sau cuộc tấn công SSS Token, một cuộc tấn công lớn hơn khác đã xảy ra vào Blast, dự án Munchables đã bị những kẻ tấn công quét sạch 17413,96 ETH, tổng trị giá khoảng 62,5 triệu đô la Mỹ.
Nửa giờ sau khi giao dịch tấn công xảy ra, 73,49 WETH trong hợp đồng dự án cũng bị hacker đánh cắp bởi một địa chỉ khác.
Tại thời điểm này, vẫn còn 7276 WETH, 7758267 USDB và 4 ETH được lưu trữ trong địa chỉ hợp đồng của bên dự án, số tiền này sẽ rơi vào tay hacker bất cứ lúc nào. Hacker có quyền lấy đi toàn bộ số tiền của toàn bộ dự án với tổng trị giá khoảng 97 triệu đô la Mỹ.
Ngay sau vụ việc, zachXBT, một thám tử on-chain nổi tiếng của X (Twitter), đã chỉ ra rằng nguyên nhân cốt lõi của cuộc tấn công này là do việc thuê tin tặc từ một quốc gia nào đó.
Chúng ta hãy xem xét kỹ hơn cách một “hacker từ một quốc gia nào đó” thực hiện một cuộc tấn công trị giá gần 100 triệu USD.
Phục hồi tại chỗ
Nạn nhân lên tiếng
[UTC+ 0] Vào lúc 21:37 ngày 26/03/2024 (5 phút sau vụ tấn công), Munchables đã chính thức đăng tải trên X (Twitter) thông báo rằng mình đang bị tấn công.
Theo điều tra của thám tử Zach trên chuỗi, kẻ tấn công đến để thực hiện một số công việc phát triển trò chơi. Anh ta rất thô bạo và thực sự trông giống một hacker Trung Quốc. Chúng tôi đã sa thải anh ta trong vòng một tháng. Anh ta cũng cố gắng thuyết phục chúng tôi thuê một trong những người của anh ta. bạn bè, người có lẽ cũng là một hacker. hacker.
Vì cuộc tấn công này gây ra tổn thất lớn cho người dùng trong cộng đồng nên chúng tôi đã ngay lập tức tiến hành một cuộc điều tra trực tuyến. Hãy cùng xem xét kỹ lưỡng chi tiết cuộc tấn công của “hacker đến từ một quốc gia nào đó” này.
Cảnh đầu tiên
[UTC+ 0] Vào lúc 21:32 ngày 26 tháng 3 năm 2024, một cuộc tấn công liên quan đến 17413,96 ETH đã xảy ra.
Chúng ta có thể thấy giao dịch tấn công này thông qua Blastscan: https://blastscan.io/tx/0x9a7e4d16ed15b0367b8ad677eaf1db6a2a54663610696d69e1b4aa1a08f55c95
Hợp đồng bị hỏng (0x 29..1 F) là hợp đồng proxy lưu trữ số tiền đã cam kết của người dùng. Chúng ta có thể thấy rằng kẻ tấn công đã gọi chức năng mở khóa của hợp đồng cam kết, vượt qua tất cả các bước kiểm tra quyền và chuyển nó đi. Tất cả ETH trong hợp đồng đi đến địa chỉ kẻ tấn công 1 (0x 6 E..c 5).
Có vẻ như kẻ tấn công đã gọi một chức năng mở khóa có hành vi giống như rút tiền và lấy đi phần lớn ETH trên hợp đồng bị xâm phạm (0x 29..1 F).
Bên dự án có quên khóa kho tiền không?
Có hai kiểm tra liên quan để mở khóa trong hợp đồng bị hỏng (0x 29..1 F). Hãy xem xét từng cái một.
Đầu tiên, chúng tôi nhận thấy rằng trong quá trình xác minh quyền, phương thức isRegistered của hợp đồng (0x 16..A 0) đã được gọi để kiểm tra xem msg.sender hiện tại, tức là địa chỉ của hacker 1 (0x 6 E..c 5) Đã đăng ký:
Câu trả lời là: đã vượt qua quá trình xác minh.
Điều này liên quan đến hợp đồng (0x 16..A 0) và hợp đồng logic mới nhất tương ứng của nó (0x e 7..f 1)
[UTC+ 0 ] Vào lúc 08:39 ngày 24 tháng 3 năm 2024 (2 ngày trước cuộc tấn công), hợp đồng logic tương ứng với hợp đồng (0x 16..A 0) đã đượ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 0x e 7..f 1 .
Địa chỉ hợp đồng logic ban đầu có thể được nhìn thấy ở đây, đó là 0x 9 e..CD.
https://blastscan.io/tx/0x7ad050d84c89833aa1398fb8e5d179ddfae6d48e8ce964f6d5b71484cc06d003
Tại thời điểm này, chúng tôi nghi ngờ rằng hacker đã cập nhật hợp đồng triển khai logic của hợp đồng proxy và thay đổi 0x 9 e..CD thành 0x e 7..f 1 độc hại, hoàn thành việc bỏ qua quyền xác minh.
Có thực sự vậy không?
Trong Web3.0, bạn không bao giờ cần phải đoán hay nghe người khác nói mà chỉ cần làm chủ công nghệ là có thể tự mình có được câu trả lời.
Bằng cách so sánh hai hợp đồng (không phải hợp đồng nguồn mở), có một số khác biệt rõ ràng giữa hợp đồng 0x 9 e..CD ban đầu và hợp đồng 0x e 7..f 1 được cập nhật:
Phần hàm khởi tạo của 0x e 7..f 1 được triển khai như sau:
Phần chức năng khởi tạo của 0x 9 e..CD được thực hiện như sau:
Có thể thấy kẻ tấn công đặt địa chỉ kẻ tấn công (0x 6 e..c 5) làm đăng ký trong hợp đồng logic ban đầu (0x 9 e..CD), và ngoài ra còn có hai địa chỉ kẻ tấn công khác 0x c 5 ..0 d, 0x bf..87 cũng được đăng ký và trường 0 của chúng được đặt thành thời gian khối trong quá trình khởi tạo. Việc sử dụng trường 0 sẽ được giải thích sau.
Trên thực tế, trái ngược với những gì chúng tôi đoán, hợp đồng logic thực sự với cửa sau đã tồn tại ngay từ đầu và các bản cập nhật tiếp theo là bình thường!
Đợi đã, bản cập nhật này xuất hiện lúc 08:39 ngày 24 tháng 3 năm 2024 [UTC+ 0] (2 ngày trước cuộc tấn công), tức là trước sự cố này, hợp đồng logic đã trở thành hợp đồng không có cửa sau. Tại sao? Kẻ tấn công vẫn có thể hoàn thành cuộc tấn công?
Điều này là do cuộc gọi ủy quyền nên bản cập nhật lưu trữ trạng thái thực tế nằm trong hợp đồng (0x 16..A 0), dẫn đến thực tế là ngay cả khi hợp đồng logic sau đó được cập nhật thành hợp đồng logic mà không có cửa sau 0x e 7.. f 1 , vị trí đã thay đổi trong hợp đồng (0x 16..A 0) sẽ vẫn không được khôi phục.
Hãy xác minh nó:
Như bạn có thể thấy, ô tương ứng trong hợp đồng (0x 16....A 0) có một giá trị.
Điều này cho phép kẻ tấn công vượt qua kiểm tra phương thức isRegistered:
Kẻ tấn công sau đó thay đổi hợp đồng cửa sau thành hợp đồng thông thường để che giấu sự thật rằng cửa sau đã được cài đặt.
Ngoài ra, quá trình mở khóa cũng bao gồm bước xác minh thứ hai:
Về việc kiểm tra thời gian khóa, phần này nhằm đảm bảo tài sản bị khóa sẽ không bị chuyển nhượng trước khi hết hạn.
Kẻ tấn công cần đảm bảo rằng thời gian chặn khi mở khóa được gọi lớn hơn thời gian hết hạn khóa được yêu cầu (trường 3).
Phần xác minh này liên quan đến hợp đồng bị hỏng (0x 29..1 F) và hợp đồng logic tương ứng 0x f 5..cd.
Trong giao dịch lúc 11:54 ngày 21 tháng 3 năm 2024 [UTC+ 0] (5 ngày trước cuộc tấn công),
https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170
Chúng ta có thể thấy rằng hợp đồng logic ban đầu của hợp đồng bị hỏng (0x 29..1 F) là 0x 91..11 và chỉ bốn phút sau, tại
https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f
Đã nâng cấp lên 0x f 5..cd.
Chúng tôi cũng so sánh hai hợp đồng và có thể thấy rằng kẻ tấn công cũng đã thực hiện các thủ thuật trong chức năng khởi tạo như trước.
Thực hiện một phần chức năng khởi tạo của 0x f 5..cd:
Thực hiện một phần chức năng khởi tạo của 0x 91..11:
Có thể thấy, rõ ràng phương pháp tương tự đã được sử dụng lại để giả mạo số lượng ETH và thời gian mở khóa, sau đó thay thế bằng hợp đồng thông thường để đánh lừa người khác. các hợp đồng logic được thấy là bình thường, và vì các hợp đồng đều là hợp đồng không phải nguồn mở nên việc nhìn rõ cốt lõi của vấn đề càng khó hơn.
Cho đến nay, chúng tôi đã hiểu giao dịch liên quan đến 17413 ETH này và kẻ tấn công đã thực hiện nó như thế nào, nhưng có phải chỉ có bấy nhiêu thông tin đằng sau vụ việc này không?
Trong phân tích ở trên, chúng tôi thực sự thấy rằng hacker đã xây dựng 3 địa chỉ trong hợp đồng:
0x 6 e..c 5 (địa chỉ kẻ tấn công 1)
0x c 5..0 d (địa chỉ kẻ tấn công 2)
0x bf..87 (địa chỉ kẻ tấn công 3)
Tuy nhiên, chúng tôi chỉ thấy 0x 6 e..c 5 trong giao dịch tấn công mà chúng tôi tìm thấy ở trên. Hai địa chỉ còn lại đã làm gì? Và bí mật nào được ẩn giấu trong địa chỉ(0), _dodoApproveAddress và _uniswapV3Factorty?
Cảnh thứ hai
Trước tiên, hãy xem địa chỉ kẻ tấn công 3 (0x bf..87), đã đánh cắp 73,49 WETH thông qua cùng một phương thức:
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
Và tấn công địa chỉ nguồn của gas (0x 97..de), đồng thời cung cấp phí xử lý cho cả 0x c 5..0 d (địa chỉ kẻ tấn công 2) và 0x bf..87 (địa chỉ kẻ tấn công 3).
Nguồn 0,1 ETH tấn công địa chỉ nguồn khí (0x 97..de) đến từ owlto.finance (cầu xuyên chuỗi).
0x c 5..0 d (địa chỉ kẻ tấn công 2) không thực hiện bất kỳ cuộc tấn công nào sau khi nhận được phí xử lý, nhưng nó thực sự có một kế hoạch ẩn giấu. Chúng ta hãy tiếp tục xem xét nó.
Trên thực tế, theo giao dịch giải cứu chính thức, địa chỉ ban đầu của hợp đồng bị hư hỏng (0x 29..1 F) không chỉ là 73,49 WETH mà cho đến khi cuộc tấn công kết thúc vẫn còn 7276,5 WETH 7758267 USDB.
Thỏa thuận giải cứu:
https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb
Kẻ tấn công ban đầu dự định đánh cắp những tài sản này, bạn có thể thấy rằng địa chỉ 0x c 5..0 d (địa chỉ kẻ tấn công 2) ban đầu được sử dụng để đánh cắp USDB.
_dodoApproveAddress ở đây là 0x000000000000000000000000004300000000000000000000000000000000000000003
là địa chỉ của usdb
0x bf..87 (địa chỉ kẻ tấn công 3) Địa chỉ này được sử dụng để đánh cắp weth:
Nhà máy _uniswap V3 ở đây là 0x00000000000000000000000000430000000000000000000000000000000000000000004
là địa chỉ của weth
Và 0x 6 e..c 5 (địa chỉ kẻ tấn công 1) chịu trách nhiệm đánh cắp địa chỉ (0), là tài sản gốc ETH.
Bằng cách đặt trường 0, kẻ tấn công có thể đánh cắp tài sản tương ứng thông qua logic sau:
câu hỏi
Tại sao kẻ tấn công không đánh cắp tất cả tài sản?
Về lý thuyết, anh ta có thể đánh cắp tất cả tài sản, đó là WETH và USDB còn lại.
0x bf..87 (địa chỉ kẻ tấn công 3) chỉ lấy trộm 73,49 WETH. 0x bf..87 (địa chỉ kẻ tấn công 3) thực sự có thể lấy đi tất cả 7350 WETH hoặc bạn có thể sử dụng 0x c 5.0 d (địa chỉ kẻ tấn công 2) đã lấy lấy đi tất cả 7758267 USDB. Tại sao nó dừng lại sau khi chỉ lấy một ít WETH? Chúng tôi không biết. Nó có thể yêu cầu một thám tử chuỗi nổi tiếng tiến hành một cuộc điều tra nội bộ chuyên sâu.
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
Tại sao kẻ tấn công không chuyển 17413 ETH sang mạng chính Ethereum?
Như chúng ta đã biết, mạng chính Blast có thể chặn các ETH này thông qua một phương pháp tập trung và để nó ở đây vĩnh viễn mà không gây tổn thất đáng kể cho người dùng. Tuy nhiên, một khi những ETH này vào mạng chính Ethereum thì không có cách nào để chặn Nó.
Chúng tôi đã đánh giá các cầu nối chuỗi chéo Blast hiện tại, không có giới hạn về số lượng cầu nối chuỗi chéo chính thức nhưng chúng cần 14 ngày để thoát ra, đủ để các quan chức của Blast chuẩn bị kế hoạch đánh chặn.
Cầu nối chuỗi chéo của bên thứ ba có thể được ghi có trong thời gian gần như thời gian thực, giống như nguồn phí của kẻ tấn công và có thể nhanh chóng hoàn thành chuỗi chéo.
Trên thực tế, kẻ tấn công đã thực hiện chuỗi chéo ngay từ giây phút đầu tiên (trong vòng 2 phút sau cuộc tấn công):
https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f
Hơn nữa, phải mất 20 giây để tiền đến mạng chính Ethereum. Về lý thuyết, kẻ tấn công có thể tiếp tục xuyên chuỗi và chuyển một lượng lớn ETH qua các chuỗi trước khi cầu nối chuỗi chéo có thể can thiệp thủ công.
Về lý do tại sao mỗi lần chỉ có thể có 3 ETH, lý do là do giới hạn thanh khoản của cầu nối chuỗi chéo, từ Blast đến ETH:
Một cây cầu xuyên chuỗi khác hỗ trợ Blast thậm chí còn ít hơn:
Sau giao dịch xuyên chuỗi này, kẻ tấn công đã không tiếp tục các hoạt động xuyên chuỗi khác. Lý do thì chúng tôi chưa rõ, có vẻ như hacker từ một quốc gia nào đó đã không chuẩn bị đầy đủ cho việc rút tiền từ Blast.
Điều gì đã xảy ra sau cuộc tấn công
Dựa trên phản hồi từ người dùng cộng đồng Nearisbuilding, anh đã tìm thấy thêm thông tin nhận dạng của kẻ tấn công và tìm ra cách để nhắc kẻ tấn công trả lại tiền.
https://twitter.com/Nearisbuilding/status/1772812190673756548
Cuối cùng, với sự quan tâm và nỗ lực của cộng đồng mã hóa, “hacker đến từ một quốc gia nào đó” có lẽ vì sợ bị lộ danh tính nên đã cung cấp khóa riêng của ba địa chỉ kẻ tấn công trên cho bên dự án và trả lại toàn bộ. Bên dự án cũng đã thực hiện giao dịch giải cứu, chuyển toàn bộ số tiền từ hợp đồng bị thiệt hại sang hợp đồng nhiều chữ ký để bảo quản an toàn.
