Với sự cố khai thác lỗ hổng xảy ra, ngành DeFi đã rơi vào hỗn loạn. Curve Finance, 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 thống kê chưa đầy đủ, việc khai thác lỗ hổng đã khiến các pool Alchemix , JPEG’d, MetronomeDAO, deBridge , Ellipsis và CRV /ETH thiệt hại tổng cộng 52 triệu đô la Mỹ, đồng thời niềm tin của toàn thị trường bị lung lay nghiêm trọng.
Khóa truy cập 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 đề xuất một 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 lỗ hổng thông thường mà còn cho thấy rủi ro tiềm ẩn rất lớn của toàn bộ ngăn xếp cơ bản đối với toàn bộ ngành DeFi.
So với trước đây, số vụ hack trong giai đoạn trước ngày càng ít đi, điều này không thể tách rời khỏi sự thịnh vượng của thị trường. Trong suốt mùa hè DeFi và mùa hè NFT, các thỏa thuận mới trị giá hàng tỷ đô la đã được tung 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 cho 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, điều đó có nghĩa là tin tặc cần các điểm vào mới hơn, chưa được khai thác để khám phá.
Những hacker quay trở lại với “những nguyên tắc đầu tiên” đã tìm thấy một điểm vào hoàn hảo trên trình biên dịch cấp thấp để ăn “chiếc bánh” khổng lồ và ngon lành trên thị trường DeFi. Trình biên dịch cấp thấp đã trở thành một hacker “thông minh” hơn. Sự lựa chọn. BlockBeats đã phỏng vấn nhà phát triển hợp đồng thông minh Box (@BoxMrChen) và nhà nghiên cứu BTX Derek (@begas_btxcap) về sự cố này và các vấn đề liên quan mà nó bộc lộ.
Stani (@StaniKulechov), 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 trở ngại đáng tiếc cho Curve và DeFi. Mặc dù DeFi là một không gian mở có thể đóng góp, nhưng nó phải làm cho đúng khó khăn và rủi ro cao. Trong trường hợp của Curve, họ đã làm đúng ở cấp độ giao thức.”
Việc khai thác mà Curve phải chịu 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 vào lại. Các cuộc tấn công vào lại 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 sử dụng sơ hở để rút tiền cho đến khi hợp đồng nạn nhân hết tiền.
Khóa Reentrant và nguyên tắc CEI
Đưa ra một ví dụ đơn giản để minh họa cho các cuộc tấn công vào lại: 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 sơ hở lớn, mỗi khi người dân 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 sơ hở này, hắn 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 lại 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 còn 1.000 tệ trước khi kiểm tra và cập nhật. Thông qua các thao tác lặp đi lặp lại, người dùng cuối cùng đã rút hết số tiền mặt trị giá 100.000 đô la Mỹ trong ngân hàng. Mãi đến cuối ngày, ngân hàng mới phát hiện ra kẽ hở đã bị lợi dụng.
Sự phức tạp của cuộc tấn công vào lại nằm ở chỗ nó lợi dụng lệnh 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 thực hiện 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 vào lại cũng rất phổ biến. Nội dung mã đặc biệt được nhắm 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 vào lại.
Solidity đặt ra “nguyên tắc CEI” (Kiểm tra tương tác hiệu ứng) cho lập trình hợp đồng thông minh, có thể bảo vệ tốt các chức năng khỏi các cuộc tấn công vào lại. Nội dung của các nguyên tắc CEI bao gồm:
1. Thứ tự gọi các thành phần chức năng nên là: đầu tiên, 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 lạc quan”, trong đó các hiệu ứng được viết trước khi tương tác thực sự xảy ra.
3. Kiểm tra nên được thực hiện khi bắt đầu chức năng để đảm bảo rằng thực thể gọi có quyền gọi chức năng.
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 kiểm soát cho các bên thứ ba độc hại.
Theo tài liệu, các 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 vào lại. Các 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. Khai thác nổi tiếng của The DAO, dẫn đến fork Ethereum, cũng bỏ qua “nguyên tắc CEI” và kẻ tấn công đã đạt được một cuộc tấn công vào lại, gây ra hậu quả tàn khốc.
Nhưng nhóm Curve 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. Do lỗ hổng mã Vyper của trình biên dịch, khóa vào lại không thành công, khiến cuộc tấn công vào lại của tin tặc đượ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, Vyper là ngôn ngữ thay thế phổ biến cho Solidity. 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 như Python sang ngôn ngữ lập trình hợp đồng thông minh Ethereum.
Theo thông tin trên github, nhà phát triển đóng góp đầu tiên cho cơ sở mã github của Vyper cũng 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 truy cập lại Vyper không thành công?
Vậy trong cuộc tấn công này, Vyper gặp vấn đề 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 (@BoxMrChen), theo ông, khóa đăng nhập lại Vyper đã được thử nghiệm với các trường hợp sử dụng. Nhưng lý do thất bại là trường hợp thử nghiệm hướng đến kết quả, tức là trường hợp thử nghiệm cũng sai.
Nói tóm lại, lý do lớn nhất khiến khóa truy cập lại Vyper không thành công là do người viết trường hợp thử nghiệm đã viết trường hợp thử nghiệm dựa trên kết quả mà không suy nghĩ về lý do tại sao vị trí lại bỏ qua 1 một cách khó hiểu.
Trong đoạn code Vyper mà Box chia sẻ dưới đây, có thể thấy rõ vấn đề. Khi tên khóa xuất hiện lần thứ hai, số lượng storage_slot sẽ bị ghi đè, nghĩa là, trong ret, vị trí cho lần mua khóa đầu tiên là 0, nhưng sau khi một chức năng sử dụng lại khóa, vị trí khóa sẽ tăng thêm một. Sau khi biên dịch, vị trí sai được sử dụng, khiến khóa người truy cập lại không có hiệu lực.
Bên trái là mã bị tấn công và bên phải là mã đã sửa chữa
“Dự kiến là kết quả kiểm tra sai và tất nhiên không có lỗi nào có thể được xác minh. Lấy một ví dụ đơn giản, bây giờ chúng ta đang thực hiện một bài toán tính toán, 1 1 = 2 , nhưng đáp số tiêu chuẩn đã cho là sai, cho biết 1 1 = 3. Tại Lần này, bạn cùng lớp trả lời sai câu hỏi đã trả lời 1 1 = 3, nhưng nó giống với đáp án tiêu chuẩn được đưa ra trước, vì vậy chương trình đương nhiên không có cách nào xác định rằng kết quả kiểm tra là sai.” Box nói trong một cuộc phỏng vấn với BlockBeats.
“Thanh kiếm của Damocles” bị treo trong hai năm
Trong sự cố tấn công vào lại lần đầu tiên được ghi nhận trong lịch sử, những kẻ tấn công WETH Attack chính xác là những hacker da trắng cố tình tạo ra các cuộc tấn công nhằm khiến các nhà phát triển chú ý đến các cuộc tấn công vào lại, với mục đích làm cho nhiều dự án miễn nhiễm hơn với các cuộc tấn công vào lại Khả năng xảy ra. 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 chức năng thay đổi trạng thái để đạt được sự bảo vệ. Điều này yêu cầu 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), ông 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 của mã trình 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 toán có thể được thực hiện bởi chính các nhà phát triển. “Loại chuyện này sẽ không xảy ra trong ngành công nghệ thông tin truyền thống, bởi vì sau khi một ngôn ngữ mới xuất hiện, 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.
Người đóng góp cho Vyper fubuloubu cũng cho biết: Trình biên dịch không được xem xét 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 quan trọng 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ả với 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, bởi 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 tạo ra bằng công cụ này.
Tất cả những điều này chỉ ra một vấn đề cuối cùng: động lực. Điều đó nói rằng, 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ông qua.
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ề các phương pháp 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 đã cho tất cả chúng ta một cảnh báo rằng tính bảo mật của trình biên dịch cơ bản đã bị bỏ qua nghiêm trọng và những tin tặc quay trở lại “các nguyên tắc đầu tiên” đã tìm thấy một nguyên tắc hoàn hảo trên trình biên dịch thấp hơn.
Sau đó, Stani (@StaniKulechov), người sáng lập Aave và Lens, 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 vào Curve có nghĩa là rủi ro của DeFi luôn liên quan đến toàn bộ ngăn xếp cơ bản, ngôn ngữ lập trình, EVM , vân vân. Điều này cảnh báo chúng ta 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ó để tìm ra chỉ bằng cách kiểm tra 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 phải 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 các 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 trạng thái- các tin tặc được hậu thuẫn có thể tham gia vào 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à xem xét các 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 công nghiệp mã hóa, tính bảo mật của Solidity lại càng được người dùng quan tâm, sau tất cả, nếu trình biên dịch Solidity gặp sự cố khóa vào lại lần này, thì lịch sử của toàn ngành DeFi có thể sẽ được viết lại.
Theo các cảnh báo bảo mật do nhóm phát triển Solidity đưa ra thường xuyên, đã có cá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ụ khiến các biểu thức đó không được thực thi, do đó, các hợp đồng được biên soạn 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 một tệp trong kho lưu trữ Github của Solidity 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 tệp bug_by_version.json khác. Tệp này có thể được sử dụng để truy vấn những lỗi nào mà một phiên bản trình biên dịch cụ thể bị ảnh hưởng.
May mắn thay, chính vì ứ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. Do đó, Solidity đã hoàn thành việc sửa đổi và cải tiến nhanh hơn Vyper vài bước, xét về khía cạnh này, đây là một trong những lý do khiến Solidity chuẩn hóa hơn 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 đ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, biện pháp giảm thiểu và 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 lần này, Box tin rằng lời cảnh tỉnh dành 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 chính mình khi chưa viết test case (vài phiên bản Vyper có vấn đề ngay cả khi các trường hợp thử nghiệm sai); không bao giờ tự phê duyệt mã của chính bạn; một số may mắn có thể mất nhiều năm để được khám phá; không thể nâng cấp là kiêu ngạo với chính mình 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ác cảnh báo 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à luôn cập nhật cơ sở mã, ứng dụng và hệ điều hành của bạn, đồng thời 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 sự cố bảo mật đã biết 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ể đưa ra các sự cố bảo mật mới. Tất nhiên, chúng ta cũng nên chú ý đến các thông báo cập nhật phiên bản chính thức và cộng đồng 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ã và 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ể các 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 tra đơn vị để hoàn thành 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, rất khó phát hiện chỉ thông qua đánh giá mã nhưng có thể phát hiện ra trong quá trình thử nghiệm. Cải thiện phạm vi 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 thể hiện mà không có nhu cầu cụ thể.
Đối với lớp giao thức và nhân viên bảo mật, không thể bỏ qua những rủi ro có thể xảy ra của phiên bản trình biên dịch khi tiến hành kiểm tra mã. Có thể thấy trước rằng tin tặc đã mở ra những ý tưởng mới và trong tương lai, sẽ ngày càng có nhiều sự cố khai thác lỗ hổng cấp thấp hơn. Đồng thời, vì cơ sở hạ tầng cơ bản, ngăn xếp cơ bản, ngôn ngữ lập trình, EVM, v.v. cần được kiểm tra. Trong tương lai, thị trường cho các công ty kiểm toán sẽ ngày càng lớn hơn, và thị trường tiền thưởng cho khách da trắng cũng sẽ ngày càng lớn hơn. Nhóm Vyper cũng có kế hoạch bắt đầu xem xét chương trình tiền thưởng lỗi sau khi vấn đề được giải quyết chính thức.
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á 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.
