Hacker quay lại “nguyên tắc đầu tiên”, khủng hoảng Curve không phải cuộc tấn công thông thường
Tác giả gốc:Jaleel，BlockBeats
Tác giả gốc:Jack，BlockBeats
Biên tập viên gốc:
Ngành công nghiệp DeFi đã rơi vào tình trạng hỗn loạn sau một sự cố khai thác lỗ hổng. Curve Finance, một gã khổng lồ trong ngành DeFi, đã trở thành mục tiêu của một cuộc “tấn công” nghiêm trọng và nhiều nhóm stablecoin như alETH/msETH/pETH đang gặp rủi ro. Theo số liệu thống kê chưa đầy đủ, sự kiện khai thác lỗ hổng đã gây ra tổng thiệt hại 52 triệu đô la Mỹ cho các nhóm Alchemix, JPEG'd, MetronomeDAO, deBridge, Ellipsis và CRV/ETH, đồng thời niềm tin của toàn bộ thị trường đã bị lung lay nghiêm trọng.
Các khóa thử lại của các phiên bản Vyper 0.2.15, 0.2.16 và 0.3.0 không hợp lệ và giao diện cài đặt tài liệu chính thức của Vyper khuyến nghị phiên bản sai. Các bên dự án khác sử dụng trình biên dịch Vyper cũng đã gấp rút tiến hành tự kiểm tra, cố gắng đảm bảo rằng họ sẽ không trở thành nạn nhân tiếp theo. Khi nguồn gốc của sự cố khai thác lỗ hổng dần được tiết lộ, thị trường dần nhận ra rằng cuộc khủng hoảng này không chỉ có nghĩa là một sự cố khai thác hacker thông thường mà còn bộc lộ rủi ro rất lớn tiềm ẩn của toàn bộ nền tảng cơ bản đối với toàn bộ ngành DeFi.
So với trước đây, số vụ hack giai đoạn trước ngày càng ít, điều này không thể tách rời khỏi sự khởi sắc của thị trường. Trong mùa hè DeFi và mùa hè NFT, các thỏa thuận tỷ đô mới được đưa ra mỗi tuần, so với thị trường ngày nay đang rất thu hẹp. Đồng thời, cơ hội thị trường để tin tặc tìm cách khai thác hoặc tạo ra các cuộc tấn công quy mô lớn đang dần bị thu hẹp, đồng nghĩa với việc tin tặc cần những điểm vào mới hơn, chưa được khai thác để khám phá.@BoxMrChen) và nhà nghiên cứu BTX Derek (@begas_btxcap）。
danh hiệu cấp một
Sự kiện Curve diễn ra như thế nào?@StaniKulechovStani, người sáng lập Aave và Lens (
) bày tỏ quan điểm của mình về vụ việc trên mạng xã hội: Đây là một bước thụt lùi đáng tiếc đối với Curve và DeFi. Mặc dù DeFi là một không gian mở, nơi có thể đóng góp nhưng rất khó để có thể chính xác tuyệt đối, và số tiền đặt cược rất cao. Trong Curve's trong trường hợp đó, họ đã hiểu đúng ở cấp độ giao thức.”
Khai thác mà Curve gặp phải là một trong những hình thức tấn công lâu đời nhất và có lẽ là phổ biến nhất đối với các hợp đồng thông minh Ethereum, cuộc tấn công reentrancy. Các cuộc tấn công Reentrancy cho phép kẻ tấn công liên tục gọi một chức năng của hợp đồng thông minh mà không cần đợi lệnh gọi trước đó đến chức năng đó hoàn tất. Bằng cách này, họ có thể tiếp tục lợi dụng kẽ hở để rút tiền cho đến khi hợp đồng của nạn nhân hết tiền.
Khóa Reentrant và nguyên tắc CEI
Hãy đưa ra một ví dụ đơn giản minh họa cho các cuộc tấn công re-entry: một ngân hàng có tổng cộng 100.000 tiền mặt. Nhưng ngân hàng này có một lỗ hổng lớn, mỗi khi có người rút tiền, nhân viên ngân hàng không cập nhật số dư tài khoản ngay mà đợi đến cuối ngày mới kiểm tra, cập nhật. Lúc này, có người phát hiện ra sơ hở này, anh ta mở tài khoản trong ngân hàng, đầu tiên gửi 1.000 tệ, sau đó rút 1.000 tệ, sau đó 5 phút rút ra 1.000 tệ. Do ngân hàng không cập nhật số dư theo thời gian thực nên hệ thống sẽ cho rằng tài khoản của anh ta vẫn còn 1.000 tệ trước khi kiểm tra và cập nhật. Qua nhiều lần thao tác, người dùng cuối cùng đã rút hết số tiền mặt 100.000 USD trong ngân hàng. Phải đến cuối ngày, ngân hàng mới phát hiện sơ hở đã bị khai thác.
Sự phức tạp của cuộc tấn công reentrancy nằm ở chỗ nó lợi dụng sự kêu gọi lẫn nhau giữa các hợp đồng và các lỗ hổng logic của chính hợp đồng đó, đồng thời đạt được hành vi gian lận bằng cách cố tình kích hoạt các ngoại lệ và chức năng khôi phục. Những kẻ tấn công có thể liên tục khai thác các lỗ hổng logic trong hợp đồng để đánh cắp tiền. Giải pháp ngăn chặn các cuộc tấn công tái nhập cũng rất phổ biến, nội dung mã đặc biệt có mục tiêu được đặt trước để bảo vệ và cơ chế bảo vệ như vậy được sử dụng để đảm bảo an toàn cho tiền, đây được gọi là khóa tái nhập.Sự vững chắc đặt ra một Nguyên tắc CEI
(Kiểm tra tương tác hiệu ứng), có thể bảo vệ tốt các chức năng khỏi các cuộc tấn công quay trở lại. Nội dung của nguyên tắc CEI bao gồm:
1. Thứ tự gọi các thành phần chức năng phải là: thứ nhất, kiểm tra, thứ hai, tác động đến các biến trạng thái và cuối cùng, tương tác với các thực thể bên ngoài.
2. Trước khi tương tác với các thực thể bên ngoài, tất cả các biến trạng thái phải được cập nhật. Điều này được gọi là sổ sách kế toán lạc quan, trong đó các hiệu ứng được ghi lại trước khi tương tác thực sự xảy ra.
3. Việc kiểm tra phải được thực hiện khi bắt đầu hàm để đảm bảo rằng thực thể gọi có quyền gọi hàm.
4. Các biến trạng thái phải được cập nhật trước bất kỳ lệnh gọi bên ngoài nào để ngăn chặn các cuộc tấn công vào lại.
5. Ngay cả các thực thể bên ngoài đáng tin cậy cũng phải tuân theo mẫu CEI vì chúng có thể chuyển luồng điều khiển cho các bên thứ ba độc hại.
Theo tài liệu, nguyên tắc CEI giúp hạn chế bề mặt tấn công của hợp đồng, đặc biệt là ngăn chặn các cuộc tấn công quay trở lại. Nguyên tắc CEI có thể được áp dụng dễ dàng, chủ yếu theo thứ tự mã chức năng mà không thay đổi bất kỳ logic nào. Việc khai thác nổi tiếng của The DAO, dẫn đến sự phân nhánh của Ethereum, cũng đã bỏ qua nguyên tắc CEI và kẻ tấn công đã thực hiện một cuộc tấn công tái nhập, gây ra hậu quả tàn khốc.
Nhưng Curve pool bị tấn công đã không tuân theo nguyên tắc CEI này vì Curve đã sử dụng trình biên dịch Vyper. Vì lỗ hổng mã Vyper của trình biên dịch, khóa reentrancy không thành công, khiến cuộc tấn công reentrancy của hacker được thực hiện thành công.
Hầu hết mọi người đều biết đến Solidity, nhưng Solidity không phải là ngôn ngữ duy nhất để tạo hợp đồng thông minh.Một lựa chọn thay thế phổ biến cho Solidity là Vyper. Mặc dù Vyper không mạnh mẽ và phổ biến như Solidity nhưng nó rất lý tưởng cho các nhà phát triển quen thuộc với Python, vì Vyper có thể dịch mã giống Python sang ngôn ngữ lập trình hợp đồng thông minh Ethereum.
Theo thông tin từ github, nhà phát triển đóng góp đầu tiên cho cơ sở mã github của Vyper cũng chính là nhà phát triển của Curve. Không khó để giải thích tại sao Curve sử dụng Vyper thay vì Solidity.
Tại sao khóa quay lại Vyper không thành công?@BoxMrChenVậy trong cuộc tấn công này, vấn đề của Vyper là gì? Tại sao khóa reentry không thành công? Có phải vì không có bài kiểm tra? BlockBeats đã phỏng vấn nhà phát triển hợp đồng thông minh Box 826.eth (
), theo ông, khóa đăng ký lại Vyper đã được thử nghiệm với các trường hợp sử dụng. Nhưng nguyên nhân thất bại là do ca kiểm thử hướng đến kết quả, tức là ca kiểm thử cũng sai.
Tóm lại, nguyên nhân lớn nhất khiến khóa quay lại Vyper thất bại là do người viết test case viết test case dựa trên kết quả mà không nghĩ tới lý do tại sao slot lại bỏ qua 1 một cách khó hiểu.
Trong các đoạn mã Vyper sau đây được Box chia sẻ, có thể thấy rõ vấn đề. Khi tên khóa xuất hiện lần thứ hai, số lượng storage_slots sẽ bị ghi đè, nghĩa là trong ret, vị trí cho lần thu khóa đầu tiên là 0, nhưng sau khi một hàm sử dụng lại khóa, vị trí khóa sẽ tăng lên thêm một. Sau khi biên dịch, sử dụng sai vị trí khiến khóa đăng ký lại không có hiệu lực.
Bên trái là mã bị tấn công, bên phải là mã đã được sửa chữa
Kết quả kiểm tra sai là điều được mong đợi và tất nhiên không thể xác minh được sai sót nào. Để đưa ra một ví dụ đơn giản, hiện tại chúng ta đang làm một bài toán tính 1+ 1 = 2, nhưng đáp án chuẩn đã cho là sai, nói 1+ 1 = 3 Còn cái này Bạn cùng lớp đang làm câu trả lời sai, trả lời 1+1 = 3 nhưng nó giống đáp án chuẩn đưa ra trước nên chương trình đương nhiên không có cách nào xác định kết quả thi là sai rồi. Box nói trong một cuộc phỏng vấn với BlockBeats.
“Thanh kiếm Damocles” bị treo cổ suốt hai nămTrong cuộc tấn công quay trở lại đầu tiên được ghi nhận,Tấn công WETH Tấn công Weiss
Những kẻ tấn công chỉ là những hacker cố tình tạo ra các cuộc tấn công để khiến các nhà phát triển chú ý hơn đến các cuộc tấn công reentrancy, nhằm giúp nhiều dự án miễn nhiễm với khả năng xảy ra các cuộc tấn công reentrancy. Trong bối cảnh hợp đồng thông minh, các nhà phát triển nên sử dụng các cơ chế kích hoạt khác nhau, chẳng hạn như gọi hàm thay đổi trạng thái để đạt được sự bảo vệ. Điều này đòi hỏi các nhà phát triển phải xem xét đầy đủ các kịch bản tấn công có thể xảy ra khi thiết kế hợp đồng và thực hiện các biện pháp phòng ngừa thích hợp.
Để hiểu sâu hơn về trình soạn thảo Vyper, BlockBeats đã phỏng vấn nhà nghiên cứu BTX Derek (@begas_btxcap), anh ấy nói rằng đối với các nhà phát triển quen thuộc với Python, Vyper là lựa chọn lý tưởng hơn Solidity, với giao diện UI thoải mái hơn và nhanh hơn học hỏi. Nhưng rõ ràng, một số phiên bản mã soạn thảo Vyper chưa được bên thứ ba đáng tin cậy kiểm tra. Thậm chí một số công việc kiểm tra có thể do chính các nhà phát triển thực hiện. Loại chuyện này sẽ không xảy ra trong ngành CNTT truyền thống, bởi vì sau khi một ngôn ngữ mới ra đời, sẽ có vô số công ty kiểm toán đang tìm kiếm sơ hở của bạn.
Chưa kể, cho phép một lỗi tồn tại công khai trong hai năm. fubuloubu Cộng tác viên Vyper
Cũng cho biết: Trình biên dịch không được hiệu đính hoặc kiểm tra như mọi người nghĩ. Hầu hết các trình biên dịch đều có những thay đổi đáng kể và thường xuyên, điều này làm cho việc kiểm tra trở nên bất lợi. Ngay cả khi kiểm tra cơ sở mã đầy đủ, nó sẽ trở nên lỗi thời khi có nhiều phiên bản được thêm vào sau đó. Kiểm tra trình biên dịch không phải là một ý tưởng hay vì sẽ hợp lý hơn khi kiểm tra sản phẩm cuối cùng (tức là mã EVM thô) do người dùng cuối sử dụng công cụ này tạo ra.
Tất cả những điều này chỉ ra một vấn đề cuối cùng: động lực. Điều đó có nghĩa là không ai có động cơ tìm ra các lỗi nghiêm trọng trong trình biên dịch, đặc biệt là các phiên bản cũ hơn. fubuloubu trước đây đã đưa ra một đề xuất giúp cải thiện Vyper bằng cách thêm một chương trình tiền thưởng do người dùng đồng tài trợ, nhưng nó đã không được thực hiện.
Tin tặc đang quay trở lại Nguyên tắc đầu tiên
Đây là một ví dụ sống động khác về thực tiễn phát triển an toàn theo hợp đồng dành cho các nhà phát triển giao thức và dự án. Nhưng quan trọng nhất, sự cố Curve đã cảnh báo tất cả chúng ta rằng tính bảo mật của trình biên dịch cơ bản đã bị bỏ qua một cách nghiêm trọng, và những hacker quay trở lại “các nguyên tắc đầu tiên” đã tìm ra một nguyên tắc hoàn hảo trên trình biên dịch thấp hơn, cắt lối vào.@StaniKulechovSau đó, người sáng lập Aave và Lens Stani (
) cũng đăng một bài viết dài trên mạng xã hội để bày tỏ cảm xúc của mình: Cuộc tấn công Curve đồng nghĩa với việc rủi ro của DeFi luôn liên quan đến toàn bộ stack cơ bản, ngôn ngữ lập trình, EVM, v.v. Điều này cảnh báo chúng tôi phải thận trọng và nhạy cảm hơn, đặc biệt là khi sử dụng EVM tùy chỉnh và chuỗi ứng dụng trong tương lai.
Tấn công từ cấp độ thấp hơn
Đối với các lỗ hổng của trình biên dịch, rất khó để phát hiện ra nếu chỉ kiểm tra tính logic của mã nguồn hợp đồng. Chỉ nghiên cứu sự khác biệt giữa các phiên bản và phiên bản cũng là một dự án lớn. Cần kết hợp các phiên bản trình biên dịch cụ thể với các mẫu mã cụ thể để xác định xem hợp đồng thông minh có bị ảnh hưởng bởi các lỗ hổng của trình biên dịch hay không.
Hiện tại chỉ có hai trình biên dịch là tốt nhất, cơ sở mã của Vyper nhỏ hơn, dễ đọc hơn và có ít thay đổi hơn để phân tích lịch sử của nó, đó có thể là lý do tại sao tin tặc bắt đầu ở đây, cơ sở mã của Solidity lớn hơn một chút ”fubuloubu thậm chí còn nghi ngờ rằng- những tin tặc được hỗ trợ có thể liên quan đến cuộc tấn công Curve này: “Sẽ mất vài tuần đến vài tháng để tìm ra lỗ hổng và xét đến nguồn lực đã đầu tư, nó có thể được thực hiện bởi một nhóm hoặc nhóm nhỏ.”
Là ngôn ngữ biên dịch được sử dụng rộng rãi nhất trong ngành mã hóa, tính bảo mật của Solidity càng được người dùng quan tâm hơn, xét cho cùng, nếu trình biên dịch Solidity gặp sự cố reentry lock failed thì lịch sử của toàn bộ ngành DeFi có thể sẽ có được viết lại.Theo các bản phát hành thường xuyên của nhóm phát triển SolidityCảnh báo an ninh
, đã có lỗ hổng bảo mật trong nhiều phiên bản khác nhau của trình biên dịch Solidity.
Lỗi trình biên dịch gần đây nhất được ghi lại là vào ngày 26 tháng 6, khi điều tra một báo cáo bảo mật liên quan đến việc sử dụng abi.error. Trình tạo mã cũ không đánh giá các biểu thức phức tạp như phép gán, lệnh gọi hàm hoặc điều kiện mà .selector đang được truy cập. Điều này gây ra tác dụng phụ là các biểu thức đó không được thực thi, do đó các hợp đồng được biên dịch bằng quy trình cũ có thể hoạt động không chính xác.Chúng ta cũng có thể thấy SolidityKho lưu trữ Githubbugs_by_version.jsonMột tệp được đặt trong đó liệt kê một số lỗi liên quan đến bảo mật đã biết trên trình biên dịch Solidity. Danh sách quay trở lại phiên bản 0.3.0, các lỗi chỉ tồn tại trước phiên bản này không được liệt kê. Ở đây, có một cái khác
tài liệu. Tệp này có thể được sử dụng để truy vấn xem phiên bản trình biên dịch cụ thể nào bị ảnh hưởng bởi lỗi nào.
May mắn thay, chính nhờ ứng dụng rộng rãi của ngôn ngữ Solidity và sự hỗ trợ của Ethereum Foundation mà nhiều vấn đề tồn tại đã được các dự án và giao thức chỉ ra trong quá trình triển khai. Vì vậy, Solidity đã hoàn thành việc sửa đổi và cải tiến nhanh hơn Vyper vài bước, từ góc độ này, đây là một trong những lý do khiến Solidity chuẩn hóa và an toàn hơn.
Để giúp các nhà phát triển Solidity kiểm tra tốt hơn và ngăn chặn điều tương tự xảy ra. Người đồng sáng lập UnitasProtocol SunSec (@ 1 nf 0 s 3 cpt) đã phát hành hướng dẫn kiểm tra bảo mật DeFiVulnLabs Solidity sau cuộc tấn công Curve, hỗ trợ 47 loại lỗ hổng, bao gồm mô tả lỗ hổng, kịch bản, phòng thủ, mã lỗ hổng và các biện pháp giảm thiểu cũng như cách kiểm tra .
Làm thế nào để tránh các cuộc tấn công cấp thấp càng nhiều càng tốt?
Trong sự cố Curve này, Box tin rằng sự soi sáng cho tất cả các nhà phát triển là: đừng cố chạy theo xu hướng công nghệ và chọn những giải pháp non nớt; đừng phê duyệt mã của riêng bạn mà không viết các trường hợp kiểm thử (một số phiên bản Vyper có vấn đề Ngay cả trường hợp kiểm thử sai); không bao giờ tự mình phê duyệt mã của riêng bạn; một số vận may có thể mất nhiều năm mới được khám phá; không thể nâng cấp là sự kiêu ngạo đối với bản thân và khinh thường người khác.
Thông thường, các nhà phát triển không nghĩ đến bất kỳ cạm bẫy nào ở đây và chọn một phiên bản để biên dịch theo ý muốn, điều này có thể bỏ qua những rủi ro do sự khác biệt giữa các phiên bản mang lại. Ngay cả những nâng cấp phiên bản nhỏ cũng có thể tạo ra những thay đổi đột phá, điều này đặc biệt quan trọng khi phát triển các ứng dụng phi tập trung.
Cảnh báo dành cho các nhà phát triển từ sự kiện Curve này là: sử dụng phiên bản mới hơn của ngôn ngữ trình biên dịch. Điều quan trọng là phải luôn cập nhật cơ sở mã, ứng dụng và hệ điều hành của bạn cũng như xây dựng hệ thống phòng thủ bảo mật của riêng bạn về mọi mặt. Nhìn chung có ít vấn đề bảo mật được biết đến hơn so với các phiên bản cũ hơn, mặc dù các phiên bản mới hơn có thể gây ra các vấn đề bảo mật mới. Tất nhiên, chúng ta cũng nên chú ý đến cộng đồng và các thông báo cập nhật phiên bản chính thức kịp thời. Hiểu những thay đổi do mỗi phiên bản mang lại và cập nhật cơ sở mã cũng như môi trường hoạt động của riêng bạn nếu cần. Thực hiện các bước này có thể làm giảm đáng kể sự cố bảo mật do lỗi trình biên dịch gây ra.
Ngoài ra, các trường hợp kiểm thử đơn vị để hoàn thiện mã. Hầu hết các lỗi ở cấp độ trình biên dịch sẽ dẫn đến kết quả thực thi mã không nhất quán, khó phát hiện chỉ khi xem xét mã nhưng có thể bị lộ trong quá trình thử nghiệm. Cải thiện phạm vi bao phủ mã có thể giúp tránh những vấn đề như vậy. Và cố gắng tránh sử dụng các tính năng ngôn ngữ phức tạp như lắp ráp nội tuyến và mã hóa và giải mã mảng đa chiều, trừ khi có nhu cầu rõ ràng. Hầu hết các lỗ hổng ngôn ngữ Solidity trước đây đều liên quan đến các tính năng nâng cao này. Các nhà phát triển nên tránh sử dụng các tính năng ngôn ngữ thử nghiệm nhằm mục đích phô trương mà không có nhu cầu cụ thể.
Tất nhiên, chúng ta không cần quá lo lắng về những rủi ro của cơ sở hạ tầng cơ bản. Hiện tại, hầu hết các lỗi trình biên dịch chỉ được kích hoạt trong các mẫu mã cụ thể và tác động thực tế cần được đánh giá tùy theo tình hình dự án. Thường xuyên nâng cấp phiên bản trình biên dịch và kiểm tra đơn vị đầy đủ có thể giúp ngăn ngừa rủi ro.
Nội dung tham khảo:
2.https://github.com/pcaversaccio/reentrancy-attacks/issues/1
3.https://nipunp.medium.com/5-8-21-rari-capital-exploit-timeline-analysis-8beda31cbc1a
4.https://docs.Soliditylang.org/en/v0.8.21/
