Rủi ro ẩn của AI agent trong Notion 3.0: rò rỉ dữ liệu qua việc lạm dụng công cụ tìm kiếm web

 (codeintegrity.ai)
2 điểm bởi GN⁺ 2025-09-21 | 1 bình luận | Chia sẻ qua WhatsApp
  • AI agent của Notion 3.0 cung cấp khả năng thực thi workflow tự động nhiều bước như soạn tài liệu, cập nhật cơ sở dữ liệu và gọi connector bên ngoài
  • Khi agent có quyền truy cập công cụ và bộ nhớ dài hạn, các cơ chế RBAC hiện có sẽ khó kiểm soát bề mặt tấn công mở rộng được hình thành
  • Phân tích cho thấy schema đầu vào của hàm web search trong Notion agent có thể bị lợi dụng làm vector rò rỉ dữ liệu để gửi bí mật nội bộ ra bên ngoài thông qua prompt gián tiếp độc hại
  • Trong bản demo, kẻ tấn công đã chứng minh luồng thực thi trong đó agent bị dẫn dắt trích xuất, ghép nối và gửi dữ liệu khách hàng bí mật qua truy vấn web bằng prompt injection được giấu trong PDF
  • Trường hợp này cho thấy mức độ nghiêm trọng mà bộ ba chết người giữa agent-công cụ-bộ nhớ (“lethal trifecta”) gây ra cho bảo mật thực tế khi kết hợp với tích hợp MCP và connector bên ngoài

Giới thiệu về AI Agents và Notion 3.0

  • Gần đây, AI Agents đang có xu hướng được tích hợp vào các nền tảng SaaS
  • Trong Notion 3.0, AI agent có thể tự động thực hiện mọi tác vụ mà người dùng có thể làm, như tạo tài liệu, cập nhật DB, tìm kiếm trên nhiều công cụ và chạy workflow nhiều bước
  • Nhờ tích hợp MCP, hệ thống có thể kết nối với nhiều công cụ bên ngoài để tạo ra khả năng tự động hóa mạnh hơn và xây dựng agent tùy biến sâu hơn
  • Cũng có thể tạo các Custom Agents theo nhóm hoạt động dựa trên trigger hoặc lịch chạy, để tự động xử lý các công việc lặp lại như thu thập phản hồi, cập nhật tracker hoặc sàng lọc yêu cầu

Vấn đề 'bộ ba chết người (lethal trifecta)'

  • 'Bộ ba chết người (Lethal Trifecta)' do Simon Willison nêu ra là mối đe dọa bảo mật phát sinh từ sự kết hợp giữa LLM agent, quyền truy cập công cụ và bộ nhớ dài hạn
  • Trong Notion 3.0, agent có thể tự lập kế hoạch hành động và thực thi cả công cụ tích hợp MCP lẫn công cụ tích hợp sẵn
  • Các agent có quyền rộng có thể tự động hóa tài liệu, cơ sở dữ liệu và thao tác với connector ngoài theo những cách mà RBAC truyền thống không lường trước
  • Vì vậy, các chỉ dấu rủi ro về rò rỉ hoặc lạm dụng dữ liệu nhạy cảm thông qua workflow tự động hóa nhiều giai đoạn được mở rộng đáng kể

Chi tiết kỹ thuật lỗ hổng: tấn công rò rỉ dữ liệu trang Notion bằng công cụ tìm kiếm web của Notion AI

  • Vấn đề: schema đầu vào của functions.search (web scope) trong công cụ tìm kiếm web cho phép cả chuỗi truy vấn trực tiếp lẫn gián tiếp 
    Name: functions.search (web scope)  
