Câu chuyện 1
Dự án được audit bởi 5 công ty - xin nhắc lại 5 công ty bảo mật, quá uy tín.
Một ngày đẹp trời, dự án bị hack -> sập.
Hỏi ra mới biết dự án chỉ audit mỗi cái token contract.
Câu chuyện 2
Dự án Y cũng được audit bởi công ty A.
Một ngày nữa đẹp trời, dự án bị hack -> sập.
Hỏi ra mới biết dự án dùng gói free để audit (công ty A cung cấp nhiều gói), chỉ chạy tool, pass checklist là ra report đẹp đẽ.
Tại sao dự án bị hack?
Trên đây là 2 câu chuyện mình bịa ra, nhưng nội dung thì cũng đôi ba phần thực tế.
Trong thị trường blockchain, việc các ứng dụng bị hack nhiều như cơm bữa, thậm chí có thể hơn.
Có rất nhiều dự án, dù audit đến mấy lần cũng vẫn bị hack. Nguyên do tại đâu?
Đầu tiên ta cần hiểu được quy trình audit gồm có những cái gì (ở đây ta chủ yếu nói đến audit phần blockchain, tức audit smart contract):
- thông thường các bên sẽ có các gói dịch vụ khác nhau tùy vào số lượng contract & sự phức tạp của dự án & thời lượng support. Rẻ thì audit một contract duy nhất (thường là token contract), audit xong là hết nhiệm vụ. Đắt thì có audit toàn bộ dự án, ưu tiên được phục vụ audit trước, lifetime support, 1-1 peer review, cùng tham gia điều tra khắc phục lỗi cùng dự án. Mỗi dự án sẽ có 1 hoặc nhiều auditor (tùy khối lượng) phụ trách.
- khi start audit, phía dự án cần cung cấp source code của contract, và không được thay đổi source code đó nữa trong suốt quá trình audit
- phía dự án cần cung cấp các tài liệu mô tả business, luồng logic, hay video code walk through để auditor có thể hiểu được cách dự án mình chạy. Điều này là rất quan trọng, auditor cũng là người, cần đọc hiểu luồng hoạt động thì mới có những góc nhìn đúng để audit, mà để đọc hiểu code của người khác thì không chỉ cứ vứt cho họ một đống source code là được, mà cần phải có mô tả, walkthrough thì việc nắm bắt mới nhanh và đúng đắn.
- auditor ban đầu sẽ chạy các tool để auto audit: Slither, MythX, Manticore, Echidna, Surya… Các tool này sẽ check qua code với các checklist có sẵn, đưa ra pass hoặc cảnh báo đối với các nguy cơ.
- tiếp theo tiến hành manual audit dựa trên các security pattern: function logic (kiểm tra tính public, private, internal, external, input, output…) và business logic (cash flow, mint, burn…) và các lỗi có thể khác, trên các môi trường blackbox & whitebox. Chỗ nào auditor không hiểu thì hỏi lại dự án. Việc này đỏi hỏi auditor phải có kỹ năng sâu về ngôn ngữ lập trình smart contract, hiểu về các model/protocol trong dapp.
- xuất report lần đầu về các bug, lỗ hổng, mức độ ảnh hưởng và các recommendation để dự án sửa.
- phía dự án tiếp nhận report, tiến hành fix & feedback (chỗ nào sửa, chỗ nào có thể coi là chấp nhận và bỏ qua được vì impact quá thấp), sau đó gửi lại version mới
- quá trình audit lần 2 & các lần sau tương tự.
- đến lần n khi dự án & auditor thống nhất về sự an toàn của contracts rồi thì report cuối cùng sẽ được tạo. Đây là report sẽ được public trên web của bên dịch vụ audit và trên web của dự án, cũng như trên etherscan/bscscan…
Các quá trình đều là sự tham gia của con người, mà con người thì dễ mắc lỗi, nên ta hiểu rằng audit chỉ có thể làm giảm thiểu nguy cơ bị tấn công, chứ không thể đảm bảo cho dự án an toàn 100% được. Câu hỏi “dự án audit rồi, tại sao vẫn bị hack?” có thể có nhiều câu trả lời:
- Phần code bị hack là phần không được audit. Case này hay gặp nhất. Để cho nhanh và rẻ, rất nhiều dự án chỉ audit một phần - thường là audit token contract để lấy certificate/report bỏ lên trang chủ là xong. Sau đó đến phase làm sản phẩm thì không tiến hành audit contract hay business logic của sản phẩm nữa.
- Dự án dùng version khác với version đã audit. Việc audit thường chỉ diễn ra trên một version code, nhưng khi chạy thực tế thì dev lại thấy thiếu thiếu nên code thêm một ít vào. Kết quả toang.
- Dự án dùng các gói audit free, chỉ chạy tool mà không có review từ auditor uy tín.
- Sự phức tạp của dự án nằm ngoài khả năng của auditor: Audit các contract đơn lẻ không hề khó, nhưng audit business logic của một dự án thì rất khó. Việc đọc hiểu code mất rất nhiều thời gian, đặc biệt với các dự án phức tạp, việc dựng blackbox & whitebox để test cũng như vậy. Nên việc auditor không bao quát được hết các case, hoặc bỏ qua những phần code mình chưa/không hiểu là điều dễ xảy ra. Và nó có thể gây lỗi. Hãy tưởng tượng bạn là một auditor, dự án bạn đang audit cần phải đọc 10 paper, 30 trang mỗi cái với chi chít công thức toán học trong 2 tuần, bạn sẽ làm gì?
- Các pattern tấn công chưa được biết: Trước khi the DAO hack thì đâu ai để ý đến re-entrancy, trước khi các sàn DEX trở nên phổ biến thì đâu có ai tấn công onchain oracle manipulation, sẽ luôn luôn có những case nằm ngoài tầm hiểu biết của dev, auditor và cả giới chuyên môn. Càng ngày người ta càng gặp nhiều kiểu tấn công hơn, và tổng hợp chúng lại thành những best pratice để các dev lưu ý. Ví dụ:
https://consensys.github.io/smart-contract-best-practices/attacks/
- Dự án bị lộ key. Case này thì chịu.
Câu chuyện làm thế nào để tránh bị hack thì là một câu chuyện tổng quát nói chung, nhưng nói riêng với audit blockchain, thì một dự án được fully audit đúng nghĩa là dự án được audit toàn bộ từ contract cho tới business logic, thậm chí cả frontend, backend, mỗi lần update đều phải pass qua toàn bộ test, và audit lại nếu cần; được thực hiện bởi các bên uy tín.
Còn nếu chỉ audit token, thì có thể coi như có cũng như không, việc audit chỉ mang tính chất minh họa.
Ngoài ra chạy các chương trình bug bounty với high return cũng là một lựa chọn để nâng cao bảo mật ngoài việc audit: https://immunefi.com/
nói thế chứ, dự án thì cần ra sớm, còn update liên tục, mà audit thì mất công, lại còn phải audit đi audit lại mỗi lần update nữa, ai chả biết là phải làm, nhưng lấy đâu ra tiền & công sức để làm thì chủ thớt lại không nói!