Blast được tạo ra bởi người sáng lập Blur Pacman (Tieshun Roquerre, The Mạng Ethereum Layer2 do Tieshun 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.
Chính thức của Blast sẽ cấp điểm thông thường cho người dùng cam kết ETH trên mạng chính của Blast:
Nhằm khuyến khích người dùng tham gia DeFi các dự án 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. network. Đã đến dự án DeFi mới được tạo.
Tính 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. 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 người dùng hay không, thậm chí hàng trăm triệu đô la.
Chưa đầy một tháng sau khi mạng chính Blast ra mắt, một cuộc tấn công vào SSS đã xảy ra vào ngày 21 tháng 3 năm 2024 Cuộc tấn công bằng Token (Super Sushi Samurai), xảy ra lỗi logic chuyển giao trong hợp đồng Token, điều này cho phép kẻ tấn công đột ngột tăng số dư SSS Token của tài khoản được chỉ định.Cuối cùng, dự án đã mất nhiều hơn 1310 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ị kẻ tấn công quét sạch. 17413,96 ETH đã bị lấy đi, tổng cộng 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 ở địa chỉ khác đánh cắp.
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 dự án, có thể rơi vào tay hacker bất cứ lúc nào Các tin tặc đã truy cập vào tất cả số tiền trong toàn bộ dự án, khiến tổng cộng khoảng 97 triệu USD gặp rủi ro.
Ngay sau khi vụ việc xảy ra, thám tử on-chain nổi tiếng ZachXBT 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 đến 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.
[UTC+0] 21:37, ngày 26 tháng 3 năm 2024 (5 phút sau cuộc tấn công ), Munchables chính thức đăng trên X (Twitter) thông báo rằng nó đang bị tấn công.
Theo điều tra của thám tử Zach We trên chuỗi, chúng tôi đã thuê kẻ tấn công Munchables để 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, và chúng tôi đã sa thải anh ta trong vòng một tháng. Anh ta cũng cố gắng để có được chúng tôi thuê một trong những người bạn của anh ấy, có lẽ anh ấy cũng là một 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 triển khai Chúng ta hãy cùng tìm hiểu sâu hơn về chi tiết cuộc tấn công của Hacker "một quốc gia nào đó" này.
Cảnh đầu tiên
< /ul>[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ư hỏng (0x29..1F ) là mộ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 kiểm tra quyền và chuyển tất cả ETH trong hợp đồng đến địa chỉ 1. của kẻ tấn công (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).
Có phải bên dự án quên khóa kho tiền không?
Việc mở khóatrong hợp đồng bị hỏng (0x29..1F) có hai kiểm tra liên quan, chúng ta hãy xem xét từng cái một.
Trước hết, 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 để xem thông báo hiện tại .sender, cũng 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]2024 Lúc 08 :39 vào ngày 24 tháng 3 năm 2019 (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.
Bạn có thể xem địa chỉ hợp đồng logic ban đầu ở đâ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 đang cập nhật hợp đồng thực hiện logic của hợp đồng đại lý , sẽ là 0x9e. .CD trở thành 0xe7..f1 độc hại, hoàn tất việc bỏ qua quyền xác minh.
Có thực sự như 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ệ để 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 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 triển khai như sau:
Phần chức năng khởi tạo của 0x9e..CD được triển khai như sau:
Như bạn có thể thấy, kẻ tấn công Trong hợp đồng logic ban đầu (0x9e..CD), địa chỉ của kẻ tấn công (0x6e..c5) được đặt thành đăng ký và hai địa chỉ kẻ tấn công khác 0xc5..0d và 0xbf..87 cũng được đặt đã đăng ký. Và trường0 của họ được đặt thành thời gian khối trong quá trình 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 ta đoán, hợp đồng logic thực sự với backdoor đã tồn tại ngay từ đầu và được cập nhật sau đó. Đó là điều 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ự việ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 sau này vẫn có thể hoàn thành cuộc tấn công?
Điều này là do cuộc gọi đại biểu nên bản cập nhật lưu trữ trạng thái thực tế nằm trong hợp đồng (0x16..A0), điều này cũng dẫn đến hợp đồng logic ngay cả sau After được cập nhật lên hợp đồng logic 0xe7..f1 không có cửa sau, vị trí đã thay đổi trong hợp đồng (0x16..A0) sẽ vẫn không được khôi phục.
Hãy cùng xác minh:
Như bạn có thể thấy, vị trí 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 xác minh phương thức isRegistered:
Kẻ tấn công sau đó đã thay thế hợp đồng cửa sau bằng hợp đồng thông thường để đánh lừa người khác. cửa sau đã là Plant.
Ngoài ra, quá trình mở khóa còn bao gồm xác minh thứ hai:
Đối với việc kiểm tra thời gian khóa, phần này nhằm đảm bảo rằng tài sản bị khóa sẽ không được 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 (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),
< p style= "text-align: left;">https://blastscan.io/tx/0x3d08f2fcfe51cf5758f4e9ba057c51543b0ff386ba53e0b4f267850871b88170Chú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
< img src="https://img.jinse.cn/7200163_image3.png">
đã đượ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 đây,
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:
Như bạn có thể thấy, rõ ràng là cùng một kỹ thuật được sử dụng lại. Anh ta đã giả mạo số ETH anh ta nắm giữ và thời gian mở khóa, sau đó thay thế nó bằng hợp đồng thông thường để đánh lừa người khác. Khi nhóm dự án và các nhà nghiên cứu bảo mật gỡ lỗi, tất cả các hợp đồng logic mà họ thấy đều bình thường, và bởi vì tất cả các hợp đồng Vì hợp đồng không phải là nguồn mở nên việc nhìn ra 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 này liên quan đến 17413 ETH 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 đã đưa 3 địa chỉ vào 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)
Chỉ một trong các giao dịch tấn công mà chúng tôi tìm thấy ở trên Nhìn thấy 0x6e.. c5, 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
< /ul>Trước tiên chúng ta hãy xem địa chỉ của kẻ tấn công 3 (0xbf..87), đã đánh cắp 73,49 WETH thông qua cùng một phương pháp:
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 tôi tiếp tục đọc.
Trên thực tế, theo giao dịch giải cứu chính thức, hóa ra có hơn 73,49 weth trên địa chỉ hợp đồng bị hư hỏng (0x29..1F). Cho đến khi cuộc tấn công kết thúc, sẽ không có nhiều hơn 73,49 weth. Vẫn còn 7276,5 WETH & 7758267 USDB.
Thỏa thuận giải cứu:
https://blastscan.io/tx/0x1969f10af9d0d8f80ee3e3c88d358a6f668a7bf4da6e598e5be7a3407dc6d5bb p>
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à 0x000000000000000000000000043000000000000000000000000000000000000003
< p style="text-align: left;">là địa chỉ của usdb0xbf..87 (địa chỉ kẻ tấn công 3) Địa chỉ này được sử dụng để đánh cắp weth:
_uniswapV3Factory ở đây là 0x000000000000000000000000004300000000000000000000000000000000000 00004< p style="text-align:center">
Dành cho weth's địa chỉ
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 trường0, kẻ tấn công có thể đánh cắp tài sản tương ứng thông qua logic sau:
< img src="https://img.jinse.cn/7200174_image3.png">
Câu hỏi
- < h2 style="text-align: left;">Tại sao kẻ tấn công không lấy hết tài sản?
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 tế có thể lấy trộm toàn bộ 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 sau khi chỉ lấy một ít WETH thì chúng tôi chưa biết. Nó có thể cần một thám tử nổi tiếng của chuỗi để đi sâu vào bên trong. .
https://blastscan.io/tx/0xfc7bfbc38662b659bf6af032bf20ef224de0ef20a4fd8418db87f78f9370f233
Tại sao Không phải kẻ tấn công đã chuyển 17413ETH sang mạng chính Ethereum sao?
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à hãy để nó tồn tại vĩnh viễn Ở đây, sẽ không có thiệt hại đáng kể nào cho người dùng, nhưng 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 hiện tại của Blast. 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 , như vậy là đủ để các quan chức 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ó gần như theo thời gian thực, giống như nguồn phí của kẻ tấn công và chuỗi chéo có thể được hoàn thành nhanh chóng Tại sao cuộc tấn công Người đó không xuyên chuỗi ngay lập tức?
Trên thực tế, kẻ tấn công đã thực hiện chuỗi chéo ngay lần đầu tiên (trong vòng 2 phút sau cuộc tấn công):
https://blastscan.io/tx/0x10cf2f2b884549979a3a1dd912287256229458ef40d56df61738d6ea7d9d198f
Và phải mất 20 giây để tiền đến mạng chính Ethereum. Về lý thuyết, những kẻ tấn công có thể tiếp tục sang chuỗi chéo, một lượng lớn ETH có thể được chuyển qua các chuỗi trước khi có sự can thiệp thủ công của cầu nối chuỗi chéo.
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 chuỗi chéo khác hỗ trợ Blast thậm chí còn hỗ trợ ít hơn:< /p >
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. Chúng tôi chưa rõ lý do. 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 .
Diễn biến các sự kiện sau cuộc tấn công
Theo cộng đồng Người dùng Nearisbuilding Dựa trên phản hồi, anh ta đã 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 từ một quốc gia nào đó" đã cung cấp cho ba kẻ tấn công trên cho dự án, có lẽ vì họ sợ bị lộ danh tính. Khóa riêng của địa chỉ và trả lại toàn bộ số tiền. Nhóm dự án cũng đã tiến hành một giao dịch giải cứu và chuyển toàn bộ số tiền của hợp đồng bị hư hỏng sang hợp đồng nhiều chữ ký vì sự bảo vệ an toàn.