Tài chính phi tập trung An toàn: 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ẻ nội dung liên quan đến an ninh DeFi, điểm lại các sự kiện an ninh quan trọng trong ngành Web3 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 này và cách để tránh, tổng kết các lỗ hổng an ninh phổ biến của hợp đồng thông minh và biện pháp phòng ngừa, đồng thời đưa ra một số lời khuyên về an ninh cho các dự án và người dùng.

Các loại lỗ hổng DeFi phổ biến thường có vay chớp nhoáng, thao túng giá, vấn đề quyền truy cập hàm, gọi ngoại tuyến tùy ý, vấn đề hàm fallback, lỗ hổng logic kinh doanh, rò rỉ chìa khóa riêng, tấn công tái nhập, v.v. Bài viết này sẽ tập trung vào ba loại vay chớp nhoáng, thao túng giá và tấn công tái nhập.

Cho vay chớp nhoáng

Vay chớp nhoáng bản thân là một sáng tạo trong Tài chính phi tập trung, nhưng khi bị hacker lợi dụng, họ không cần tốn bất kỳ chi phí nào để vay tiền, sau khi thực hiện toàn bộ quy trình chênh lệch giá rồi trả lại, phần còn lại chính là lợi nhuận từ chênh lệch giá, họ chỉ cần trả một khoản phí Gas nhỏ để có được lợi nhuận khổng lồ.

Các cuộc tấn công phổ biến thường đi kèm với cho vay chớp nhoáng, kẻ tấn công thích mượn một lượng lớn tiền thông qua cho vay chớp nhoáng, thao túng giá cả, tấn công logic kinh doanh, v.v. Các nhà phát triển cần xem xét liệu chức năng của hợp đồng có bị lỗi do lượng tiền khổng lồ hay thông qua lượng tiền khổng lồ trong một giao dịch để tương tác với nhiều hàm trong hợp đồng để nhận thưởng hay không.

Thường thấy một số giá trị số lượng Token trong hợp đồng được sử dụng để tính toán phần thưởng, hoặc là sử dụng số lượng Token trong cặp giao dịch DEX để tham gia vào nhiều tính toán khác nhau, vì các nhà phát triển khi thiết kế các tính năng này không xem xét đến việc kẻ tấn công có thể lợi dụng vay chớp nhoáng để thao túng các biến này, dẫn đến việc quỹ trong hợp đồng bị đánh cắp.

Trong hai năm qua, các khoản vay chớp nhoáng đã gặp rất nhiều vấn đề. Nhiều dự án Tài chính phi tập trung có vẻ mang lại lợi nhuận cao, nhưng thực tế trình độ của các bên dự án rất không đồng đều. Chẳng hạn, mã nguồn có thể được mua, ngay cả khi mã nguồn không có lỗ hổng, thì về mặt logic vẫn có thể tồn tại vấn đề. Ví dụ, đã từng gặp một dự án, sẽ phát thưởng theo 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 phần thưởng được phát ra, phần lớn phần thưởng đã chảy về tay kẻ tấn công. Hơn nữa, còn một số dự án tính giá thông qua Token, có thể bị ảnh hưởng giá cả bởi vay chớp nhoáng, vì vậy các bên dự án cầ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ó mối quan hệ chặt chẽ với vay chớp nhoáng, vấn đề này chủ yếu do một số tham số có thể được người dùng kiểm soát trong quá trình tính toán giá, có hai loại vấn đề thường gặp.

• Một cách là sử dụng dữ liệu của bên thứ ba khi tính giá, nhưng việc sử dụng không đúng cách hoặc thiếu kiểm tra dẫn đến giá cả bị thao túng một cách độc hại.
• Một loại khác là do sử dụng số lượng Token của một số địa chỉ làm biến số tính toán, trong khi số dư Token của những đị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 hiểm 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 mong đợi trên dữ liệu của bạn.

Do vì số dư của người dùng chỉ được đặt thành 0 vào cuối hàm, nên 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 tồn tại của việc gọi lại, 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 để thực hiện tấn công gọi lại. Vì vậy, khi giải quyết vấn đề gọi lại, chúng ta cần lưu ý những điểm sau:

1. Không chỉ ngăn chặn vấn đề tái nhập của một hàm đơn lẻ;
2. Tuân theo mô hình Checks-Effects-Interactions khi lập trình ;
3. 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à phải lặp lại việc tạo ra bánh xe, cần gì cũng tự viết, trong vòng này có rất nhiều thực hành an toàn tốt nhất, chúng ta chỉ cần áp dụng là đủ, hoàn toàn không cần phải lặp lại việc tạo ra bánh xe. Khi bạn tạo ra một bánh xe, nó chưa được xác minh đầy đủ, lúc này xác suất xảy ra sự cố rõ ràng cao hơn nhiều so với việc sử dụng một cái đã trưởng thành và được thử nghiệm qua thời gian.

Câu chuyện đằng sau lỗ hổng Omni Protocol --- Cuộc chiến giữa bốn hacker

Mempool của Ethereum luôn bị giám sát bởi một số lượng lớn hacker, họ liên tục phân tích các giao dịch và thực hiện các giao dịch chạy trước có lợi để kiếm lợi nhuận. Giao dịch tấn công được gửi bởi người phát hiện lỗ hổng Omni Protocol đã bị hai hacker bắt được, họ đã sử dụng bot chạy trước để thực hiện giao dịch chạy trước trên flashbot, chiếm đoạt 1200 ETH trong giao thức Omni Protocol, trong khi người phát hiện lỗ hổng lại chỉ nhận được 480 ETH. Trong thời gian này, còn có một hacker khác đã phát hiện ra giao dịch tấn công của hacker chạy trước được gửi trên flashbot, và đã thực hiện một cuộc tấn công sandwich bằng cách lợi dụng đặc điểm giao dịch tấn công cần mua token Doodle ERC20, thu lợi 151 ETH.

Những người phát hiện ra lỗ hổng không phải là người kiếm được nhiều lợi nhuận nhất, mà những người kiếm được nhiều hơn là những thợ săn khác trong khu rừng tối. Trong hệ sinh thái này có rất nhiều thợ săn, thợ săn có thể là con mồi của nhau, ngay cả khi là người khởi xướng tấn công, nếu là người mới, cũng có thể không lấy được phần lớn tiền của dự án, trừ khi rút một lần. Còn nhiều người sẽ sử dụng phí Gas cao hơn để thực hiện giao dịch trước, trong quá trình chạy đua, nếu liên quan đến việc mua bán token trong DEX, sẽ liên quan đến việc bị tấn công sandwich, rất hỗn loạn.

Đề xuất an toàn

Cuối cùng là những lời khuyên an toàn dành cho các nhà dự án và người dùng tham gia thông thường.

Mẹo an toàn cho dự án

Một, phát triển hợp đồng tuân thủ các thực hành an toàn tốt nhất.

Hai, hợp đồng có thể nâng cấp, tạm dừng: Nhiều cuộc tấn công không phải là một lần 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 hoàn chỉnh, thì có thể phát hiện ra. Khi phát hiện, giả định rằng 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ả.

Ba, áp dụng khóa thời gian: Giống như một số trường hợp, nếu có khóa thời gian, giả sử là trong vòng 48 giờ, 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 một phương pháp mint mới, và bất kỳ 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à họ có thể thông báo cho đội ngũ 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ị tổn 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 gặp phải vấn đề.

Bốn, tăng cường đầu tư vào an ninh, thiết lập một hệ thống an ninh hoàn chỉnh: An ninh không phải là một điểm, cũng không phải là một đường, an ninh phải có 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 là không có vấn đề gì, kết quả là hacker đã lấy trộm khóa riêng, ngay cả khi đó là ký quỹ đa chữ ký, lấy hết tất cả các khóa riêng. Hoặc là mô hình kinh tế có vấn đề, mô hình kinh doanh có vấn đề...... Có hàng triệu cách gây ra mất tiền, chỉ cần xem có thể tránh được tất cả các rủi ro an ninh trước khi xảy ra hay không. Cần cố gắng thực hiện mô hình rủi ro, sau đó dần dần loại bỏ phần lớn rủi ro, rủi ro còn lại cũng là rủi ro có thể chấp nhận được, trong phạm vi có thể chịu đựng. An ninh và hiệu suất không thể đồng thời đạt được, cần phải có sự đánh đổi nhất định. Nhưng nếu hoàn toàn không quan tâm đến an ninh, không đầu tư vào an ninh, thì việc bị tấn công là điều rất bình thường.

Năm, nâng cao nhận thức an ninh của tất cả nhân viên: Nâng cao nhận thức an ninh không cần nhiều kỹ thuật. Trên Twitter, chúng ta thường thấy nhiều người bị lừa đảo và mất NFT, thực ra cách lừa đảo là lợi dụng những điểm yếu của con người, chỉ cần chú ý một chút, sẽ không bị mắc bẫy. Trong môi trường Web3 rộng 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 đề.

Sáu, ngăn chặn các hành vi xấu bên trong, đồng thời nâng cao hiệu quả và tăng cường kiểm soát rủi ro: Hãy lấy một số trường hợp làm ví dụ. Thứ nhất, chủ sở hữu hợp đồng là một chữ ký đơn thay vì chữ ký đa, nếu mất chìa khóa riêng thì toàn bộ dự án sẽ bị kiểm soát; thứ hai, không sử dụng khóa thời gian, một số thao tác cập nhật quan trọng, ngay lập tức được cập nhật, không ai biết, điều này rất không công bằng đối với tất cả người tham gia vào giao thức; nữa là các hành vi xấu bên trong, cơ chế an ninh nội bộ không có tác dụng gì.

