Xem thêm:《Vượt qua lớp 0: Tại sao bảo mật biệt lập không phải là bảo mật》
Tác giả: Krzysztof Urbański, thành viên nhóm L2BEAT
Biên soạn bởi: Babywhale, Foresight News
L2BEAT đã đầu tư nỗ lực đáng kể kể từ khi thành lập để phân tích và hiểu các rủi ro liên quan đến giao thức Lớp 2. Chúng tôi luôn hành động vì lợi ích tốt nhất của người dùng và hệ sinh thái của mình, đồng thời cố gắng hết sức để trở thành người giám sát độc lập, khách quan mà không để sở thích cá nhân của chúng tôi đối với các dự án hoặc nhóm liên quan ảnh hưởng đến thực tế. Đó là lý do tại sao, mặc dù chúng tôi tôn trọng thời gian và công sức mà nhóm dự án bỏ ra cho dự án, nhưng chúng tôi vẫn có thể “đánh tiếng báo động” hoặc chỉ ra mối lo ngại của mình về những rủi ro tiềm ẩn của một số giao thức nhất định. Việc sớm thảo luận liên quan đến bảo mật cho phép toàn bộ hệ sinh thái được chuẩn bị tốt hơn cho các rủi ro tiềm ẩn và phản ứng sớm hơn với mọi hành vi đáng ngờ.
Hôm nay chúng tôi muốn thảo luận về mô hình bảo mật chung cho các ứng dụng chuỗi chéo. Hiện tại có hai mô hình bảo mật: bảo mật chia sẻ và bảo mật ứng dụng độc lập. Bảo mật được chia sẻ giống như tất cả các Bản tổng hợp. Bảo mật ứng dụng độc lập chủ yếu được sử dụng bởi các dự án "omnichain", chủ yếu sử dụng LayerZero.
Bảo mật được chia sẻ so với bảo mật độc lập
Bảo mật được chia sẻ đề cập đến một mã thông báo hoặc ứng dụng cụ thể chạy trên cơ sở hạ tầng nhất định và thay vì tự do lựa chọn mô hình bảo mật, chúng phải tuân thủ mọi yêu cầu bảo mật do cơ sở hạ tầng áp đặt. Ví dụ: Bản tổng hợp lạc quan thường áp đặt thời hạn cuối cùng là 7 ngày—một ứng dụng chạy trên các Bản tổng hợp như vậy không thể đơn giản bỏ qua hoặc rút ngắn khoảng thời gian này. Mặc dù điều này có vẻ như là một trở ngại nhưng vẫn có lý do cho nó. Khoảng thời gian này cung cấp cho người dùng những đảm bảo về bảo mật rằng bất kể chính sách bảo mật nội bộ của ứng dụng phải được tuân thủ như thế nào, ứng dụng chỉ có thể tăng cường tính bảo mật của Rollups chứ không làm suy yếu nó.
Bảo mật độc lập có nghĩa là mỗi ứng dụng chịu trách nhiệm xác định tính bảo mật của nó và không bị cơ sở hạ tầng hạn chế dưới bất kỳ hình thức nào. Ban đầu, đây có vẻ là một ý tưởng hay vì xét cho cùng, nhà phát triển ứng dụng biết rõ nhất những biện pháp bảo mật mà ứng dụng có thể cần. Nhưng đồng thời, nó chuyển trách nhiệm đánh giá rủi ro liên quan đến từng chính sách bảo mật ứng dụng sang người dùng cuối. Ngoài ra, nếu nhà phát triển ứng dụng có quyền tự do lựa chọn chính sách bảo mật của mình thì họ cũng có thể thay đổi chúng bất kỳ lúc nào. Do đó, việc đánh giá rủi ro một lần cho mỗi ứng dụng là chưa đủ; cần phải đánh giá mỗi khi chính sách của ứng dụng thay đổi.
Các vấn đề
Chúng tôi tin rằng một mô hình bảo mật độc lập trong đó mỗi ứng dụng được tự do xác định chính sách bảo mật của mình sẽ tạo ra các vấn đề bảo mật nghiêm trọng. Đầu tiên, nó làm tăng rủi ro cho người dùng cuối vì họ phải xác minh rủi ro cho từng ứng dụng họ định sử dụng.
Bảo mật độc lập cũng làm tăng rủi ro cho các ứng dụng sử dụng mô hình này, ví dụ như tăng thêm rủi ro liên quan đến thay đổi chính sách bảo mật - nếu kẻ tấn công thay đổi mô hình bảo mật của ứng dụng, họ cũng có thể vô hiệu hóa nó, do đó hết tiền hoặc gặp rủi ro trong bất kỳ cách nào. Tấn công theo những cách khác. Không có lớp bảo mật bổ sung nào trên ứng dụng để ngăn chặn các cuộc tấn công.
Ngoài ra, do các chính sách bảo mật có thể thay đổi bất cứ lúc nào và nhanh chóng nên gần như không thể giám sát các ứng dụng trong thời gian thực và thông báo cho người dùng về các rủi ro.
Chúng tôi nhận thấy nó tương tự như khả năng nâng cấp của hợp đồng thông minh mà chúng tôi đã cảnh báo trên L2BEAT. Chúng tôi thông báo cho người dùng về Rollup và cầu nối chuỗi chéo có cơ chế nâng cấp trong hợp đồng thông minh của họ và cơ chế chính xác để quản lý khả năng nâng cấp trong từng trường hợp. Điều này vốn đã khá phức tạp và việc sử dụng một mô hình bảo mật riêng biệt sẽ nhân số lượng lên gấp bội, khiến việc theo dõi một cách hiệu quả gần như không thể thực hiện được.
Đây là lý do tại sao chúng tôi coi mô hình bảo mật độc lập là một rủi ro bảo mật và chúng tôi cho rằng mọi ứng dụng sẽ sử dụng mô hình này theo mặc định sẽ được coi là rủi ro cho đến khi được chứng minh ngược lại.
Chứng minh rằng lỗ hổng bảo mật tồn tại
Chúng tôi quyết định thử nghiệm giả thuyết của mình trên mạng chính. Khung LayerZero đã được chọn để thử nghiệm vì đây là một trong những giải pháp tập trung vào bảo mật độc lập phổ biến nhất. Chúng tôi đã triển khai mã thông báo omnichain an toàn và sau đó đã cập nhật cấu hình bảo mật để cho phép rút mã thông báo có mục đích xấu. Mã cho mã thông báo dựa trên các ví dụ do LayerZero cung cấp và rất giống hoặc giống với nhiều mã thông báo và ứng dụng omnichain khác được triển khai trong đời thực.
Nhưng trước khi đi vào chi tiết, chúng ta hãy xem sơ qua mô hình bảo mật LayerZero trông như thế nào.
Như LayerZero đã chỉ ra trong sách trắng của mình, “giao tiếp liên chuỗi không đáng tin cậy” của nó dựa vào hai tác nhân độc lập (nhà tiên tri và người chuyển tiếp) hành động cùng nhau để đảm bảo tính bảo mật của giao thức.
LayerZero tuyên bố trên trang web của mình rằng khái niệm cốt lõi của nó là “các ứng dụng người dùng chạy ULN (UltraLightNode), các thiết bị đầu cuối trên chuỗi có thể định cấu hình”. Thành phần trên chuỗi của LayerZero dựa vào hai thành phần ngoài chuỗi bên ngoài để chuyển tiếp thông điệp giữa các chuỗi – oracle và rơle.
Bất cứ khi nào bất kỳ thông báo M nào được gửi từ chuỗi A đến chuỗi B, hai thao tác sau sẽ xảy ra:
Đầu tiên, oracle đợi cho đến khi hoàn thành giao dịch gửi tin nhắn M trên chuỗi A, sau đó ghi thông tin liên quan lên chuỗi B, chẳng hạn như giá trị băm của tiêu đề khối của chuỗi A chứa thông báo M (giá trị chính xác giữa các chuỗi/oracle khác nhau Định dạng có thể khác nhau).
Sau đó, rơle sẽ gửi một "bằng chứng" (chẳng hạn như Bằng chứng Merkle) đến chuỗi B, chứng minh rằng tiêu đề khối được lưu trữ có chứa thông báo M.
LayerZero giả định rằng rơle và oracle là những người tham gia độc lập, trung thực. Tuy nhiên, LayerZero cũng tuyên bố trong sách trắng rằng nếu giả định này không được đáp ứng, chẳng hạn như rơle và oracle thông đồng với nhau, dẫn đến "cả tiêu đề khối do oracle cung cấp và bằng chứng giao dịch do rơle cung cấp đều không hợp lệ, nhưng vẫn phù hợp."
LayerZero tuyên bố rằng "Thiết kế của LayerZero loại bỏ khả năng thông đồng." Nhưng trên thực tế, tuyên bố này không chính xác (chúng tôi chứng minh điều này trong các thử nghiệm hiển thị bên dưới), bởi vì mỗi ứng dụng người dùng có thể xác định rơle và oracle của riêng mình. LayerZero không đảm bảo về mặt thiết kế rằng các thành phần này độc lập và không thể thông đồng với nhau, thay vào đó, việc cung cấp những đảm bảo này là tùy thuộc vào ứng dụng người dùng. LayerZero không có cơ chế dừng ứng dụng nếu họ chọn phá vỡ chúng.
Ngoài ra, theo mặc định, tất cả các ứng dụng của người dùng có thể thay đổi rơle và oracle bất kỳ lúc nào, xác định lại hoàn toàn các giả định về bảo mật. Do đó, chỉ kiểm tra tính bảo mật của một ứng dụng nhất định một lần là không đủ vì nó có thể thay đổi bất kỳ lúc nào sau khi kiểm tra, như chúng tôi sẽ trình bày trong các thử nghiệm của mình.
thiết kế thử nghiệm
Đối với các thử nghiệm của mình, chúng tôi đã quyết định tạo một mã thông báo omnichain đơn giản, CarpetMoon, chạy trên cả Ethereum và Optimism, đồng thời sử dụng LayerZero để liên lạc giữa hai chuỗi.
Mã thông báo của chúng tôi ban đầu sử dụng mô hình bảo mật mặc định do LayerZero cung cấp, làm cho nó giống hệt với một ứng dụng LayerZero lớn (có lẽ không phải tất cả) hiện được triển khai. Do đó, nhìn chung nó an toàn như bất kỳ đồng tiền nào khác sử dụng LayerZero.
Đầu tiên, chúng tôi triển khai hợp đồng mã thông báo của mình trên Ethereum và Optimism:
https://ethtx.info/mainnet/0xf4d1cdabb6927c363bb30e7e65febad8b9c0f6f76f1984cd74c7f364e3ab7ca9/
https://optimistic.etherscan.io/tx/0xf41389d71fa3942de5225efb067072728c6c6de56c241574187781db7c73d221
Sau đó, chúng tôi thiết lập định tuyến để LayerZero biết hợp đồng nào tương ứng với hợp đồng nào trên cả hai chuỗi.
https://ethtx.info/mainnet/0x19d78abb03179969d6404a7bd503148b4ac14d711f503752495339c96a7776e9/
https://optimistic.etherscan.io/tx/0x037b1bad33faa5607bb5835460a1d5caaf3a147dc3a09762ac7703befcdb3c3c
Mã thông báo đã được triển khai và nó trông giống hệt như mọi mã thông báo omnichain khác sử dụng LayerZero, sử dụng cấu hình mặc định và không có gì đáng nghi về nó.
Chúng tôi đã cung cấp 1 tỷ token CarpetMoon trên Ethereum cho “người dùng thử nghiệm” Alice của chúng tôi.
https://ethtx.info/mainnet/0x7e2faa8426dacae92830efbf356ca2da760833eca28e652ff9261fc03042b313/
Bây giờ Alice sử dụng LayerZero để liên kết chéo các mã thông báo này thành Lạc quan.
Chúng tôi khóa mã thông báo trong hợp đồng ký quỹ trên Ethereum:
https://ethtx.info/mainnet/0xe4dc3757b86bfda8e7baddc088fb1a599e083ed77034c29e5dd8bd11f1e17771/。
Thông báo chứa giao dịch đang được chuyển tới Optimism qua LayerZero:
https://layerzeroscan.com/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/message/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7nonced10d/。
Mã thông báo chuỗi chéo đang được tạo ra trên Optimism và Alice hiện sở hữu 1 tỷ mã thông báo MoonCarpet trên Optimism:
https://optimistic.etherscan.io/tx/0x5388ced88cf562acafff82d6798f791b0b38b90ee106df9bf91c0d86306ec302。
Mọi thứ hoạt động như mong đợi, Alice xâu chuỗi chéo các mã thông báo và thấy rằng có 1 tỷ mã thông báo MoonCarpet trong hợp đồng ký quỹ trên Ethereum và 1 tỷ mã thông báo MoonCarpet trong tài khoản của cô tại Optimism. Nhưng để đảm bảo mọi thứ đều ổn, cô ấy đã chuyển một nửa số token của mình trở lại Ethereum.
Chúng tôi bắt đầu với một giao dịch trên Optimism đã đốt 500 triệu token:
https://optimistic.etherscan.io/tx/0x118a57106488ad0bae1f3b920b1fd98b187752ad966f3a901fc53cff47f2097f。
Thông tin về giao dịch được chuyển tới Ethereum:
https://layerzeroscan.com/111/address/0x201fe0d843b546f2e24d4c8444318d1c71b7d10d/message/101/address/0xc6005ccc1de4b300d538903b74848bff881d5dc5/nonce/1。
Đúng như dự kiến, 500 triệu token MoonCarpet được trả lại từ hợp đồng ký quỹ đến địa chỉ của Alice:
https://etherscan.io/tx/0x27702e07a65a9c6a7d1917222799ddb13bb3d05159d33bbeff2ca1ed414f6a18。
Cho đến nay, mọi thứ đều hoạt động tốt và chính xác như giả định. Alice đã kiểm tra rằng cô ấy có thể liên kết các token từ Ethereum sang Optimism và ngược lại, cô ấy không có lý do gì để lo lắng về token MoonCarpet của mình.
Nhưng các giả thuyết đều có vấn đề riêng của họ - ví dụ: nhóm đằng sau mã thông báo của chúng tôi gặp sự cố và kẻ xấu Bob giành được quyền truy cập vào cấu hình LayerZero của ứng dụng của chúng tôi.
Bằng cách này, Bob có thể thay đổi các oracle và chuyển tiếp từ các thành phần mặc định thành các thành phần mà anh ấy kiểm soát.
Cần lưu ý rằng đây là cơ chế được cung cấp cho mọi ứng dụng sử dụng LayerZero và bắt nguồn từ kiến trúc của LayerZero. Đây không phải là bất kỳ loại cửa hậu nào mà là một cơ chế tiêu chuẩn.
Vì vậy Bob thay đổi oracle thành EOA dưới sự kiểm soát của anh ấy:
https://ethtx.info/mainnet/0x4dc84726da6ca7d750eef3d33710b5f63bf73cbe03746f88dd8375c3f4672f2f/。
Bộ lặp cũng được thay đổi:
https://ethtx.info/mainnet/0xc1d7ba5032af2817e95ee943018393622bf54eb87e6ff414136f5f7c48c6d19a/。
Bây giờ có điều gì đó kỳ lạ xảy ra. Vì nhà tiên tri và rơle hiện nằm dưới sự kiểm soát hoàn toàn của Bob nên anh ta có thể đánh cắp mã thông báo của Alice. Mặc dù không có hành động nào được thực hiện đối với Optimism (mã thông báo MoonCarpet vẫn còn trong ví của Alice), Bob vẫn có thể thuyết phục hợp đồng thông minh MoonCarpet trên Ethereum (sử dụng cơ chế LayerZero) rằng anh ta đã phá hủy các mã thông báo trên chuỗi khác và anh ta có thể rút token trên token MoonCarpet trên Ethereum.
Đầu tiên, anh ấy cập nhật hàm băm khối của Ethereum bằng cách sử dụng oracle mà anh ấy kiểm soát:
https://ethtx.info/0xde2edee2cc7f070120e96c9df90d86696970befcfc221e18c6ac4168bb5b1d92/。
Bây giờ anh ta có thể rút số token còn lại khỏi hợp đồng ký quỹ:
https://ethtx.info/0xda695f374b375d5372efeca37aae4c5a17f114d5a76db1e86edebb0924bcdcc7/。
Kết quả thực nghiệm
Alice thậm chí còn không biết tại sao và khi nào lỗi xảy ra. Đột nhiên, token MoonCarpet của cô trên Optimism không còn được hỗ trợ bởi token trên Ethereum nữa.
Hợp đồng thông minh không thể nâng cấp và hoạt động như mong đợi. Hoạt động đáng ngờ duy nhất là các thay đổi về oracle và chuyển tiếp, nhưng đây là một cơ chế thông thường được tích hợp trong LayerZero, vì vậy Alice thậm chí không biết liệu thay đổi này có phải là cố ý hay không. Ngay cả khi Alice biết về sự thay đổi thì đã quá muộn - kẻ tấn công có thể rút hết tiền trước khi cô kịp phản ứng.
LayerZero không thể làm gì - đây đều là những cách triển khai hiệu quả các cơ chế của họ mà họ không có quyền kiểm soát. Về lý thuyết, bản thân các ứng dụng có thể ngăn chúng thay đổi oracle và rơle, nhưng theo hiểu biết của chúng tôi, chưa có ứng dụng nào được triển khai làm như vậy.
Chúng tôi thực hiện thí nghiệm này để kiểm tra xem có ai để ý đến nó không, nhưng đúng như chúng tôi mong đợi, không ai để ý cả. Gần như không thể giám sát hiệu quả tất cả các ứng dụng được xây dựng bằng LayerZero để kiểm tra xem chính sách bảo mật của chúng có thay đổi hay không và cảnh báo cho người dùng khi điều này xảy ra.
Ngay cả khi ai đó có thể kịp thời phát hiện ra rằng các oracle và rơle đã thay đổi và tạo ra rủi ro bảo mật thì cũng đã quá muộn. Vì các oracle và rơle mới hiện có thể tự do lựa chọn thông điệp nào sẽ gửi hoặc đơn giản là vô hiệu hóa giao tiếp giữa các chuỗi, nên nhìn chung người dùng không thể làm gì nhiều về vấn đề này. Các thử nghiệm của chúng tôi cho thấy rõ ràng rằng ngay cả khi Alice nhận thấy sự thay đổi cấu hình ứng dụng, cô ấy cũng không thể làm được gì nhiều với các mã thông báo chuỗi chéo của mình - các oracle và rơle mới không còn được chấp nhận trên tin nhắn chuỗi liên lạc ban đầu, vì vậy tin nhắn sẽ không được trả lại Ethereum .
Tóm lại là
Như chúng ta có thể thấy, mặc dù mã thông báo của chúng tôi được xây dựng bằng LayerZero và sử dụng cơ chế của nó như dự định, nhưng chúng tôi vẫn có thể lấy cắp tiền từ ký quỹ của mã thông báo. Tất nhiên, đây là lỗi của ứng dụng (trong trường hợp của chúng tôi là mã thông báo CarpetMoon) chứ không phải của chính LayerZero, nhưng nó chứng tỏ rằng bản thân LayerZero không cung cấp bất kỳ đảm bảo bảo mật nào.
Khi LayerZero mô tả mô hình bảo mật của họ liên quan đến các oracle và bộ chuyển tiếp, họ cho rằng chủ sở hữu ứng dụng (hoặc bất kỳ ai có khóa riêng) sẽ không làm bất cứ điều gì vô lý. Nhưng trong một môi trường đối nghịch, giả định này là không chính xác. Ngoài ra, nó yêu cầu người dùng tin tưởng nhà phát triển ứng dụng với tư cách là bên thứ ba đáng tin cậy.
Vì vậy, trong thực tế, người ta không thể đưa ra bất kỳ giả định nào về tính bảo mật của các ứng dụng được xây dựng bằng LayerZero - mọi ứng dụng đều phải được coi là rủi ro cho đến khi được chứng minh ngược lại.
Trên thực tế, toàn bộ câu chuyện bắt đầu bằng một hoạt động PR mà chúng tôi dự định đưa tất cả các token omnichain vào trang web L2BEAT - chúng tôi đang gặp khó khăn trong việc tìm ra cách đánh giá rủi ro của chúng. Khi phân tích rủi ro, chúng tôi nảy ra ý tưởng thử nghiệm.
Nếu L2BEAT hoạt động, hậu quả là chúng tôi sẽ phải đặt cảnh báo trên mọi ứng dụng được xây dựng bằng LayerZero để cảnh báo về các rủi ro bảo mật có thể xảy ra. Nhưng chúng tôi muốn có một cuộc thảo luận rộng hơn về các mô hình bảo mật vì chúng tôi tin rằng bảo mật độc lập là mô hình nên tránh, đặc biệt là trong lĩnh vực của chúng tôi.
Chúng tôi tin rằng khi các mô hình bảo mật độc lập như LayerZero trở nên phổ biến hơn thì ngày càng có nhiều dự án sẽ lạm dụng chúng, gây ra thiệt hại lớn và làm tăng sự bất ổn trong toàn ngành.