Tài chính phi tập trung Các lỗ hổng bảo mật thường gặp và biện pháp phòng ngừa
Gần đây, một chuyên gia an ninh đã chia sẻ một buổi học về an ninh DeFi cho các thành viên trong cộng đồng. Chuyên gia đã xem xét các sự kiện an ninh nghiêm trọng mà ngành Web3 đã gặp phải trong hơn một năm qua, thảo luận về nguyên nhân xảy ra những sự kiện an ninh này và cách để tránh chúng, tổng hợp các lỗ hổng an ninh thường gặp của hợp đồng thông minh cũng như các biện pháp phòng ngừa, đồng thời đưa ra một số lời khuyên an ninh cho các bên dự án và người dùng bình thường.
Các loại lỗ hổng DeFi thường gặp bao gồm cho vay chớp nhoáng, thao túng giá cả, vấn đề quyền hạn hàm, gọi ngoài tùy ý, vấn đề hàm fallback, lỗ hổng logic kinh doanh, rò rỉ khóa riêng, tấn công tái nhập, v.v. Dưới đây sẽ tập trung giới thiệu ba loại: cho vay chớp nhoáng, thao túng giá cả và tấn công tái nhập.
Vay chớp nhoáng
Vay chớp nhoáng bản thân là một đổi mới của Tài chính phi tập trung, nhưng khi bị hacker lợi dụng, họ có thể vay được một lượng lớn tiền mà không cần tốn bất kỳ chi phí nào, thực hiện toàn bộ quy trình chênh lệch giá và hoàn trả, chỉ cần trả một khoản phí Gas nhỏ để thu được lợi nhuận khổng lồ.
Trong hai năm qua, các khoản vay chớp nhoáng đã xuất hiện nhiều vấn đề. Một số dự án DeFi có vẻ mang lại lợi nhuận cao, nhưng thực tế trình độ của các dự án này rất khác nhau. Một số mã nguồn của dự án có thể đã được mua, ngay cả khi mã nguồn không có lỗ hổng, về mặt logic vẫn có thể tồn tại vấn đề. Chẳng hạn, từng có một dự án phát thưởng dựa trên số lượng token mà người nắm giữ có vào một thời điểm cố định, nhưng đã bị kẻ tấn công lợi dụng vay chớp nhoáng để mua một lượng lớn token, khiến phần lớn phần thưởng chảy vào tay kẻ tấn công khi phần thưởng được phát. Ngoài ra, còn có một số dự án tính toán giá thông qua Token, có thể bị ảnh hưởng giá bởi các khoản vay chớp nhoáng. Là một bên dự án, bạn nên nâng cao cảnh giác đối với những vấn đề này.
Kiểm soát giá
Vấn đề thao túng giá cả có mối quan hệ chặt chẽ với khoản vay chớp nhoáng, vấn đề này chủ yếu là do một số tham số trong quá trình tính toán giá có thể được người dùng kiểm soát, thường có hai loại vấn đề xảy ra:
Sử dụng dữ liệu của bên thứ ba khi tính giá, nhưng cách sử dụng không đúng hoặc thiếu kiểm tra dẫn đến giá bị thao túng một cách ác ý.
Sử dụng một số lượng Token của các địa chỉ làm biến số tính toán, và số dư Token của các địa chỉ này có thể được tăng hoặc giảm tạm thời.
Tấn công tái nhập
Một trong những nguy cơ chính khi gọi hợp đồng bên ngoài là chúng có thể chiếm quyền điều khiển luồng và thực hiện những thay đổi không lường trước đối với dữ liệu của bạn.
Do người dùng có số dư được đặt thành 0 chỉ đến cuối hàm, lần gọi thứ hai ( và các lần gọi ) sau đó vẫn sẽ thành công, và sẽ liên tục rút số dư.
Đối với các hợp đồng khác nhau, có nhiều cách để thực hiện tấn công reentrancy, có thể kết hợp các hàm khác nhau của hợp đồng hoặc các hàm của nhiều hợp đồng khác nhau để hoàn thành cuộc tấn công reentrancy, vì vậy khi giải quyết vấn đề reentrancy, chúng ta cần chú ý đến những điểm sau:
Không chỉ ngăn chặn vấn đề tái nhập của một hàm đơn lẻ;
Thực hiện mã hóa theo mô hình Checks-Effects-Interactions;
Sử dụng modifier chống tái nhập đã được kiểm chứng theo thời gian.
Thực ra điều đáng sợ nhất là việc lặp lại việc chế tạo bánh xe, cần gì thì tự mình viết. Trong lĩnh vực này có rất nhiều thực tiễn an toàn tốt nhất, chúng ta chỉ cần sử dụng chúng, hoàn toàn không cần thiết phải lặp lại việc chế tạo bánh xe. Khi bạn chế tạo một cái bánh xe, nó không được kiểm chứng đầy đủ, lúc này xác suất xảy ra vấn đề, rõ ràng lớn hơn rất nhiều so với việc sử dụng một cái đã được kiểm chứng và thử nghiệm lâu dài.
Đề xuất an toàn
Mẹo an toàn cho dự án
Phát triển hợp đồng tuân thủ các thực hành an toàn tốt nhất.
Hợp đồng có thể nâng cấp, tạm dừng: Nhiều cuộc tấn công không chỉ diễn ra một lần mà chuyển toàn bộ tiền, mà là thực hiện qua nhiều giao dịch khác nhau. Nếu có một cơ chế giám sát tương đối tốt, nó có thể được phát hiện. Sau khi phát hiện, giả sử hợp đồng có thể tạm dừng, thì có thể giảm thiểu thiệt hại một cách hiệu quả.
Sử dụng khóa thời gian: Nếu có khóa thời gian, giả sử là trong vòng 48 giờ để hoàn thành, lúc này nhiều người có thể phát hiện ra rằng người tạo ra đã cập nhật lại một phương pháp mint, và ai cũng có thể sử dụng, những người giám sát sẽ biết rằng dự án có thể đã bị hack, và có thể thông báo cho bên dự án để thay đổi, ngay cả khi giả sử đã thông báo nhưng không ai quan tâm, ít nhất có thể rút phần tiền của mình ra trước, để đảm bảo lợi nhuận của mình không bị thiệt hại. Vì vậy, nếu một dự án không có khóa thời gian, về lý thuyết sẽ làm tăng xác suất xảy ra vấn đề.
Tăng cường đầu tư vào an toàn, thiết lập một hệ thống an toàn hoàn chỉnh: An toàn không phải là một điểm, cũng không phải là một đường thẳng, an toàn là một hệ thống. Đừng nghĩ rằng với tư cách là bên dự án, hợp đồng đã được nhiều công ty kiểm toán thì sẽ không có vấn đề gì. Cần cố gắng thực hiện mô hình hóa rủi ro, sau đó từng bước loại bỏ phần lớn rủi ro, phần rủi ro còn lại cũng là rủi ro có thể chấp nhận, nằm trong phạm vi có thể chịu đựng. An toàn và hiệu quả không thể đạt được cùng lúc, cần phải có một số sự hy sinh nhất định. Nhưng nếu hoàn toàn không quan tâm đến an toàn, không đầu tư vào an toàn, thì việc bị tấn công là điều rất bình thường.
Nâng cao nhận thức về an toàn của tất cả nhân viên: Nâng cao nhận thức về an toàn không cần quá nhiều kỹ thuật. Trong bối cảnh lớn này, chỉ cần hỏi thêm một chút về lý do, suy nghĩ thêm một chút là có thể tránh được nhiều vấn đề.
Ngăn chặn hành vi xấu từ bên trong, đồng thời nâng cao hiệu quả và tăng cường quản lý rủi ro.
An ninh của bên thứ ba: Là một phần trong hệ sinh thái, các bên dự án đều có các bên trên và dưới của riêng mình. Về mặt an ninh có nguyên tắc "mặc định tất cả các bên trên và dưới đều không an toàn". Dù là đối với bên trên hay bên dưới, đều phải thực hiện kiểm tra. Đối với bên thứ ba, chúng ta rất khó kiểm soát, rủi ro an ninh thực tế rất lớn, vì vậy cần phải rất chú ý đến việc đưa bên thứ ba vào. Hợp đồng là mã nguồn mở, có thể được đưa vào, gọi nó; nếu hợp đồng không mã nguồn mở, thì tuyệt đối không được tham chiếu.
Người dùng/LP làm thế nào để xác định hợp đồng thông minh có an toàn không?
Đối với người dùng bình thường, chúng tôi đánh giá xem dự án có an toàn hay không chủ yếu dựa vào sáu điểm sau:
Hợp đồng có nguồn mở không: Những dự án không có hợp đồng nguồn mở, tuyệt đối không chạm vào, vì chúng ta không biết hợp đồng đã được viết gì.
Chủ sở hữu có sử dụng đa chữ ký hay không, và đa chữ ký có phi tập trung hay không: Nếu không sử dụng đa chữ ký, chúng tôi không thể đánh giá được logic và nội dung của dự án, một khi xảy ra sự cố an ninh, không thể xác định liệu đó có phải là do hacker hay không. Ngay cả khi sử dụng đa chữ ký, cũng cần phải đánh giá xem đa chữ ký có thực sự phi tập trung hay không.
Tình hình giao dịch của hợp đồng đã có: đặc biệt là trên thị trường có nhiều dự án lừa đảo qua việc đánh cắp thông tin, có thể tạo ra một hợp đồng tương tự, lúc này chúng ta cần xem xét thời gian triển khai hợp đồng, số lần tương tác, v.v., đây đều là những tiêu chí để đánh giá xem hợp đồng có an toàn hay không.
Hợp đồng có phải là hợp đồng đại diện không, có thể nâng cấp không, có khóa thời gian không: Nếu hợp đồng hoàn toàn không thể nâng cấp, thì quá cứng nhắc, vẫn khuyến nghị rằng hợp đồng của dự án có thể nâng cấp. Nhưng việc nâng cấp cần chú trọng phương pháp, khi nâng cấp có nội dung nâng cấp, thay đổi tham số quan trọng, cần có một khóa thời gian, cần cho mọi người một khoảng thời gian để đánh giá việc nâng cấp thực sự có hại hay có lợi cho người dùng, đây cũng là một hình thức công khai minh bạch.
Hợp đồng có được nhiều tổ chức kiểm toán chấp nhận không ( đừng mù quáng tin tưởng vào công ty kiểm toán ), Quyền hạn của Owner có quá lớn không: trước tiên đừng chỉ tin vào một công ty kiểm toán, vì các công ty kiểm toán khác nhau, các kiểm toán viên khác nhau, góc nhìn về vấn đề là khác nhau. Thứ hai, cần xem quyền hạn của Owner có quá lớn không. Quyền hạn của một Owner trong một dự án bình thường chắc chắn phải có thể kiểm soát được, như vậy sẽ không có quá nhiều thao tác nguy hiểm, và các thao tác cũng sẽ được thực hiện theo cách khóa thời gian, để người dùng biết thao tác là gì.
Chú ý đến oracle: Nếu dự án sử dụng oracle hàng đầu trên thị trường, thì hầu như sẽ không có vấn đề lớn, nhưng nếu sử dụng oracle tự xây dựng, hoặc oracle mà có thể gửi giá chỉ bằng cách thế chấp một số token tùy tiện, thì cần phải chú ý. Khi phát hiện oracle có thể tồn tại một số vấn đề, hoặc nói rằng có khả năng bị thao túng, thì ngay cả khi lợi nhuận của dự án cao đến đâu cũng không được tham gia.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Tài chính phi tập trung an toàn: Phân tích và biện pháp phòng ngừa các lỗ hổng phổ biến
Tài chính phi tập trung Các lỗ hổng bảo mật thường gặp và biện pháp phòng ngừa
Gần đây, một chuyên gia an ninh đã chia sẻ một buổi học về an ninh DeFi cho các thành viên trong cộng đồng. Chuyên gia đã xem xét các sự kiện an ninh nghiêm trọng mà ngành Web3 đã gặp phải trong hơn một năm qua, thảo luận về nguyên nhân xảy ra những sự kiện an ninh này và cách để tránh chúng, tổng hợp các lỗ hổng an ninh thường gặp của hợp đồng thông minh cũng như các biện pháp phòng ngừa, đồng thời đưa ra một số lời khuyên an ninh cho các bên dự án và người dùng bình thường.
Các loại lỗ hổng DeFi thường gặp bao gồm cho vay chớp nhoáng, thao túng giá cả, vấn đề quyền hạn hàm, gọi ngoài tùy ý, vấn đề hàm fallback, lỗ hổng logic kinh doanh, rò rỉ khóa riêng, tấn công tái nhập, v.v. Dưới đây sẽ tập trung giới thiệu ba loại: cho vay chớp nhoáng, thao túng giá cả và tấn công tái nhập.
Vay chớp nhoáng
Vay chớp nhoáng bản thân là một đổi mới của Tài chính phi tập trung, nhưng khi bị hacker lợi dụng, họ có thể vay được một lượng lớn tiền mà không cần tốn bất kỳ chi phí nào, thực hiện toàn bộ quy trình chênh lệch giá và hoàn trả, chỉ cần trả một khoản phí Gas nhỏ để thu được lợi nhuận khổng lồ.
Trong hai năm qua, các khoản vay chớp nhoáng đã xuất hiện nhiều vấn đề. Một số dự án DeFi có vẻ mang lại lợi nhuận cao, nhưng thực tế trình độ của các dự án này rất khác nhau. Một số mã nguồn của dự án có thể đã được mua, ngay cả khi mã nguồn không có lỗ hổng, về mặt logic vẫn có thể tồn tại vấn đề. Chẳng hạn, từng có một dự án phát thưởng dựa trên số lượng token mà người nắm giữ có vào một thời điểm cố định, nhưng đã bị kẻ tấn công lợi dụng vay chớp nhoáng để mua một lượng lớn token, khiến phần lớn phần thưởng chảy vào tay kẻ tấn công khi phần thưởng được phát. Ngoài ra, còn có một số dự án tính toán giá thông qua Token, có thể bị ảnh hưởng giá bởi các khoản vay chớp nhoáng. Là một bên dự án, bạn nên nâng cao cảnh giác đối với những vấn đề này.
Kiểm soát giá
Vấn đề thao túng giá cả có mối quan hệ chặt chẽ với khoản vay chớp nhoáng, vấn đề này chủ yếu là do một số tham số trong quá trình tính toán giá có thể được người dùng kiểm soát, thường có hai loại vấn đề xảy ra:
Sử dụng dữ liệu của bên thứ ba khi tính giá, nhưng cách sử dụng không đúng hoặc thiếu kiểm tra dẫn đến giá bị thao túng một cách ác ý.
Sử dụng một số lượng Token của các địa chỉ làm biến số tính toán, và số dư Token của các địa chỉ này có thể được tăng hoặc giảm tạm thời.
Tấn công tái nhập
Một trong những nguy cơ chính khi gọi hợp đồng bên ngoài là chúng có thể chiếm quyền điều khiển luồng và thực hiện những thay đổi không lường trước đối với dữ liệu của bạn.
Do người dùng có số dư được đặt thành 0 chỉ đến cuối hàm, lần gọi thứ hai ( và các lần gọi ) sau đó vẫn sẽ thành công, và sẽ liên tục rút số dư.
Đối với các hợp đồng khác nhau, có nhiều cách để thực hiện tấn công reentrancy, có thể kết hợp các hàm khác nhau của hợp đồng hoặc các hàm của nhiều hợp đồng khác nhau để hoàn thành cuộc tấn công reentrancy, vì vậy khi giải quyết vấn đề reentrancy, chúng ta cần chú ý đến những điểm sau:
Không chỉ ngăn chặn vấn đề tái nhập của một hàm đơn lẻ;
Thực hiện mã hóa theo mô hình Checks-Effects-Interactions;
Sử dụng modifier chống tái nhập đã được kiểm chứng theo thời gian.
Thực ra điều đáng sợ nhất là việc lặp lại việc chế tạo bánh xe, cần gì thì tự mình viết. Trong lĩnh vực này có rất nhiều thực tiễn an toàn tốt nhất, chúng ta chỉ cần sử dụng chúng, hoàn toàn không cần thiết phải lặp lại việc chế tạo bánh xe. Khi bạn chế tạo một cái bánh xe, nó không được kiểm chứng đầy đủ, lúc này xác suất xảy ra vấn đề, rõ ràng lớn hơn rất nhiều so với việc sử dụng một cái đã được kiểm chứng và thử nghiệm lâu dài.
Đề xuất an toàn
Mẹo an toàn cho dự án
Phát triển hợp đồng tuân thủ các thực hành an toàn tốt nhất.
Hợp đồng có thể nâng cấp, tạm dừng: Nhiều cuộc tấn công không chỉ diễn ra một lần mà chuyển toàn bộ tiền, mà là thực hiện qua nhiều giao dịch khác nhau. Nếu có một cơ chế giám sát tương đối tốt, nó có thể được phát hiện. Sau khi phát hiện, giả sử hợp đồng có thể tạm dừng, thì có thể giảm thiểu thiệt hại một cách hiệu quả.
Sử dụng khóa thời gian: Nếu có khóa thời gian, giả sử là trong vòng 48 giờ để hoàn thành, lúc này nhiều người có thể phát hiện ra rằng người tạo ra đã cập nhật lại một phương pháp mint, và ai cũng có thể sử dụng, những người giám sát sẽ biết rằng dự án có thể đã bị hack, và có thể thông báo cho bên dự án để thay đổi, ngay cả khi giả sử đã thông báo nhưng không ai quan tâm, ít nhất có thể rút phần tiền của mình ra trước, để đảm bảo lợi nhuận của mình không bị thiệt hại. Vì vậy, nếu một dự án không có khóa thời gian, về lý thuyết sẽ làm tăng xác suất xảy ra vấn đề.
Tăng cường đầu tư vào an toàn, thiết lập một hệ thống an toàn hoàn chỉnh: An toàn không phải là một điểm, cũng không phải là một đường thẳng, an toàn là một hệ thống. Đừng nghĩ rằng với tư cách là bên dự án, hợp đồng đã được nhiều công ty kiểm toán thì sẽ không có vấn đề gì. Cần cố gắng thực hiện mô hình hóa rủi ro, sau đó từng bước loại bỏ phần lớn rủi ro, phần rủi ro còn lại cũng là rủi ro có thể chấp nhận, nằm trong phạm vi có thể chịu đựng. An toàn và hiệu quả không thể đạt được cùng lúc, cần phải có một số sự hy sinh nhất định. Nhưng nếu hoàn toàn không quan tâm đến an toàn, không đầu tư vào an toàn, thì việc bị tấn công là điều rất bình thường.
Nâng cao nhận thức về an toàn của tất cả nhân viên: Nâng cao nhận thức về an toàn không cần quá nhiều kỹ thuật. Trong bối cảnh lớn này, chỉ cần hỏi thêm một chút về lý do, suy nghĩ thêm một chút là có thể tránh được nhiều vấn đề.
Ngăn chặn hành vi xấu từ bên trong, đồng thời nâng cao hiệu quả và tăng cường quản lý rủi ro.
An ninh của bên thứ ba: Là một phần trong hệ sinh thái, các bên dự án đều có các bên trên và dưới của riêng mình. Về mặt an ninh có nguyên tắc "mặc định tất cả các bên trên và dưới đều không an toàn". Dù là đối với bên trên hay bên dưới, đều phải thực hiện kiểm tra. Đối với bên thứ ba, chúng ta rất khó kiểm soát, rủi ro an ninh thực tế rất lớn, vì vậy cần phải rất chú ý đến việc đưa bên thứ ba vào. Hợp đồng là mã nguồn mở, có thể được đưa vào, gọi nó; nếu hợp đồng không mã nguồn mở, thì tuyệt đối không được tham chiếu.
Người dùng/LP làm thế nào để xác định hợp đồng thông minh có an toàn không?
Đối với người dùng bình thường, chúng tôi đánh giá xem dự án có an toàn hay không chủ yếu dựa vào sáu điểm sau:
Hợp đồng có nguồn mở không: Những dự án không có hợp đồng nguồn mở, tuyệt đối không chạm vào, vì chúng ta không biết hợp đồng đã được viết gì.
Chủ sở hữu có sử dụng đa chữ ký hay không, và đa chữ ký có phi tập trung hay không: Nếu không sử dụng đa chữ ký, chúng tôi không thể đánh giá được logic và nội dung của dự án, một khi xảy ra sự cố an ninh, không thể xác định liệu đó có phải là do hacker hay không. Ngay cả khi sử dụng đa chữ ký, cũng cần phải đánh giá xem đa chữ ký có thực sự phi tập trung hay không.
Tình hình giao dịch của hợp đồng đã có: đặc biệt là trên thị trường có nhiều dự án lừa đảo qua việc đánh cắp thông tin, có thể tạo ra một hợp đồng tương tự, lúc này chúng ta cần xem xét thời gian triển khai hợp đồng, số lần tương tác, v.v., đây đều là những tiêu chí để đánh giá xem hợp đồng có an toàn hay không.
Hợp đồng có phải là hợp đồng đại diện không, có thể nâng cấp không, có khóa thời gian không: Nếu hợp đồng hoàn toàn không thể nâng cấp, thì quá cứng nhắc, vẫn khuyến nghị rằng hợp đồng của dự án có thể nâng cấp. Nhưng việc nâng cấp cần chú trọng phương pháp, khi nâng cấp có nội dung nâng cấp, thay đổi tham số quan trọng, cần có một khóa thời gian, cần cho mọi người một khoảng thời gian để đánh giá việc nâng cấp thực sự có hại hay có lợi cho người dùng, đây cũng là một hình thức công khai minh bạch.
Hợp đồng có được nhiều tổ chức kiểm toán chấp nhận không ( đừng mù quáng tin tưởng vào công ty kiểm toán ), Quyền hạn của Owner có quá lớn không: trước tiên đừng chỉ tin vào một công ty kiểm toán, vì các công ty kiểm toán khác nhau, các kiểm toán viên khác nhau, góc nhìn về vấn đề là khác nhau. Thứ hai, cần xem quyền hạn của Owner có quá lớn không. Quyền hạn của một Owner trong một dự án bình thường chắc chắn phải có thể kiểm soát được, như vậy sẽ không có quá nhiều thao tác nguy hiểm, và các thao tác cũng sẽ được thực hiện theo cách khóa thời gian, để người dùng biết thao tác là gì.
Chú ý đến oracle: Nếu dự án sử dụng oracle hàng đầu trên thị trường, thì hầu như sẽ không có vấn đề lớn, nhưng nếu sử dụng oracle tự xây dựng, hoặc oracle mà có thể gửi giá chỉ bằng cách thế chấp một số token tùy tiện, thì cần phải chú ý. Khi phát hiện oracle có thể tồn tại một số vấn đề, hoặc nói rằng có khả năng bị thao túng, thì ngay cả khi lợi nhuận của dự án cao đến đâu cũng không được tham gia.