Chào mừng bạn trở lại với Spotlight Lỗ Hổng của Sherlock, nơi chúng tôi làm nổi bật một lỗ hổng quan trọng được phát hiện trong một cuộc kiểm toán của Sherlock. Tuần này, chúng ta có lỗ hổng Giả Mạo Gửi Tiền. Nó đã được phát hiện bởi @0xalpharush & @bernd_eth trong Cuộc Thi Cross-Chain của @zetablockchain. 🧵

Dưới đây là tóm tắt về lỗ hổng của @bernd_eth: 1. Các quan sát viên của ZetaChain theo dõi các giao dịch trên các chuỗi bên ngoài (ví dụ: Ethereum, Solana) và thêm chúng vào một trình theo dõi tập trung để xử lý chúng như là các khoản tiền gửi và rút tiền, giả định rằng giao dịch thành công. 2. Khác với việc tích hợp EVM, việc triển khai của Solana bỏ qua các kiểm tra thành công của giao dịch, cho phép một quan sát viên độc hại thêm các khoản tiền gửi không thành công, tạo ra ZRC20 SOL không có tài sản đảm bảo, và rút cạn quỹ đã được cầu nối. 3. Mặc dù các quan sát viên được ZetaChain cho phép rõ ràng, điều quan trọng là phải đảm bảo rằng không có bên nào có thể làm tổn hại đến chuỗi hoặc siphon tài sản.

Thông thường, các quan sát viên không xử lý các giao dịch thất bại, nhưng đường dẫn mã này không thực hiện cùng một xác thực như đối tác EVM của nó. Mặc dù điều này yêu cầu một vai trò "đặc quyền", nhưng mọi validator đều là một quan sát viên, và đồng thuận BFT được cho là có khả năng chịu đựng Byzantine, tức là, chịu đựng <1/3 các bên độc hại. Do đó, một quan sát viên độc hại không nên có khả năng làm giả một khoản tiền gửi và khiến các validator trung thực bỏ phiếu để đúc ZRC20 Sol cho các giao dịch thất bại thông qua bộ theo dõi đầu vào, cái mà thiếu các xác thực cho việc triển khai Solana của nó.

Nguyên nhân gốc rễ của lỗ hổng này: Hàm ProcessInboundEvents không yêu cầu một giao dịch phải thành công, khác với bộ quan sát inbound EVM, cái mà thực hiện điều này đúng cách ở đây. Vì lệnh được giải mã như thể nó đã thành công, một bộ quan sát độc hại có thể giả mạo một khoản tiền gửi cho toàn bộ số dư ZRC20-SOL và sau đó rút SOL bị khóa ở phía Solana của cầu, đánh cắp tất cả lamports trong cầu. Cuộc tấn công này cũng có thể được sử dụng để rút các token SPL hoặc thực hiện các khoản tiền gửi và gọi tùy ý. Ví dụ, việc loại bỏ thuộc tính có thể ghi từ PDA của cổng trong lệnh gửi tiền dẫn đến một giao dịch thất bại (xem lỗi ràng buộc anchor trong POC), và nó vẫn có thể được xử lý một khi được thêm vào bộ theo dõi inbound thông qua MsgAddInboundTracker.

Các điều kiện tiên quyết nội bộ: Một người quan sát độc hại hoặc bất cẩn thêm một giao dịch Solana thất bại chứa các hướng dẫn Gateway vào bộ theo dõi đầu vào bằng MsgAddInboundTracker, dẫn đến tất cả các validator xử lý và bỏ phiếu để đúc ZRC20 Sol trên Zetachain. CCTX nhận được đủ phiếu bầu, và ZRC20 Sol không có tài sản đảm bảo trên Zetachain được đúc.

Các điều kiện bên ngoài: Bất kỳ bên nào gửi một giao dịch thất bại đến cổng với hướng dẫn gửi tiền (hoặc gửi tiền và gọi). Người nhận ZRC20 Sol trên Zetachain rút nó và nhận lamports trên Solana.

Đường tấn công: 1) Bất kỳ bên nào gửi một giao dịch thất bại đến cổng với hướng dẫn gửi tiền (hoặc gửi tiền và gọi). 2) Một quan sát viên độc hại hoặc bất cẩn thêm một giao dịch Solana thất bại chứa các hướng dẫn Gateway vào bộ theo dõi đầu vào bằng MsgAddInboundTracker, dẫn đến tất cả các validator xử lý và bỏ phiếu để đúc ZRC20 Sol trên Zetachain. 3) Nhiệm vụ ProcessInboundTrackers khiến CCTX giả mạo nhận đủ phiếu bầu, và ZRC20 Sol không được bảo đảm trên Zetachain được đúc ra. 4) Người nhận ZRC20 Sol trên Zetachain rút nó và nhận lamports trên Solana.

Tác động là gì? Tất cả lamports và token SPL được gửi vào cầu Solana có thể bị đánh cắp, vì các khoản gửi có thể bị làm giả với bất kỳ số tiền nào (chúng được xử lý mặc dù chương trình Gateway khiến các giao dịch bị hoàn lại).

Biện pháp giảm thiểu: Trong quá trình xử lý bộ theo dõi đầu vào của Solana Observer, hãy kiểm tra xem giao dịch có thành công trước khi bỏ phiếu cho nó.

Chúng tôi tự hào đã giúp bảo vệ @zetablockchain thông qua phát hiện này. Khi cần bảo mật tuyệt đối, Sherlock là sự lựa chọn đúng đắn.