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à dự án chất lượng cao đã 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 để giới thiệu và khuyến khích người dùng cam kết ETH cho DeFi lần thứ hai để 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 đã thế chấp 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 từ một địa chỉ khác.

Tại thời điểm này, vẫn còn 7.276 WETH, 7.758.267 USDB và 4 ETH được lưu trữ trong địa chỉ hợp đồng của bên dự án, có thể 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ỗ

[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.

[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 (0x29..1F) là hợp đồng proxy lưu trữ số tiền mà người dùng đã cam kết. 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 cầm cố, vượt qua tất cả các bước kiểm tra quyền và chuyển tiền trong hợp đồng. Tất cả ETH đến địa chỉ kẻ tấn công 1 (0x6E..c5).

Có vẻ như kẻ tấn công đã gọi một chức năng mở khóa tương tự như hành vi rút tiền và lấy đi phần lớn ETH trên hợp đồng bị hỏng (0x29..1F).

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 (0x29..1F). 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 (0x16..A0) đã được gọi để kiểm tra xem msg.sender hiện tại, tức là địa chỉ hacker 1 (0x6E..c5) đã được đăng ký chưa :

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 (0x16..A0) và hợp đồng logic mới nhất tương ứng của nó (0xe7..f1)

[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 (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ể được xem ở đây, đó là 0x9e..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 0x9e..CD thành 0xe7..f1 độ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ở), chúng tôi nhận thấy rằng có một số khác biệt rõ ràng giữa hợp đồng 0x9e..CD ban đầu và hợp đồng 0xe7..f1 được cập nhật:

Phần chức năng khởi tạo của 0xe7..f1 được thực hiện như sau:

Phần chức năng khởi tạo của 0x9e..CD được triển khai như sau:

Có thể thấy, kẻ tấn công đặt địa chỉ kẻ tấn công (0x6e..c5) làm đăng ký trong hợp đồng logic ban đầu (0x9e..CD), ngoài ra còn có hai địa chỉ kẻ tấn công khác là 0xc5..0d và 0xbf.. 87 cũng có đã được đăng ký và trường0 của họ được đặt thành thời gian khối khi khởi tạo. Việc sử dụng trường0 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 một hợp đồng không có cửa sau. Tại sao? Kẻ tấn công có thể hoàn thành được không? cuộc tấn công sau này?

Điều này là do cuộc gọi đại biểu, do đó, bản cập nhật lưu trữ trạng thái thực tế nằm trong hợp đồng (0x16..A0), 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 0xe7..f1 mà không có cửa sau, hợp đồng (0x16. .A0) sẽ vẫn không được khôi phục.

Hãy xác minh nó:

Có thể thấy, slot tương ứng trong hợp đồng (0x16....A0) có giá trị bằng số.

Đ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ần thiết (trường 3).

Phần xác minh này liên quan đến hợp đồng bị hỏng (0x29..1F) và hợp đồng logic tương ứng 0xf5..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 (0x29..1F) là 0x91..11 và chỉ bốn phút sau, tại

https://blastscan.io/tx/0xea1d9c0d8de4280b538b6fe6dbc3636602075184651dfeb837cb03f8a19ffc4f

Đã được nâng cấp lên 0xf5..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.

Triển khai một phần chức năng khởi tạo của 0xf5..cd:

Đã được nâng cấp lên 0xf5..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.

Triển khai một phần chức năng khởi tạo của 0xf5..cd:

Triển khai một phần chức năng khởi tạo của 0x91..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. tất cả các hợp đồng logic được nhìn thấy đều 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ó khăn hơn.

Cho đến nay, chúng tôi đã hiểu giao dịch liên quan đến 17413 ETH này và cách kẻ tấn công thực hiện nó. Nhưng đằng sau vụ việc này chỉ có bấy nhiêu thông tin thôi sao?

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:

0x6e..c5 (địa chỉ kẻ tấn công 1)

0xc5..0d (địa chỉ kẻ tấn công 2)

0xbf..87 (địa chỉ kẻ tấn công 3)

Tuy nhiên, chúng tôi chỉ thấy 0x6e..c5 trong giao dịch tấn công 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?

Trước tiên, chúng ta hãy xem địa chỉ kẻ tấn công 3 (0xbf..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 (0x97..de), đồng thời cung cấp phí xử lý cho cả 0xc5..0d (địa chỉ kẻ tấn công 2) và 0xbf..87 (địa chỉ kẻ tấn công 3).

Nguồn 0,1 ETH tấn công địa chỉ nguồn khí (0x97..de) đến từ owlto.finance (cầu xuyên chuỗi).

0xc5..0d (đị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 chính thức sau giải cứu, địa chỉ ban đầu của hợp đồng bị hư hỏng (0x29..1F) 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.

Trên thực tế, theo giao dịch chính thức sau giải cứu, địa chỉ ban đầu của hợp đồng bị hư hỏng (0x29..1F) 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

Ban đầu kẻ tấn công dự định đánh cắp những tài sản này, bạn có thể thấy rằng địa chỉ 0xc5..0d (đị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

0xbf..87 (địa chỉ kẻ tấn công 3) Địa chỉ này được sử dụng để đánh cắp weth:

0xbf..87 (địa chỉ kẻ tấn công 3) Địa chỉ này được sử dụng để đánh cắp weth:

_uniswapV3Factory ở đây là 0x000000000000000000000000043000000000000000000000000000000000000000004

là địa chỉ của weth

Và 0x6e..c5 (đị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 field0, 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

Về mặt lý thuyết, anh ta có thể đánh cắp tất cả tài sản, cụ thể là WETH và USDB còn lại.

0xbf..87 (địa chỉ kẻ tấn công 3) chỉ lấy trộm 73,49 WETH. 0xbf..87 (địa chỉ kẻ tấn công 3) thực sự có thể lấy đi tất cả 7350 WETH. Bạn cũng có thể sử dụng 0xc5..0d (địa chỉ kẻ tấn công 2)) đã lấy đi tất cả 7758267 USDB , tại sao nó lại dừng lại sau khi chỉ lấy một ít WETH thì chúng tôi không biết, có thể phải cần đến một thám tử nổi tiếng của dây chuyền để tiến hành một cuộc điều tra nội bộ chuyên sâu.

0xbf..87 (địa chỉ kẻ tấn công 3) chỉ lấy trộm 73,49 WETH. 0xbf..87 (địa chỉ kẻ tấn công 3) thực sự có thể lấy đi tất cả 7350 WETH. Bạn cũng có thể sử dụng 0xc5..0d (địa chỉ kẻ tấn công 2)) đã lấy đi tất cả 7758267 USDB , tại sao nó lại dừng lại sau khi chỉ lấy một ít WETH thì chúng tôi không biết, có thể phải cần đến một thám tử nổi tiếng của dây chuyền để tiến hành một cuộc điều tra nội bộ chuyên sâu.

https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233

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ầu nối chuỗi 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 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 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:

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 nhóm dự án và trả lại toàn bộ. Nhóm 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.