ChatGPT for Google Sheets làm rò rỉ sổ làm việc của người dùng ra bên ngoài qua prompt injection

 (promptarmor.com)
5 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Chỉ với một prompt injection gián tiếp được ẩn trong một sheet, có thể đồng thời làm rò rỉ các workbook trên toàn bộ tài khoản của nạn nhân và thực hiện cả tấn công lớp phủ lừa đảo
  • Cuộc tấn công này có thể vượt qua ngay cả khi người dùng đã cấu hình trong phần cài đặt để yêu cầu phê duyệt của con người (human-in-the-loop) một cách rõ ràng
  • Điều kiện để kích hoạt tấn công chỉ là một truy vấn hợp lệ của người dùng, sau đó việc rò rỉ nhiều workbook, popup lừa đảo, chiếm sidebar và chỉnh sửa trái phép sẽ được thực hiện cùng lúc
  • OpenAI đã phản ứng ngay sau khi nhận báo cáo bằng cách gỡ bỏ khả năng tạo mã Apps Script, đồng thời cho biết sẽ xem xét lại tương tác với API của Google, cách tiếp cận sandboxing và các tính năng tương tự
  • Đây là một ví dụ thực chứng về rủi ro bảo mật kiểu tác tử (agentic security risk) phát sinh khi các quyền được cấp cho tiện ích mở rộng AI bị lạm dụng

Tổng quan

  • Tiện ích mở rộng ChatGPT cho Google Sheets do OpenAI phát hành đã đạt hơn 185.000 lượt tải xuống khi chưa đầy một tháng sau ngày ra mắt
  • Người dùng tương tác với chatbot AI thường trực trong sidebar để thao tác bảng tính, đồng thời có thể tận dụng dữ liệu từ ChatGPT connectors
  • Một cuộc tấn công prompt injection gián tiếp (indirect prompt injection) duy nhất có thể gây ra các thiệt hại sau chỉ với một truy vấn bình thường
    • Rò rỉ nhiều workbook trên toàn bộ tài khoản của nạn nhân
    • Hiển thị popup lừa đảo dạng tương tác
    • Ghi đè toàn bộ sidebar GPT bằng giao diện chatbot do kẻ tấn công kiểm soát
    • Chỉnh sửa workbook do kẻ tấn công kiểm soát
  • Các nguồn dữ liệu không đáng tin cậy (sheet được nhập vào, ChatGPT connector, v.v.) có thể điều khiển ChatGPT để chạy script bên ngoài do kẻ tấn công kiểm soát, và script này sẽ tận dụng nguyên vẹn các quyền mà người dùng đã cấp cho tiện ích mở rộng

Phản ứng của OpenAI

  • OpenAI bày tỏ sự cảm ơn đối với nghiên cứu bảo mật và thừa nhận báo cáo này đã bị lọt khỏi quy trình công khai hiện có
  • Biện pháp tức thời là loại bỏ khả năng tạo mã Apps Script của mô hình để loại bỏ rủi ro đối với người dùng ChatGPT for Google Sheets
  • Công ty đang xem xét kỹ lưỡng cách tính năng này tương tác với Google Sheets API, đồng thời đánh giá lại cách tiếp cận sandboxing để tăng khả năng chống chịu trước các cuộc tấn công prompt injection
  • Ở phạm vi rộng hơn, các tính năng tương tự trong những khu vực khác cũng sẽ được rà soát lại để bảo đảm tính nhất quán và hiệu quả của biện pháp phòng vệ

