ช่องโหว่ด้านความปลอดภัยที่สำคัญใน Model Context Protocol (MCP) ของ Supabase ถูกค้นพบแล้ว ซึ่งช่วยให้ผู้โจมตีสามารถดึงข้อมูลฐานข้อมูล SQL ทั้งหมดผ่านเทคนิค prompt injection ที่ซับซ้อน ช่องโหว่นี้แสดงให้เห็นว่า AI agent สามารถถูกจัดการให้ข้ามการควบคุมความปลอดภัยและรั่วไหลข้อมูลสำคัญเมื่อเชื่อมต่อกับฐานข้อมูลที่ใช้งานจริง
 |
|---|
| ข้อความโจมตีที่สำคัญภายในตั๋วรับแจ้งปัญหาแสดงให้เห็นว่าการจัดการที่ซับซ้อนมุ่งเป้าไปที่ช่องโหว่ของฐานข้อมูลอย่างไร |
เวกเตอร์การโจมตี: เมื่อข้อมูลผู้ใช้กลายเป็นคำสั่ง
ปัญหาหลักเกิดจากปัญหาพื้นฐานของ Large Language Models (LLMs) คือไม่สามารถแยกแยะระหว่างคำสั่งที่ถูกต้องและคำสั่งที่เป็นอันตรายที่ฝังอยู่ในเนื้อหาที่ผู้ใช้สร้างขึ้นได้อย่างน่าเชื่อถือ นักวิจัยด้านความปลอดภัยจาก General Analysis ได้แสดงให้เห็นว่าผู้โจมตีสามารถส่งตั๋วสนับสนุนที่มีคำสั่งที่สร้างขึ้นอย่างระมัดระวัง ซึ่งดูเหมือนข้อความปกติแต่จริงๆ แล้วเป็นคำสั่งให้ AI agent ทำการดำเนินการฐานข้อมูลที่ไม่ได้รับอนุญาต
เมื่อนักพัฒนาที่ใช้ Cursor (โปรแกรมแก้ไขโค้ดที่ขับเคลื่อนด้วย AI) ที่เชื่อมต่อกับ Supabase MCP ตรวจสอบตั๋วสนับสนุนที่เป็นอันตราย คำสั่งที่ฝังอยู่จะหลอก AI ให้ดำเนินการคิวรี SQL เพื่อดึงข้อมูลสำคัญ เช่น โทเค็นการตรวจสอบสิทธิ์ ข้อมูลประจำตัวผู้ใช้ และข้อมูลลับอื่นๆ การโจมตีนี้ใช้ได้ผลเพราะ AI ประมวลผลทั้งคำสั่งที่ถูกต้องของนักพัฒนาและคำสั่งที่ซ่อนอยู่จากตั๋วสนับสนุนเป็นข้อมูลที่ถูกต้องเท่าเทียมกัน
MCP (Model Context Protocol): มาตรฐานการสื่อสารที่ช่วยให้ AI agent โต้ตอบกับเครื่องมือและบริการภายนอก รวมถึงฐานข้อมูล
ขอบเขตสิทธิ์ในระบบที่มีช่องโหว่
| ผู้ใช้งาน | บทบาท/การเข้าถึงใน Freshdesk | บทบาท/การเข้าถึงใน SQL |
|---|---|---|
| ลูกค้าที่ส่งตั๋วแจ้งปัญหา | ผู้รายงาน | AGENT: SELECT; INSERT; UPDATE |
| เจ้าหน้าที่ฝ่ายสนับสนุน | เอเจนต์ | AGENT: SELECT; INSERT; UPDATE; pg_read_all_stats |
| นักพัฒนา | ผู้ดูแลระบบ | ADMIN: .+Extension; CREATE FUNCTION |
การตอบสนองของอุตสาหกรรมและความพยายามในการลดความเสี่ยง
วิศวกร Supabase ได้ใช้มาตรการป้องกันหลายอย่าง รวมถึงการส่งเสริมการเข้าถึงฐานข้อมูลแบบอ่านอย่างเดียวตามค่าเริ่มต้น และการเพิ่ม prompt ที่ออกแบบมาเพื่อป้องปรามไม่ให้ AI ทำตามคำสั่งที่ฝังอยู่ อย่างไรก็ตาม ชุมชนด้านความปลอดภัยยังคงสงสัยเกี่ยวกับประสิทธิภาพของการป้องกันแบบ prompt เหล่านี้
การโจมตีนี้เกิดจากการรวมกันของข้อบกพร่องในการออกแบบสองประการ: การเข้าถึงที่อนุญาตมากเกินไป (service_role) ที่มีให้กับระบบที่มีความน่าเชื่อถือต่ำหรือไม่น่าเชื่อถือ ในขณะที่ MCP ปลดล็อกความสามารถในการทำงานอัตโนมัติที่ทรงพลัง จำเป็นต้องจัดการนิพจน์ความปลอดภัยการตรวจสอบอย่างระมัดระวัง
ความท้าทายพื้นฐานคือ prompt engineering ไม่สามารถทำหน้าที่เป็นขอบเขตความปลอดภัยที่เชื่อถือได้ ต่างจากช่องโหว่ความปลอดภัยเว็บแบบดั้งเดิม เช่น SQL injection ซึ่งมีการแก้ไขที่ยอมรับกันดีผ่าน parameterized queries และการทำความสะอาดข้อมูลนำเข้า ปัจจุบันยังไม่มีกลไกที่เทียบเท่าสำหรับการรักษาความปลอดภัย LLM prompt จากการโจมตี injection
มาตรการป้องกันที่ Supabase ได้นำมาใช้
- อ่านอย่างเดียวตามค่าเริ่มต้น: ส่งเสริมให้ผู้ใช้กำหนดค่า MCP ด้วยการเข้าถึงฐานข้อมูลแบบอ่านอย่างเดียว
- การห่อหุ้มการตอบกลับ: เพิ่มพรอมต์ที่ท้อแท้ LLM จากการทำตามคำสั่งภายในข้อมูลผู้ใช้
- การทดสอบ E2E: ทดสอบกับ LLM ที่มีความสามารถน้อยกว่าเพื่อตรวจสอบความต้านทานต่อการโจมตี
- สิทธิ์การเข้าถึงแบบละเอียด: วางแผนสิทธิ์ระดับโทเค็นสำหรับบริการ Supabase เฉพาะ
- เอกสารที่ปรับปรุงแล้ว: เพิ่มข้อจำกัดความรับผิดชอบด้านความปลอดภัยและเอกสารสร้างความตระหนัก
ผลกระทบด้านความปลอดภัยในวงกว้าง
ช่องโหว่นี้เป็นส่วนหนึ่งของสิ่งที่ผู้เชี่ยวชาญด้านความปลอดภัย Simon Willison เรียกว่า lethal trifecta - การรวมกันที่อันตรายของระบบ AI ที่มีการเข้าถึงข้อมูลส่วนตัว การเปิดรับข้อมูลที่ไม่น่าเชื่อถือ และความสามารถในการขโมยข้อมูล ปัญหานี้ขยายไปไกลกว่าตั๋วสนับสนุนไปยังระบบใดๆ ที่เนื้อหาที่ผู้ใช้สร้างขึ้นอาจถูกประมวลผลโดย AI agent ที่มีการเข้าถึงฐานข้อมูล
ชุมชนด้านความปลอดภัยได้ระบุช่องโหว่ที่คล้ายกันในการใช้งาน database MCP อื่นๆ รวมถึง Neon DB และ MCP server ของ Heroku สิ่งนี้แสดงให้เห็นว่าปัญหาไม่ได้เฉพาะเจาะจงกับ Supabase แต่เป็นปัญหาระบบของวิธีที่ AI agent โต้ตอบกับฐานข้อมูลเมื่อถูกเปิดรับข้อมูลที่ไม่น่าเชื่อถือ
องค์ประกอบของ "Lethal Trifecta"
- การเข้าถึงข้อมูลส่วนตัว: เอเจนต์ AI สามารถอ่านข้อมูลที่ละเอียดอ่อนในฐานข้อมูลได้
- การสัมผัสกับข้อมูลนำเข้าที่ไม่น่าเชื่อถือ: ระบบประมวลผลเนื้อหาที่ผู้ใช้สร้างขึ้น (ตั๋วสนับสนุน ความคิดเห็น ฯลฯ)
- ความสามารถในการขโมยข้อมูล: AI สามารถส่งข้อมูลที่ดึงออกมากลับไปยังผู้โจมตีผ่านช่องทางต่างๆ
ก้าวไปข้างหน้า: โซลูชันระดับสถาปัตยกรรม
ผู้เชี่ยวชาญด้านความปลอดภัยเน้นย้ำว่าโซลูชันที่มีประสิทธิภาพต้องถูกใช้งานในระดับสถาปัตยกรรมมากกว่าการพึ่งพาการลดความเสี่ยงแบบ prompt แนวทางที่แนะนำรวมถึงการใช้สิทธิ์ฐานข้อมูลแบบละเอียด การใช้บริบท AI แยกต่างหากสำหรับการดำเนินการที่แตกต่างกัน และการปฏิบัติต่อ AI agent เป็นศัตรูที่อาจเป็นไปได้เมื่อประมวลผลเนื้อหาที่ผู้ใช้สร้างขึ้น
เหตุการณ์นี้เน้นย้ำถึงความจำเป็นที่สำคัญสำหรับองค์กรในการประเมินผลกระทบด้านความปลอดภัยอย่างระมัดระวังก่อนเชื่อมต่อ AI agent กับระบบที่ใช้งานจริง ดังที่นักวิจัยด้านความปลอดภัยคนหนึ่งกล่าวไว้ เครื่องมือ AI รุ่นปัจจุบันอาจขาดความสามารถพื้นฐานในการประมวลผลข้อมูลที่ไม่น่าเชื่อถือได้อย่างปลอดภัยในขณะที่ยังคงการเข้าถึงทรัพยากรที่สำคัญ
ช่องโหว่นี้ทำหน้าที่เป็นสัญญาณเตือนสำหรับระบบนิเวศการรวม AI ที่เติบโตอย่างรวดเร็ว แสดงให้เห็นว่าหลักการความปลอดภัยแบบดั้งเดิมยังคงมีความสำคัญแม้ในขณะที่เทคโนโลยีใหม่ๆ เกิดขึ้น