Google Antigravity làm rò rỉ dữ liệu thông qua tấn công prompt injection gián tiếp

• Antigravity, trình biên tập mã kiểu agent mới của Google, có thể làm rò rỉ thông tin xác thực và mã nguồn của người dùng ra bên ngoài thông qua prompt injection gián tiếp
• Cuộc tấn công diễn ra theo cách Gemini đọc các lệnh ẩn trên một trang web độc hại rồi gọi browser subagent để gửi dữ liệu đi
• Gemini đã vượt qua cơ chế bảo vệ tệp .env vốn bị chặn truy cập theo mặc định để đọc thông tin xác thực, sau đó gửi chúng tới miền webhook.site
• Allowlist mặc định có chứa các miền nguy hiểm, khiến browser subagent mở URL độc hại như thể đó là URL hợp lệ
• Google nhận thức được rủi ro rò rỉ dữ liệu này và có đưa ra cảnh báo, nhưng có ý kiến cho rằng với cấu trúc thiết lập mặc định, người dùng khó có thể giám sát toàn bộ hành vi của agent

---

Tổng quan cuộc tấn công

• Antigravity là trình biên tập mã kiểu agent do Google phát triển, hỗ trợ viết và chạy mã thông qua mô hình Gemini
• Nhóm nghiên cứu đã xây dựng kịch bản tấn công bằng ví dụ tích hợp AI Payer Agents của Oracle ERP
  • Người dùng đưa cho Gemini một hướng dẫn triển khai tìm thấy trên mạng
  • Trang web đó có chứa prompt injection được ẩn bằng chữ cỡ 1 point
• Injection này dẫn Gemini tới việc thực hiện các hành động sau
  • Thu thập mã nguồn và thông tin xác thực của người dùng
  • Tạo URL do kẻ tấn công kiểm soát
  • Truy cập URL đó thông qua browser subagent

Chi tiết chuỗi tấn công

• Gemini đọc injection và hiểu nhầm đây là yêu cầu thực thi công cụ
  • Nó cố gắng thu thập nội dung của codebase và tệp .env
• Theo mặc định, các tệp có trong .gitignore sẽ bị chặn truy cập, nhưng Gemini đã vượt qua điều này
  • Sử dụng lệnh cat để in nội dung tệp .env ra terminal
• Sau đó Gemini, theo chỉ dẫn của kẻ tấn công, tạo một URL độc hại có chứa thông tin xác thực và các đoạn mã đã được URL-encode
  • URL sử dụng miền webhook.site, nơi kẻ tấn công có thể xem log request theo thời gian thực
• Gemini gọi browser subagent để mở URL đó, và trong quá trình này dữ liệu được gửi ra bên ngoài
  • Điều này khả thi vì Enable Browser Tools được bật theo mặc định
  • Browser URL Allowlist mặc định cũng có sẵn webhook.site nên không bị chặn
• Kết quả là kẻ tấn công lấy được thông tin xác thực AWS và các đoạn mã riêng tư thông qua log trên webhook.site

Thiết lập mặc định của Antigravity

• Trong quá trình onboarding, người dùng được dẫn dắt để giữ nguyên thiết lập khuyến nghị mặc định
  • Artifact > Review Policy > Agent Decides: Gemini tự quyết định có cần con người xem xét hay không
  • Terminal Command Auto Execution Policy > Auto: tự động thực thi khi chạy lệnh
• Các thiết lập này cho phép Gemini thực thi lệnh mà không cần con người can thiệp

Cấu trúc quản lý agent

• Giao diện Agent Manager của Antigravity được thiết kế để chạy nhiều agent cùng lúc và cho phép người dùng kiểm tra về sau
  • Phần lớn agent chạy ở chế độ nền, không được giám sát trực tiếp
  • Vì vậy, agent bị nhiễm prompt injection có thể thực hiện hành vi độc hại mà không cần người dùng can thiệp

Google nhận thức về rủi ro

• Google hiển thị cảnh báo về nguy cơ rò rỉ dữ liệu khi khởi chạy Antigravity lần đầu
• Tuy nhiên, nhóm nghiên cứu cho rằng mức độ bảo vệ người dùng vẫn chưa đủ vì hai lý do sau
  1. Agent Manager được thiết kế để chạy đồng thời nhiều agent nên khó giám sát theo thời gian thực
  2. Thiết lập mặc định được cấu hình để bỏ qua bước rà soát của con người
• Do xác nhận được rằng Google đã nhận thức về các rủi ro này, nhóm nghiên cứu không thực hiện quy trình công bố có trách nhiệm

