Nền tảng bảo mật LLM: Phân tích toàn diện các mô hình đe dọa

Hãy thử Matic, được đảm bảo bằng chính sách hoàn tiền trong 6 tháng.

Nhận Matic

Vào tháng 6 năm 2025, các nhà nghiên cứu bảo mật tại Aim Security đã chứng minh rằng một email duy nhất có thể khiến Microsoft 365 Copilot truy xuất các tệp nội bộ của công ty và truyền chúng đến một máy chủ bên ngoài mà không cần sự tương tác của người dùng.

Email này chứa văn bản thông thường và không khai thác bất kỳ lỗ hổng phần mềm nào. Kết quả đầu ra của Copilot được điều khiển bởi các chỉ dẫn ẩn trong email cùng với yêu cầu thực tế của người dùng, và hệ thống không phân biệt được giữa hai thành phần này. Microsoft đã đóng đường dẫn cụ thể đó trong vòng vài ngày và báo cáo rằng khách hàng không bị ảnh hưởng.

Tuy nhiên, sự cố này đã làm sáng tỏ cách các mô hình ngôn ngữ xử lý văn bản. Lỗ hổng này được đặt tên là EchoLeak, gán mã CVE-2025-32711, và nó đóng vai trò là một nghiên cứu hữu ích để hiểu về bối cảnh bảo mật LLM.

Để so sánh, hãy xem xét một trường hợp khác. Với khoảng 20 đô la cho các truy vấn API, một nhóm đã trích xuất được một phần của mô hình OpenAI thương mại thông qua giao diện công khai của nó. Đó mới là mối đe dọa mà hầu hết các đội ngũ thực sự nên lo ngại.

Trong bài viết này, chúng tôi cố gắng xây dựng một bản đồ về toàn bộ bề mặt tấn công đe dọa đến bảo mật của LLM. Với bản đồ này, một tính năng LLM cụ thể có thể được định vị, các điểm phơi nhiễm được xác định và các mối đe dọa mới có thể được suy luận khi chúng xuất hiện.

Vậy hãy bắt đầu với đặc tính quan trọng nhất.

Tuyên bố miễn trừ trách nhiệm: Bài viết này dựa trên các chi tiết được chia sẻ công khai từ nhiều nguồn khác nhau. Các tài liệu tham khảo nằm ở cuối bài. Vui lòng để lại bình luận nếu bạn nhận thấy bất kỳ điểm nào không chính xác.

Hầu như mọi lỗ hổng LLM đều bắt nguồn từ một đặc tính. Một mô hình ngôn ngữ nhận chỉ dẫn và dữ liệu dưới dạng một chuỗi token duy nhất, và chuỗi đó không chứa dấu hiệu nào để phân tách các lệnh khỏi thông tin.

Phần mềm truyền thống giữ hai thành phần này tách biệt.

Ví dụ, một truy vấn cơ sở dữ liệu có tham số (parameterized database query) giữ lệnh ở một vị trí và dữ liệu đầu vào của người dùng ở một vị trí khác. Điều này có nghĩa là văn bản được nhập vào trường tên vẫn chỉ là văn bản ngay cả khi nó viết ra một câu lệnh SQL, vì cấu trúc của truy vấn buộc phải có sự phân tách.

Tuy nhiên, ngữ cảnh của LLM chỉ có một vị trí cho mọi thứ. System prompt xác định vai trò của trợ lý, tin nhắn của người dùng, tài liệu được truy xuất từ cơ sở dữ liệu và kết quả trả về bởi một công cụ được gọi, tất cả đều được nối tiếp trong cùng một chuỗi. Bất kỳ phần nào của chuỗi đó cũng có thể ảnh hưởng đến kết quả được tạo ra như thể đó là một chỉ dẫn, vì mô hình tính toán mỗi token tiếp theo từ toàn bộ chuỗi phía trước mà không có sự xử lý riêng biệt cho bất kỳ phần nào.

Đây là nơi prompt injection xuất hiện, nghĩa là việc cung cấp văn bản giống như chỉ dẫn để kết quả đầu ra của mô hình tuân theo các chỉ dẫn đó thay vì ý định của người vận hành. Nó tiếp cận mô hình qua hai con đường:

Con đường trực tiếp là một chỉ dẫn độc hại được nhập vào khung chat. Đây là phiên bản mà hầu hết mọi người đều hình dung.

Con đường gián tiếp đặt chỉ dẫn vào bên trong nội dung mà mô hình truy xuất trong quá trình thực hiện một tác vụ hợp lệ, chẳng hạn như một trang web đang được tóm tắt, một tài liệu đang được đọc hoặc một email trong hộp thư được quản lý.

EchoLeak là một ví dụ về con đường gián tiếp. Người dùng yêu cầu công việc thông thường, và các chỉ dẫn của kẻ tấn công xuất hiện trong một email mà người dùng chưa mở. Trên thực tế, payload đã đi qua bộ phân loại cross-prompt-injection chuyên dụng của Microsoft, điều này cho thấy việc lọc dữ liệu đầu vào có thể vẫn còn lỗ hổng nếu chỉ sử dụng đơn lẻ.

Đặc tính này áp dụng cho bất kỳ hệ thống nào cung cấp văn bản bên ngoài cho một mô hình. Một tính năng xử lý kết quả tìm kiếm được truy xuất, tệp tải lên, phiếu hỗ trợ hoặc bình luận đều mang theo nguy cơ bị tấn công gián tiếp theo cấu trúc.