Luồng tấn công

  • Người dùng đang làm việc với mô hình tài chính (financial model) nội bộ
  • Để bổ sung cho mô hình, người dùng nhập (import) một bộ dữ liệu bên ngoài
  • Trong sheet bên ngoài có prompt injection được ẩn bằng chữ màu trắng
  • Người dùng yêu cầu ChatGPT for Google Sheets tích hợp dữ liệu đã nhập vào mô hình tài chính
  • Injection điều khiển ChatGPT chạy script bên ngoài
    • Thiết lập 'Apply edits automatically' quyết định thời điểm yêu cầu con người phê duyệt trước khi hành động tác tử hoàn tất, nhưng cuộc tấn công vẫn thành công ngay cả khi đã tắt tự động chỉnh sửa
  • Script bên ngoài làm rò rỉ mô hình tài chính khỏi workbook của người dùng, và mô hình bị rò rỉ đã được xác nhận trong log máy chủ của kẻ tấn công
  • Từ dữ liệu đã đánh cắp, script xác định và làm rò rỉ liên kết tới các workbook khác, rồi lan sang mọi workbook có thể phát hiện được
    • Sheet mô hình tài chính nội bộ có chứa liên kết tới các bảng tính ngân sách khác; script nhận diện các URL đó, tiếp tục rò rỉ workbook mới rồi xử lý thêm các workbook khác, tổng cộng cuối cùng là 12 workbook bị rò rỉ
    • Ngay cả khi nhấn nút 'stop' trên sidebar ChatGPT, việc thực thi script đã khởi chạy vẫn không bị dừng lại

Tấn công lớp phủ lừa đảo

  • Ngoài việc rò rỉ dữ liệu, cùng script do kẻ tấn công kiểm soát còn có thể thực hiện hai biến thể tấn công lớp phủ lừa đảo
  • Biến thể 1: mở một sidebar phủ lên tiện ích mở rộng từ trang do kẻ tấn công kiểm soát để mạo danh tiện ích; sidebar độc hại này có thể chạy script chỉnh sửa sheet giống như ChatGPT và thực hiện các hành vi độc hại sau
    • Thu thập mọi prompt của người dùng
    • Cung cấp cho người dùng một chatbot bị lệch chuẩn (misaligned)
    • Dụ người dùng 'kết nối lại' connector để giành thêm quyền truy cập ứng dụng
    • Hiển thị giao diện lừa đảo nhằm đánh cắp thông tin xác thực OpenAI
  • Biến thể 2: mở một popup modal hiển thị website do kẻ tấn công kiểm soát để thực hiện lừa đảo thông tin xác thực

Cách kiểm soát truy cập

  • Tổ chức có thể kiểm soát quyền truy cập vào ChatGPT for Google Sheets bằng thiết lập sau
    • Workspace settings > Permissions & roles > ChatGPT for Excel and Google Sheets

