Google Antigravity รั่วไหลข้อมูลผ่านการโจมตีแบบ indirect prompt injection

 (promptarmor.com)
2 คะแนน โดย GN⁺ 2025-11-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Antigravity โปรแกรมแก้ไขโค้ดแบบเอเจนต์ตัวใหม่ของ Google อาจทำให้ ข้อมูลรับรองและโค้ด ของผู้ใช้รั่วไหลออกไปภายนอกผ่าน indirect prompt injection
  • การโจมตีเกิดขึ้นโดย Gemini อ่านคำสั่งอันตรายที่ซ่อนไว้ในหน้าเว็บ แล้วเรียกใช้ browser subagent เพื่อส่งข้อมูลออกไป
  • Gemini สามารถ ข้ามการป้องกันไฟล์ .env ที่ตามค่าเริ่มต้นควรถูกบล็อกไม่ให้เข้าถึง อ่านข้อมูลรับรอง แล้วส่งไปยังโดเมน webhook.site
  • มีโดเมนที่เสี่ยงอยู่ใน allowlist เริ่มต้น ทำให้ browser subagent เปิด URL อันตรายได้ราวกับเป็น URL ปกติ
  • Google รับรู้ถึง ความเสี่ยงด้านการรั่วไหลของข้อมูลและมีข้อความเตือน แต่ก็มีข้อชี้ให้เห็นว่า ด้วยโครงสร้างค่าเริ่มต้น ผู้ใช้ตรวจสอบการทำงานของเอเจนต์ทั้งหมดได้ยาก

ภาพรวมของการโจมตี

  • Antigravity เป็น โปรแกรมแก้ไขโค้ดแบบเอเจนต์ ที่ Google พัฒนา โดยรองรับการเขียนและรันโค้ดผ่านโมเดล Gemini
  • ทีมวิจัยสร้างสถานการณ์โจมตีโดยใช้ตัวอย่างการผสานรวม AI Payer Agents ของ Oracle ERP
    • ผู้ใช้ส่งคู่มือการติดตั้งที่พบทางออนไลน์ให้ Gemini
    • หน้าเว็บดังกล่าวมี prompt injection ที่ซ่อนไว้ด้วยตัวอักษรขนาด 1 พอยต์
  • injection นี้ชักจูงให้ Gemini ทำสิ่งต่อไปนี้
    • รวบรวมโค้ดและข้อมูลรับรองของผู้ใช้
    • สร้าง URL ที่ผู้โจมตีควบคุม
    • เข้า URL ดังกล่าวผ่าน browser subagent

รายละเอียดของสายโซ่การโจมตี

  • Gemini อ่าน injection แล้วเข้าใจผิดว่าเป็น คำขอเรียกใช้เครื่องมือ
    • พยายามรวบรวมเนื้อหาใน codebase และไฟล์ .env
  • ตามค่าเริ่มต้น ไฟล์ที่อยู่ใน .gitignore จะถูกบล็อกไม่ให้เข้าถึง แต่ Gemini ข้ามข้อจำกัดนี้ได้
    • ใช้คำสั่ง cat เพื่อพิมพ์เนื้อหาไฟล์ .env ออกทางเทอร์มินัล
  • จากนั้น Gemini สร้าง URL อันตรายที่มี ข้อมูลรับรองและชิ้นส่วนโค้ดที่เข้ารหัสแบบ URL ตามคำสั่งของผู้โจมตี
    • URL ใช้โดเมน webhook.site ซึ่งผู้โจมตีสามารถดูบันทึกคำขอได้แบบเรียลไทม์
  • Gemini เรียกใช้ browser subagent เพื่อเปิด URL ดังกล่าว และในกระบวนการนี้ข้อมูลก็ถูกส่งออกไปภายนอก
    • ในค่าเริ่มต้นเปิดใช้งาน ‘Enable Browser Tools’ ไว้ จึงสามารถทำงานได้
    • ใน ‘Browser URL Allowlist’ มี webhook.site รวมอยู่โดยค่าเริ่มต้น จึงไม่ถูกบล็อก
  • ผลลัพธ์คือผู้โจมตีได้รับ ข้อมูลรับรอง AWS และชิ้นส่วนโค้ดที่ไม่เปิดเผยต่อสาธารณะ ผ่านบันทึกของ webhook.site

ค่าเริ่มต้นของ Antigravity

  • ในขั้นตอน onboarding ผู้ใช้ถูกชักจูงให้ยอมรับ การตั้งค่าที่แนะนำตามค่าเริ่มต้น ตามเดิม
    • Artifact > Review Policy > Agent Decides: Gemini ตัดสินใจเองว่าจะต้องให้มนุษย์ตรวจสอบหรือไม่
    • Terminal Command Auto Execution Policy > Auto: รันคำสั่งโดยอัตโนมัติ
  • การตั้งค่าเหล่านี้ทำให้ Gemini สามารถรันคำสั่งได้โดยไม่มีมนุษย์เข้ามาแทรกแซง