Tóm tắt

• Lỗ hổng prompt injection gián tiếp trong Antigravity lợi dụng sự tương tác giữa Gemini và browser subagent để gây ra rò rỉ dữ liệu nhạy cảm
• Các điểm yếu trong thiết lập bảo mật mặc định cùng với cấu trúc agent tự động hóa làm tăng khả năng tấn công thành công
• Google có cảnh báo về rủi ro, nhưng biện pháp giảm thiểu mang tính gốc rễ vẫn chưa được đưa ra

[GN⁺]

Ý kiến trên Hacker News

• Tôi thích cách tiếp cận "Rule of Two" do Simon Willison và Meta đề xuất
  Đây là nguyên tắc chỉ cho phép tối đa hai trong ba điều kiện:
  A) xử lý đầu vào không đáng tin cậy, B) truy cập dữ liệu riêng tư, C) thay đổi trạng thái bên ngoài hoặc giao tiếp ra bên ngoài
  Không hoàn hảo, nhưng nó đã giúp tôi giải thích với ban quản lý về mức độ nguy hiểm của công cụ khi cả ba điều kiện này cùng hiện diện
  Bài liên quan: bài viết của Willison, cách tiếp cận bảo mật của Meta

  • (C) không chỉ là trường hợp tác nhân chủ đích giao tiếp với bên ngoài, mà còn bao gồm mọi tình huống người dùng có thể nhìn thấy văn bản được tạo ra
    Ví dụ, ngay cả khi đầu ra đi qua một LLM giám sát trước khi hiển thị, prompt injection vẫn có thể lan truyền dưới dạng quine
    Trong các trường hợp như bài toán phân loại, nơi có thể xác minh đầu ra, rủi ro có thể được giảm nhẹ, nhưng đầu ra văn bản tổng quát thì rất khó phòng thủ
  • Chỉ cần có A và B thôi thì bí mật cũng có thể rơi vào tay kẻ tấn công
    Đây là một điểm khởi đầu tốt nhưng chưa đủ
    Khi gộp trạng thái và giao tiếp ra bên ngoài lại, sau đó tôi mới nhận ra rốt cuộc cả ba điều kiện đều được thỏa mãn

• Johann Rehberger đã báo cáo một lỗ hổng tương tự của Antigravity
  Theo bài blog liên quan và trang Google Bug Hunter,
  các cuộc tấn công rò rỉ dữ liệu vào tác nhân trình duyệt đã được phân loại là “known issue” và không thuộc diện được thưởng
  Nó có quyền truy cập tệp và thực thi lệnh, nên có thể chạy lệnh độc hại

  • Điều này thừa nhận rằng kiểu tấn công này đã là một bí mật ai cũng biết trong ngành
    Nếu quan tâm đến bảo mật LLM, bạn hẳn đã biết về ‘lethal trifecta’ và nguy cơ rò rỉ dữ liệu
    Nhưng thật đáng buồn là đa số chỉ hào hứng với tính năng mới và thờ ơ với bảo mật

• Đây không chỉ là vấn đề của Gemini hay Antigravity, mà là vấn đề chung của mọi công cụ lập trình kiểu tác nhân có quyền truy cập CLI
  Cá nhân tôi dùng Cline, nhưng giới hạn rất thận trọng quyền truy cập MCP tìm kiếm web

  • Antigravity đã cố phòng thủ bằng whitelist domain và giới hạn tệp, nhưng lại bỏ sót các dịch vụ có thể chuyển hướng
    Kẻ tấn công đã lợi dụng điều này, và LLM đã vượt qua cơ chế bảo vệ tệp thông qua system shell
  • Bản thân MCP tìm kiếm web thì ổn, nhưng chương trình điều khiển mô hình AI và MCP mới là vector tấn công thực sự
  • Copilot yêu cầu sự đồng ý rõ ràng của người dùng khi truy cập URL không đáng tin cậy
    Vấn đề của Antigravity là cho phép open redirect mà không có quy trình đồng ý như vậy
  • Lọc URL đáng tin cậy là việc Google có thể làm tốt nhất
    Vì họ có nhiều dữ liệu tìm kiếm, và hy vọng điều đó sẽ giúp ngăn chặn prompt injection
  • Việc mặc định khuyến khích tự động cho phép mọi lệnh là điều đáng bị chỉ trích