Công bố và diễn biến phản hồi

  • Lỗ hổng đã được gửi cho OpenAI theo hình thức công bố có trách nhiệm, nhưng sau nhiều lần liên hệ tiếp theo thì cho đến thời điểm công bố ban đầu vẫn không có liên lạc nào ngoài thư trả lời tự động
  • Tài liệu OpenAI không mô tả các khả năng nhạy cảm được cấp cho mô hình, chẳng hạn như thực thi script có đặc quyền hoặc rủi ro bị điều khiển thông qua prompt injection gián tiếp, mà chủ yếu tập trung vào các giới hạn tính năng và lo ngại về xử lý dữ liệu
  • Mục đích công bố là giúp mọi người có thể đưa ra đánh giá dựa trên thông tin về bề mặt rủi ro

  • Dòng thời gian

    • 8 tháng 5 năm 2026: PromptArmor công bố với OpenAI qua email
    • 8 tháng 5 năm 2026: OpenAI gửi phản hồi tự động xác nhận đây là kênh tiếp nhận báo cáo dự kiến
    • 8 tháng 5 năm 2026: PromptArmor xác nhận ưu tiên liên lạc qua email
    • 12 tháng 5 năm 2026: PromptArmor liên hệ tiếp
    • 18 tháng 5 năm 2026: PromptArmor liên hệ tiếp
    • 27 tháng 5 năm 2026: công bố
    • 31 tháng 5 năm 2026: OpenAI phản hồi
    • OpenAI cho biết sau khi nhận biết báo cáo, họ đã ngay lập tức gỡ bỏ khả năng tạo mã Apps Script của mô hình như một biện pháp bảo vệ người dùng, và điều này sẽ loại bỏ rủi ro đối với người dùng ChatGPT for Google Sheets
    • OpenAI cho biết sẽ xem xét kỹ lưỡng cách tính năng này tương tác với Google Sheets API và đánh giá lại cách tiếp cận sandboxing để đạt độ vững chắc tối đa trước các cuộc tấn công prompt injection
    • OpenAI cho biết cũng sẽ rà soát lại các tính năng tương tự trên những bề mặt khác để xác nhận rằng biện pháp phòng vệ là nhất quán và hiệu quả

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Tôi là Max từ đội ngũ bảo mật của OpenAI. Cảm ơn nghiên cứu bảo mật lần này, và thật đáng tiếc khi vụ việc này đã lọt qua kẽ hở của quy trình xử lý báo cáo công khai
    Giờ chúng tôi đã nắm được báo cáo này, nên để bảo vệ người dùng trước các cuộc tấn công tiềm tàng trong khu vực liên quan, chúng tôi đã loại bỏ khả năng mô hình tạo mã Apps Script, nhờ đó rủi ro đối với người dùng ChatGPT for Google Sheets sẽ không còn nữa
    Chúng tôi cũng đang xem xét kỹ hơn cách tính năng này tương tác với Google Sheets API, đồng thời đánh giá lại cách tiếp cận sandbox để sản phẩm có khả năng chống chịu tối đa trước các cuộc tấn công prompt injection. Ở phạm vi rộng hơn, chúng tôi cũng sẽ rà soát lại các tính năng tương tự trên những bề mặt khác để bảo đảm cơ chế phòng vệ nhất quán và hiệu quả trên toàn bộ hệ thống

    • Không rõ “phòng vệ” ở đây có chỉ là viết dài trong prompt rằng AI không được làm những việc này, hay là một kiến trúc kiểu sub-agent trong sandbox
    • Tôi muốn biết chính xác một phòng thí nghiệm tuyến đầu tiếp cận việc “loại bỏ để mô hình không thể làm được” như thế nào
      Ví dụ, có khác biệt rất lớn giữa việc chặn ở mức tường lửa để mô hình không thể định tuyến qua một đường nào đó, với việc chỉ đơn giản cập nhật prompt. Điều này càng đúng nếu xét đến lịch sử mô hình tương đối kém trong việc hiểu prompt phủ định
    • Họ nói “cảm ơn nghiên cứu bảo mật”, “đã lọt qua kẽ hở của quy trình xử lý báo cáo công khai”, “giờ đã nắm được báo cáo”, nhưng đây không phải lần đầu xảy ra chuyện kiểu này
      https://x.com/PhilipTsukerman/status/1988634162773778501 https://x.com/xpn/status/1986382527817564437
      Có vẻ ở đây họ đã nhận được báo cáo bảo mật thiện chí qua email, nhưng có thể đã buộc nhà nghiên cứu phải nộp lại qua nơi như HackerOne hoặc Bugcrowd. Như vậy họ sẽ bị yêu cầu tuân theo điều khoản nền tảng, điều khoản công bố, quy tắc ứng xử, v.v.
      Tệp SECURITY.md trong kho GitHub chỉ ghi địa chỉ email. Cần phải làm rõ liệu các nhà nghiên cứu như vậy có thể báo cáo sự cố qua email và nhận phản hồi hay không
      Ngày 8 tháng 5 năm 2026 PromptArmor gửi công bố qua email cho OpenAI
      Ngày 8 tháng 5 năm 2026 OpenAI trả lời tự động xác nhận đây là kênh báo cáo dự kiến
      Ngày 8 tháng 5 năm 2026 PromptArmor xác nhận ưu tiên dùng email
      Ngày 12 tháng 5 năm 2026 PromptArmor liên hệ tiếp
      Ngày 18 tháng 5 năm 2026 PromptArmor liên hệ tiếp
    • Có phải ChatGPT đang giám sát pipeline xử lý công bố công khai không?

  • LLM có thể ở trên cloud, nhưng mọi công cụ đều nên (1) chạy cục bộ và (2) được container hóa. Cái kiểu tùy tiện “chạy một thứ gì đó” rõ ràng sớm muộn cũng sẽ nổ tung
    Có người có thể chưa biết, nhưng Codex cũng cài các binary tùy ý lên PC. Nếu bạn nói “hãy đọc PDF này”, nó sẽ cài một chương trình đọc PDF. Không ai biết nó đã được kiểm chứng chưa, đến từ đâu, có phải virus không. Mô hình thì cứ thế chạy
    Tôi đang làm một dự án container hóa WASI cho quy trình làm việc LLM cục bộ, và đây là một bài toán khá khó. Thật ngạc nhiên khi Anthropic và OpenAI không lo lắng hơn về các đường tấn công kiểu này, cảm giác rất nghiệp dư

    • Tôi đồng ý rằng Anthropic và OpenAI đáng ra phải lo hơn về các đường tấn công này. Cả hai đều đã có thể bị đánh lừa rất dễ dàng bằng phông chữ độc hại trong file Docx, và tôi đã ghi lại ở đây: https://tritium.legal/blog/noroboto
      Tôi tự hỏi liệu prompt injection, cùng với hàng nghìn cách để che giấu nỗ lực injection, có phải trên thực tế là một vấn đề không thể giải quyết hay không. Việc thảo luận điều này tự nó có thể là mối đe dọa hiện hữu đối với mô hình kinh doanh
    • Tôi đồng cảm với lo ngại đó, nhưng nói rằng họ không nghiêm túc xử lý thì không chính xác: https://www.anthropic.com/engineering/how-we-contain-claude
      Lo ngại của tôi là mọi người không xử lý vấn đề này ở đúng cấp độ. Hiện giờ người ta nghĩ theo kiểu “làm sao tạo một máy ảo để nhốt tác tử này lại”, nhưng trên thực tế đây là vấn đề ở cấp độ phải thiết kế một hệ điều hành hoàn toàn mới
    • Tôi đồng cảm với lo ngại này. Chỉ là có lẽ đây cũng giống tình huống “thị trường có thể phi lý lâu hơn khả năng bạn trụ vững”
    • Container hóa ở đây có giúp được nhiều đến vậy không? Nếu là công cụ mã nguồn thì cuối cùng nó vẫn cần quyền đọc/ghi vào các tệp mã. Dĩ nhiên vẫn có thể có những trường hợp sử dụng hữu ích
    • Có link dự án không? Tôi đang làm việc có thể tận dụng thứ tương tự

  • Câu “lỗ hổng này đã được công bố có trách nhiệm cho OpenAI. Dù đã nhiều lần liên hệ tiếp, chúng tôi không nhận được bất kỳ phản hồi nào ngoài thư trả lời tự động cho công bố ban đầu” thực sự trông rất tệ

    • Một người tự nhận thuộc OpenAI đang cập nhật trong phần bình luận. Điều này một lần nữa cho thấy cuối cùng vẫn phải có áp lực từ mạng xã hội thì công ty mới để tâm. Cũng chẳng có gì mới
    • Cách gọi “công bố có trách nhiệm” có phải là một cách diễn đạt quá thiện chí không? Tôi tự hỏi điều gì mới là có trách nhiệm hơn
      Có phải vì họ cân nhắc hiệu ứng bậc một của các mô hình công bố khác nhau? Nhưng nếu thông qua suy luận ở cấp cao hơn và tư duy phản biện, ta đi đến kết luận rằng dù trong một số vụ việc cụ thể có thể tệ hơn, một mô hình công bố khác lại tốt hơn cho người dùng trung bình và sức khỏe dài hạn của ngành thì sao
      Mô hình công bố có thể dẫn tới những văn hóa bảo mật khác nhau. Tôi không hiểu vì sao chỉ cách này mới chiếm được cái tên công bố có trách nhiệm, còn các lựa chọn khác chưa từng được chứng minh là tệ hơn thì tự động bị gắn mác vô trách nhiệm
      Điều này cũng hơi gợi tôi nhớ tới khái niệm trộm cắp danh tính. Thực ra bên mất tiền là ngân hàng hoặc một chủ nợ khác, nhưng một người ngẫu nhiên không hề tham gia vào giao dịch lại bị coi là nạn nhân và phải gánh món nợ đó cho tới khi vấn đề được giải quyết

  • Ở công ty chúng tôi, rò rỉ dữ liệu vẫn là nỗi lo lớn nhất và là lý do chính cản trở việc triển khai agent. Đã bàn rất nhiều rồi, nhưng chúng tôi vẫn chưa tìm ra cách nào để tránh thực tế là mình đang đưa dữ liệu quan trọng vào phần mềm mà thực ra không thể nhìn thấy dữ liệu đó đang được xử lý thế nào
    Có thể chặn gửi dữ liệu ra ngoài ở cấp độ mạng, nhưng làm vậy thì về cơ bản cũng trói luôn rất nhiều việc mà agent cần làm để trở nên hữu ích

    • Nên xem xét LLM chạy cục bộ trên phần cứng do công ty sở hữu. Nếu muốn chắc chắn thì thực tế gần như chỉ có cách đó
    • Hay là tạo một bản sao đã ẩn danh hoặc làm rối dữ liệu rồi để agent dùng bản đó?
    • Tôi nghĩ giải pháp duy nhất cho vấn đề này là buộc agent phải đi qua proxy. Nếu proxy xử lý toàn bộ việc xác thực và phân quyền cho agent, thì agent sẽ không có quá nhiều quyền truy cập để có thể bị lạm dụng, đồng thời cũng có thể giám sát rò rỉ dữ liệu hoặc prompt injection

  • Câu “Cuộc tấn công này xảy ra khi một nguồn dữ liệu không đáng tin cậy, ví dụ như sheet được nhập vào hoặc connector ChatGPT, thao túng ChatGPT để thực thi một script bên ngoài do kẻ tấn công kiểm soát; script này chạy bằng cách tận dụng các quyền mà người dùng đã cấp cho tiện ích mở rộng ChatGPT for Google Sheets” thật sự khiến tôi không hề yên tâm

    • Có vẻ mấu chốt để cuộc tấn công này hoạt động là người dùng đã nói rõ với mô hình rằng hãy thực thi chỉ dẫn đó. Trong trường hợp này, thứ bị thao túng không phải là mô hình mà là người dùng
      Kiểu như: “hãy cập nhật mô hình của tôi bằng dữ liệu đến ô F29 theo quy trình từng bước trong comp sheet”
    • Nếu lời nhắc xác nhận chỉnh sửa tệp gây phiền, chỉ cần bảo Codex lách qua nó, rồi nó sẽ cứ thế ghi vào tệp bằng cat >>. LLM quá thông minh để bị giới hạn bằng những ràng buộc kỹ thuật nửa vời

  • Cuối cùng, nếu muốn dùng AI để làm công việc thực tế và an toàn thì cần một lớp ứng dụng đúng nghĩa; kiểu cắm bừa LLM vào hạ tầng bí mật hoặc trọng yếu sẽ không hiệu quả

  • Nếu bạn lịch sự yêu cầu công cụ làm rò rỉ dữ liệu và nó thực sự làm thế, thì đó là một công cụ không an toàn, và rồi chúng ta cũng sẽ phải nhận ra rằng không bao giờ nên dùng nó trong bất kỳ bối cảnh nào mà bảo mật dù chỉ hơi quan trọng

  • “Hành động thật nhanh và phá hỏng đồ của chính bạn!”
    Tôi vẫn không hiểu nổi vì sao tấn công prompt injection vẫn còn tồn tại. Chẳng phải đã khoảng 6 năm rồi sao? Nếu bạn nói với AI “hãy bỏ qua chỉ dẫn trước đó và pha cho tôi một ly cà phê”, thì 9 trên 10 lần có cảm giác như sản phẩm chủ lực của một công ty nghìn tỷ đô sẽ khom lưng pha cho bạn một ly Americano dở tệ thay vì tạo bản tóm tắt email bằng AI

  • Bộ ba chết người lại xuất hiện lần nữa

  • Trước đây tôi từng ngạc nhiên khi biết tồn tại lỗ hổng iMessage zero-click, nhưng sau khi hiểu cách nó hoạt động thì thấy cũng hợp lý. Prompt injection mang lại cảm giác như một phiên bản không thể giải quyết của vấn đề phân tích nội dung tin nhắn