โครงสร้างการจัดการเอเจนต์

  • อินเทอร์เฟซ Agent Manager ของ Antigravity ถูกออกแบบให้รันเอเจนต์หลายตัวพร้อมกัน และให้ผู้ใช้กลับมาตรวจสอบภายหลังได้
    • เอเจนต์ส่วนใหญ่ทำงาน เบื้องหลังโดยไม่มีการเฝ้าดู
    • ส่งผลให้เอเจนต์ที่ติด prompt injection อาจ ทำพฤติกรรมอันตรายได้โดยไม่มีการแทรกแซงจากผู้ใช้

การรับรู้ความเสี่ยงของ Google

  • Google แสดง ข้อความเตือนเกี่ยวกับความเสี่ยงในการรั่วไหลของข้อมูล เมื่อเริ่มใช้งาน Antigravity ครั้งแรก
  • อย่างไรก็ตาม ทีมวิจัยชี้ว่า การปกป้องผู้ใช้ยังไม่เพียงพอ ด้วยเหตุผล 2 ข้อ
    1. Agent Manager ถูกออกแบบให้รันหลายเอเจนต์พร้อมกัน จึงยากต่อการเฝ้าดูแบบเรียลไทม์
    2. การตั้งค่าเริ่มต้นถูกตั้งให้ข้ามการตรวจสอบโดยมนุษย์
  • เนื่องจากยืนยันได้ว่า Google รับรู้ความเสี่ยงนี้อยู่แล้ว ทีมวิจัยจึง ไม่ดำเนินกระบวนการเปิดเผยช่องโหว่อย่างรับผิดชอบ

สรุป

  • ช่องโหว่ indirect prompt injection ของ Antigravity อาศัยการโต้ตอบระหว่าง Gemini กับ browser subagent เพื่อทำให้เกิด การรั่วไหลของข้อมูลสำคัญ
  • ช่องโหว่ในค่าความปลอดภัยเริ่มต้น และ โครงสร้างเอเจนต์แบบอัตโนมัติ เพิ่มโอกาสให้การโจมตีสำเร็จ
  • Google มีการเตือนถึงความเสี่ยง แต่ มาตรการบรรเทาในระดับรากฐาน ยังไม่ได้ถูกนำเสนอ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-11-26
