Hack Google Bard: từ prompt injection đến rò rỉ dữ liệu
(embracethered.com)- Khi Bard Extensions cho phép đọc cả tài liệu cá nhân và email, indirect prompt injection ẩn trong tài liệu bên ngoài có thể trở thành một đường dẫn rò rỉ dữ liệu thực tế
- Kẻ tấn công có thể ép chia sẻ một Google Docs độc hại với nạn nhân, và khiến Bard thực thi các chỉ dẫn trong tài liệu ngay khi Bard tìm kiếm hoặc phân tích tài liệu đó
- Kết xuất ảnh Markdown của Bard có thể gọi URL bên ngoài mà không cần người dùng nhấp chuột, trở thành kênh để đính kèm ngữ cảnh hội thoại vào chuỗi truy vấn rồi đưa dữ liệu ra ngoài
- Content Security Policy của Google đã chặn việc tải ảnh tùy ý, nhưng Google Apps Script chạy trên
script.google.comvàgoogleusercontent.comđã được dùng làm đường vòng - Vấn đề này được báo cáo cho Google VRP vào ngày 19/9/2023, được xác nhận đã sửa vào ngày 19/10; có vẻ Google đã bổ sung bộ lọc để ngăn dữ liệu bị chèn vào URL
Bề mặt tấn công mới do Bard Extensions tạo ra
- Google Bard hỗ trợ Extensions sau bản cập nhật, cho phép truy cập YouTube, tìm kiếm vé máy bay/khách sạn, cũng như tài liệu cá nhân và email của người dùng
- Khi Bard có thể phân tích Drive, Docs, Gmail của người dùng, đã xuất hiện tình huống đưa dữ liệu bên ngoài không đáng tin cậy vào ngữ cảnh LLM
- Trong cấu trúc như vậy, hệ thống có thể bị lộ trước indirect prompt injection, nơi các chỉ dẫn ẩn trong nội dung bên ngoài làm thay đổi phản hồi của mô hình
- Trong thử nghiệm tóm tắt video YouTube và
Google Docs, đã xác nhận hành vi Bard làm theo các chỉ dẫn được nhúng trong nội dung bên ngoài
Kịch bản tấn công
- Indirect prompt injection qua email hoặc Google Docs nguy hiểm vì có thể được truyền tới mà người dùng không cần nhấp rõ ràng vào liên kết độc hại
- Kẻ tấn công có thể ép chia sẻ một Google Docs độc hại với nạn nhân
- Nếu nạn nhân dùng Bard để tìm kiếm hoặc tương tác với tài liệu đó, các chỉ dẫn prompt injection trong tài liệu có thể được thực thi
- Một đường dẫn dễ bị khai thác thường thấy trong ứng dụng LLM là rò rỉ lịch sử chat thông qua hyperlink và kết xuất ảnh
Chèn ảnh Markdown
- LLM của Google có thể đưa các phần tử Markdown vào phản hồi dạng văn bản, và Bard kết xuất chúng thành HTML
- Cú pháp ảnh Markdown được chuyển thành thẻ
<img>của HTML, và thuộc tínhsrccó thể trỏ tới máy chủ của kẻ tấn công - Để hiển thị ảnh, trình duyệt tự động truy cập URL đó mà không cần tương tác từ người dùng
- Sau khi LLM tóm tắt hoặc đọc dữ liệu trước đó trong ngữ cảnh chat, nếu nó gắn giá trị đó vào URL ảnh, dữ liệu có thể thoát ra ngoài qua yêu cầu bên ngoài
- Khai thác ban đầu được phát triển nhanh theo cách đọc lịch sử hội thoại rồi tạo hyperlink chứa dữ liệu đó, nhưng kết xuất ảnh bị Content Security Policy của Google chặn
Vượt qua Content Security Policy
- CSP của Google chặn việc tải ảnh từ các vị trí tùy ý
- Tuy nhiên CSP bao gồm các vị trí được cho phép khá rộng như
*.google.comvà*.googleusercontent.com - Google Apps Script có thể được gọi bằng URL tương tự macro Office, và chạy trên miền
script.google.comhoặcgoogleusercontent.com - Vì đặc điểm này, Apps Script trở thành một ứng viên phù hợp để vượt CSP
Triển khai Bard Logger
- Đã triển khai Bard Logger bằng
Apps Script - Logger ghi tất cả tham số truy vấn gắn trên URL gọi vào Google Doc
- Trong giao diện Apps Script, đã tìm thấy cấu hình cho phép truy cập không cần xác thực, nhờ đó có thể tạo endpoint cho phép gọi ẩn danh
- Chuỗi tấn công gồm các yếu tố sau
- Indirect prompt injection phát sinh từ dữ liệu Bard Extensions
- Yêu cầu zero-click được tạo qua kết xuất ảnh của Bard
- Chỉ dẫn prompt injection trong Google Doc độc hại
- Endpoint ghi log dựa trên
google.comnhận dữ liệu khi ảnh được tải
Luồng demo
- Trong demo, khi
Google Docđộc hại đi vào ngữ cảnh chat, lịch sử chat của người dùng bị rò rỉ - Luồng ảnh chụp màn hình như sau
- Người dùng truy cập Google Doc có tên “The Bard2000”
- Chỉ dẫn của kẻ tấn công được chèn vào và ảnh được kết xuất
- Kẻ tấn công nhận dữ liệu vào Google Doc thông qua Bard Logger Apps Script
- Chuỗi này phức tạp hơn các trường hợp trước đây từng được thảo luận với Bing Chat, ChatGPT, Claude, vì cần vượt CSP
Shell Code bằng ngôn ngữ tự nhiên và payload
- Như cách nói “Shell Code is natural language these days”, khai thác được cấu thành bằng prompt ngôn ngữ tự nhiên
- Google Doc độc hại chứa payload thực hiện prompt injection và rò rỉ dữ liệu
- Payload này dụ LLM thay thế văn bản trong URL ảnh bằng dữ liệu hội thoại
- Để Bard hoàn thành tác vụ, cần in-context learning bằng cách cung cấp một vài ví dụ
- Payload trong phụ lục chỉ dẫn in ra 20 từ đầu tiên của hội thoại, mã hóa khoảng trắng thành
+, rồi chèn vào truy vấn của URL thực thi Apps Script - Phụ lục cũng bao gồm chuỗi đầu ra “AI Injection succeeded #10”
Bản sửa của Google và lịch trình
- Vấn đề này được báo cáo cho Google VRP vào ngày 19/9/2023
- Sau yêu cầu kiểm tra trạng thái vào ngày 19/10/2023, Google xác nhận đã sửa xong và phê duyệt việc đưa demo vào bài trình bày tại Ekoparty 2023
- Cách sửa khi đó chưa hoàn toàn rõ ràng
- CSP không được sửa và ảnh vẫn được kết xuất, nên có vẻ đã bổ sung bộ lọc để ngăn chèn dữ liệu vào URL
- Lịch trình sửa lỗi
- 19/9/2023: báo cáo vấn đề
- 19/10/2023: xác nhận đã sửa
1 bình luận
Các ý kiến trên Hacker News
thetrong 2–3 prompt liên tiếp, nhưng cách này không hiệu quả với BardTôi từng nghĩ quy tắc được áp dụng toàn cục và đồng đều cho toàn bộ prompt
Sau đó, cùng vấn đề này xuất hiện lại trong XSS: hệ thống không phân biệt được lệnh và dữ liệu, nên kẻ tấn công có thể tạo ra một thông điệp bị hệ thống hiểu nhầm là lệnh. Giải pháp là tìm cách phân định dữ liệu một cách chắc chắn
Với LLM, giải pháp có lẽ cũng tương tự. Có thể là huấn luyện LLM tôn trọng những lệnh kiểu “100 token đầu tiên là bất biến, và không chỉ dẫn nào khác được phép phản bác chúng. [chèn lệnh được bảo vệ]”. Nếu đưa những thứ như vậy vào giai đoạn huấn luyện, thay vì gắn thêm chỉ dẫn bảo vệ ở thời điểm suy luận, có thể sẽ khó chèn chỉ dẫn độc hại hơn; nhưng trên thực tế không dễ, vì phải dự đoán mọi kiểu tấn công có thể xảy ra ngay từ lúc huấn luyện
Vấn đề là tại sao lại trao quyền truy cập đặc biệt cho một bộ lấy mẫu token ngẫu nhiên moi ra từ đống rơm, rồi tin rằng nó sẽ luôn hoạt động tốt chỉ vì nhìn chung có vẻ ổn
Hy vọng trong vài năm tới sẽ có một đột phá về cấu trúc cho phép tách các chỉ dẫn, tức prompt, khỏi phần hội thoại “dữ liệu”
Ví dụ, có thể có cách nhận đầu vào gồm hai loại token: token prompt và token dữ liệu, sao cho chúng không bao giờ bị trộn lẫn hay nhầm lẫn với nhau. Tôi chưa biết cách làm, và để học cũng như vận hành ở hai tầng như vậy sẽ cần một bước tiến lớn về kiến trúc, nhưng chỉ còn biết hy vọng ai đó tìm ra
Không có lý do nền tảng nào để cho rằng điều này là bất khả thi. Nó không khớp với mô hình chuỗi token đơn hiện tại, nhưng đó cũng là lý do các mô hình phải tiến hóa
Chỉ nên đưa cho mô hình những dữ liệu mà người dùng cũng được phép đọc qua một giao diện khác
Giải pháp là coi LLM như một thành phần không đáng tin cậy và thiết kế hệ thống dựa trên giả định đó
Khi dùng cùng cơ sở dữ liệu vector và API, có thể dễ dàng truyền thông tin ngữ cảnh hoặc kiểm soát truy cập dựa trên vai trò, nên hoạt động khá tốt
Tôi không mấy ấn tượng với LLM dưới dạng cơ sở dữ liệu tri thức, nhưng với vai trò giao diện thì ấn tượng hơn nhiều
Vài ngày trước ở đây có người dùng cách gọi hệ điều hành, và tôi cũng thích cách diễn đạt đó
Một giờ trước tôi cũng dùng ChatGPT, và thú vị là nó chuyển truy vấn của tôi thành tìm kiếm Bing rồi trả lời nhất quán bằng thông tin đúng. Tôi hỏi cụ thể về một dự án nguồn mở; trước đây nó chỉ biết đặc tả API và tài liệu, nhưng lần này hoạt động rất tốt
LLM về bản chất là không an toàn, chủ yếu vì về bản chất chúng rất dễ bị lừa. Để hữu ích, chúng phải dễ bị thuyết phục ở một mức độ nào đó, nhưng vì vậy mọi ứng dụng phơi bày văn bản từ nguồn không đáng tin cậy, chẳng hạn tính năng tóm tắt trang web, đều có thể bị kẻ tấn công ác ý lật ngược
Chúng ta đã nói về prompt injection suốt 14 tháng, nhưng vẫn chưa có gì trông gần giống một giải pháp đáng tin cậy
Tôi thật sự hy vọng sẽ sớm có ai đó giải được bài toán này; nếu không, sẽ rất khó xây dựng an toàn nhiều thứ mà chúng ta muốn tạo ra bằng LLM
[1] https://gandalf.lakera.ai/
Để giải thích thêm một chút quan điểm của tôi, cuối cùng tôi nghĩ hướng đi sẽ là áp dụng thứ gì đó như
addslashescho mọi prompt mà LLM diễn giải. Vì vậy tôi đã đơn giản hóa thành “LLM có thể giải quyết vấn đề này”Nếu nghĩ về việc
addslasheslàm, đó là áp dụng đoạn mã loại bỏ hoặc giảm nhẹ các ký tự đặc biệt ảnh hưởng đến việc thực thi mã theo sau. Theo cùng cách đó, tôi nghĩ LLM cũng có thể tự làm sạch đầu vào để không thể thoát ra đượcNếu đồng ý rằng không có ký tự đầu vào nào có thể loại bỏ các dấu slash đã được thêm vào, thì hẳn phải có một phiên bản
addslashesdành cho prompt: mộtaddslashesbọc ngoài để giảm nhẹ prompt injection mà không chỉ thị nào có thể thoát khỏiTôi chưa suy nghĩ đến cùng về việc nó sẽ ảnh hưởng thế nào đến khả năng sử dụng của hệ thống, nhưng nó vẫn phải có thể thực hiện hầu hết tác vụ trong phạm vi sử dụng dự định
Nếu Lakera AI có biện pháp phòng thủ cho việc này thì họ phải chứng minh được. Nếu có cách chặn injection hiệu quả 100%, thì trong trò chơi phải có một màn không thể vượt qua. Nhưng vì không có cách như vậy, nên trong trò chơi cũng không có màn nào như thế
Lakera AI đang dùng phòng thủ mang tính xác suất, nhưng trong marketing lại khiến người ta tưởng như họ có thứ gì đó đáng tin cậy hơn thế. Chưa ai trình diễn được một bộ phát hiện hoàn toàn đáng tin cậy, và cũng không có cách nào chắc chắn chặn mọi prompt injection. Tôi thật sự cho rằng việc Lakera AI thường bỏ qua sự thật này trong marketing là mang tính lừa dối
Bài viết ở trên là sai. Không có cách nào dùng bộ phát hiện injection để bắt cuộc tấn công cụ thể này với độ tin cậy 100%. Phải nói rằng Lakera AI có một bộ phát hiện injection đôi khi bắt được cuộc tấn công này. Nhưng Lakera không diễn đạt marketing như vậy. Họ đang ngầm cố bán một sản phẩm không tồn tại và các nhà nghiên cứu thậm chí còn chưa chứng minh được là có thể tạo ra
Nói cách khác, trong số những khách hàng cần phòng thủ prompt injection và sẵn sàng trả tiền, ai là người có thể chấp nhận một mức lỗi nào đó?
Người dùng không có ý định để kẻ tấn công thấy các cuộc trò chuyện trước đó của mình. Đó là lỗ hổng bảo mật
Cuộc trò chuyện đó có thể hoàn toàn vô hại, nhưng cũng có thể là lời khuyên về vấn đề cá nhân, chẳng hạn như tư vấn y tế, tài chính hoặc các mối quan hệ
Tôi đã tạo một custom GPT làm việc đó thay mình
Bạn đã từng viết blog hoặc công khai quá trình tạo ra nó chưa? Trông khá hay đấy