Việc tham số hóa (parameterization) đã giải quyết SQL injection bằng cách tách mã khỏi dữ liệu tại ranh giới cơ sở dữ liệu. Không có phương pháp tương đương nào cho ngôn ngữ tự nhiên, vì chỉ dẫn và thông tin đều được thể hiện dưới dạng từ ngữ, và hiện tại không có phương pháp đáng tin cậy nào để đánh dấu một đoạn văn bản là "trơ" và đảm bảo dấu hiệu đó được tôn trọng trong quá trình tạo văn bản. Việc lọc chỉ giảm bớt vấn đề ở một mức độ nào đó chứ không loại bỏ hoàn toàn.

Vì sự nhầm lẫn có thể xảy ra bất cứ nơi nào văn bản đi vào mô hình hoặc hành động đi ra khỏi nó, bước tiếp theo là lập bản đồ các điểm đó.

OWASP Top 10 cho các ứng dụng Large Language Model là tài liệu tham khảo của ngành về các rủi ro LLM nghiêm trọng nhất. Phiên bản gần đây của nó trình bày mười mục riêng biệt. Khi đặt vào con đường mà dữ liệu đi qua một ứng dụng, mười mục đó trở thành các vị trí trên một bản đồ duy nhất.

Quy trình xử lý (pipeline) chạy theo từng giai đoạn.

Dữ liệu đầu vào đến từ người dùng. Hệ thống thường truy xuất ngữ cảnh để củng cố câu trả lời, một bước thường được xây dựng trên cơ sở dữ liệu vector lưu trữ tài liệu dưới dạng các embedding số và trả về những tài liệu liên quan nhất đến truy vấn. Mô hình đó là Retrieval-Augmented Generation (RAG). Sau đó, mô hình xử lý dữ liệu đầu vào đã được tập hợp. Nó có thể gọi các công cụ hoặc các tác nhân (agent) khác để thực hiện hành động bên ngoài. Kết quả đầu ra trả về cho người dùng. Việc giám sát bao quanh quy trình này, và mọi thành phần trong đó đều bắt nguồn từ một nhà cung cấp, tạo thành chuỗi cung ứng bên dưới hệ thống.

Dưới đây là một số chi tiết về từng giai đoạn và các rủi ro tiềm ẩn liên quan đến chúng:

Đầu vào (Input): Direct prompt injection và tiêu thụ tài nguyên không giới hạn, điều mà OWASP định nghĩa là việc sử dụng tài nguyên không kiểm soát có khả năng làm tăng chi phí của nạn nhân, đôi khi được gọi là "denial of wallet".

Truy xuất (Retrieval): Indirect injection, các điểm yếu về vector và embedding. PoisonedRAG, một nghiên cứu năm 2024, đã làm hỏng câu trả lời của hệ thống RAG bằng cách chèn chỉ năm đoạn văn bản độc hại vào cơ sở dữ liệu tri thức hàng triệu mục, đạt tỷ lệ thành công 90% trên các câu hỏi mục tiêu.

Mô hình (Model): Rò rỉ dữ liệu huấn luyện, đầu độc dữ liệu và mô hình, và rò rỉ system prompt.

Công cụ (Tools): Excessive agency (quyền hạn quá mức), tình trạng một tác nhân nắm giữ nhiều quyền hạn hơn mức cần thiết cho tác vụ của nó.

Đầu ra (Output): Xử lý đầu ra không đúng cách, nơi phản hồi được chuyển tiếp mà không qua kiểm duyệt, và thông tin sai lệch, nơi một câu trả lời tự tin nhưng không chính xác.

Chuỗi cung ứng (Supply chain): Sự thỏa hiệp của bất kỳ thành phần nào cung cấp cho các giai đoạn trên.

Bản đồ cung cấp một điểm tham chiếu để tìm ra các chi tiết cụ thể của một cuộc tấn công. Một cuộc tấn công mới có thể được định vị trên đó. Các câu hỏi liên quan là nó chèn văn bản không đáng tin cậy ở đâu và ở giai đoạn nào, và liệu nó có lạm dụng quyền hạn mà mô hình không nên có hay không. Các câu trả lời chỉ ra cả mức độ nghiêm trọng và biện pháp phòng thủ áp dụng.

Chuỗi cung ứng không thể được đặt gọn gàng trên con đường này, vì một mô hình bị xâm nhập hoặc kho lưu trữ vector bị đầu độc sẽ ảnh hưởng đến mọi giai đoạn sau đó cùng một lúc. Vì lý do đó, nó xuất hiện như một phân đoạn riêng bao trùm mọi thứ.

Bản đồ cũng phơi bày sự chênh lệch trong sự chú ý. Các mối đe dọa gây ra nhiều lo ngại nhất và các mối đe dọa thực sự xảy ra trong môi trường sản xuất là khác nhau.

Các cuộc tấn công nhắm vào nội tại của mô hình, bao gồm đánh cắp trọng số, trích xuất dữ liệu huấn luyện và đầu độc trong quá trình huấn luyện, là hoàn toàn có thật, nhưng đối với hầu hết các nhà phát triển, chúng xếp hạng thấp về nỗ lực ban đầu. Chúng thường tốn kém, phạm vi hẹp hoặc đã được nhà cung cấp mô hình giảm thiểu.

Dưới đây là một vài ví dụ: