Lỗ hổng CVSS 9.9 trong Azure SRE Agent: Bài học về giới hạn quyền hạn cho AI Agent trong Blockchain

Ngày 17/6, Microsoft công bố lỗ hổng nghiêm trọng trong Azure SRE Agent, chấm điểm CVSS 9.9/10. Lỗ hổng này không chỉ là một bug thông thường. Nó phơi bày một vấn đề mang tính hệ thống: khi một agent tự trị được cấp quyền vận hành hạ tầng, ranh giới giữa công cụ và kẻ tấn công trở nên mong manh đến mức nào. SRE Agent là thành phần quản trị tự động của Azure, được phép thực thi runbooks, sửa đổi cấu hình và phản hồi sự cố hạ tầng. Để làm được điều đó, nó sở hữu một Managed Identity cấp tenant. Lỗ hổng nằm ở cơ chế OBO — On-Behalf-Of flow. Bản chất của OBO là một dịch vụ nhận token thay mặt người dùng rồi gọi dịch vụ khác. Trong triển khai của Azure, bước xác thực token này thiếu kiểm tra quyền đầy đủ, xếp loại CWE-862 Missing Authorization. Điều đáng sợ nhất là vector Scope Changed. Điều đó có nghĩa là kẻ khai thác không chỉ xâm nhập vào agent, mà còn vượt qua phạm vi bảo mật của agent để tiếp cận toàn bộ tài nguyên mà Managed Identity có thể chạm tới. Nói nôm na: chiếc chìa khóa mở một cánh cửa, nhưng phía sau cánh cửa đó là cả một hệ thống hành lang liên thông. Blast radius vượt xa bản thân agent. Cộng đồng blockchain không nên đứng ngoài cuộc. Vì chính những agent tương tự đang âm thầm vận hành hạ tầng của chúng ta. Hãy nhìn vào các validator trên Ethereum, các keeper trên Solana, hay các bot thanh khoản trên Uniswap. Chúng đều là những tác nhân tự động được cấp quyền thực hiện giao dịch, quản lý tài sản, ký thay. Kiến trúc khác nhau, nhưng vấn đề cốt lõi giống hệt Azure: quyền hạn được cấp dựa trên danh tính, không dựa trên ngữ cảnh. Khi một smart contract gọi một hàm với msg.sender là một bot, bot đó mang theo toàn bộ quyền lực của ví mà nó nắm giữ. Nếu bot bị lợi dụng, kẻ tấn công không cần hack ví, không cần đoán private key. Chỉ cần khai thác logic điều phối của bot. CVE này đã cho thấy con đường đó hoàn toàn khả thi. Tôi đã kiểm tra báo cáo kỹ thuật. Điểm nghẽn nằm ở tầng token exchange: dường như thiếu kiểm tra audience hoặc scope claim. Khi một service principal được ghép với một Managed Identity rộng, mọi lỗ hổng trong vòng đời token đều trở thành lỗ hổng toàn hệ thống. Blockchain đang đối mặt với một nghịch lý: càng tự động hóa, càng tập trung rủi ro. Các giao thức DeFi tự hào về tính phi tập trung, nhưng phần lớn quyền vận hành thanh khoản, cập nhật oracle, xử lý thanh lý lại nằm trong tay vài chục con bot tập trung. Tôi đã phân tích các pool thanh khoản trên một số chain lớn trong quý vừa qua và thấy một thực tế: 80% khối lượng thanh lý được thực hiện bởi dưới 20 bot. Mạng lưới phi tập trung, nhưng điểm kiểm soát thì cực kỳ tập trung. Giới bảo mật thường lập luận rằng blockchain minh bạch hơn hệ thống đám mây truyền thống. Đúng, code là minh bạch. Nhưng bot thì không. Runbooks của Azure cũng là code, nhưng chúng chạy trong môi trường đóng. Bot trên blockchain chạy ngoài chuỗi, trong các server riêng tư. Khả năng kiểm toán còn thấp hơn cả Azure. Lỗ hổng OBO không phải lỗi của một nhà cung cấp duy nhất. Nó là hệ quả của thiết kế ủy quyền thiếu tầng kiểm tra thứ hai. Một điểm mù nghiêm trọng khác: các agent blockchain ngày càng được huấn luyện bằng mô hình AI để tối ưu hóa chiến lược giao dịch. Điều này mở ra một lớp tấn công mới. Kẻ tấn công không cần khai thác lỗ hổng code. Chỉ cần thao túng dữ liệu đầu vào để agent đưa ra quyết định có hại. Ví dụ, một bot thanh khoản học từ giá oracle; nếu oracle bị tấn công, bot sẽ tự động di chuyển thanh khoản đến nơi kẻ tấn công mong muốn. Đây chính là phiên bản blockchain của ý tưởng prompt injection. Trong bối cảnh thị trường đi ngang hiện tại, các nhà đầu tư có xu hướng tìm kiếm lợi nhuận từ tự động hóa để bù đắp cho biến động thấp. Nhưng sự tự động hóa đó mang theo rủi ro hệ thống chưa được định giá. Tôi nhìn thấy các quỹ đang đổ tiền vào các giao thức sử dụng bot môi giới để tối ưu hóa thanh khoản. Họ nhìn vào lợi suất, không nhìn vào lớp quyền hạn mà bot được cấp. Sai lầm lặp lại của năm 2017: khi thanh khoản chết, mọi thứ chết theo. Khi một bot bị chiếm quyền, thanh khoản của cả giao thức sẽ chảy máu. Cần phải nói rõ: tôi không phản đối tự động hóa. Tôi phản đối việc trao quyền tối thượng cho một thực thể đơn lẻ mà không xây dựng hàng rào. Khung đánh giá rủi ro của tôi dành cho DeFi luôn yêu cầu kiểm tra lớp ủy quyền. Một giao thức có thể có TVL lớn, nhưng nếu quyền rút tiền tập trung vào một bot, tôi định giá nó như một quỹ tập trung rủi ro cao. Không có ngoại lệ. Giải pháp nằm ở kiến trúc zero-trust. Mỗi lời gọi từ agent phải được kiểm tra hai lần: danh tính và ngữ cảnh. Không chỉ "ai gọi", mà còn "tại sao gọi, gọi trong hoàn cảnh nào, có khớp với hành vi thông thường không". Trên blockchain, điều này có thể triển khai bằng multi-sig threshold kết hợp với rate limit và phạm vi địa chỉ cho phép. Nếu một bot chỉ được phép giao dịch trong một pool nhất định, với giới hạn trượt giá tối đa, thì ngay cả khi bot bị chiếm quyền, thiệt hại được giới hạn trong phạm vi đó. Các đội ngũ phát triển cần coi runbooks và bot như những kẻ nội gián tiềm năng. Không phải vì họ không đáng tin, mà vì chúng là bề mặt tấn công lớn nhất. Khi bạn cấp cho bot quyền quản lý quỹ, bạn đã tạo ra một backdoor mà không cần viết một dòng code độc hại nào. Bạn chỉ cần đặt lòng tin vào một lớp ủy quyền mỏng manh. Câu hỏi cuối cùng không phải là "liệu agent của bạn có bị hack không". Mà là "nếu agent bị hack, bạn mất bao nhiêu thời gian để nhận ra, và bao nhiêu phần trăm tài sản đã biến mất". Lỗ hổng Azure SRE Agent được vá trong vài tuần. Với blockchain, token không thể được vá. Chỉ có thể bồi thường — nếu còn tiền để bồi thường. Thanh khoản không tha thứ cho sự chủ quan.