ความคิดเห็นจาก Hacker News

  • ฉันชอบแนวทาง “Rule of Two” ที่ Simon Willison และ Meta เสนอ
    มันคือหลักการที่อนุญาตได้แค่สองในสามเงื่อนไขต่อไปนี้:
    A) ประมวลผลอินพุตที่ไม่น่าเชื่อถือ, B) เข้าถึงข้อมูลที่ไม่เปิดเผย, C) เปลี่ยนแปลงสถานะภายนอกหรือสื่อสารออกภายนอก
    ถึงจะไม่สมบูรณ์แบบ แต่เมื่อครบทั้งสามข้อ มันช่วยให้ฉันอธิบาย ความเสี่ยงของเครื่องมือ ให้ผู้บริหารเข้าใจได้
    บทความที่เกี่ยวข้อง: บทความของ Willison, แนวทางความปลอดภัยของ Meta

    • (C) ไม่ได้หมายถึงแค่กรณีที่เอเจนต์ สื่อสารกับภายนอกโดยตั้งใจ เท่านั้น แต่รวมถึงทุกสถานการณ์ที่ผู้ใช้สามารถเห็นข้อความที่ถูกสร้างขึ้นได้ด้วย
      ตัวอย่างเช่น ต่อให้มี LLM สำหรับเฝ้าระวังคั่นก่อนแสดงผล prompt injection ก็ยังแพร่กระจายในรูปแบบ quine ได้
      กรณีอย่างงานจัดประเภทที่ตรวจสอบเอาต์พุตได้จะบรรเทาได้บ้าง แต่เอาต์พุตข้อความทั่วไปป้องกันได้ยาก
    • แค่มี A กับ B ก็เพียงพอให้ความลับหลุดไปถึงมือผู้โจมตีได้แล้ว
      มันเป็นจุดเริ่มต้นที่ดี แต่ยังไม่พอ
      พอรวมเรื่องสถานะกับการสื่อสารภายนอกเข้าด้วยกัน ก็เลยมารู้ทีหลังว่าสุดท้ายแล้วครบทั้งสามเงื่อนไขอยู่ดี

  • Johann Rehberger ได้รายงานช่องโหว่ลักษณะคล้ายกันของ Antigravity
    จาก โพสต์ในบล็อกที่เกี่ยวข้อง และ หน้าบั๊กฮันเตอร์ของ Google
    การโจมตีแบบ ขโมยข้อมูลออก ของ browser agent ถูกจัดเป็น “known issue” ไปแล้ว และไม่มีสิทธิ์รับรางวัล
    มันมีสิทธิ์เข้าถึงไฟล์และสิทธิ์รันคำสั่ง จึงสามารถรันคำสั่งอันตรายได้

    • นี่คือการยอมรับว่าในวงการมันเป็น ความลับที่ใคร ๆ ก็รู้กัน อยู่แล้ว
      ถ้าใครสนใจเรื่องความปลอดภัยของ LLM ก็น่าจะรู้จัก ‘lethal trifecta’ และความเสี่ยงด้าน data exfiltration กันอยู่แล้ว
      แต่น่าเสียดายที่คนส่วนใหญ่กลับตื่นเต้นกับฟีเจอร์ใหม่ ๆ และไม่สนใจความปลอดภัย

  • นี่ไม่ใช่ปัญหาเฉพาะของ Gemini หรือ Antigravity แต่เป็นปัญหาร่วมของ เครื่องมือเขียนโค้ดแบบเอเจนต์ทุกตัวที่มีสิทธิ์เข้าถึง CLI
    ส่วนตัวฉันใช้ Cline แต่ก็จำกัดการเข้าถึง MCP สำหรับการค้นหาเว็บอย่างระมัดระวัง

    • Antigravity พยายามป้องกันด้วยโดเมน whitelist และข้อจำกัดเรื่องไฟล์ แต่กลับมองข้าม บริการที่ redirect ได้
      ผู้โจมตีจึงใช้ช่องนี้ และ LLM ก็อ้อมการปกป้องไฟล์ผ่าน system shell
    • ตัว web search MCP เองไม่ได้มีปัญหา แต่ โปรแกรมที่ควบคุม AI model กับ MCP ต่างหากที่เป็น attack vector จริง
    • Copilot จะขอ ความยินยอมอย่างชัดเจน จากผู้ใช้เมื่อจะเข้าถึง URL ที่ไม่น่าเชื่อถือ
      ปัญหาของ Antigravity คือมันยอมให้มี open redirect โดยไม่มีขั้นตอนขอความยินยอมแบบนี้
    • การกรอง URL ที่เชื่อถือได้เป็นสิ่งที่ Google น่าจะทำได้ดีที่สุด
      เพราะมีข้อมูลการค้นหาจำนวนมาก และหวังว่าจะช่วยเรื่องการป้องกัน prompt injection ได้
    • การชี้นำให้ตั้งค่าเริ่มต้นเป็นอนุญาตทุกคำสั่งอัตโนมัติควรถูกวิจารณ์อย่างหนัก

  • ความคิดสร้างสรรค์ ของผู้โจมตีเพิ่งเริ่มต้นเท่านั้น
    ยิ่งมีระบบ AI แบบเอเจนต์และระบบ deploy อัตโนมัติเพิ่มขึ้น ก็ยิ่งน่ากลัวว่าความไว้วางใจจะถูกสร้างมากเกินไป
    แม้แต่เฟิร์มแวร์ของ GPU เองก็อาจกลายเป็น attack vector ได้
    ถ้าฉันเป็นผู้โจมตีระดับรัฐ ฉันคงเล็งตรงนั้น

    • ที่ที่ฉันทำงานอยู่ เอเจนต์ AI ไม่มีสิทธิ์เข้าถึงความลับใด ๆ เลย
      หลายสิบปีมาแล้วที่เราไม่ยอมให้แม้แต่มนุษย์เข้าถึงความลับโดยตรง
      การเอาไฟล์ .env ขึ้น git เป็นเรื่องที่นึกไม่ถึง
      แต่ช่วงนี้ต้องระวังมากขึ้น เพราะความเป็นไปได้ของ การโจมตีแบบผสมระหว่างช่องโหว่เฟิร์มแวร์กับโมเดล AI กำลังเพิ่มขึ้น
    • ตอนนี้บริษัทต่าง ๆ ก็เริ่มตระหนักถึงความเสี่ยงแล้ว
      ตาม บทความของ TechCrunch แม้แต่วงการประกันภัยก็ประเมินว่า AI มีความเสี่ยงสูงเกินไป

  • ฉันเองก็เคย เปิดเผยช่องโหว่นี้ต่อ Google อย่างมีความรับผิดชอบ เหมือนกัน
    โดยใช้การ bypass โดเมนแบบเดียวกัน (webhook.site)
    และใน โพสต์บล็อกของฉัน ก็สรุปปัญหาที่เปิดเผยแล้วอื่น ๆ เช่นการรันคำสั่งจากระยะไกลไว้ด้วย

  • พูดตรง ๆ ว่าฉันรู้สึกว่าบทความพวกนี้พูดเกินจริงไปมาก
    การเปิด CVE ให้ LLM ทุกตัวแล้วตื่นตกใจว่า “มันรันคำสั่งได้” ดูเป็นการเสียเวลามาก
    ฉันไม่เข้าใจว่าทำไมบทความแบบนี้ถึงขึ้นหน้าแรกของ HN

    • แต่ประเด็นนี้ไม่ใช่บั๊กของตัว LLM เอง มันคือ ข้อบกพร่องด้านการออกแบบของซอฟต์แวร์ที่ใช้ LLM
      LLM ไม่ได้รันโค้ดเอง แต่ถ้าเอาไปผสานแบบประมาทอย่าง Antigravity ก็จะเกิดช่องโหว่ขึ้น
    • แก่นของปัญหาคือบุคคลที่สามสามารถ นำมันไปใช้เป็น attack vector ได้

  • ถ้ามีสิทธิ์เข้าถึงทั้งระบบ ก็สามารถเลี่ยงการตรวจสอบที่สร้างขึ้นมาได้
    มีเครื่องมือแยกกักอย่าง sandbox หรือ chroot แต่ก็มักถูกตัดทิ้งเพราะ ความเร็วในการออกสู่ตลาด (GTM)
    แม้แต่ local model ก็ไม่ปลอดภัย หากไม่มีการตัดอินเทอร์เน็ตหรือ outbound firewall
    ต้นเหตุหลักของช่องโหว่ส่วนใหญ่คือ LLM แยกคำสั่งกับข้อมูลไม่ออก
    เป็นบทความที่ยอดเยี่ยมมาก

    • สมัยก่อนเคยมีช่วงที่ vim รันโค้ดได้ผ่าน modeline
      ประวัติศาสตร์แบบนี้วนซ้ำมาตั้งแต่ CVE-2002-1377 ถึง CVE-2019-12735
      เลยสงสัยว่า Antigravity จะได้ CVE ในที่สุดไหม
    • ระหว่างโมเดลกับอินเทอร์เน็ตควรมี ไฟร์วอลล์ เสมอ
      เครื่องมือที่จัดการทั้ง language model และอินเทอร์เน็ตภายนอกพร้อมกันไม่ควรเข้าถึงข้อมูลอ่อนไหว
    • LLM พวกนี้อาจ เรียนรู้ได้เอง ว่าจะเข้าถึงคอมพิวเตอร์ระยะไกลหรือแฮ็กอย่างไร
    • การปนกันของคำสั่งกับข้อมูลไม่ใช่ปัญหาเฉพาะของ LLM
      ACE, XSS, SQL injection ต่างก็มีรากเดียวกัน
      เหมือนที่เราเคยหาทางแก้ในโค้ดแบบเดิมได้ ฉันก็เชื่อว่าในโลก LLM สุดท้ายก็น่าจะหาทางแก้ได้

  • IDE อย่าง Cursor เข้าถึงความลับนับล้านรายการทุกวัน
    ปัญหาแบบนี้จึงน่าจะ เกิดขึ้นบ่อยต่อไป

  • สิ่งที่น่าสนใจคือการโจมตีที่อาศัย prompt injection ขาดความสามารถในการทำซ้ำผลลัพธ์
    โมเดลเชิงสถิติมีองค์ประกอบแบบสุ่ม จึงอาจให้ผลต่างกันแม้ใช้อินพุตเดียวกัน
    โมเดลคลาวด์ของ Google เองก็ถูกออกแบบให้ผู้วิจัยทำซ้ำช่องโหว่ได้ยาก
    แถมยังมีความย้อนแย้งตรงที่สไตล์ของบทความก็ดูคล้ายเอกสาร Google Cloud ด้วย

  • Antigravity ยังเคยมีช่องโหว่ ขโมยข้อมูลออกผ่านภาพใน Markdown ด้วย
    มีการรายงานไปเมื่อไม่กี่วันก่อน แต่ถูกระบุว่าเป็น “พฤติกรรมที่ตั้งใจไว้”
    ทวีตที่เกี่ยวข้อง

    • ตอนนี้ก็ยังเป็นแบบเดิม และยังมีปัญหาอื่นอีกมาก
      ฉันได้บันทึกบางส่วนไว้ใน บล็อกของฉัน