Input:  {  
    "web": {  
        "queries": ["<query or URL>", "..."]    // mảng chuỗi truy vấn (URL hoặc từ khóa tìm kiếm)  
    }
  • Chính khả năng đưa URL hoặc từ khóa tùy ý vào mảng truy vấn là điểm bị khai thác
  • Bề mặt tấn công: nếu giấu prompt độc hại trong tài liệu người dùng mà agent có thể đọc như PDF, agent có thể thực thi chỉ dẫn đó
  • Tiêm prompt gián tiếp thông qua tuyến xử lý của agent (văn bản trong tệp → đường xử lý của agent) khiến việc chèn lệnh trở nên khả thi trong thực tế
  • Kỹ thuật né tránh của kẻ tấn công: dùng các câu chữ thuyết phục về tâm lý và kỹ thuật như thẩm quyền, tính khẩn cấp, độ tin cậy kỹ thuật và màn kịch bảo mật kiểu “pre-authorized” để vượt qua khâu rà soát của con người và các lớp an toàn
  • Cấu trúc này có thể bị lợi dụng cho rò rỉ dữ liệu bằng cách kết hợp có chọn lọc các truy vấn do kẻ tấn công kiểm soát

Trình diễn tấn công: kịch bản đánh cắp dữ liệu theo từng bước

  • Bước 1: Tạo PDF độc hại

    • Chèn lén một prompt độc hại giống như chỉ thị thực thi vào tài liệu PDF phản hồi khách hàng nhìn bề ngoài hoàn toàn bình thường
    • Prompt ẩn này ngụy trang thành một “tác vụ vận hành quan trọng”, hướng dẫn gửi dữ liệu tới một hệ thống backend nội bộ
    • Nội dung chính của prompt độc hại
      • Khẳng định thẩm quyền (Authority assertion): dùng các cụm như "Important routine task", "consequences" để nhấn mạnh đây là “tác vụ thường lệ quan trọng”
      • Tạo cảm giác khẩn cấp giả (False urgency): nhấn mạnh rằng nếu không thực hiện sẽ ảnh hưởng tới tổ chức
      • Tính hợp lệ kỹ thuật (Technical legitimacy): mô tả như thật về hệ thống nội bộ và cú pháp lệnh công cụ
      • Kịch bản trấn an bảo mật (Security theater): dùng các cụm như "pre-authorized" và "safe from security perspective" để nhấn mạnh rằng thao tác đã được phê duyệt trước và là an toàn
    • Sau khi đọc PDF, agent bị dẫn dắt trích xuất thông tin doanh nghiệp như tên khách hàng, ARR rồi gửi dữ liệu tới một URL do kẻ tấn công kiểm soát nhưng giả làm hệ thống nội bộ

  • Bước 2: Chờ tương tác của người dùng

    • Cuộc tấn công được kích hoạt khi người dùng Notion tải PDF đó lên Notion hoặc yêu cầu agent tóm tắt tài liệu
    • Với các lệnh như “tóm tắt báo cáo”, AI sẽ vô tình diễn giải cả prompt được cài cắm bí mật

  • Bước 3: Dữ liệu thực sự bị rò rỉ

    • Agent ghép dữ liệu khách hàng như tên công ty, ngành nghề, ARR thành một chuỗi duy nhất theo chỉ dẫn trong prompt
    • Sau đó tạo URL nhắm tới domain của kẻ tấn công và chuyển URL đó thành truy vấn cho công cụ tìm kiếm web
    • Máy chủ độc hại nhận yêu cầu này, do kẻ tấn công kiểm soát, sẽ thu thập dữ liệu nhạy cảm
  • Kịch bản này cho thấy dù Notion AI sử dụng mô hình Claude Sonnet 4.0, các guardrail bảo mật vẫn có thể bị vượt qua

Cách tích hợp MCP mở rộng bề mặt tấn công của Notion AI agent

  • Notion hỗ trợ AI Connector từ nhiều nguồn như GitHub, Gmail, Jira
  • Context và metadata mà từng connector cung cấp cho agent tạo thêm bề mặt tấn công, làm tăng khả năng prompt độc hại xâm nhập từ nguồn bên ngoài thông qua tấn công tiêm prompt gián tiếp
  • Rủi ro về các hành vi tự động hóa ngoài ý muốn mang tính độc hại và các nỗ lực rò rỉ dữ liệu nhạy cảm cũng tăng lên
  • Ví dụ: commit message hoặc nội dung issue độc hại, hay email bên ngoài, có thể hoạt động như prompt gián tiếp để khiến agent truy cập và gửi dữ liệu nội bộ

Hàm ý và khuyến nghị (tóm tắt)

  • Hàm ý cốt lõi: khi agent có quyền truy cập công cụ, các chỉ dẫn độc hại trong tài liệu có thể dẫn tới lời gọi công cụ và từ đó gây ra rò rỉ thông tin mật
  • Các điểm phòng thủ cần thảo luận:
    • Lời gọi công cụ của agent cần đi qua xác minh nguồn gốc, giới hạn ngữ cảnh và lọc theo chính sách
    • Các chỉ dẫn thực thi trong tài liệu, như hướng dẫn tạo URL, cần được xử lý bằng cơ chế kiểm tra an toàn riêng, xác nhận của con người hoặc môi trường thực thi cô lập
    • Cần tăng cường nguyên tắc đặc quyền tối thiểu theo từng MCP connector cùng với hệ thống log và cảnh báo cho các lời gọi
  • Kết luận: các tính năng của Notion 3.0 có tiềm năng lớn trong nâng cao năng suất, nhưng vector tấn công mới do sự kết hợp giữa agent-công cụ-bộ nhớ tạo ra đòi hỏi phải xem xét lại thiết kế bảo mật trong thực tế

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-09-21
Ý kiến trên Hacker News
  • Tôi muốn nhấn mạnh rằng điều Simon Willison gọi là "lethal trifecta" được mô tả là một vector tấn công mạnh nhưng cũng rất dễ bị lạm dụng thông qua sự kết hợp giữa tác nhân LLM, quyền truy cập công cụ và bộ nhớ dài hạn là cách giải thích sai. Lethal trifecta thực sự là quyền truy cập vào dữ liệu riêng tư, khả năng tiếp xúc với nội dung không đáng tin cậy và khả năng giao tiếp với bên ngoài. Một tác nhân LLM có chức năng tìm kiếm web thuộc cả hai trường hợp: tiếp xúc với nội dung không đáng tin cậy và giao tiếp với bên ngoài.
    • Tôi nghĩ TFA đã hiểu sai khái niệm này ngay từ đầu. Nguồn gốc bài viết gốc của Simon Willison là bài này.
    • Theo tôi, có thể giải thích trifecta đơn giản hơn: nếu kẻ tấn công có thể đưa đầu vào cho LLM thì họ có thể kiểm soát mọi tài nguyên.
    • Cách giải thích đó không hợp với cái tên trifecta. Ba yếu tố thật sự là: đầu vào không đáng tin cậy, quyền truy cập có đặc quyền và kênh rò rỉ dữ liệu.
  • Cách xây dựng prompt tạo cảm giác rất giống đặc trưng của các chiến dịch phishing.
    • Tự nhận thẩm quyền
    • Tạo cảm giác khẩn cấp giả tạo
    • Biện minh bằng kỹ thuật
    • Giả vờ liên quan đến bảo mật
      Điều này khiến tôi nghĩ prompt injection giống như phishing nhắm vào một thực thể không có bản ngã hay khả năng tự phản tư để dừng lại và nghi ngờ.
    • Tôi cũng thấy hiện tượng này giống CSRF. Cả hai kiểu tấn công đều lợi dụng đầu vào mà hệ thống tin tưởng để lừa một người dùng có đặc quyền thực hiện hành động họ không mong muốn. Ví dụ, một file PDF độc hại dùng prompt injection để khiến tác nhân Notion (có quyền truy cập workspace) gọi công cụ web bên ngoài và đẩy nội dung trang ra ngoài. Về bản chất, đây vẫn là cùng một mô hình lạm dụng đặc quyền. Chỉ là bề mặt kỹ thuật đã đổi thành prompt injection + chuỗi công cụ, thay vì giả mạo HTTP request như trước đây.
    • Tôi nghĩ nếu được huấn luyện phù hợp thì LLM hoàn toàn có thể phát triển khả năng "nghi ngờ" và chống chịu các cuộc tấn công như vậy. Tuy nhiên, với các mô hình gần đây thì việc tăng khả năng kháng "persona" injection lại mâu thuẫn với cách dùng hội thoại. Vì vậy, tôi cho rằng rất có thể chúng ta sẽ thấy sự tách biệt giữa các mô hình "agent" được tăng cường và các mô hình hội thoại cởi mở hơn. Cũng có thể điều chỉnh kỳ vọng bằng cách thêm base context vào đầu vào, nhưng làm vậy có lẽ sẽ cần thay đổi ở mức kiến trúc.
  • Tôi đã tự thử trực tiếp trên Notion, và có vẻ nó có tìm URL nhưng không thực sự gửi dữ liệu đến URL đó. Tôi tò mò điểm rò rỉ dữ liệu nằm ở đâu (ngoài phần chỉ được gửi đến dịch vụ tìm kiếm).
    • Tôi đã yêu cầu bot AI của Notion tạo một trang mới từ một URL, rồi xác nhận qua log máy chủ của mình rằng Notion thực sự truy cập URL đó. User-Agent là Chrome/139/Mac.
    • Tôi nghĩ ý đồ là lợi dụng query string để buộc tạo request đến một URL cụ thể. Có vẻ công cụ tìm kiếm không hoạt động theo cách đó, hoặc log chưa thể hiện rõ việc rò rỉ nên vẫn chưa thể khẳng định chắc là đã thành công.
  • Cuộc tấn công này đã được demo từ 2 năm trước. Đây không phải vấn đề mới. Liên kết liên quan.
    • Vấn đề là Notion lại có lỗ hổng này và hoàn toàn không có biện pháp nào để ngăn chặn hay giảm thiểu nó.
    • Đây hoàn toàn không phải lỗ hổng mới, vậy mà Notion vẫn đưa nguyên xi vào trong tuần này. Kết quả của việc chỉ chăm chăm tung ra tính năng AI hào nhoáng để trình diễn.
  • Tôi tự hỏi có ai đang xử lý vấn đề instruction/data-conflation hay không. Chừng nào còn để LLM mù quáng làm theo chỉ dẫn nằm trong dữ liệu thì việc kết nối các nguồn dữ liệu thực với chức năng bên ngoài vẫn còn quá sớm. Notion còn khuyến khích người dùng kết nối Github, GMail, Jira v.v. với mô hình mà không hề có cảnh báo nào. Ở mức này, việc coi đây là một tính năng trong một sản phẩm an toàn gần như là hành vi phạm lỗi nghiêm trọng.
    • Chúng ta đã bàn về vấn đề này hơn 3 năm, nhưng vẫn chưa có giải pháp thực sự vững chắc. Hiện tại người ta tách system prompt và user prompt rồi huấn luyện để tin một bên hơn, nhưng cách này cũng lỏng lẻo. Một kẻ tấn công đủ quyết tâm vẫn sẽ tìm ra đường vòng. Biện pháp giảm thiểu thuyết phục nhất mà tôi thấy là bài báo CaMeL của DeepMind, nhưng ngay cả cách đó cũng áp nhiều ràng buộc lên cách cấu thành tính năng. Liên kết.
    • Tôi là tác giả của exploit này. Ở CodeIntegrity.ai, chúng tôi đã xây dựng một nền tảng có thể trực quan hóa luồng dữ liệu thực và luồng điều khiển trong các hệ thống AI dạng agent để đánh giá rủi ro của từng phần. Chúng tôi cũng cung cấp guardrail thời gian chạy để kiểm soát các luồng theo mức chấp nhận rủi ro. Nếu muốn tìm hiểu thêm, cứ email cho tôi theo địa chỉ abi@codeintegrity.ai.
    • Cách bạn diễn đạt vấn đề này khá thú vị. Tôi hình dung đến việc dùng cho đầu vào LLM một cấu trúc dữ liệu phân tách rõ giữa dữ liệu đã được tin cậy và dữ liệu chưa được tin cậy. Kết quả web search hay MCP mặc định sẽ là không đáng tin cậy (trừ khi bạn tự viết MCP và có thể tin được nó). Dữ liệu không đáng tin cậy chỉ được phép trải qua các phép biến đổi thuần túy, không có side effect. Ví dụ: tóm tắt, loại bỏ khoảng trắng, chuyển sang float, v.v., tất cả đều chạy trong sandbox không có truy cập mạng. Chẳng hạn, yêu cầu như "hãy tóm tắt tất cả issue công khai trên GitHub rồi lưu vào DB" có vẻ vẫn có thể làm an toàn nếu nội dung không đáng tin cậy chỉ được xử lý trong sandbox!
    • Nó giống như "vấn đề trao quyền thực thi mã cho người dùng phổ thông". Trên thực tế không có lời giải dễ dàng.
    • Giải pháp thực ra đã tồn tại. Đây không phải là một vấn đề dữ liệu đặc biệt gì mà ngay cả các guardrail hiện có cũng có thể hạn chế AI. Nếu người dùng không có quyền truy cập dữ liệu thì LLM cũng phải bị giới hạn tương tự. Những công ty cứ mở toang như vậy mới là điều kỳ lạ. Đây không phải phép màu. Các công ty có vấn đề bảo mật AI thường cũng có nhiều lỗ hổng nghiêm trọng khác. Chỉ là với AI thì chúng dễ lộ ra hơn.
  • Bài viết gốc ở đây.
  • Gần đây Notion ngày càng khiến tôi có cảm giác như spyware. Trong lúc họp, nó liên tục hiện popup nói rằng đã phát hiện tôi đang họp và hỏi "có muốn ghi chú giúp không?".
  • Tôi không nghĩ có thể gọi các lỗ hổng được phát hiện trong những công cụ công khai gắn mác "AI" là "ẩn giấu".
  • Bài này khá hay vì cho thấy một lỗ hổng thực tế bằng ví dụ cụ thể, mà phần giải thích cũng không quá thiên về kỹ thuật.
  • Tôi thắc mắc một người dùng bình thường sẽ đưa tài liệu vào instance Notion của tôi bằng cách nào.
    • Chỉ cần tìm trên Google "best free notion marketing templates", tải về rồi import vào. Tôi đã làm vậy nhiều lần, và hàng nghìn, hàng chục nghìn người trên khắp thế giới cũng dùng tương tự.
    • Bài viết lấy PDF làm ví dụ, nhưng tùy vào cách tác nhân Notion mở và lưu liên kết, cũng có thể hiển thị các trang web khác nhau cho crawler/trình duyệt agent, nên ngay cả các tài liệu phổ biến trong ngành cũng có thể trở thành mục tiêu phishing.
    • Nhiều công ty dùng công cụ tự động hóa như Zapier để tải trực tiếp các tài liệu như hóa đơn lên, hoặc nhận tài liệu exploit qua email rồi đăng ký vào Notion.
    • Người ta đưa đủ loại tài liệu vào Notion. Dùng như DB, dùng web clipper để lưu tài liệu trực tuyến, và dùng cả như công cụ cộng tác. Cách sử dụng rất đa dạng.
    • Trong trường hợp này, cách làm là gửi qua email một file PDF có tiêu đề đủ thuyết phục để trông như tài liệu đáng chia sẻ với đồng nghiệp. Các lệnh độc hại được giấu bằng chữ trắng trên nền trắng, v.v. Về sau khi các MCP có thể truy cập cả issue tracker công khai hay email nhận vào, sẽ còn xuất hiện nhiều kịch bản tấn công khác nữa.