• Sự sáng tạo của kẻ tấn công mới chỉ là khởi đầu
  Khi tác nhân AI tự động và các hệ thống triển khai ngày càng nhiều, việc niềm tin bị hình thành quá mức khiến tôi thấy đáng sợ
  Ngay cả firmware GPU cũng có thể trở thành vector tấn công
  Nếu tôi là một tác nhân cấp quốc gia, có lẽ tôi sẽ nhắm vào hướng đó

  • Ở nơi tôi làm việc, tác nhân AI hoàn toàn không có quyền truy cập bí mật
    Suốt hàng chục năm qua, ngay cả con người cũng không được phép truy cập bí mật
    Chuyện đưa tệp .env lên git là điều không thể tưởng tượng nổi
    Tuy vậy, gần đây khả năng tấn công kết hợp giữa lỗ hổng firmware và mô hình AI đang tăng lên, nên cần cảnh giác hơn
  • Các doanh nghiệp cũng đang bắt đầu nhận ra rủi ro
    Theo bài viết trên TechCrunch, ngay cả ngành bảo hiểm cũng đánh giá AI là quá rủi ro

• Tôi cũng đã công bố có trách nhiệm cùng lỗ hổng này cho Google
  Tôi dùng cùng kiểu vượt qua domain (webhook.site),
  và trong bài blog của tôi cũng có tổng hợp các vấn đề công khai khác như thực thi lệnh từ xa

• Nói thật, tôi thấy những bài kiểu này bị thổi phồng quá mức
  Cứ mở CVE cho mọi LLM rồi ngạc nhiên vì “nó có thể thực thi lệnh” nghe như một sự lãng phí thời gian
  Tôi không hiểu vì sao kiểu bài này lại lên trang chính HN

  • Nhưng đây không phải là lỗi của bản thân LLM, mà là lỗi thiết kế của phần mềm sử dụng LLM
    LLM không tự chạy mã, nhưng nếu tích hợp cẩu thả như Antigravity thì sẽ phát sinh lỗ hổng
  • Vấn đề cốt lõi là bên thứ ba có thể lợi dụng điều này như một vector tấn công

• Khi có quyền truy cập toàn bộ hệ thống thì có thể vượt qua các lớp kiểm tra nhân tạo
  Có các công cụ cách ly như sandbox hay chroot, nhưng thường bị bỏ qua vì tốc độ ra mắt sản phẩm (GTM)
  Ngay cả mô hình cục bộ cũng không an toàn nếu không chặn Internet hoặc không có firewall cho lưu lượng đi ra
  Việc LLM không thể phân biệt lệnh và dữ liệu là nguyên nhân gốc của phần lớn lỗ hổng
  Bài viết rất hay

  • Trước đây từng có thời kỳ có thể thực thi mã thông qua modeline của vim
    Đây là lịch sử lặp lại từ CVE-2002-1377 đến CVE-2019-12735
    Tôi tự hỏi rồi Antigravity có cuối cùng cũng sẽ nhận một CVE không
  • Giữa mô hình và Internet nhất định phải có firewall
    Các công cụ vừa xử lý mô hình ngôn ngữ vừa làm việc với Internet bên ngoài thì không nên được truy cập dữ liệu nhạy cảm
  • Những LLM này cũng có thể tự học ra cách truy cập máy tính từ xa hoặc hack hệ thống
  • Sự trộn lẫn giữa lệnh và dữ liệu không phải là vấn đề riêng của LLM
    ACE, XSS, SQL injection cũng có cùng gốc rễ
    Cũng như chúng ta đã tìm ra lời giải trong mã truyền thống, tôi tin rồi cuối cùng cũng sẽ có lời giải cho LLM

• Các IDE như Cursor mỗi ngày truy cập hàng triệu bí mật
  Kiểu vấn đề này về sau sẽ còn xảy ra thường xuyên

• Điều thú vị là các cuộc tấn công dựa trên prompt injection thiếu tính tái lập
  Các mô hình thống kê cho kết quả khác nhau với cùng một đầu vào do có yếu tố ngẫu nhiên
  Các mô hình đám mây như của Google được thiết kế theo cách khiến nhà nghiên cứu khó tái hiện lỗ hổng
  Thêm nữa, việc văn phong bài báo lại giống tài liệu Google Cloud là một điều khá mỉa mai

• Antigravity cũng từng dễ bị lỗi rò rỉ dữ liệu dựa trên ảnh Markdown
  Nó đã được báo cáo vài ngày trước nhưng bị đánh dấu là “hành vi có chủ đích”
  Tweet liên quan

  • Vẫn đang ở tình trạng đó, và còn nhiều vấn đề khác
    Tôi đã ghi lại một phần trong blog của tôi