Tiêu Đề Gốc: Làm Thế Nào Để Ngừng Mất Tiền Trong Các Vụ Hack DeFi
Tác Giả Gốc: sysls, openforage
Dịch Gốc: AididiaoJP, Foresight News
Sau khi nghiên cứu về nhiều vụ tấn công hack lớn trên DeFi, tôi bắt đầu sợ hãi về "Thể Độ Hành Động Quốc Gia". Họ vô cùng thành thạo về công nghệ, giàu có về tài nguyên, và đang tham gia một trò chơi rất dài hơi; những siêu phản diện này tập trung vào việc kiểm tra từng góc của giao thức và cơ sở hạ tầng của bạn để tìm lỗ hổng, trong khi sự chú ý của các nhóm giao thức thông thường lại phân tán vào sáu bảy hướng kinh doanh khác nhau.
Tôi không tự nhận mình là một chuyên gia bảo mật, nhưng tôi đã từng lãnh đạo các nhóm trong môi trường cao rủi ro (bao gồm quân đội và lĩnh vực tài chính với số vốn lớn), có kinh nghiệm trong việc suy nghĩ và lập kế hoạch dự phòng.
Tôi tin tưởng rằng, chỉ có những người hoang tưởng mới sống sót được. Không có nhóm nào bắt đầu với tư duy "Tôi sẽ trông nom cho an toàn một cách không cẩn thận, vừa lòng"; tuy nhiên, các vụ tấn công hack vẫn diễn ra. Chúng ta cần làm tốt hơn.