Các giao thức trên chuỗi có thể nâng cao tính an toàn trong khi đảm bảo hiệu quả như thế nào? Một số công cụ an toàn có thể chỉ định một người nào đó thực hiện một thao tác, chẳng hạn như ký nhiều chữ ký theo tỷ lệ ba phần năm; có thể chỉ định một địa chỉ nào đó thực hiện một thao tác cụ thể, chẳng hạn như giao cho một nút rất đáng tin cậy thực hiện giám sát rủi ro an toàn, giả sử phát hiện rằng giao thức đang bị tấn công, và tiền đang dần chuyển đến địa chỉ hacker, nếu hợp đồng này có chức năng tạm dừng, thì chúng ta sẽ trao quyền tạm dừng cho một người nào đó, và họ có thể thực hiện thao tác này.

Ví dụ như các nhà tạo lập thị trường cho DEX, nếu không hạn chế quyền hạn của Owner, thì Owner có thể chuyển tiền đến địa chỉ khác, có thể hạn chế địa chỉ chuyển coin, hạn chế chỉ được thao tác với một vài cặp coin, thiết lập chỉ được rút tiền đến một địa chỉ nào đó. Trong khi nâng cao hiệu suất, vẫn đảm bảo một mức độ an toàn nhất định.

Bảy, An toàn khi giới thiệu bên thứ ba: Là một phần của hệ sinh thái, các dự án đều có các đối tác trên và dưới. Về mặt an toàn, có một nguyên tắc là "mặc định tất cả các đối tác trên và dưới đều không an toàn". Dù là đối tác trên hay dưới, đều cần phải kiểm tra. Đối với bên thứ ba, chúng ta rất khó để kiểm soát, rủi ro an toàn thực sự rất lớn, vì vậy cần phải rất chú ý đến việc giới thiệu bên thứ ba. Hợp đồng là mã nguồn mở, có thể được giới thiệu và gọi; nếu hợp đồng không mở mã nguồn, thì tuyệt đối không được tham chiếu. Bởi vì chúng ta không biết logic bên trong là gì, hoặc việc giới thiệu hợp đồng này bản thân nó có thể là một hợp đồng có thể nâng cấp, sử dụng bình thường có thể không vấn đề gì, nhưng chúng ta không thể dự đoán liệu có một ngày nào đó nó sẽ được nâng cấp thành một hợp đồng xấu, điều này là không thể kiểm soát.

Người dùng/LP làm thế nào để xác định hợp đồng thông minh có an toàn hay không?

Đối với người dùng thông 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:

Một, hợp đồng có mã nguồn mở không: Tất cả các dự án không có hợp đồng mã nguồn mở, chúng tôi kiên quyết không chạm vào, vì chúng tôi không thể biết hợp đồng được viết ra như thế nào.

Hai, Owner có sử dụng ký đa không, ký đa có phi tập trung không: Nếu không sử dụng ký đa, chúng tôi không thể xác định logic và nội dung kinh doanh 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 gây ra hay không. Ngay cả khi sử dụng ký đa, cũng cần xác định xem ký đa có phải là phi tập trung hay không.

Ba, tình hình giao dịch của hợp đồng hiện có: Đặc biệt là trên thị trường có nhiều dự án lừa đảo bằng hình thức giả mạo, có thể tạo ra một hợp đồng khá giống nhau, 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.

Bốn, hợp đồng có phải là hợp đồng đại diện không, có thể nâng cấp không, có thời gian khóa 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ị hợp đồng của dự án có thể nâng cấp. Nhưng việc nâng cấp cần phải có phương pháp, khi có nội dung nâng cấp, thay đổi thông số quan trọng, cần phải có một thời gian khóa, cần cho mọi người một khoảng thời gian để đánh giá liệu 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 cách công khai và minh bạch.

Năm, Hợp đồng có được nhiều tổ chức kiểm toán chấp nhận không ( không nên 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, không chỉ nên tin tưởng 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. Nếu một dự án có kết quả kiểm toán từ nhiều tổ chức khác nhau, phát hiện ra các vấn đề khác nhau và bên dự án đã thực hiện sửa chữa, thì so với việc chỉ có một công ty kiểm toán, điều này an toàn hơn. Một bên dự án có trách nhiệm sẽ tìm nhiều tổ chức kiểm toán để thực hiện kiểm toán chéo.

Thứ hai, cần xem xét quyền hạn của Owner có quá lớn hay không. Ví dụ, có một số dự án貔恘盘, Owner có thể hoàn toàn kiểm soát tài sản của người dùng, nếu mua ít token có thể giao dịch bình thường, nhưng nếu số lượng mua token lớn, Owner ngay lập tức có thể kiểm soát và khóa lại, khiến không thể giao dịch. Cũng có một số dự án NFT tương tự. Quyền hạn của Owner trong một dự án bình thường phải được kiểm soát, như vậy sẽ không có quá nhiều thao tác nguy hiểm, và các thao tác 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ì. Đặc biệt là trong thời điểm thị trường không tốt, có rất nhiều loại dự án lừa đảo, vì vậy mọi người cần đặc biệt chú ý đến quyền hạn của Owner.

Sáu, lưu ý đến oracle: Nếu dự án sử dụng oracle hàng đầu trên thị trường, cơ bản sẽ không có vấn đề lớn, nhưng nếu sử dụng oracle tự xây dựng, hoặc chỉ cần thế chấp một số token một cách ngẫu nhiên thì có thể gặp rủi ro.