(Nguồn dữ liệu: https://defillama.com/hacks)
Vụ tấn công hack không phải là hiếm, nhưng tần suất đã rõ ràng tăng lên. Quý I năm 2026 đã ghi nhận số lượng vụ tấn công hack DeFi cao nhất từ trước đến nay, trong khi Quý II vẫn mới chỉ bắt đầu nhưng đã có triển vọng phá kỷ lục của Quý trước.
Điều này nên thay đổi hoàn toàn cách chúng ta suy nghĩ và đối phó với vụ tấn công hack. Những giao thức cũ đến từ những người đã quen với biện pháp an ninh trước khi AI trở nên mạnh mẽ, đang ngày càng đối diện với nguy cơ bị "giết chết" trong khoảnh khắc.

(Nguồn dữ liệu: https://defillama.com/hacks)

Diện tích bề mặt của cuộc tấn công Hacker thực sự có thể rút gọn xuống ba mảng chính: nhóm giao thức, hợp đồng thông minh và cơ sở hạ tầng, ranh giới tin cậy của người dùng (DSN, truyền thông xã hội, v.v.).
Sau khi xác định các bề mặt này, hãy chồng thêm lớp phòng thủ:
· Phòng ngừa: Nếu thực hiện nghiêm ngặt, có thể giảm thiểu khả năng bị lợi dụng của quy trình.
· Giảm thiểu: Khi phòng ngừa thất bại, hạn chế mức độ tổn thất.
· Tạm dừng: Không ai có thể đưa ra quyết định tốt nhất dưới áp lực lớn. Khi xác nhận cuộc tấn công, kích hoạt ngay công tắc giết tất cả. Đóng băng có thể ngăn chặn thêm tổn thất và tạo ra không gian suy nghĩ...
· Hồi phục: Nếu bạn mất kiểm soát đối với các thành phần độc hại hoặc bị xâm nhập, hãy từ bỏ và thay thế chúng.
· Khôi phục: Hồi phục những gì bạn đã mất. Lập kế hoạch trước với các đối tác tổ chức có thể đóng băng tài khoản, hủy giao dịch và hỗ trợ điều tra.
Các nguyên tắc này hướng dẫn chúng ta thực hiện các hành động cụ thể tại mỗi lớp phòng thủ.
Sử dụng rộng lớn mô hình AI tiên tiến để quét kho lưu trữ mã nguồn và cấu hình của bạn, tìm kiếm lỗ hổng và thực hiện kiểm thử đỏ trên diện rộng: Thử tìm lỗ hổng ở phía giao diện, xem xét xem chúng có thể tiếp cận phía sau hay không. Kẻ tấn công sẽ làm điều đó. Những gì bạn có thể phát hiện thông qua quét phòng thủ, họ đã phát hiện thời gian trước qua việc quét tấn công của họ.
Sử dụng kỹ năng pashov, nemesis, cùng với các nền tảng AI như Cantina (Apex) và Zellic (V12), để nhanh chóng quét mã nguồn trước khi nộp bản kiểm toán đầy đủ.
Thêm quy trình đa bước và khóa thời gian vào bất kỳ hoạt động nào có thể gây hại. Bạn cần đủ thời gian để can thiệp và đóng băng khi phát hiện bất thường.
Lý do trước đây chống lại khóa thời gian và cài đặt đa bước là vì sẽ gây ma sát cho nhóm giao thức. Bây giờ bạn không cần phải lo lắng quá nhiều vì AI có thể dễ dàng bỏ qua những ma sát này.
Hợp đồng thông minh có thể được xây dựng phòng thủ bằng cách viết ra "sự thật" không thể thay đổi: Nếu những sự thật này bị phá vỡ, toàn bộ logic giao thức sẽ sụp đổ.
Bạn thường chỉ có một số ít sự thật không thể thay đổi. Hãy cẩn thận khi nâng cao chúng lên mức độ mã nguồn; buộc các sự thật không thể thay đổi ở mức tường lớp mỗi hàm làm cho việc quản lý của chúng trở nên khó khăn.
Nhiều cuộc tấn công từ hacker bắt nguồn từ ví đã bị tấn công. Bạn cần có cấu hình như vậy: ngay cả khi multisig bị tấn công, bạn vẫn có thể nhanh chóng kiềm chế thiệt hại và đưa giao thức trở lại trạng thái có thể quyết định của quản trị.
Điều này đòi hỏi sự cân đối giữa quản trị (quyết định tất cả) và cứu trợ (khôi phục khả năng ổn định của quản trị, nhưng không thể thay thế hoặc lật đổ quản trị chính mình).
Bắt đầu với giả định: bất kể bạn thông minh đến đâu, bạn vẫn sẽ bị hack. Hợp đồng thông minh hoặc phụ thuộc của bạn có thể bị lỗi. Bạn có thể bị tấn công xã hội, cập nhật mới có thể mang lại lỗ hổng mà bạn không dự đoán được.
Khi bạn đã suy nghĩ như vậy, việc giới hạn tốc độ thiệt hại và máy cắt nguồn cho giao thức sẽ trở thành người bạn tốt nhất của bạn. Hãy giữ thiệt hại dưới 5-10%, sau đó đóng băng, sau đó lập kế hoạch cho phản ứng của bạn. Không ai có thể ra quyết định tốt nhất trong cơn bão đạn nổ.
Hãy suy nghĩ về kế hoạch phản ứng của bạn trước khi bị hack. Hãy mã hóa quy trình càng nhiều càng tốt và tập luyện cùng nhóm của bạn, điều này giúp bạn không bối rối khi xảy ra cuộc tấn công. Trong thời đại AI, điều này có nghĩa là có khả năng trình bày thông tin một cách nhanh chóng nhất có thể và chia sẻ bản tóm tắt và dài cho vòng tròn cốt lõi của bạn.
Bạn không cần phải hoàn hảo, nhưng bạn phải sống sót. Không có hệ thống nào từ ngày đầu tiên đã không thể phá hủy; qua nhiều lần lặp, bạn sẽ trở nên chống lại sự dễ vỡ.
Không có bằng chứng về việc bị hack không có nghĩa là bạn sẽ không bị hack. Điểm thoải mái nhất thường là điểm nguy hiểm nhất.
Sau khi xác định các điều không thay đổi, hãy nâng chúng lên thành kiểm tra thời gian chạy. Hãy cân nhắc xem những điều không thay đổi nào thực sự đáng giá để bắt buộc thực thi.
Đó chính là mẫu FREI-PI (Yêu Cầu Chức Năng, Hiệu Ứng, Tương Tác, Khẳng Định Giao Thức): Tại cuối mỗi hàm tiếp xúc giá trị, hãy xác minh lại các khái niệm không thay đổi mà hàm đó cam kết duy trì. Nhiều cuộc tấn công khô máu thông qua CEI (Kiểm Tra-Hiệu Ứng-Tương Tác) (ví dụ: tấn công sáng-chiều-tối với Flash Loan, buổi chiều với số phẩy tư vấn-vay, tách chức năng Cross) có thể bị bắt bởi kiểm tra không thay đổi khi hàm kết thúc.
Thử nghiệm mù mờ có trạng thái (Stateful fuzzing) sẽ tạo ra một chuỗi gọi ngẫu nhiên đối với toàn bộ bề mặt công khai của giao thức và kiểm tra tính không thay đổi tại mỗi bước. Hầu hết các lỗ hổng trong môi trường sản xuất đều liên quan đến nhiều giao dịch, thử nghiệm mù mờ có trạng thái gần như là phương pháp đáng tin cậy duy nhất để khám phá những con đường này trước kẻ tấn công.
Sử dụng kiểm tra tính không thay đổi để khẳng định rằng thuộc tính vẫn đúng trong tất cả các chuỗi gọi mà máy mù mờ có thể tạo ra. Kết hợp với xác minh hình thức, nó có thể chứng minh rằng thuộc tính vẫn đúng trong tất cả các trạng thái mà có thể đạt được. Invariant của bạn nhất định nên được xử lý theo cách này.
Sự phức tạp là kẻ thù của bảo mật. Mỗi phụ thuộc bên ngoài đều mở rộng bề mặt tấn công. Nếu bạn đang thiết kế nguyên tắc cơ bản, hãy đưa quyền lựa chọn tin tưởng vào ai và tin tưởng vào gì cho người dùng. Nếu không thể loại bỏ phụ thuộc, hãy đa dạng hóa chúng để không có điểm lỗi đơn nhất có thể phá hủy giao thức của bạn.
Mở rộng phạm vi kiểm toán để bao gồm cách mà Oracle và Phụ thuộc có thể thất bại và áp dụng giới hạn tốc độ vào hậu quả của việc chúng thất bại.
Lỗ hổng gần đây của KelpDAO là một ví dụ: họ kế thừa cấu hình requiredDVNCount=1 mặc định của LayerZero, mà cấu hình này nằm ngoài phạm vi kiểm toán của họ. Cuối cùng, cái bị tấn công là cơ sở hạ tầng chuỗi ngoại đồi nằm ngoài phạm vi kiểm toán.
Hầu hết các tấn công bề mặt trong DeFi đã được liệt kê. Kiểm tra từng loại, hỏi xem nó có áp dụng cho giao thức của bạn không, sau đó triển khai kiểm soát dành cho vector tấn công đó. Phát triển kỹ năng đội đỏ, để cho AI của bạn tự động tìm kiếm lỗ hổng trong giao thức của bạn; điều này đã trở thành yêu cầu cơ bản hiện nay.
Trong quản trị dựa trên bỏ phiếu, quyền lực ban đầu tập trung trong ví nhiều ký hiệu của nhóm và cần thời gian để lan truyền. Ngay cả khi phân phối token rộng rãi, việc ủy quyền thường tập trung quyền lực vào vài ví (đôi khi thậm chí chỉ là n=1). Khi những ví này bị tấn công, trò chơi kết thúc.
Triển khai "Ví Bảo Vệ", ban hành cho họ quyền lực hẹp chặt: họ chỉ có thể tạm dừng giao thức và ở ngưỡng>=4/7, họ có thể xoay chuyển ủy quyền bị tổn thương sang ví thay thế được xác định trước. Ví Bảo Vệ không bao giờ được thực hiện đề xuất quản trị.
Do đó, bạn có một tầng cứu trợ luôn có thể khôi phục tính ổn định có thể quản trị mà không có quyền lực lật đổ quản trị. Tần suất xảy ra tình huống xấu nhất mất>=4/7 Ví Bảo vệ rất thấp (xem xét tính đa dạng của chủ sở hữu), và khi quản trị đã trưởng thành và phân tán, tầng này có thể dần dần bị loại bỏ.
Ví đa chữ ký là yêu cầu cơ bản, tối thiểu là 4/7. Không có cá nhân nào kiểm soát tất cả 7 chìa khóa. Thay đổi người ký xác nhận thường xuyên, và phải thực hiện một cách im lặng.
Chìa khóa không bao giờ nên tương tác với thiết bị sử dụng hàng ngày. Nếu bạn sử dụng thiết bị ký xác nhận để duyệt web, gửi/nhận email hoặc mở Slack, hãy coi như người ký đó đã bị xâm nhập.
Sở hữu nhiều ví đa chữ ký, mỗi cái có một mục đích khác nhau. Đặt ra giả định rằng ít nhất một ví đa chữ ký đầy đủ sẽ bị xâm nhập và lập kế hoạch từ đó. Không ai nên có quyền kiểm soát đủ lớn để phá hủy giao thức, ngay cả trong tình huống cực kỳ (bắt cóc, tra tấn, v.v.).
Nếu bạn có tài nguyên, đặt một phần thưởng lỗi cao so với TVL của giao thức là rất đáng giá; thậm chí nếu bạn là một giao thức tương đối nhỏ, phần thưởng lỗi cũng nên rất hào phóng (ví dụ tối thiểu 7-8 chữ số).
Nếu bạn đối mặt với cuộc tấn công từ một tổ chức quốc gia, họ có thể không thương lượng, nhưng bạn vẫn có thể tham gia kế hoạch "Harbor An Ninh White Hat", ủy quyền cho các chuyên gia bảo mật White Hat đại diện cho bạn để bảo vệ tài chính, và nhận một phần trăm cố định của số tiền lỗi như phí (thực tế là phần thưởng được trả bởi người gửi tiền).
Trước đây, tôi đã viết rằng, khi các mô hình ngôn ngữ lớn trở nên thông minh hơn, giá trị biên của việc thuê kiểm toán viên sẽ giảm đi. Tôi vẫn kiên định quan điểm này, nhưng quan điểm của tôi đã thay đổi một chút.
Đầu tiên, một kiểm toán viên tốt sẽ đi trước về dòng. Nếu bạn đang làm một số điều mới lạ, mã của bạn và các lỗ hổng của nó có thể không có trong dữ liệu huấn luyện, việc tăng số lượng Token mà không có bằng chứng cụ thể về việc phát hiện lỗ hổng mới hiệu quả chưa được chứng minh. Bạn không muốn trở thành điểm mẫu đầu tiên cho một lỗ hổng độc đáo.
Thứ hai, một lợi ích bị đánh giá thấp là: Thuê kiểm toán viên là sự cam kết của họ bằng danh tiếng. Nếu họ ký duyệt và bạn bị tấn công, họ sẽ được khích lệ mạnh mẽ để giúp đỡ. Xây dựng mối quan hệ với những người chuyên nghiệp về an ninh cũng là một ưu điểm lớn.
Hãy coi việc bảo mật hoạt động như một chỉ số thành công. Thực hiện cuộc tập kết câu lạc bộ câu cá; thuê một đội Red Team (đáng tin cậy) thử tấn công kỹ thuật xã hội vào nhóm của bạn. Chuẩn bị ví dự phòng và thiết bị, để có thể thay thế toàn bộ ví đa chữ ký khi cần thiết. Bạn không muốn phải mua những thứ này vào phút cuối.
Bất kỳ sự cố với giá trị xuất khỏi tuyến đường của giao thức đều có một giới hạn tối đa, đó là tổn thất lý thuyết tối đa khi tuyến đường đó bị lợi dụng lỗ hổng. Nói một cách đơn giản: không có giới hạn theo từng khối với hàm đúc tiền, đó chính là mở một tờ séc trắng cho bất kỳ lỗ hổng đúc tiền vô hạn nào. Không có giới hạn tuần lĩnh với hàm đền bù, đó chính là mở một tờ séc trắng cho bất kỳ lỗ hổng còn dư số dư tài sản nào.
Hãy cân nhắc một giá trị cụ thể cho tuyến đường ra của bạn. Con số này cần cân bằng giữa tổn thất tối đa mà bạn chấp nhận được và nhu cầu UX cực đoan nhất của người dùng. Nếu có sự cố xảy ra, đây chính là điều có thể giúp bạn tránh khỏi việc bị tàn phá hoàn toàn.
Hầu hết các giao thức đều có một danh sách có thể gọi, giao dịch hoặc nhận được, cũng như một danh sách mà người dùng tuyệt đối không thể làm. Ngay cả khi nó mặc định, đây đều là biên giới tin cậy và nên được hợp lý hóa.
Việc hợp lý hóa nó giúp bạn có thể thiết lập một setter theo hai giai đoạn, tạo ra sự trì trệ có ý nghĩa. Kẻ tấn công sẽ cần phải được thêm vào danh sách trắng (và/hoặc loại bỏ khỏi danh sách đen) trước khi họ có thể hành động. Đồng thời sở hữu cả hai nghĩa là kẻ tấn công cần phá vỡ cùng một lúc cả hai quy trình: thị trường phải được cho phép (tích hợp/listing), và hành động đó không thể bị cấm (kiểm tra an ninh).
Nếu không có ai theo dõi, công tắc giết chết sẽ không có tác dụng. Người theo dõi ngoại tuyến nên tiếp tục theo dõi những không thay đổi, và nếu có vấn đề xảy ra, họ sẽ cập nhật cảnh báo theo cách tự động. Cuối cùng, con đường phải dẫn đến tay con người của người bảo vệ nhiều chữ kí, và cung cấp đủ bối cảnh để họ có thể ra quyết định trong vài phút.
Nếu bạn bị tấn công, bạn cần ngừng chảy máu trước tiên, chứ không phải làm quyết định trong thời gian đếm ngược. Đối với giao thức, đó chính là nút giết chết (cũng cần phải được thể hiện trên giao diện người dùng): một nút bấm có thể tạm dừng tất cả các tuyến đường chuyển giá trong một giao dịch. Chuẩn bị một tập lệnh phụ "tạm dừng tất cả", liệt kê tất cả các thành phần có thể tạm dừng và tạm dừng chúng một cách nguyên tử.
Chỉ có quản trị có thể gỡ bỏ tạm dừng, vì vậy công tắc giết chết không thể tạm dừng chính sách quản trị chính trị. Nếu tầng bảo vệ có thể tạm dừng hợp đồng quản trị, tầng bảo vệ bị tấn công có thể đóng kín quá trình phục hồi mãi mãi.
Đóng băng, ngừng chảy máu, sau đó kêu gọi tất cả mọi người mà bạn tin tưởng (một nhóm nhỏ, đã thống nhất trước) vào một kênh giao tiếp. Bạn muốn nhóm của mình nhỏ để tránh rò rỉ thông tin cho kẻ tấn công, công chúng hoặc người tham gia khai thác với ý định xấu.
Thực hiện vai trò mà nhóm của bạn cần: một người ra quyết định; một nhà thực hiện kỹ thuật thực thi tập lệnh phòng thủ và tạm dừng; một người sửa lỗi và xác định nguyên nhân căn bản; một người liên lạc với các bên quan trọng; một người ghi nhận quan sát, sự kiện và dòng thời gian quyết định.
Khi mọi người đều biết vai trò của mình và đã được diễn tập, bạn sẽ có thể phản ứng theo quy trình, không bối rối trong thời điểm tồi tệ nhất.
Giả sử kẻ tấn công của bạn rất tinh ranh. Lỗ hổng đầu tiên có thể là mồi nhử, hoặc là hạt giống để tấn công sau này. Cuộc tấn công có thể đang thúc đẩy bạn làm một điều hoàn toàn sai lầm, từ đó kích hoạt lỗ hổng thực sự.
Tạm dừng phải trải qua quá trình nghiên cứu cẩn thận, hoàn toàn có thể kiểm soát và không thể bị lợi dụng. Tạm dừng nên là đóng băng toàn bộ giao thức: bạn không muốn bị dừng một phần của thành phần do bị gài mìn, mà lại mở cánh cửa cho phần khác. Khi bạn đã xác định nguyên nhân cốt lõi và vector tấn công, hãy khám phá bề mặt lộ liễu và hiệu ứng dây chuyền liên quan và sửa chữa toàn bộ cùng một lúc.
Chỉ khi biết trước người kế nhiệm, việc luân phiên mới an toàn. Tôi thích ý tưởng về đăng ký trước người kế nhiệm: nó làm cho việc thay thế một ví hoặc ví quản trị khỏe mạnh bằng một bị hack khó hơn đối với kẻ tấn công. Điều này liên quan đến ý tưởng "danh sách trắng / danh sách đen" trong biện pháp giảm thiểu.
Đăng ký một địa chỉ người kế nhiệm cho mỗi vai trò quan trọng. Nguyên tố luân phiên duy nhất mà tầng cấp bắt buộc thực hiện là "thay thế vai trò X bằng người kế nhiệm của nó". Điều này cũng cho phép bạn đánh giá người kế nhiệm trong thời gian bình yên: từ từ, kiểm tra kỹ lưỡng, bay đến và thăm người đề nghị.
Khi bạn đã xác định nguyên nhân cốt lõi và phạm vi ảnh hưởng, bạn cần phát hành bản cập nhật. Điều này có thể là mã nguồn nguy hiểm nhất bạn sẽ triển khai: được viết dưới áp lực, dành cho kẻ tấn công đã chứng minh rằng họ đủ hiểu biết về giao thức của bạn và đã tìm thấy lỗ hổng.
Trì hoãn việc phát hành mà chưa được kiểm tra kỹ lưỡng. Nếu không có thời gian để kiểm tra an toàn, hãy dựa vào mối quan hệ với người hacker tốt, hoặc thiết lập một cuộc đua 48 giờ trước triển khai để thu được một cuộc xem xét đối kháng mới tươi.
Tiền bị đánh cắp có thời gian bán rưỡi; một khi lỗ hổng được khai thác, chúng sẽ nhanh chóng vào hệ thống rửa tiền. Hãy chuẩn bị sẵn sàng dùng các nhà cung cấp phân tích chuỗi như Chainalysis để đánh dấu cụm địa chỉ của kẻ tấn công theo thời gian thực và thông báo cho các sàn giao dịch để đánh dấu và theo dõi khi chúng chuyển chuỗi.
Hãy chuẩn bị trước một danh sách các bộ phận tuân thủ trung tâm gồm bộ phận tuân thủ của sàn giao dịch tập trung, quản trị viên cầu nối liên chuỗi, quản trị viên bảo quản, và các bên thứ ba có quyền quản lý có thể đóng băng tin nhắn liên chuỗi hoặc danh sách tiền gửi đang chuyển theo dõi.
Đúng vậy, điều này rất đau lòng, nhưng bạn vẫn nên cố gắng nói chuyện với kẻ tấn công. Rất nhiều vấn đề trong cuộc sống có thể được giải quyết thông qua đàm phán. Đề xuất một khoản tiền thưởng White Hat có hạn chót và công bố rằng nếu toàn bộ số tiền được hoàn trả trước ngày đó, sẽ không có hành động pháp lý được thực hiện.
Nếu bạn đang đối mặt với một tổ chức quốc gia, bạn có thể gặp may không tốt, nhưng bạn có thể đang đối mặt với một kẻ tấn công không chuyên nghiệp, họ chỉ tìm ra cách sử dụng bạn và muốn thoát ra với chi phí thấp.
Trước khi làm điều đó, hãy chắc chắn có một luật sư tư vấn đồng hành.
Các cuộc tấn công của hacker sẽ không ngừng, khi AI trở nên thông minh hơn, các cuộc tấn công sẽ càng nhiều. Chỉ việc làm cho người phòng thủ trở nên "sắc bén hơn" là chưa đủ. Chúng ta cần sử dụng các công cụ giống như những gì kẻ tấn công sử dụng, thực hiện kiểm thử Red Team cho giao thức của chúng ta, theo dõi liên tục, và đặt ra hạn chế cứng rắn cho tổn thất, để chúng ta có thể sống sót trong tình huống tồi tệ nhất.
Liên kết Gốc
Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:
Nhóm Telegram đăng ký: https://t.me/theblockbeats
Nhóm Telegram thảo luận: https://t.me/BlockBeats_App
Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia